浅谈自动化测试框架设计

笔者结合实际项目经验以及学习其他前辈经验，总结分享一下自动化测试框架设计的思想

• 自动化测试一般有数据驱动和关键字驱动两种模式，这里将两种思想结合起来，即有关键字驱动也有数据驱动。从架构层面设计，采用开发常用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创建好任务，发布新版本之后，直接运行任务，自动部署版本包，下载自动化测试用例并执行，生成报告，这样的一条流水线，在当今敏捷开发模式下效率是很高的。