自动化测试流程
1. 合理的自动化测试切入点。项目只有在经历了完整的系统测试后才算具备了基本的引入测试自动化的条件。
2. 测试自动化分析
a) 可行性分析(项目时间紧迫,项目需求变幻无常,项目周期短,自动化测试工具对系统的有效性)
b) 抽样demo分析。利用demo对整个项目是否可以进行自动化测试有一个总体的把握。关于demo的选取,一般直接选择冒烟测试用例(大冒烟)写成测试脚本后执行,检查脚本是否能够成功运行通过,已设计的测试点是否全部执行到即可。
c) 测试需求分析。测试需求其实就是测试目标,也可看做测试自动化的功能点,也就是自动化测试工程师想完成的任务。需求大体的分为正向和反向,优先实现正向的测试用例然后实现反向的测试用例。
注:“正向”测试用例就是正常的业务操作流,几乎没有什么非正常情况操作融入在其中。反之,“反向”测试用例就是异常的业务操作流。
3. 测试计划定制
4. 自动化测试设计阶段
(1) 自动化测试框架设计、开发与搭建。
自动化测试框架”:
● 自动化测试框架是能保证测试的分布执行,脚本模块化,数据驱动,日志分析,错误截图,报表回收,共享对象库,公共函数库,环境配置,统一设计模式,异常处理,场景恢复等的一个无人值守的,针对每个独立项目的测试框架。
● 自动化测试框架就是一个“舞台”,可以让所有自动化测试工程师在“舞台”上表演,没有这个“舞台”,自动化测试工程师就只能单干,在一段时间内是可以的,但是长期发展后会遇到很大的瓶颈,这时候就需要自动化测试框架来突破瓶颈
(2) 自动化测试用例设计三部曲。
● 筛选手工测试用例的过程。首先要根据测试需求分析阶段得出的“分析结果”筛选出所有要被“测试自动化”的手工测试用例。在全部筛选完毕后,再分成两部分,一部分是可以直接二次复用的手工测试用例,不要客气,直接拿来即可。另外一部分则要经历改造这个过程。
● 转换手工测试用例的过程。一般转换要素无非两种,一种就是测试用例的格式和规则,另一种就是优化自动化测试业务流程。
● 新增&补充自动化测试用例的过程。
5. 测试脚本设计与开发
测试脚本大致可划分为5种:
(1)线性脚本:通过录制直接产生的线性执行的脚本。
(2)结构化脚本:具有顺序、循环、分支等结构的脚本。
(3)可共享脚本:可以被多个测试用例使用,被其他脚本调用的脚本。
(4)数据驱动脚本:测试数据和业务流程控制分离的脚本,通过读入数据文件来驱动流程进行的脚本。
(5)关键字驱动脚本:脚本、数据、业务分离,数据和关键字在不同的数据表中,通过关键字来驱动测试业务逻辑。关键字驱动脚本的特点是,它看起来更像描述一个测试用例在做什么,而不是如何做。
测试脚本开发要点:
● 自动化测试脚本代码必须严谨、规范。
● 自动化测试脚本是参照自动化测试用例开发出来的,测试用例即是开发参照物。
● 发挥自己的想象尽一切可能使自动化测试脚本更智能、高效、稳定、复用性高。
● 开发过程中多利用程序插桩+断点,检查业务组件是否存在缺陷或代码是否存在漏洞。
● 自动化测试脚本开发完毕后,至少运行成功3次以上,方可认为脚本已经没有问题。
6. 自动化测试执行
所有的自动化测试脚本全部开发完毕并发布后会进入合并联调阶段
(1) 无人值守的测试。
● 环境搭建、部署与配置。
● 自动化测试用例和测试脚本互相绑定。
● 自动化测试用例执行顺序排列与组合。
(2) 异常处理和场景恢复。为的是避免自动化测试无端端停止,拖延测试进程
(3) 一个自动化测试执行实例。
7. 提交自动化测试产物(执行情况、测试结果、分析报表、测试报告、质量情况等)
测试脚本维护。