自动化测试规范V1..doc

福建XX信息技术有限公司 自动化测试规范V1.1 2015年3月20日  文档编号： 文档信息 文件状态： [√]草稿 [ ]正式发布 [ ]正在修改 文件标识： 自动化测试规范V1.1 当前版本： V1.1 作者： 张振江 完成日期： 2015.01.20 分发单位 From自 部门 职务 行动 日期 Email / 电话 张振江 创昱达/测试部 初级测试工程师 发送 2015-01-20 zhangzhenjiang217@126.com 给To 部门 职务 行动 截止日期 Email / 电话 　 　 　 　 　 　 　 　 　 　 　 　 版本历史 版本编号 版本日期 修订人 修改描述 文件名 1.0　张振江 首次编写 自动化测试规范V1.0.doc 1.1 张振江 增加 自动化测试规范V1.1.doc 　 　 　 　 　 版权声明 本文档模板由福建创昱达测试部负责制定，具体章节内容由福建创昱达测试部相关编写人员负责解释。  目 录 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:2，如人力与机器大批量工作无法权衡则只能放弃自动化了。 明确手工测试的需求分析、测试设计和测试案例是否适合于自动化测试的需要： 如涉及到系统联调类的用例、不同系统接口之间不适宜（注意：非绝对）做自动化。 自动化测试应达到自动化率目标多少，如覆盖率达到50% 与开发负责人沟通： 获取相关开发信息：如相关界面设计文档、详细设计说明书等等 如，我们用Selenium开源工作做自动化，完全可以在开发设计完界面，实现脚本前或进行中 将定位Element的属性（如id、xpath等）添加到相关数据驱动文件中。 相关开发人员支持 在开发程序上达成一些共识，比如在界面设计对每个空间都添加一个id(html id)，提高对象识别的准确性，方便自动化测试工作顺利、高效开展 风险评估： 主要集中在环境、技术实现、工具、人员 环境：如稳定性 技术：技术上实现时候有难度，如终端内部的对象难以抓取等 工具：选择合适的工具，非开源工具（如QTP） 或者 开源工具（如Selenium、Watir等） 人员：时候有足够的人力、是否需要培训 输出《XXX系统自动化可行性分析报告.doc》 3.自动化测试需求分析 目标： 完成自动化需求分析 角色 自动化组长、自动化测试工程师、手工组组长、手工组测试工程师 工作内容 业务需求 步骤： 整理《系统业务流梳理表.xls》 根据业务需求梳理出业务流表，主要字段： 业务名称、子业务名称、业务步骤、步骤分支、详细步骤 截图： 案例转化 对系统进行模块划分，然后根据手工用例库转换（筛选）出可以做自动化的用例，并进行优先级、阶段划分（任务量比较大，