功能自动化测试实施流程与规范

一 目的：基于Selenium 自动化回归测试解决方案。

Selenium简介：ThroughtWorks 公司一个强大的开源 Web 功能测试工具系列，包括Selenium-IDE、Selenium-RC、Selenium-Webdriver 以及 Selenium-Grid。

自动化实施目的 ：

自动执行重复工作较大回归测试。
Web 系统在不同环境下的兼容性测试（多操作系统和多浏览器）。
与 CI 服务集成，作为持续集成实践的一部分。

二 Selenium自动化实施方案简介

实施方案：

自动化测试框架：Selenium 2（WebDriver）+ Page Object

用例管理系统：Testlink/TD

脚本开发：Java 语言

脚本生成方式：手工编写 + IDE 辅助元素识别

脚本运行方式：Testng 测试框架调度

测试数据：Testng 数据驱动

脚本回放：IE/Chrome/FireFox

自运行方案：Ant 批处理/CI 调度（Jenkins）

测试报告：Testng Report

工具：Eclipse + Selenium + testng + ant + Jenkins

Page Object设计模式简介 ：Page Object 将测试对象及单个的测试步骤封装在每个 Page 对象中，以 page 为单位进行管理。在 Web 应用程序的用户界面中存在测试交互。Page Object 可以简单的用测试代码将页面对象模型化，从而减少了重复的代码量，如果 UI 发生变化，只需要在统一的地方变更。

方案特性：

支持多环境下的兼容性测试
支持数据驱动（DDT）
对象库的分离和管理
自动化测试脚本的组织和管理
 脚本的可重用（团队）和可配置

灵活的断言机制
便捷的后台服务
直观性的测试报告

支持与 CI 集成
强大的场景恢复

方案适用的情形：

产品型项目

增量式开发、持续集成项目

能够自动编译、自动发布的系统

回归测试

多次重复、机械性动作

需要频繁运行测试

将烦琐的任务转化为自动化测试

方案不适用的情形：

定制型项目(一次性的)

项目周期很短的项目

业务规则复杂的对象

美观、声音、易用性测试

测试很少运行

软件不稳定

涉及物理交互

三 自动化测试环境：

开发环境 
 硬件环境 
普通开发用的 PC 即可。
软件环境 
 Windows XP/7
 Eclipse 4.2（含 testng 插件）
 JDK 1.6

testng 6.7.0
selenium server 2.25 或以上
IE 8 或 9（含 IEDriver）、Firefox（含 firebug 插件）

运行环境 
硬件环境 
PC Server
双核或四

80G 以上磁盘空间
100M 或以上以太网卡
软件环境 
Windows（除 Win8）、Linux
JRE 1.6
testng 6.7.0
selenium server 2.25 或以上
ant 1.8.4
 IE（不支持 IE10，含 IEDriver）、Firefox、Google Chrome（含 Chr

四 自动化测试实施流程：

前置条件：软件需求变动不频繁。项目周期足够长。自动化测试脚本可重复使用。另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

流程图：

主要过程描述：

可行性分析 ：在进行项目自动化测试之前，第一步就是要确认其可行性性，是否可以实行测试自动化。

如果出现其中任何一种，自动化测试工作都是不应该展开的，项目常见不可行因素如下：

项目时间紧迫 

项目需求变幻无常

项目周期短

自动化测试工具对系统的有效性：举个例，假设你所在的公司购买了一款商业化的自动化测试工具，项目系统中全部是一些 Java 控件，但是测试工具自带的插件中又不包含 Java 控件的识别插件，那么此时就算拥有这款自动化测试工具，但由于无法有效地识别到项目中的控件，所以，对于项目来说是毫无作用的。

抽样 demo 分析 ：

把 demo （是一个实体案例）看成更深层次的可行性分析，一旦通过了抽样 demo 分析，自动化测试就可以展开了。关于 demo 的选取，一般直接选择冒烟测试用例（大冒烟）写成测试脚本后执行，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行到即可。

