您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

一个优秀的测试基础架构是如何炼成的?eBay茹炳晟畅谈测试演进史

发表于:2018-06-11 作者:周雪 来源:51CTO

2018年5月18-19日,由51CTO主办的全球软件与运维技术峰会在北京召开。此次峰会围绕人工智能、大数据、物联网、区块链等12大核心热点,汇聚海内外60位一线专家,是一场高端的技术盛宴,也是顶级IT技术人才学习和人脉拓展不容错过的平台。

在“DevOps转型之路”分会场,eBay中国研发中心测试基础架构技术主管茹炳晟带来了《测试基础架构的演进之路》的主题演讲,分享了大型电商网站的测试基础架构设计经验与心得。会后,51CTO记者根据茹炳晟在WOT2018全球软件与运维技术峰会的演讲内容进行了整理。

eBay茹炳晟,WOT

GUI 自动化测试框架的演变

茹炳晟介绍到,eBay是一家大型电商平台,其中测试基础架构与DevOps的关系非常大,跟CI/CD(持续集成持续发布)高度集成。在CI/CD的流程中,对测试的调用都是通过统一的测试执行服务,通过这个统一的测试执行服务来发起所有的测试执行,包括API测试,GUI测试和性能测试。CI/CD整个流程过程当中,发起者并不需要知道测试运行在哪里,测试执行环境在哪里,测试是怎么设计的,他只负责发起一个测试,同步或者异步得到一个结果,然后决定这个流水线是不是可以往下走。这些行为都是基于测试基础架构来进行构建的。

GUI(图形用户界面)自动化测试是最早的自动化测试之一,属于比较重量级的测试,投入产出比一直不高,所以对于大型电商网站通常用于上线前的轻量级Smoke测试以确保所以核心功能的正确性。同时GUI(图形用户界面)自动化测试也是经历了一个传奇式的变化,从一个非常简单的架构,一直演进到大型电子商务能够适应全球化站点,同一套测试脚本能够运行在全球化不同国家的站点上。

在最原始的测试框图上,有业务的需求会转换成功能需求,功能需求转换成测试需求,测试需求会有测试用例,测试用例会在本地测试执行环境运行。测试团队会在本地机器上面打开这个网站进行测试,那么问题来了,一旦需要进行全回归测试,原始方法效率肯定很差,必须借助自动化测试功能,录制回放就是最初的自动化。UFT这种工具可以在录制完之后反复回放脚本。但是缺点是一旦界面有任何变化的,脚本需要从最初开始修改,这显然让人无法接受。

模块化因此应运而生,它可以将一些基于操作级别可重复的脚本单独抽象出来,并且把它参数化。但茹炳晟表示,在实际操作中,哪些是可重复的脚本,脚本的力度如何控制,其实比较难处理。因为每个人理解都不一样,对于可重用脚本的定义,在每个团队之间会有很大的差异。

经过进一步的发展,茹炳晟和他的团队把可重复的脚本进一步演变成对于Page Object(页面对象模型)的抽象,自动化脚本就变成了page的分装,上面有基于page元素上的操作。后来,他们在page的基础上,又做了一层Business Flow(业务流程)的抽象,测试人员可以直接看到业务驱动的测试脚本,从case维护的易操作性及可读性来看,又上了一个档次。

再到后来,茹炳晟和他的团队开始尝试使用Out-of-box Test Data / Golden Data Set测试数据,逐渐开始基于Unified Flow Framework实现Flow Branch控制。茹炳晟解释道,像全球都拥有站点的大型电商网站,每一个国家对网站的功能都会有轻微的差异,这就要求技术团队必须在同一个业务流程里能够实现不同的功能点。过去是5个国家写5个各自独立的脚本,而现在只需要1个脚本就可以供不同国家站点进行差异化测试,对工程师的工作效能提升而言是非常有帮助的。

后来,他们又基于Page Encapsulation Code Generator提高Page Object的效率。当一个新的page或者一个page有改动的时候,他们可以通过一个很小的程序,就可以把这个page上面所有的元素动态捕捉下来,以后需要用的时候,只要是这个page上面的元素就可以调用了,整个page的生成都是自动完成,不需要人工去做。

到了这个阶段,测试能力已经非常强,但是eBay的测试团队仍然没有满足,他们引入Test Data Service,提供统一的测试数据准备服务。他们提供了一个完整统一的接口,可以帮助测试人员降低所有测试数据的复杂性,让测试工作变得更加高效。

测试数据之疼+应对策略的平台化演变

茹炳晟将测试数据的痛点归纳成五个部分。

第一个痛点是On-the-fly数据的时间消耗准备。On-the-fly是什么概念呢?测试人员在测试用例开始实施之前,会在测试的脚本里动态生成数据,但如果是非常复杂的数据会十分消耗时间。

第二个痛点是Out-of-box测试数据的脏数据,在拥有大量测试用例的场景,可能存在数据相互干扰的问题,会让大量的测试用例由于脏数据而测试不通过。

第三个痛点是测试数据本身组合的复杂性,电子商务网站需要绑定不同的支付方式、快递方式,不同国家有不同法务要求,各种参数的组合非常多,给测试数据带来很大的困扰。

第四个痛点是测试数据准备的环境依赖性,例如做某个功能的测试,需要准备特定的数据,但是因为微服务,这个数据是由另外一个服务器提供,但各种问题可能导致数据准备不出来,结果功能测试就无法完成。

第五个痛点是性能测试数据准备的时间消耗。在这方面eBay有非常好的实践,通过Test Data Service,他们将成功率提高了很高的量级,并且把测试数据的问题从原来的30%降到5%以下。

eBay茹炳晟,WOT

API自动化测试框架的演变

茹炳晟介绍到,大型电商网站通常有上万个API,由于快速迭代并上线发布,留给测试的时间非常少,只能通过一个很大的集群环境去并行运行这些API测试,他们会引入一个并发的访问控制器,对这些集群、上万个API进行控制。

经过五六个不同阶段的发展,对于API测试,目前eBay已经完全迁到微服务上实现。目前公司service数量大概有百余个,如果按原来API的思路,case数量会超过10万,即使用集群也跑不完。所以他们改变策略,引入了一个基于消费者契约的验证模式。例如当A端的B来调用某个脚本,测试系统只需要知道是谁来调用,如何调用,然后把涉及到的API调用测试一遍就可以了。下一次只会测试之前调用过的脚本,就能保证整个模块的质量。

对于测试执行环境的搭建,茹炳晟以GUI测试为例,例如某个测试人员要求这个GUI测试是运行在某个操作系统中的某个浏览器上的某一个版本上。那么他们会先到Selenium Grid集群里发送请求,询问集群下面有没有安装着这个操作系统的这个浏览器版本的节点?如果有,测试系统会直接发给他,如果没有,测试系统会动态地创建一个。

以上内容是51CTO记者根据eBay中国研发中心测试基础架构技术主管茹炳晟在WOT2018全球软件与运维技术峰会的采访内容整理,更多关于WOT的内容请关注51cto.com。

 相关文章