自动化测试实施规范

   在这篇文章中，主要讲述自动化测试过程中的一些规范性的建议，毕竟好的标准往往能够带来事半功倍的效果，以下仅供大家参考。

1、用例选取标准 

    该测试是否包含核心业务流程 

    该测试是否覆盖了最关键的特性路径 

    该测试的重复执行率较高 

    该测试是否定期运行，比如，经常重用，还作为回归测试或构建测试的一部分 对于手动运行这个测试是否太昂贵而不可能或是禁止的，如并行，渗透，耐力测试，内存泄漏等  。

    是否有对时间敏感的组件而必须自动化  

    该测试是否覆盖了最复杂的领域（通常是最有可能出错的领域） 

    使用相同步骤时，该测试是否需要许多数据组合  

    期望的结果是常数吗，比如每一次测试时都不会改变或不同？即使结果不同，是否可参数化（结果可预知）或可测出一个与期望结果的可接受的百分比（结果不可预知） 

    该测试是否非常耗时，如对成百上千的输出进行预期的分析 

    该测试是否运行在稳定的应用上 

    运行速度很慢的 case 不应该选取为自动化实现 

    自动化测试用例是否包含了手工测试的基线用例集 

    自动化的用例以正向用例为主，辅以个别重要的反向用例

2、对象识别规范

 

    优先选择 By.id,By.name,By.classname 

    优先选择当前页面中不重名的属性 

    如遇重名属性，使用 List 返回多个元素，使用时根据元素在 List 中的位置调用 

    极其难以定位的元素可以考虑使用 xpath 定位 

3、验证点规范 

3.1、验证点选取标准 

    自动化 case 的验证点需满足对手工 case 验证点的覆盖，这里说的手工 case 是专门为自动化测试选取的，验证点也是专门为自动化测试优化选取的，验证点选取原则如下： 

    要选取能覆盖当前 case 本质的主要验证点 

    尽量选取前台的明文验证点，即验证点在页面上可见，方便获取 

    前台无法验证的 case，需要去后台验证的情况下，需提供查询的表名与字段以及验证关系 

    新增类 case 的验证点需新增保存成功后重新查询比对查询结果得出 

    修改类 case 的验证点需修改保存保存成功后重新查询比对查询结果得出 

    数据计算类的验证点需要在数据驱动中提供预期结果 

    页面跳转类的验证点可以选 page title 或判断页面上比较特殊的元素的存在性

3.2、脚本断言机制 

    断言是 testng 中提供的一种判断验证点是否通过的机制，需要说明的是：如果某个断言失败，则当前 case 会自动结束并 fail 掉，不会继续执行当前 case 的后续步骤。断言可以添加在业务层即 business 层也可以添加到 case 层，可根据 case 的实际业务选择断言的位置，  为了代码风格的统一并尽量少的引入 jar 包，断言建议使用 testng 自带断言org.testng.Assert，尽量不要使用 junit 断言。 

    Testng 提供了多种断言方法，详见 Testng API Assert 类。建议优先选用下面的断言： 

    Assert.assertEquals (expected, actual);：期望值与实际值比较  

    Assert.assertTrue (Boolean expression)：布尔表达式即为验证点的预期值与实 际值的关系 

    Assert.fail ("failing message")：对于可预知失败的验证点 

3.3、待测系统开发规范 

此章节主要罗列影响自动化测试编码的几个重要的规范，其余规范请遵循 Java Web应用开发通用编码规范。 

    元素的 ID 名有意义且尽量不要使用动态 ID 

    一个页面上的所有元素的 name 名尽量保证不重复 

    日期选择控件需要支持手动输入 

    文件上传控件的路径需要支持手动输入 

    尽量少的使用弹出页面 

    尽量避免使用 js 监听浏览器的关闭事件，会导致浏览器无法正常关闭 

4、自动化脚本编码规范 

4.1、基本信息 

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

4.2、常量命名规范 

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

4.3、变量命名规范 

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

4.4、参数命名规范 

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

4.5、方法命名规范 

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

4.6、代码注释规范 

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

4.7、空行 

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

4.8、 缩进 

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

4.9、续行 

    对于过长的语句来说，必须使用续行，续行的位置要有明显意义，例如，sql ="SELECT [code]，[name] FROM [Person]"_&"WHERE [code] LIKE'001%'"。 另外，还要通过管理对象库来提高代码的可读性，通过修改命名来达到更加易读的

效果。对于使用比较频繁的代码块来说，最好将其写成函数，并尽量将功能复杂的大函数拆分成小函数。 

4.10、检查点检查 

    每个测试脚本都应该有相应的检查点及对应的检查结果输出。 

5、用例组织规范 

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

低耦合方式组织 case 

    一个模块对应一个 class 

    一个测试对应一个@test，测试方法无需指定执行顺序，默认顺序或者随机顺序执行都可以 

    Case 可自定义属于 Groups，如 groups = { "uitest", "funtest" } 

    浏览器的初始化与全局元素等待在基类的@BeforeMethod 中定义 

    浏览器的关闭与其他资源回收在基类的@AfterMethod 中定义 

    Xml 中配置需要执行的 class 与 groups 即可 

    高耦合方式组织 case 

    一个模块下的有关联的一系列 case 对应一个 class 

    一个测试对应一个@test，测试方法需指定执行顺序，用 dependsOnMethods 实现 

    浏览器的初始化与全局元素等待在基类的@BeforeClass 中定义 

    浏览器的关闭与其他资源回收在基类的@AfterClass 中定义 

    Xml 中配置需要执行的 class 与 groups 即可 

6、结构分层规范 

6.1、Control 层 

    框架底层，定义web page的基本元素类型（含元素识别、属性、方法），勿轻易修改。 

6.2、Util 层 

    对 selenium driver方法的重定义与 封 装 （ Selenium2Proxy） 、自定 义 通 用 方法（CommonMethord）、公共case方法（CommonCase），第三方服务等，可根据需要自行添加 。

6.3、Page 层 

    以页面为单位，定义页面上的元素识别与基本动作（赋值、点击等），一个页面对应一个java文件 

6.4、Business 层 

一个页面对应一个java文件，定义该页面上的所有基本事务（查询、新增、删除等），事务是page层所定义元素的动作组合 

6.5 、Case 层 

    Case实现层，是business层、page层所定义对象的组合操作，并加入适当的断言（验证点）。 

    Case组织方式请参看“用例组织规范” 

6.6、Data 层 

    数据驱动层，定义case层中的测试方法所用到的数据 

6.7、Config 层 

    配置定义，含浏览器驱动配置、配置文件读取等，勿轻易修改。 

7、脚本回放规范 

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

    Htmlunit 回放时无界面，对 js 支持不是很好，不建议使用 

    本地开发时选择适合自己的回放浏览器（不建议使用 IE6，推荐 IE8 和Chrome） 

    执行机批量执行选择可兼容的最快的浏览器进行回放 

    浏览器兼容性测试时选择需求规定的浏览器回放 

    建议控制每个测试方法的回放速度在 60S 之内，通过优化测试脚本实现 

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