开发自动化测试平台的实践真知

从2016年初至今,T2cloud自动化测试已经走过3年多的历程,从最初的python + selenium脚本发展到如今功能健全且行之有效的自动化测试平台,我们一直在探索一直在前进。下面我们以发展历程中里程碑式的节点来讲述公司自动化测试道路上的实践真知。

决定引入自动化测试

2016年,自动化测试技术已经相当成熟,市面上也出现不少自动化测试架构可供使用。当时公司主要产品T2OS的测试用例数目不到1000条,手工测试尚未感受到压力,没有到“不得不”引入自动化测试的地步。

但是随着产品规模不断扩大,测试用例数目也在不断增加,而测试周期却需要尽可能地缩短。当时测试经理预见到在这种发展趋势下,自动化测试将成为必然,决定未雨绸缪尽早地开展自动化测试。

第一代自动化测试框架Hurricane

“工欲善其事必先利其器”,开展自动化测试之前需要先选择一款合适的框架。结合测试产品特点和当时主流的自动化测试方法,我们设想出满足自身需求的理想框架应该是:

简单易用,便于开发

提高代码的可重用性,减少自动化测试人员的编码量

良好的可扩展性

良好的可维护性

可视化运维,提供场景化的测试报表

测试结果实时通知

智能异常检测,错误信息定位,方便排错

与TestLink集成,测试结果更新到TestPlan

与Jenkins集成,实现CI/CD

带着这些需求,我们逐一了解当时主流的自动化测试框架,发现这些框架都有不如意之处,我们决定自主研发一款自动化测试架构以适应公司的实际发展需求。

自动化测试架构的研发为避免浪费大量的人力和时间,先由自动化架构师实现框架的核心调度部分,使自动化测试用例能够顺利执行,然后各自动化测试人员将TestLink上的手工测试用例进行编码实现。

自动化测试架构Hurricane的主要思想是采用流程驱动,将测试粒度细化到测试步骤,每个测试步骤及验证被封装为python函数,每个测试用例用json文件来表示,框架会解析json文件,依次执行其中定义的测试步骤。

随着自动化测试用例数目增多,测试步骤对应的python代码逻辑覆盖越广,后期的自动化工作量越来越少,在了解自动化脚本现有功能的基础上,甚至不需要编码,只需要编写json文件就可以实现业务测试用例的编写。

我们依托Hurricane开发的自动化测试用例,在两年多的时间里参与了多次BVT测试及回归测试,极大地缩短了回归测试周期,降低了人力成本。

然而随着T2OS产品业务的不断扩大和升级,尤其是引入敏捷开发模式之后产品迭代周期明显加快,Hurricane开始面临一些挑战:

T2OS产品逐一对接VMWare、PowerVC,测试用例数量成倍增长,自动化任务也随之倍增,离我们预期的覆盖率渐行渐远。

由于前端架构改用VUE,绝大部分页面元素没有id或name属性,给UI自动化中准确定位元素带来挑战。

Hurricane使用python语言编写,随着自动化程度不断提高,越来越多的第三方python模块被引入,导致搭建自动化测试环境的工作量不断增加。

由于UI自动化测试中,需要使用本机浏览器作为执行平台,不具备并发执行能力。随着自动化测试用例数目的不断增加,自动化脚本执行效率低、周期长的问题逐渐凸显。

结合公司产品的实际情况,以及自动化知识、经验、策略等方面的积累,针对以上问题我们讨论出如下解决方案:

问题解决方案:

升级Hurricane,最大化地提高代码复用性,最大化地简化json内容,提高自动化脚本的编写效率。降低脚本编写难度,使公司的初级测试工程师也可以顺利地介入其中,提高测试组整体的产出值。

问题解决方案:

了解VUE及其渲染出的html5元素特性和通性,熟练掌握xpath各种定位方法并形成一种约定或规范,要求自动化人员按这种约定编写xpath,而不是直接使用浏览器插件自动获取的xpath,这样能最大程度地包容变化。

问题解决方案:

引入容器技术,将自动化代码打包成容器镜像,自动化测试人员只需执行安装脚本就可以快速搭建好自动化测试环境。

问题解决方案:

引入Zalenium工具,对Selenium的功能进行扩展,利用其支持多线程执行的特点,提高自动化代码的执行效率,满足自动化测试对效率的需求。

第二代自动化测试平台T2TAPE

为满足公司的发展需求,我们对Hurricane进行升级,开发出第二代自动化测试平台T2TAPE(T2Cloud test automation platform engine),T2TAPE充分利用了面向对象编程思想,通过封装、抽象、继承、接口等将Hurricane进行分层,层级内细化出各个子组件,组件内高内聚,组件间低耦合。