测试需求分析 :

为下一阶段定制具体计划打下基础。测试需求其实就是测试目标，也可看做测试自动化的功能点，也就是自动化测试工程师想完成的任务。优先考虑实现正向的测试用例后再去实现反向的测试用例，而且反向的测试用例大多都是需要进行分
析然后筛选出来的，因为反向的测试用例实在太多了。自动化测试是不需要也没有必要做到 100%覆盖率的。所以，在测试需求分析这个阶段，确定测试覆盖率以及自动化测试粒度、测试用例上的筛选等都是重点工作。

制定测试计划 :

与以前的测试计划过程一致，只是在原来的测试计划中，添加对项目实施自动化测
试所需的资源、测试范围、测试进度的描述。

自动化测试设计 :

框架设计、开发与搭建

测试用例设计 :筛选手工测试用例的过程。转换手工测试用例的过程。新增&补充自动化测试用例的过程。

 

测试脚本开发 :

根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》，录制、调试、编写各个功能点的自动化测试脚本，并添加检查点，进行参数化。该过程还需要编写数据文件处理脚本、日志文件处理脚本、数据库处理脚本、公共检查点处理脚本等等。该过程的产出物是各个功能点的自动化测试脚本和其他公共处理脚本。

需要注意的是：自动化测试脚本代码必须严谨、规范。
自动化测试脚本需参照自动化测试用例开发，测试用例即是开发参照物。
尽一切可能使自动化测试脚本更智能、高效、稳定、复用性高。

开发过程多利用插桩+断点，检查业务组件是否存在缺陷或代码是否存在漏洞。
脚本开发完毕后，至少运行成功 3 次以上，方可认为脚本已经没有问题。
必须使用一款优秀的代码版本管理软件来管理好每一个测试版本的自动化测试
脚本，这也是自动化测试项目中非常重要的环节。

自动化测试数据设计 ：根据《软件需求规格说明书》、《自动化测试用例》设计出对各个功能点和相关业务规则进行测试的输入数据和预期输出，填写入对应的数据文件中。该过程的产出物是各个功能点的数据文件。

自动化测试执行：测试脚本开发完成后就要对测试脚本进行管理，执行；测试脚本的执行主要包含如下内容：

测试环境的管理配置
测试脚本配置
测试脚本的执行
测试异常中断处理和恢复

自动化测试结果分析：

对测试结果文件中报告错误的记录进行分析，如果确实是由于被测系统的缺陷导致，则提交缺陷报告。对自动化测试的结果进行总结，分析系统存在的问题，提交《测试报告》。

自动化测试脚本维护：如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护，以适应变更后的系统。

脚本开发流程简述 ：

1. 安装配置开发环境和工具
   安装配置 JDK
   安装 Eclipse
   安装 testng 插件
   新建 testng 测试项目
  导入需要的 jar 包和 driver 驱动
2. 制定手工 case
3. 脚本录制、对象识别
4. 编写公共方法和公共 case
5. Case 分层编码实现

6. 加入适当的断言覆盖手工 case 的验证点
7. 调试回放运行

自动化测试项目“标配” ：自动化测试组长、测试开发工程师、用例设计工程师、脚本开发工程师、配置管理

五 自动化测试实施规范 ：

用例选取标准：该测试是否包含核心业务流程
该测试是否覆盖了最关键的特性路径
该测试的重复执行率较高
该测试是否定期运行，比如，经常重用，还作为回归测试或构建测试的一部分
对于手动运行这个测试是否太昂贵而不可能或是禁止的，如并行，渗透，耐力测
试，内存泄漏等

是否有对时间敏感的组件而必须自动化
该测试是否覆盖了最复杂的领域（通常是最有可能出错的领域）

使用相同步骤时，该测试是否需要许多数据组合
期望的结果是常数吗，比如每一次测试时都不会改变或不同？即使结果不同，是
否可参数化（结果可预知）或可测出一个与期望结果的可接受的百分比（结果不
可预知

