自动化测试框架的AW模式

     近年自动化测试发展迅猛，几乎每个行业，如GUI、APP、云等都开发出自己的自动化开源框架来满足本行业自动化测试的需求，但这些自动化开源架构大多是偏向自动化实现技术的。从自动化工程角度出发，给出通用的自动化测试框架。

 从自动化工程的角度来说，自动化测试框架主要分为4层。

自动化测试架构的底层是“被测系统/测试环境层”，主要包括自动化测试对象的实际物理设备和虚拟化环境。自动化脚本实际就运行在这一层上。

第二层是“自动化测试架构层”，这是自动化测试架构的核心层，主要包含几个子系统。

·脚本语言运行环境和各种框架的集合：包含自动化测试相关的语言环境、库、开源/自研框架等。

·业务负载发生器：主要作用是模拟所需的业务负载。

·测试数据生成器：根据测试要求生成所需的测试数据。

·被测系统管理系统：包括配置文件的管理、相关数据库管理等。

·测试环境管理系统：主要是对测试环境的管理，如测试拓扑、资源等。

·AW（Action Word，动作关键字）：在自动化测试中，所有的操作都需要抽象封装为关键字，供上层自动化脚本调用。

·工具：与自动化测试相关的工具组件（如测试报告生成工具）和其他系统（如需求管理系统、测试用例系统或缺陷系统关联的工具插件等）。

第三层是“自动化脚本和套件层”。建议从“特性——测试类型”这样的角度来组织自动化脚本。还可以根据场景、专项等将满足特定条件的自动化脚本组合起来，形成自动化测试用例集（又称自动化测试套件），方便用户层调度使用。

 

 最顶层是“用户层”，包含的子系统如下。

·脚本调度运行系统：如Jenkins Jobs等，提供与脚本调度和运行相关的能力。

·自动化测试报告：提供自动化测试结果，为测试失败的脚本提供详细信息，以供自动化测试执行人员分析使用。

·仪表盘：提供当前自动化项目的整体状态、统计等信息。

·用户管理系统：提供基本的账号管理、权限等能力。

AW是第二代自动化测试框架新的架构中的思想其中之一。（ActionWord）

总结分享一下自动化测试框架设计的思想

• 自动化测试一般有数据驱动和关键字驱动两种模式，这里将两种思想结合起来，即有关键字驱动也有数据驱动。从架构层面设计，采用开发常用MVC框架思想，分为逻辑控制层（Controller）、持久层（Model）、展示层（View）。如下图所示，以Java语言为例，每层应用到的技术：

　　逻辑控制层：Selenium适用于Web自动化，真实模拟用户操作浏览器；HttpClient应用于接口自动化；TestNG是一个目前很流行实用的单元测试框架，有完善的用例管理模块，配合Maven能够很方便管理依赖第三方插件，事半功倍。如果适用python，也是有类似的开源库可供选择，如python+selenium+request+unittest。

　　持久层：这一层注意用例测试数据的管理，很多是适用excel表格的形式去管理测试数据，这里也不是说不好，毕竟也是经过市场的考验。例外介绍一个笔者觉得更加优秀的思路，采用MyBatis+MySQL的方式管理数据，可能很多测试人员开发经验不足，不太熟悉MyBatis框架，这里有必要可以学一学。总体的思想就是首先做好测试分析，根据业务设计好测试数据库表结构，然后将测试数据保存在MySQL数据库，实现测试数据和期望结果数据的线上管理，这里只需要在MyBatis框架下面写好对应的SQL语句即可实现数据驱动的自动化测试。笔者对python的第三方库不是很熟悉，想必python应该也有类似的管理MySQL的库。

　　展示层：主要是测试报告的展示，采用ExtentReport框架实现测试报告的展示，该框架的测试报告效果目前来看是比较好的。

• 逻辑业务层的具体实现来看，主要分基础框架类、封装工具类、封装业务类和自动化脚本。如图所示：

 

　　基础框架类：这里可以直接使用maven引入即可，管理起来很方便。

　　封装工具类：这个类主要包括连接数据库、读取配置文件、读取excel文件等基本工具类，还包括对selenium、HttpClient等框架进行二次封装的类，可能有人会说，这是多余的，为什么要做这个封装，做这个主要是为了解耦业务类与框架。如果某天发现这个框架有点缺陷，业务类不好使，当我们更新框架可能会需要大量修改封装的业务类，维护工作量巨大，如果有这一层，那我们只需要修改二次封装类的具体实现就可以了，对业务类提供的API不变，这样维护工作量小很多。

　　封装业务类：这一层采用关键字驱动的自动化测试思想，根据被测对象的特性，设计很多个不同的业务类，比如登录操作，如果很多个登录的入口，就写一个登录基类，不同入口继承基类分别实现子类。如果是接口自动化，这个设计起来就比较简单了，有多少个接口就设计多少个业务类，这些类我们称之为AW（Action Word），是为了自动化测试脚本测试不同场景直接引用方法，组合AW，形成一条条测试用例。这样，我们测试人员即使代码能力一般，也能依葫芦画瓢，组合各个AW写自动化测试用例。如果公司资金人力允许，还可以针对开发一个桌面工具或者网站，实现表格式开发测试用例，这样的话，即使不懂代码的测试人员，也能根据业务逻辑自己在桌面工具或者页面组合AW，形成测试用例，程序自动组装TestNG测试用例。笔者用到过的类似这种框架就有Robot Framework，一个非常优秀的开源python自动化测试框架。

　　自动化脚本：直接组合业务类写好的AW。针对这一层需要测试人员懂一点点Java代码就可以胜任这个工作，如果想要小白都能写，需要针对开发一个桌面工具或者网站，实现表格式开发测试用例，前面已经讲到不再赘述。

• 最后说一说测试执行，目前用的比较多的就是Jenkins，持续集成；将我们写好的测试用例使用git仓库管理，事先在Jenkins创建好任务，发布新版本之后，直接运行任务，自动部署版本包，下载自动化测试用例并执行，生成报告，这样的一条流水线，在当今敏捷开发模式下效率是很高的。

 

参考：https://www.cnblogs.com/andrew209/p/10091841.html