浅谈自动化测试框架设计

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

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

浅谈自动化测试框架设计_第1张图片

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

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

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

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

浅谈自动化测试框架设计_第2张图片

 

  基础框架类:这里可以直接使用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

你可能感兴趣的:(python,数据库,java)