该测试是否非常耗时，如对成百上千的输出进行预期的分析
该测试是否运行在稳定的应用上
运行速度很慢的 case 不应该选取为自动化实现
自动化测试用例是否包含了手工测试的基线用例集
自动化的用例以正向用例为主，辅以个别重要的反向用例

验证点规范：

验证点选取标准：

要选取能覆盖当前 case 本质的主要验证点
尽量选取前台的明文验证点，即验证点在页面上可见，方便获取
前台无法验证的 case，需要去后台验证的情况下，需提供查询的表名与字段以及验证关系
新增类 case 的验证点需新增保存成功后重新查询比对查询结果得出
修改类 case 的验证点需修改保存保存成功后重新查询比对查询结果得出
数据计算类的验证点需要在数据驱动中提供预期结果
页面跳转类的验证点可以选 page title 或判断页面上比较特殊的元素的存在性

脚本断言机制：

断言是 testng 中提供的一种判断验证点是否通过的机制，可以添加在业务层即 business 层也可以添加到 case 层，可根据 case 的实际业务选择断言的位置。

Assert.assertEquals(expected, actual);：期望值与实际值比较
 Assert.assertTrue(Boolean expression)：布尔表达式即为验证点的预期值与实际值的关系
Assert.fail("failing message")：对于可预知失败的验证点

待测系统开发规范：

元素的 ID 名有意义且尽量不要使用动态 ID
一个页面上的所有元素的 name 名尽量保证不重复
日期选择控件需要支持手动输入
文件上传控件的路径需要支持手动输入
尽量少的使用弹出页面
尽量避免使用 js 监听浏览器的关闭事件，会导致浏览器无法正常关闭

自动化脚本编码规范：

基本信息 ：在每个脚本模块的最上面，必须写上脚本运行的软件和硬件环境（如 IE 版本、框架版本、数据库版本等）、项目名称、脚本编写人（使用英文名或中文拼音缩写）、脚本创建时间、脚本修改时间、修改说明、输入参数、输出参数、脚本描述等。

常量命名规范：常量的命名应该全部用大写，使用"_"作为单词间的分隔符，单词尽量使用全名称，
如，final int MY_SCORE = 100;。
另外，对常量的声明必须带上类型。

 变量命名规范 ：变量命名应该简单，应尽量使用缩写。如果是一般的值类型（如 int、String），则直接使用变量用途命名。尽量使用全名，例如，String name；如果是一般的临时性变量定义，应该尽可能地简单，例如，int i；如果名称由多个单词组成，则取每个单词的首字母，如 EntityManager 缩写为 em，ProcedureManager 缩写为 pm；如果名称由一个单词组成，则对单词进行分段取首字母，如 Entity 缩写为 et。缩写应该控制在 3 个字母以内，且尽量清晰。

参数命名规范 ：参数命名的原则是全部用小写，如果参数包括两个或两个以上的单词时，首单词字
母小写，其他单词首字母大写，如 stepName、stepDescription。

方法命名规范：方法表示的是一个动作，所以它的结构应该是动词+名词，动词必须小写，后面的名称首字母大写，如 getMaterialCode。函数命名尽量不要使用缩写，而且它的名称应该使人一目了然，能够从名称就知道这个函数的功能，不要使用无意义的函数名称。当函数名称不足以表达其功能时，应使用在函数头部加上让调用者足够明白的注释。

代码注释规范：注释务必做到准确简洁，能够充分表达代码实现的功能。

空行：空行是区分代码块与块的间隔，在函数之间必须加上空行；而在函数内部，变量声明块和实现块（实现块指除变量声明外的其他代码）要使用空行来间隔，实现块的内部，通过空行来标识一个功能段。

缩进 
必须严格执行缩进，变量声明块不缩进，实现块必须保证全部缩进（不可能有实现块是行首对齐的）；对于基本的控制结构来说，必须要有缩进，如 IF、DO、FOR、WHILE块。

