自动化测试实施流程 .pdf

⾃动化测试实施流程 在上篇⽂章中，我们已经介绍过Selenium的⼀些基础知识，以及是否能够开展⾃动化测试的情形，在这篇⽂章中，我们将主要介绍⾃动 化测试的实施流程。 1、⾃动化测试流程图 2、主要过程描述 2.1、⾃动化测试的切⼊点 开展⾃动化测试的时间点很关键，需要在系统已经过多版本的系统测试，达到稳定之后。 2.2、可⾏性分析 在进⾏项⽬⾃动化测试之前，第⼀步就是要确认其可⾏性，是否可以实⾏测试⾃动化。如果项⽬时间紧迫、项⽬周期短、项⽬需求变幻⽆ 常则建议和上级领导商议，不要开展⾃动化测试。想要开展⾃动化测试，还是应该遵循以下⼏个前提条件： 软件需求变动不频繁 项⽬周期⾜够长 ⾃动化测试脚本可重复使⽤ 在这个阶段应该产出《可⾏性分析报告》。 2.3、抽样 demo 分析 通过可⾏性分析后，接下来需要做⼀个demo ，等待 demo 完成后，可以再次通过分析⾃动化测试⼯作能否顺利地开展下去，因为 demo 已经是⼀个实体案例，所以，可以完全通过透析 demo 来发现是否存在技术上的致命问题。通常在 demo 完成之后，有经验的⾃动 化测试⼯程师或组长就能对这个项⽬的⾃动化测试⼯作有⼀个⼤体的把握了。⼀旦通过了抽样 demo 分析，⾃动化测试就可以展开了。关 于 demo 的选取，⼀般直接选择冒烟测试⽤例（⼤冒烟）写成测试脚本后执⾏，检查脚本是否能够成功运⾏通过，已设计的测试点是否全 部执⾏到即可。 2.4、 测试需求分析 到了测试需求分析这⼀步，分析的就不再是能否在项⽬中引⼊测试⾃动化了，⽽是在为下⼀阶段制定具体计划打下基础。测试需求其实就 是测试⽬标，也可以看做是⾃动化测试⼯程师所要完成的新的功能点，需要分析项⽬中具体哪些测试需求（功能点）准备进⾏⾃动化测试。 ⼀条测试需求可以包含多条 ⾃动化测试⽤例，通过测试需求分析来判定项⽬中测试⾃动化要做到什么程度。如在⾃动化测试⽤例的设计上， ⼤体是以正向、反向划分的，⼀般在⾃动化测试中，优先考虑实现正向的测试⽤例后再去实现反向的测试⽤例，⽽且反向的测试⽤例⼤多都 是需要进⾏分析然后筛选出来的，因为反向的测试⽤例实在太多了。我们知道，⾃动化测试是不需要也没有必要做到 100%覆盖率的。所 以，在测试需求分析这个阶段，确定测试覆盖率以及 ⾃动化测试粒度、测试⽤例上的筛选等都是重点⼯作。 2.5、制定测试计划 在经过了测试需求分析阶段后，项⽬ PM 和 ⾃动化测试组长就该正式起草正式⽅案了。 与以前的测试计划过程⼀致，只是在原来的测试 计划中，添加对项⽬实施 ⾃动化测试所需的资源、测试范围、测试进度的描述。该过程产出物为 《测试计划》。 2.6、⾃动化测试设计 框架设计、开发与搭建 ⾃动化测试框架是能保证测试的分布执⾏，脚本模块化,数据驱动， ⽇志分析，错误截图，报表回收,共享对象库，公共函数库，环境配 置，统⼀设计模式，异常处理,场景恢复等的⼀个⽆⼈值守的，针对每个独⽴项⽬的测试框架。 2.7、测试⽤例设计 ⾃动化测试流程其实跟⼿⼯测试流程差不太多，要先编写测试⽤例，只是被叫作⾃动化测试⽤例⽽已。先设计好 ⾃动化测试⽤例，再严格 根据设计完成的测试⽤例编写测试脚本，这是⼀种规律、⼀个过程。此过程产出物为 《⾃动化测试⽤例》。 ⾃动化测试⽤例设计和⼿⼯测试⽤例设计是有明显区别的，⼿⼯测试⽤例是从⽆到有的过程，⽽⾃动化测试⽤例不是的。⾃动化测试⽤例 是有参考物的，它就是⼿⼯测试⽤例。它有时候可以直接拿来⽤、有时候需要稍加修改，在此把整个⾃动化测试⽤例设计过程分为 3 步： 筛选⼿⼯测试⽤例的过程。 转换⼿⼯测试⽤例的过程。⼀般转换要素⽆⾮两种，⼀种就是测试⽤例的格式和规则，另⼀种就是优化⾃动化测试业务流程。⾃动化测试 业务流程和⼿⼯测。试业务流程还是有⼀定区别的，⾃动化测试业务流程更精简、严格。 新增补充 ⾃动化测试⽤例的过程。 2.8、测试脚本开发 根据《软件需求规格说明书》、 《⾃动化测试⽤例》、 《系统原型》，录制、调试、编写各个功能点的⾃动化测试脚本，并添加检查点， 进⾏参数化。该过程还需要编写数据⽂件处理脚本、 ⽇志⽂件处理脚本、数据库处理脚本、公共检查点处理脚本等 等。该过程的产出物是各个功能点的⾃动化测试脚本和其他公共处理脚本。 此过程需要注意的是： ⾃动化测试脚本代码必须严谨、规范。 ⾃动化测试脚本需参照 ⾃动化测试⽤例开发，测试⽤例即是开发参照物。 尽⼀切可能使 ⾃动化测试脚本更智能、⾼效、稳定、复⽤性⾼。 开发过程多利⽤插桩+断