(T2TAPE结构图)

T2TAPE整体上分为3层,驱动层、服务层和应用层:

驱动层包含大量的第三方驱动库、支持类和工具库,主要被服务层和应用层调用。

服务层是整个自动化测试平台的核心架构部分,涵盖了从测试启动到结束的整个调度流程,并为应用层的测试环境搭建提供基类。

应用层可以看作是项目层或产品层,每个项目或产品有独自的应用层,应用层之间相互独立,可以同时存在多个应用层。

除了架构上的优化,相较于Hurricane还做了以下几个方面的改进:

将功能的实现、验证及其他相关操作封装在一个类中,比如创建云主机操作,其对应的类中包括UI层功能实现、接口层功能实现、OpenStack层功能实现、分层级的功能验证、日志检查、资源清理等。通过在json中做简单的配置即可按约定的流程执行,将之前的四五个Task描述的功能简化为一个Task,大大简化了json结构。

执行并发数可随意配置,自动化执行人员可以根据当前环境资源配置情况设置合适的并发数。

对于个别自动化无法实现的测试点,在自动化测试脚本中会进行特殊标注,执行该脚本后会将此信息同步到测试执行管理软件中,并对测试用例的执行状态进行标注,便于手工测试人员进行补充测试。

对于不适合并发的测试用例(如:影响到其他测试用例、测试使用资源会受到其他测试用例影响),框架进行特殊处理单独执行。

对于有环境要求的测试用例(比如公有云相关测试用例)在执行时,会自动匹配可以执行的环境进行运行。如果当前环境不满足要求,测试用例将不被执行。

框架根据需求可以支持在多个环境中同时执行。

提供自动化管理辅助工具,如:自动化工程师编写用例数量的统计工具、脚本及用例信息一致性校验工具,测试用例批量修改工具等。

执行方式的多样化,可以执行所有case、执行指定TestPlan中的case、执行指定模块下的case、执行单个或几个case等。

资源清理可控,可以清理全部资源,也可以保留失败case创建的资源。

UI测试引入Zalenium容器,自动化人员无须再关注driver版本维护、与浏览器版本冲突等问题。

由于Hurricane本身的可复用性很高,所以升级的过程没有遇到明显的阻力或痛点。目前T2TAPE下自动化测试用例数量已经超过3000个,KVM的测试覆盖率达到80%以上,在一年多的时间里参与了20多次大规模回归测试,取得了比预期更高的收益。

Hurricane和T2TAPE都经历了长期的实践,T2TAPE不仅有更高的收益,在成本控制上也是更胜一筹:

可复用性的提高和json的简化,使同级别的自动化测试人员平均产出提高1.5-2个case/天。

T2TAPE的架构特点和严格的代码规范,使其具有更好的可维护性,降低了维护成本。

Hurricane要求每个自动化成员都具备一定的编码能力,T2TAPE则更容易上手,对于同一类型的case,完全可以先产出一个模板case,然后投入初级自动化测试人员甚至手工测试人员来完成剩余case,使自动化测试团队的人员配置更加弹性。

T2TAPE未来发展方向

T2TAPE目前已满足公司各个产品线的需求,从长远来看,考虑以下几个方向的优化和发展:

json文件数据库化

一个测试用例用一个json文件来表示,那么3000多个测试用例就代表有3000多个json文件,为了更好地管理和维护,将json文件内容存储到数据库应该是个更好的选择。

开发UI界面

为了降低学习门槛,提供更多的执行可能,以及更好地向相关人员介绍T2TAPE,UI界面应该能起到锦上添花的作用。

kolla化

我们设想的理想场景是:在部署完环境后,运维人员进行简单的配置就可以执行自动化测试,达到验收测试的目的或者在手工测试开始之前通过自动化提前发现严重问题。这种想法的实现需要我们将自动化测试脚本加入到公司的kolla部署安装体系中,通过kolla统一管理、部署。

开源

当T2TAPE发展到可以视为一个产品的时候,我们会考虑将其开源,让更多的同仁去使用它、升华它。

由于篇幅有限,以上只是针对公司开展自动化测试以来具有代表性的实践做了简要的阐述,公司自动化团队在长期开发实践中积累了丰富的经验,完备了相关知识体系(规范、编码能力、排错方法等)。未来,我们将继续在自动化测试道路上积极探索实践,深入挖掘自动化测试潜能,为大家分享更多的精品干货。

技术内容提供者:

云途腾T2Cloud 高级测试开发工程师李秀兰

—完—

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190808A030E600?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券