测试开发之自动化篇——自动化测试框架设计

今天，给大家介绍如何进行自动化测试框架的设计。这里所说的框架，是建立在一些主流类库、框架或工具的基础上的，自行研发的、适合公司的自动化测试资产。

如今有很多UnitTest测试框架，已经提供了数据驱动、用户并发、断言、报告等优异的特性，完全可以被用来进行单元测试之外的功能、性能、接口等方面的测试，建议大家可以基于他们来实现。

这里给出我们建议的、自动化测试框架的分层结构，下面将围绕此给大家逐一做介绍。

测试用例脚本

在此实现业务的自动化测试，这一层面的脚本同手工测试用例具有最直接的对应关系。

公共业务脚本

一些提取出的、可在业务层面复用的函数、类库或脚本。比如网上购物系统的登录、加购物车、下单、付款等常用的业务操作。也可包括一些应用系统层面、或有安全限制的Knowledge Base的实现，如笔者曾经在测试电子支付系统时使用的、向全球央行打款的命令行工具，其由公司核心人员开发，执行于安全性极高的隔离环境中。

脚本解析

用于解析类似关键字驱动（Data Driver）、自然语言理解（NLU）等更高形式的测试脚本，将其转换成某种编程语言的可执行代码。如解析QTP关键字视图的脚本到VBScript代码，转换RobotFramework自定义关键字的脚本到Python3代码的过程。

数据管理

实现自动化测试的数据管理和数据驱动。比如，大家习惯用Excel维护二维的表格数据，在脚本中读取后再迭代引用；也可以类似前一篇文章中的例子，为数据文件或ZenData数据接口编写DataProvider，然后在脚本中使用Java标注的形式，将数据循环、逐条地”喂给“业务测试方法。

执行调度

分布式测试框架中，用于控制测试执行发生在什么样的系统、设备或节点等环境上。可以类似Jenkins的代理，执行测试于不同的远程机器中；也可以类似禅道的ZAgent开源项目，执行测试于指定特征的虚拟机、容器或手机设备中。

结果断言

通常是对一些主流测试框架的断言和日志特性做封装，使其用起来更方便、更适合公司的业务。比如，在用例做验证点检查的同时，打印、朝数据库存储、向日志系统推送指定格式的、更为详尽的消息，以利于后续的统计分析。

日志消息

除了上述断言有关的、验证点检查所输出的 期待结果、实际结果、通过与否等信息，也可以包括：基于UI的自动化测试中、每个步骤的控件定位结果、操作结果；基于协议的接口测试中，请求、响应的消息和状态，如此等等各类有益于排错和分析的日志。

统计分析

对测试步骤、检查点、用例、测试集、执行计划等各个层面的输出结果做采集和分析，生成完整的自动化测试统计报告。

测试资产管理

集中管理不同类型的测试资产，包括物理服务器、虚拟测试机、手机或嵌入式设备，甚至是AI测试中的 语音识别（ASR）语料、自然语言理解（NLU）说法、人脸识别的图库。

基础工具类库

一些常用的、特定编程语言层面的类库。如字符串处理、文件解析、协议请求、消息发送等等。

基础框架和工具

基于的第三方自动化测试类库、框架或工具来实现类似测试集组织、（分布式）执行调用、数据提供者等功能。如上文提及的JUnit、TestNG、Selenium、Appium、JMeter、QTP等优秀的开源和商业项目。大部分时候，我们不需要重复去造基础的轮子。

以上所述的模块和功能，算是囊括了一个自动化测试平台的方方面面。实际工作中，大家可以按需、逐步的进行实践，适合的永远是最好的。