东莞市主营网站建设服务机构,开源网站 做镜像 如何做,wordpress播放下载,视频制作软件有哪些一、自动化测试的概念 以程序测试程序#xff0c;以代码代替思维#xff0c;以脚本的运行代替手工测试#xff0c;可以大大提高工作测试的效率。
二、自动化测试的优点
1.回归测试更为方便#xff0c;可靠。自动化测试最主要的任务和特点#xff0c;特别是在程序修改比较…一、自动化测试的概念 以程序测试程序以代码代替思维以脚本的运行代替手工测试可以大大提高工作测试的效率。
二、自动化测试的优点
1.回归测试更为方便可靠。自动化测试最主要的任务和特点特别是在程序修改比较频繁的时效果最为明显。由于回归测试的业务流程流程操作和测试用例是预先完全设计好的预期结果也是完全在项目人员掌握之中的将回归测试交给计算机自动运行可以极大提高测试效率缩短回归测试时间。但是上述说的程序修改比较频繁指的是新功能不断加入而老公能的逻辑是不变或者很少变化的不是指整个程序全部或者大批量的改动。因为这样是违反自动化测试原理的。 2.可运行更多更为繁琐的测试且快速高效。自动化测试可以实现在短暂的时间运行更多的test case。我们知道有很大一部分业务功能由于业务逻辑极其繁琐使用手工测试往往耗费大量的时间测试1次2次3次还可以但是如果测试10次以上或者更多耐心会达到极致。 3.可以执行对于手工测试来说相当困难或者根本做不到的测试。比如对于大量用户的测试并发不可能同时让足够多的测试人员同时进行测试但是却可以通过对自动化测试模拟同时有许多用户并发点击某一功能从而达到测试的目的。再比如人工不可能24小时不眠不休进行测试但是计算机则不同休息。当然类似的例子还有很多无法全部列举出来。 4.更好地利用资源使资源的使用更有价值。将方所的任务自动化可以提高准确性和测试人员的积极性将测试技术人员 解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动化测试仅适合手工测试将可自动化测试的测试自动化后可以让测试人员在专注于手工测试部分提高手工测试的效率。 5.自动化测试脚本完全更有信任度。 6.自动化测试脚本完全具有复用性。 7.多个环境下进行测试。我们知道一个系统往往会被要求能够支持各种不同的环境并稳定运行但是这么多不同的环境比如常用浏览器有IE6,IE7,IE8,FireFox等系统有Windows 2003Windows XPWindows VistaWindows 7等甚至还有杀毒软件如卡巴斯基360诺顿等这么多环境的组合如果每一种环境组合我们都需要花人力物力去把功能测试一遍会无形加重负担。
三、适合引入自动化测试的条件
1.项目周期长系统版本不断。如果你目前躲在测试的项目或者系统是属于一个周期比较长的项目的时候可以说的确非常适合引入自动化测试把大量的回归测试托付给测试自动化是一个比较明智的选择。还有一种根据是从系统的版本数得来的曾经测试领域专家有过相关的研讨并最后得出结论一般自动化测试耗费的时间是手工测试的6-10倍所以如果你所在的项目版本数在10个以上纳闷引入测试自动化也同样非常的睿智。 2.需求变更不频繁当项目的需求非常稳定不会进场出现变更的时候此时也很适合引入测试自动化。 3.系统中的测试对象基本可以正常识别。 4.系统中不存在大批量第三方控件。有实际项目经验的人一定会发现无论什么系统B/S架构也好C/S架构也好多少存在一些第三方控件但是如果这些第三方的控件数量不多的话经过详细的计划与评估后完全可以引入测试自动化当然如果第三方控件数量庞大或者刑事种类庞大的话就会带来很多麻烦。 5.需要反复测试。
PS多数对象无法识别以及脚本维护频繁与艰难二者有其一自动化测试注定失败。如果项目中存在大量无法识别的空间这种情况基本是发生在系统中存在大量的第三方控件或者项目中没有获得相应的对象识别插件是没有办法写出自动化测试脚本的。当然对象的识别不一定要靠插件还有其他解决方法比如SDK插件扩展或者让开发人员提供相应的DDL来识别等。 自动化测试工具对系统具有有效性。如果项目时间并不紧迫项目需求也较为稳定项目周期也较长那么可想尝试开发自动化测试脚本必须具备一款匹配的自动化测试工具那么可以是开源的也可以是商业化的甚至是自主研发一款。此时就需要确切的了解这款测试工具是否真的能够应付项目需求假设你所在的公司购买了一款商业化的自动化测试工具项目系统中全部是一些java控件但是测试工具自带的插件中又不包含java控件的识别插件那么此时就算拥有这款自动化测试工具但是由于无法有效的识别到项目中的控件所以对于项目来说是毫无作用的。
四、自动化测试的一个流程
1.合理的自动化测试切入点。通常项目只有在经历了完整的系统测试后才算具备了基本的引入测试自动化的条件。一般也就在这个时间段项目经理与测试经理才会以此定位自动化测试开始筹划与准备的时间点。到目前为止绝大部分的公司都以系统测试完成为标准来作为自动哈UC屙屎的切入点因为在这之前的任何阶段中都不是非常适合做自动化测试。
2.测试自动化分析
1可行性分析
2抽样demo分析 demo已经是一个实体案例所以完全可以通过透析demo来发现是否存在技术上的致命问题通常在demo完成之后有经验的自动化测试工程师或者组长就能对这个项目的自动化测试工作有一个答题的把握了关于demo的选取一般直接选择猫眼测试用例写成测试脚本检查脚本是否能够成功运行通过已设计的测试点是否全部执行到即可。
3测试需求分析 我们需要分析项目中具体哪些测试需求功能点准备进行自动化测试一条测试需要可以包含多条自动化测试用例通过测试需求分析来判定项目中此时自动化要做到什么程度。举个例子在自动化测试用例的设计上大体是一正向反向划分我们知道自动化测试是不需要也没有必要做到100%覆盖率所以在测试需求分析这个阶段确定测试覆盖率以及自动化测试粒度测试用例上筛选等都是重点工作。
PS:正向测试用例就是正常的业务操作流几乎没有什么非正常的情况反向及时一场的业务操作流。
3.测试计划的定制
4.自动化测试设计阶段
1自动化测试框架设计开发与搭建 自动化测试框架对于整个自动化测试项目来说就相当于一个架构这个架构越好功能越强大和使用呢就可以给今后整个自动化测试项目的工作过程带来更多的好处自动化测试框架是能保证测试的分布执行脚本模块化数据驱动日志分析错误截图报表回收共享对象库公共函数库环境配置同一设计模式异常处理场景回复等一个无人值守针对每个肚里项目的测试框架。
2自动化测试用例设计三部曲 .筛选手工测试用例的过程 首先要根据测试需求分析阶段得出的分析结果筛选出所有要被测试自动化的手工测试用例在全部筛选完毕后再分成两部分一部分是可以直接二次复用的手工测试用例不要客气直接拿来即可另外一部分则要经理下一个过程实际上大多数还是需要经历改造的毕竟自动化测试用例的设计方法和手工测试用例的设计方法有点出入哪怕是冒烟测试用例多少也要修改。 .转换手工测试用例的过程 .新增和补充自动化测试用例的过程
5.测试脚本设计与开发 在自动化测试中测试脚本大致可以划分为5种 1线性脚本通过录制直接产生的线性执行的脚本 2结构化脚本具有顺序循环分支等结构的脚本 3可共享脚本可以被多个测试用例使用被其他脚本调用的脚本 4数据驱动脚本测试数据和业务流程控制分离的脚本通过读入数据文件来驱动流程进行的脚本 5关键词驱动脚本脚本数据业务分离数据和关键字在不同的数据表中通过关键字来驱动测试业务逻辑关键字驱动脚本的特点是她看起来更像描述一个测试用例在做什么而不是如何做
6.自动化测试执行 所有的自动化测试脚本全部开发完毕后会进入合并联调阶段脚本联调成功后方能进入这一阶段。 脚本联调是一个关键的时期联调如果不通过是无法进行下一个环节的毕竟都到了这个阶段了已经花了很多工时了 1无人值守的测试 .环境搭建部署与配置 .自动化测试用例和测试脚本互相绑定 .自动化测试用例执行顺序排列与组合 2异常处理和场景恢复 3一个自动化测试执行实例举一个QC自动化测试框架Quality Center 一款集测试解决方案测试流程管理缺陷管理的工具其本身也是一个自动化测试框架的例子我们将测试脚本上传到QC服务器与相应测试用例绑定最后可以生成一个测试集测试集里可以导入之前设计的测试用例如果导入的用例和脚本有过绑定则脚本也随之自动加载到测试集中只需要点击执行按钮即可如果在执行过程中发生意外秦光只要预先设置了各种异常情况及处理应对方式QC就会自动进行处理并把测试场景恢复到预置的状态重新自动执行测试。等测试集中的测试用例全部运行完毕后QC就会显示这些测试用例的运行结果并生成图标然后自动将缺陷提交到服务器中方便测试工程师了解自动化测试运行以及完成的情况乃至发现的缺陷情况。
7.提交自动化测试产物
8.测试脚本维护
五、自动化测试项目的人员构成
1.自动化测试组长自动化测试团队的最高管理拥有发言权
2.高级测试开发工程师:团队中技术最牛的角色通常负责自动化测试框架的设计与搭建负责自动化项目实施过程中各类技术难点的解决负责公共数据的提炼和开发如公共函数库等
3.自动化测试用例设计人员由团队中对业务和手工测试情况最熟悉的人员担当负责自动化测试用例的设计开发工作及今后的测试用例维护工作负责测试脚本的验收工作监督测试脚本业务逻辑时候与设计好的自动化测试用例一致
4.脚本开发人员负责自动测试脚本的设计与开发负责脚本合并联调工作负责后期的脚本维护工作
5.自动化项目库管理人员类似文职人员可以没有代码开发经验负责整个子弟欧诺个话团队中日常工作中的文档变更记录的整理公共对象库管理代码版本管理与公共函数库管理等
自动化测试用例的范围往往是核心业务流程或者重复执行率较高的
自动化测试用例的选择一般以正向为主
不是所有的手工测试用例都可以使用自动化测试来实现的
手工测试用例可以不用回归原点而自动化用例往往是必须的
自动化测试用例和手工测试用例不同不需要每个步骤都写预期结果
感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
