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

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

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

GUI 自动化测试框架的演变

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

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

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

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

经过进一步的发展，茹炳晟和他的团队把可重复的脚本进一步演变成对于Page t(页面对象模型)的抽象，自动化脚本就变成了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 t的效率。当一个新的page或者一个page有改动的时候，他们可以通过一个很小的程序，就可以把这个page上面所有的元素动态捕捉下来，以后需要用的时候，只要是这个page上面的元素就可以调用了，整个page的生成都是自动完成，不需要人工去做。

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

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

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

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

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

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

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

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

API自动化测试框架的演变

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

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

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

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

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】