续行 
对于过长的语句来说，必须使用续行，续行的位置要有明显意义，例如，sql ="SELECT [code]，[name] FROM [Person]"_&"WHERE [code] LIKE'001%'"。另外，还要通过管理对象库来提高代码的可读性，通过修改命名来达到更加易读的效果。对于使用比较频繁的代码块来说，最好将其写成函数，并尽量将功能复杂的大函数拆分成小函数。
检查点检查 
每个测试脚本都应该有相应的检查点及对应的检查结果输出。

五 结构分层规范 
Control 层 
框架底层，定义web page的基本元素类型（含元素识别、属性、方法），勿轻易修改。
Util 层 
对 selenium driver方法的 重定义 与 封 装 （ Selenium2Proxy） 、 自 定 义 通 用 方 法（CommonMethord）、公共case方法（CommonCase），第三方服务等，可根据需要自行添加
Page 层 
以页面为单位，定义页面上的元素识别与基本动作（赋值、点击等），一个页面对应一个java文件

Business 层 
一个页面对应一个java文件，定义该页面上的所有基本事务（查询、新增、删除等），事务是page层所定义元素的动作组合
Case 层 
Case实现层，是business层、page层所定义对象的组合操作，并加入适当的断言（验证点）。
Case组织方式请参看“用例组织规范”
Data 层 
数据驱动层，定义case层中的测试方法所用到的数据
Config 层 
配置定义，含浏览器驱动配置、配置文件读取等，勿轻易修改。

用例组织规范：

如项目 case 总数量不多（1500 以内），为了提高回放通过率，建议使用低耦合的方式组织 case，即每个测试方法结束后将浏览器关闭。如果 case 数量较多，为了保证一次自动化的构建所占用的时间不会特别长以至于无法接受，建议将 case 改造为高耦合的方式 ，即每次启动浏览器后完成一系列相关的 case 执行后再关闭浏览器，case 执行顺序通过 dependsOnMethods 实现。构建两个测试基类，可实现在一个自动化构建中两种方式并存。

对象识别规范 ：

优先选择 By.id,By.name,By.classname
优先选择当前页面中不重名的属性
如遇重名属性，使用 List 返回多个元素，使用时根据元素在 List 中的位置调用
极其难以定位的元素可以考虑使用 xpath 定位

脚本回放规范 ：

Selenium 脚本回放由快到慢：htmlunit>chrome>firefox>ie。

Htmlunit 回放时无界面，对 js 支持不是很好，不建议使用
本地开发时选择适合自己的回放浏览器（不建议使用 IE6，推荐 IE8 和Chrome）
执行机批量执行选择可兼容的最快的浏览器进行回放
浏览器兼容性测试时选择需求规定的浏览器回放
建议控制每个测试方法的回放速度在 60S 之内，通过优化测试脚本实现

为防止因某个测试方法卡住很长时间影响整个自动化构建的持续运行，所有测试方法应该加上超时限制，如：timeOut = 120000(ms)，时间长短根据当前
case 的复杂程度人为判定
为提高元素识别的准确率和稳定性，自动化测试回放时浏览器默认最大化处理
为提高元素识别的准确率与识别速度，自动化测试回放时需设置全局的元素默
认等待时间，implicitlyWait(10, TimeUnit.SECONDS)，建议 10S

六 其他注意项

1. 注意根据项目特点选取 case 的组织形式，如项目 case 较多，建议采用高耦合
的方式组织 case，以提高回放执行的效率
2. 善用 aftermethod 和 afterclass 方法，对资源进行回收，避免脚本执行机器的
资源被大量占用而引起当机（常见于浏览器和 driver 没有回收）
3. 避免死脚本的出现，如数据硬编码，唯一键冲突，无效数据驱动等
4. 断言失败会导致 case 中断执行，故不是每个步骤都需要加入验证点
5. 已知处理表格时，全局的元素等待会造成表格遍历的性能问题，故处理表格之
前需要将全局元素等待时间归 0，表格处理完毕后再还原