自动化测试规范V1..doc

福建XX信息技术有限公司

2016年5月14日
文档编号:
文档信息
文件状态:
[√]草稿
[ ]正式发布
[ ]正在修改
文件标识:

当前版本:

作者:
张振江
完成日期:

分发单位
From自
部门
职务
行动
日期
Email / 电话
张振江
创昱达/测试部
初级测试工程师
发送
2015-01-20
zhangzhenjiang217@
给To
部门
职务
行动
截止日期
Email / 电话












版本历史
版本编号
版本日期
修订人
修改描述
文件名

20150119
张振江
首次编写


20150121
张振江
增加






版权声明
本文档模板由福建创昱达测试部负责制定,具体章节内容由福建创昱达测试部相关编写人员负责解释。
目录
4
6
目标: 6
角色: 6
工作内容 6
8
目标: 8
角色 8
工作内容 8
10
目标: 10
角色: 10
工作内容: 10
11
目标: 11
角色: 11
工作内容: 11
12
: 12
角色: 12
工作内容: 12
13
: 13
角色: 13
工作内容: 13
(需求变更) 14
目标: 14
角色: 14
工作内容: 14

图示:

目标:
对系统进自动化可行性分析,确认或否决自动化工作的开展。如确认开展自动化,并进行风险评估。
角色:
测试管理部、自动化组长、手工组组长(项目负责人)、开发组组长(项目负责人)
工作内容
讨论系统开展自动化工作的可行性:
符合自动化测试开展的几种情况:
产品型项目(项目周期长、需求变更有计划性、而且频率不高)
产品型的项目,新版本是在旧版本的基础上进行改进,功能变不大的项目,但项目的新老功能都必须重复的测试。
回归测试
回归测试是自动化测试的强项,它能够很好的验证你是否引入了新的缺陷,老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。
机械并频繁的测试
每次需要输入相同、大量的一些数据,并且在一个项目中运行的周期比较长。
但有一些交互性比较强(业务逻辑较复杂),需要人工干预的操作,就不要指望通过自动化测试来完成了。例如,银保通交行前置机测试。
资源丰富(人员)
众所周知,自动化工作相对比较耗人力,开发脚本的时间与调试脚本的时间比例能达到1:1、甚至1:2,如人力与机器大批量工作无法权衡则只能放弃自动化了。
明确手工测试的需求分析、测试设计和测试案例是否适合于自动化测试的需要:
如涉及到系统联调类的用例、不同系统接口之间不适宜(注意:非绝对)做自动化。
自动化测试应达到自动化率目标多少,如覆盖率达到50%
与开发负责人沟通:
获取相关开发信息:如相关界面设计文档、详细设计说明书等等
如,我们用Selenium开源工作做自动化,完全可以在开发设计完界面,实现脚本前或进行中将定位Element的属性(如id、xpath等)添加到相关数据驱动文件中。
相关开发人员支持
在开发程序上达成一些共识,比如在界面设计对每个空间都添加一个id(html id),提高对象识别的准确性,方便自动化测试工作顺利、高效开展
风险评估:
主要集中在环境、技术实现、工具、人员
环境:如稳定性
技术:技术上实现时候有难度,如终端内部的对象难以抓取等
工具:选择合适的工具,非开源工具(如QTP) 或者开源工具(如Selenium、Watir等)
人员:时候有足够的人力、是否需要培训
输出《》

目标:
完成自动化需求分析
角色
自动化组长、自动化测试工程师、手工组组长、手工组测试工程师
工作内容
业务需求
步骤:
整理《》
根据业务需求梳理出业