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

《自动化测试规范V1.1..》由会员分享，可在线阅读，更多相关《自动化测试规范V1.1..（14页珍藏版）》请在金锄头文库上搜索。

1、福建创昱达测试部自动化测试规范自动化文档福建创昱达信息技术有限公司自动化测试规范V1.12015年3月20日文档编号： 文档信息文件状态： 草稿 正式发布 正在修改文件标识：自动化测试规范V1.1当前版本：V1.1作者：张振江完成日期：2015.01.20分发单位From自部门职务行动日期Email / 电话张振江创昱达/测试部初级测试工程师发送2015-01-给To 部门职务行动截止日期Email / 电话版本历史版本编号版本日期修订人修改描述文件名1.020150119张振江首次编写自动化测试规范V1.0.doc1.120150121 张振江增加自动化测试规范V1.1.doc版权声明本文档

2、模板由福建创昱达测试部负责制定，具体章节内容由福建创昱达测试部相关编写人员负责解释。目 录1.自动化主流程42.自动化测试可行性分析62.1 目标：62.2 角色：62.3 工作内容63.自动化测试需求分析83.1目标：83.2角色83.3工作内容84.自动化测试计划制定104.1 目标：104.2 角色：104.3 工作内容：105.自动化测试设计115.1 目标：115.2 角色：115.3 工作内容：116.自动化测试执行126.1目标：126.2 角色：126.3 工作内容：127.自动化测试分析137.1目标：137.2 角色：137.3 工作内容：138.自动化测试维护（需求变更）

3、148.1 目标：148.2 角色：148.3 工作内容：141.自动化主流程图示：2.自动化测试可行性分析2.1 目标：对系统进自动化可行性分析，确认或否决自动化工作的开展。如确认开展自动化，并进行风险评估。2.2 角色：测试管理部、自动化组长、手工组组长（项目负责人）、开发组组长（项目负责人）2.3 工作内容（1） 讨论系统开展自动化工作的可行性：符合自动化测试开展的几种情况： 产品型项目（项目周期长、需求变更有计划性、而且频率不高）产品型的项目，新版本是在旧版本的基础上进行改进，功能变不大的项目，但项目的新老功能都必须重复的测试。 回归测试回归测试是自动化测试的强项，它能够很好的验证你是

4、否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。 机械并频繁的测试每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长。但有一些交互性比较强（业务逻辑较复杂），需要人工干预的操作，就不要指望通过自动化测试来完成了。例如，银保通交行前置机测试。 资源丰富（人员）众所周知，自动化工作相对比较耗人力，开发脚本的时间与调试脚本的时间比例能达到1:1、甚至1:2，如人力与机器大批量工作无法权衡则只能放弃自动化了。（2） 明确手工测试的需求分析、测试设计和测试案例是否适合于自动化测试的需要：如涉及到系统联调类的用例、不同系统接口之间不适宜（注意：非

5、绝对）做自动化。（3） 自动化测试应达到自动化率目标多少，如覆盖率达到50%（4） 与开发负责人沟通： 获取相关开发信息：如相关界面设计文档、详细设计说明书等等如，我们用Selenium开源工作做自动化，完全可以在开发设计完界面，实现脚本前或进行中 将定位Element的属性（如id、xpath等）添加到相关数据驱动文件中。 相关开发人员支持 在开发程序上达成一些共识，比如在界面设计对每个空间都添加一个id(html id)，提高对象识别的准确性，方便自动化测试工作顺利、高效开展（5） 风险评估：主要集中在环境、技术实现、工具、人员 环境：如稳定性 技术：技术上实现时候有难度，如终端内部的对象

6、难以抓取等 工具：选择合适的工具，非开源工具（如QTP） 或者 开源工具（如Selenium、Watir等） 人员：时候有足够的人力、是否需要培训（6） 输出XXX系统自动化可行性分析报告.doc3.自动化测试需求分析3.1 目标：完成自动化需求分析3.2 角色自动化组长、自动化测试工程师、手工组组长、手工组测试工程师3.3 工作内容3.3.1 业务需求步骤：（1） 整理系统业务流梳理表.xls根据业务需求梳理出业务流表，主要字段：业务名称、子业务名称、业务步骤、步骤分支、详细步骤截图：（2） 案例转化对系统进行模块划分，然后根据手工用例库转换（筛选）出可以做自动化的用例，并进行优先级、阶段划

7、分（任务量比较大，分1期、2期等完成），输出XXX系统自动化用例库参考示例文档：寿险2012版保全服务GPS系统业务流梳理表_V1.0.xls（3） 自动化案例库评审（侧重转换率和优先级划分）（4） 根据不同优先级分阶段实现系统的自动化3.3.2 硬件需求 工具：测试远程机、测试工具等时候准备完毕。环境：环境是否配置完毕（如GT配置、数据库配置等）3.3.3 技术需求（如 读写数据库、读写Excel、读写txt、终端控制、状态判断等 ） 培训自动化测试人员相关系统业务知识 培训自动化测试人员相关自动化技能 根据已有技术实现 来优化筛选用例（不能实现的或实现较困难的用例不采用自动化方式实现）3.

8、3.4 数据需求（也叫数据准备） 数据字典 数据库的pdm和数据库sql 造数脚本是否已实现3.3.5 人员需求 手工组业务老师支持 合适自动化人员开展自动化。4.自动化测试计划制定4.1 目标：任务量化，指定详细的测试计划4.2 角色：自动化组组长4.3 工作内容：（1） 根据自动化需求分析输出的系统自动化用例库的用例以及用例的优先级，确定自动化测试的执行顺序（2） 根据不同阶段的任务给不同的自动化测试人员划分工作量（3） 标明工量、开始时间、结束时间、负责人等，最终输出输出XXX系统自动化测试计划.mpp参考示例文档：GPS系统自动化测试计划V1.2.mpp5.自动化测试设计5.1 目标：

9、开发脚本，实现系统自动化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系统自动化测试报告.doc8.自动化测试维护（需求变更）8.1 目标：维护脚本，覆盖新需求变更用例。8.2 角色：自动化组组长、自动化测试工程师8.3 工作内容：（1） 分析新需求是否符合实现自动化条件（2） 新需求案例转化的自动化用例库评审（3） 开发或维护脚本第 14页 /共 14页