一个完整的自动化测试平台应该包含什么

  提到自动化测试,很常见的误解就是把自动化测试等同于某种自动化测试工具,例如最广为人知的Selenium,但这只是狭义上的理解。在真正的项目实践中,自动化测试包含的内容很多,不仅仅只是某种自动化测试工具,我理解的一个成熟的自动化测试平台,应该包含以下这些方面:

1. 对被测系统进行操作的自动化框架或者工具:例如web程序的Selenium, 移动端程序的Appium,windows应用程序的white,autoit,QTP等。请注意,它们只是自动化框架,提供了能够自动化操作被测系统的功能,不是测试框架,因为它们不具备测试框架基本的用例组织,结果校验等功能,所以在实践基本上都是需要和一个测试框架集成起来使用的。

2. 测试框架:与自动化框架集成,提供用例整理,分类,调度,结果校验,报告输出等功能,例如Java的Junit, TestNG, Python的Pytest, Ruby的Rspec, 以及能够适应各种语言的Cucumber等。

3. 测试环境构建:使用Vmware,AWS等虚拟化和云技术构建和管理操作系统级别的服务器,使用docker等容器化技术构建和管理应用级别的服务。当需要多个容器时可以使用docker compose,docker swarm等,再复杂时可以使用kubernetes来管理和维护整个环境。理想状态下测试环境应该是自动化的一键式部署,有完整的部署脚本且纳入版本管理系统控制。可追溯,可回滚,可以很方便的从零开始构建,能够快捷的在本地构建起一个测试环境,测试人员有自己的专属测试环境,对于环境有控制权,同时具备维护环境的能力,可以按照需要随时构建或者销毁。

4. 测试数据准备:自动化测试需要完整的,可控的测试数据作为支持,否则自动化测试就是摆设,无法预判的执行结果反而会成为团队的负担。主要的障碍其实在于人员能力和权限管理,需要测试人员对于业务和系统有深刻的了解,才能准确的准备所需要的数据(例如业务中的操作和数据对应哪些API的哪些字段,又对应数据库中的哪些表)。数据的准备从底向上可以分为直接构建数据库(一般比较难实现,需要对数据库具有权限,且熟悉表结构,但却是最高效的方法),调用API创建数据(需要熟悉被测系统API消息体的结构,并且有权限),通过UI自动化脚本创建(可见性最好,但是最低效,最不稳定),在执行完自动化测试后也需要有相应的方法来清理数据。还有一种方法是通过mock server,这样既能解决依赖系统的问题,也能完成依赖数据的准备,但是开发mock server需要一定的工作量,且需要对系统和业务非常熟悉,而且使用mock server会导致测试的不真实性,无法发现真实系统集成之间的问题。Java的spring boot,wiremock,python的flask,Ruby的sinatra等都可以用来做mock server。

5. 并发执行:并发执行是提高测试执行速度的有效方法,有不同的方法可以实现并发执行,比如使用构建工具的并行测试功能,例如maven的surefire和failsafe,gradle的多线程执行功能,cucumber-jvm的并发执行。也可以使用其他工具或者库来实现,例如ruby的parallel-test,再复杂一些的,可以写个专门的程序或者服务来将测试的分发到不同的docker容器上执行,在BAT等顶尖互联网公司的测试分享中有过这样的案例。并发执行的另一个难题是需要解决好测试用例,测试数据,测试环境的隔离性问题,避免出现并发时互相干扰的情况。这就需要在设计测试用例时做好解藕,每个测试用例或者测试场景都是可以单独执行的,不存在用例间互相依赖的情况。在测试数据的准备上,要做好数据的唯一性和独立性,执行前预先准备好数据,执行后清除无用的数据,某些场景还要考虑共享数据在多线程运行时的同步,死锁等问题,不过目前主流的编程语言例如Java, Python在处理多线程编程时都有很成熟的方法。关于测试环境的准备,根据项目场景也有不同的方法,可以在多个测试环境上执行,也可以只在一个环境上执行,但是某些系统可能存在账户不能同时登陆等问题,需要提前考虑或者规避。在这里我想再替docker打个广告,docker容器技术的轻量化,低开销启动销毁,容器间互相隔离等特点,非常适合用来快速构建测试环境和并发执行测试。

6. 与CI集成:自动化测试只有与CI集成才能最大的发挥作用,否则如果只能在测试人员的机器上执行,将存在结果对团队不可见,缺乏规范的调度策略,无法引起团队的重视等问题,导致自动化测试形同虚设。而一个完整的CI流水线也需要包含自动化测试,在敏捷理念中有一句话,没有自动化测试的CI不能称之为CI。自动化测试与CI集成在技术上并不难实现,本质就是把测试由在本地执行放到CI的执行机上去执行,目前主流的CI工具,例如Jenkins,Bamboo,CircleCI等都能很容易的完成配置。需要注意的依然是测试环境,这里的测试环境包含两部分,被测系统的环境和执行自动化测试的环境。被测系统的环境需要能够被CI执行机访问,执行自动化测试的环境一般在CI的执行机上,就需要配置CI执行机的环境了,例如Java或者Python环境,Webdriver,浏览器等等。而这又会牵扯很多细节问题,例如CI的执行机一般都是Linux环境,无法运行图形界面,需要使用浏览器的headless模式,依然强烈推荐使用docker来封装整个的测试执行环境,这样在CI执行机上只需要docker pull, docker run就可以了,避免因为环境,依赖包等差异带来众多的问题。

7. 与用例管理系统集成:自动化测试执行后都会生成测试报告,但是更进一步,如果能够和用例管理系统集成,自动标注执行结果,那就更省事了,在很多项目中也是常见的做法。不同公司和项目使用的用例管理系统千差万别,有些还是内部开发的系统,需要根据实际情况分析解决。但一般都需要用例管理系统能够提供标注执行结果的API,在测试执行后有专门的程序来收集整理测试报告,再调用用例管理系统的API来标注结果。以业界名气最大的JIRA举例,就提供了API可以查询和标注test case的执行结果,所以只需要将执行结果按照API规定消息格式整理好,调用即可,并不难实现。

  以上介绍了一个通用的自动化测试平台需要包含哪些功能,以及这些功能如何实现。如果是移动端的测试平台,则还有更多的问题,例如不同设备的兼容性,如何并发和调度多台不同设备,在BAT这些顶尖互联网公司有成熟的实践,而我自己这方面的经验并不多,依然处在学习探索的阶段。从本质上看,构建一个比较完善的自动化测试平台,需要对被测系统有深入的了解,有扎实的软件测试和编程基础,熟悉至少一门编程语言,熟悉CI和Devops,有比较广的知识面和技术栈,知道如何选用合适的工具和框架来解决问题。

一个完整的自动化测试平台应该包含什么
滚动到顶部