当前位置:文档之家› 自动化测试规范V1.1..

自动化测试规范V1.1..

福建创昱达信息技术有限公司自动化测试规范V1.1
2022年4月25日
文档编号:
文档信息
分发单位
版本历史
版权声明
本文档模板由福建创昱达测试部负责制定,具体章节内容由福建创昱达测试部相关编写人员负责解释。

目录
1.自动化主流程 (4)
2.自动化测试可行性分析 (6)
2.1目标: (6)
2.2角色: (6)
2.3工作内容 (6)
3.自动化测试需求分析 (8)
3.1目标: (8)
3.2角色 (8)
3.3工作内容 (8)
4.自动化测试计划制定 (10)
4.1目标: (10)
4.2角色: (10)
4.3工作内容: (10)
5.自动化测试设计 (11)
5.1目标: (11)
5.2角色: (11)
5.3工作内容: (11)
6.自动化测试执行 (12)
6.1目标: (12)
6.2角色: (12)
6.3工作内容: (12)
7.自动化测试分析 (13)
7.1目标: (13)
7.2角色: (13)
7.3工作内容: (13)
8.自动化测试维护(需求变更) (14)
8.1目标: (14)
8.2角色: (14)
8.3工作内容: (14)
1.自动化主流程图示:
2.自动化测试可行性分析
2.1 目标:
对系统进自动化可行性分析,确认或否决自动化工作的开展。

如确认开展自动化,并进行风险评估。

2.2 角色:
测试管理部、自动化组长、手工组组长(项目负责人)、开发组组长(项目负责人)
2.3 工作内容
(1)讨论系统开展自动化工作的可行性:
符合自动化测试开展的几种情况:
➢产品型项目(项目周期长、需求变更有计划性、而且频率不高)
产品型的项目,新版本是在旧版本的基础上进行改进,功能变不大的项目,但项
目的新老功能都必须重复的测试。

➢回归测试
回归测试是自动化测试的强项,它能够很好的验证你是否引入了新的缺陷,老的
缺陷是否修改过来了。

在某种程度上可以把自动化测试工具叫做回归测试工具。

➢机械并频繁的测试
每次需要输入相同、大量的一些数据,并且在一个项目中运行的周期比较长。

但有一些交互性比较强(业务逻辑较复杂),需要人工干预的操作,就不要指望
通过自动化测试来完成了。

例如,银保通交行前置机测试。

➢资源丰富(人员)
众所周知,自动化工作相对比较耗人力,开发脚本的时间与调试脚本的时间比例
能达到1:1、甚至1:2,如人力与机器大批量工作无法权衡则只能放弃自动化了。

(2)明确手工测试的需求分析、测试设计和测试案例是否适合于自动化测试的需要:
如涉及到系统联调类的用例、不同系统接口之间不适宜(注意:非绝对)做自动化。

(3)自动化测试应达到自动化率目标多少,如覆盖率达到50%
(4)与开发负责人沟通:
➢获取相关开发信息:如相关界面设计文档、详细设计说明书等等
如,我们用Selenium开源工作做自动化,完全可以在开发设计完界面,实现脚
本前或进行中将定位Element的属性(如id、xpath等)添加到相关数据驱动
文件中。

➢相关开发人员支持
➢在开发程序上达成一些共识,比如在界面设计对每个空间都添加一个id(html id),提高对象识别的准确性,方便自动化测试工作顺利、高效开展
(5)风险评估:
主要集中在环境、技术实现、工具、人员
➢环境:如稳定性
➢技术:技术上实现时候有难度,如终端内部的对象难以抓取等
➢工具:选择合适的工具,非开源工具(如QTP)或者开源工具(如Selenium、Watir等)
➢人员:时候有足够的人力、是否需要培训
(6)输出《XXX系统自动化可行性分析报告.doc》
3.自动化测试需求分析
3.1目标:
完成自动化需求分析
3.2角色
自动化组长、自动化测试工程师、手工组组长、手工组测试工程师
3.3工作内容
3.3.1业务需求
步骤:
(1)整理《系统业务流梳理表.xls》
根据业务需求梳理出业务流表,主要字段:
业务名称、子业务名称、业务步骤、步骤分支、详细步骤
截图:
(2)案例转化
对系统进行模块划分,然后根据手工用例库转换(筛选)出可以做自动化的用例,并进行优先级、阶段划分(任务量比较大,分1期、2期等完成),输出《XXX系统自动化用例库》
参考示例文档:《寿险2012版保全服务GPS系统业务流梳理表_V1.0.xls》
(3)自动化案例库评审(侧重转换率和优先级划分)
(4)根据不同优先级分阶段实现系统的自动化
3.3.2硬件需求
工具:测试远程机、测试工具等时候准备完毕。

环境:环境是否配置完毕(如GT配置、数据库配置等)
3.3.3技术需求(如读写数据库、读写Excel、读写txt、终端控制、状态判断等)
➢培训自动化测试人员相关系统业务知识
➢培训自动化测试人员相关自动化技能
➢根据已有技术实现来优化筛选用例(不能实现的或实现较困难的用例不采用自动化方式实现)
3.3.4数据需求(也叫数据准备)
➢数据字典
➢数据库的pdm和数据库sql
➢造数脚本是否已实现
3.3.5人员需求
➢手工组业务老师支持
➢合适自动化人员开展自动化。

4.自动化测试计划制定
4.1 目标:
任务量化,指定详细的测试计划
4.2 角色:
自动化组组长
4.3 工作内容:
(1)根据自动化需求分析输出的《系统自动化用例库》的用例以及用例的优先级,确定自动化测试的执行顺序
(2)根据不同阶段的任务给不同的自动化测试人员划分工作量
(3)标明工量、开始时间、结束时间、负责人等,最终输出输出《XXX系统自动化测试计划.mpp》
参考示例文档:《GPS系统自动化测试计划V1.2.mpp》
5.自动化测试设计
5.1 目标:
开发脚本,实现系统自动化
5.2 角色:
自动化测试工程师
5.3 工作内容:
(1)编写规范:
➢脚本重复利用率高
➢代码规范(变量定义、注释习惯)
➢可维护性高
(2)系统模块划分:公共模块、子组件、正常模块(3)脚本开发
(4)测试管理器开发(数据参数化)
(5)脚本调试
6.自动化测试执行6.1目标:
运行自动化测试, 实现自动回归测试的目标6.2 角色:
自动化测试工程师
6.3 工作内容:
(1)脚本执行
7.自动化测试分析
7.1目标:
分析自动化测试结果、总结自动化测试报告
7.2 角色:
自动化组长、手工组组长、自动化测试工程师
7.3 工作内容:
(1)缺陷分析
➢手工验证是否可重现
➢跟手工组老师沟通,判断缺陷是否符合标准(非配置、环境原因导致)➢输出《XXX系统自动化缺陷报告.xls》(同自动化案例库一个文档)(2)是否达到自动化覆盖率要求
(3)优化脚本和测试管理器
对脚本实现方法进行优化。

(4)输出《XXX系统自动化测试报告.doc》
8.自动化测试维护(需求变更)8.1 目标:
维护脚本,覆盖新需求变更用例。

8.2 角色:
自动化组组长、自动化测试工程师
8.3 工作内容:
(1)分析新需求是否符合实现自动化条件
(2)新需求案例转化的自动化用例库评审
(3)开发或维护脚本。

相关主题