本文章介绍自动化测试方案设计。

Quick Guide

方案选择

自动化测试框架的类型

1. 单的录制／回放：由工具录制并记录操作的过程和数据形成脚本，通过回放来重复人工操作的过程。在这种模式下数据和脚本混在一起，几乎一个测试用例对应一个脚本，维护成本很高。而且即使界面的简单变化也需要重新录制，脚本 可重复使用的效率低。
2. 数据驱动 （data driven） 的自动化测试：从数据文件读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例。在这种模式下数据和脚本分离，脚本的利用率、可维护性大大提高，但受界面变化的影响仍然很大。
3. 关键字驱动（keyword driven） 的自动化测试：关键字驱动测试是数据驱动测试的一种改进类型，它将测试逻辑按照关键字进行分解，形成数据文件，关键字对应封装的业务逻辑。主要关键字包括三类：被操作对象（Item）、操作（Operation）和值（value）， 用面向对象形式可将其表现为Item.Operation（Value）。 关键字驱动的主要思想是：脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离。
4. 行为驱动测试框架：支持自然语言作为测试用例描述的自动化测试框架。

考虑的因素

• 根据团队技术基础
  • 如果团队有编码基础，选择跟开发技术栈一致
  • 没有，选择简单易学工具或者编程语言（python/js）
• 业务的场景应用
  • 如果偏向后端测试且业务简单，都是接口，可以考虑直接用接口工具（jmeter/postman）实现
  • 如果web或者移动端，就需要测试框架能支持selenium/appium
  • 如果业务复杂，尽量使用能编码的框架
• 业务的生命周期

方案设计

分层设计： 高内聚低耦合

• 高内聚：就是每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码；
• 低耦合：就是模块与模块之间接口的复杂程度，比如在类内部尽可能减少方法之间的调用，否则一个方法的变动会影响调用它的另一个方法。

操作组件 —>功能点—–>业务流程：

1. 封装各个模块的底层API,构建上下游mock和fake, 通过调用单一个模块进行 功能点的验证
2. 通过模块组合实现对业务流程的验证。

页面PO设计

1. 以每个页面为单独一个类,页面中的控件为属性，控件的操作作为方法
2. 组合不同方法去完成用户操作

脚本分离设计

• 封装基础函数、基本的业务逻辑、验证点
• 对象、操作、测试数据、业务逻辑相互剥离、灵活调用

结构化管理

1. 用例目录结构化和命名规范
   1. Project/Resource/Method/Request命名。
   2. TestSuit/TestCase/TestStep命名，呈现特性树，方便通过每个特性的用例数和功能点
2. 信息一体化：基本信息的编写（比如用例场景、用例维护人员、自动化用例）和项目文档（业务API、需求需求文档、环境信息和常用命令）能在一个地方统一跳转过去
3. 对象、操作组件、基础函数、测试数据 结构化
4. 参数化
   1. 环境参数化
   2. 脚本参数化

• 用例
  • 功能特性1
    • 测试数据
      • 输入数据
      • 验证结果
    • 测试脚本
    • 相关资料文档
  • 功能特性2
• 公共库
  • 业务逻辑
  • 第三方库
  • 自定义库
• 公共文档
• 环境变量

方案执行

有效的执行体系

1. 批量、定制执行、自动运行
2. 异常处理机制（重试或者跳过）
3. 业务数据还原初始状态
4. 版本管理

结果体系

1. 针以每条用例，输出用例执行结果
2. 针对每个检查点，输出详细的检查点执行结果
3. 输出执行日志