全球大型电商测试基础架构设计概览

作者 | 茹炳晟

编辑 | Eva

本文为 eBay中国研发中心测试基础架构技术主管 茹炳晟关于“eBay高效能测试基础架构的前世今生”主题分享的部分节选，想了解全部内容，请在公众号后台回复关键词“高效能架构”获取完整直播视频。

“知其然知其所以然”是学习和深入理解技术本质的核心，面对大型网站的测试基础架构的复杂性以及测试框架的复杂性，作为测试架构师和资深测试开发工程师很有必要从根本上理解问题的本质和设计的初衷。但是如果直接讲解各个模块的功能以及设计固然能明白其作用和原理，但是其过程是相当地乏味，而且很难从业务驱动的层面理解问题的本质。所以本次极客 Live的讲解抛弃了传统的就技术谈技术的方式，而是采用业务驱动为切入点，以工程实际问题为主线，以提出问题到给出对应解决方案为主干，讲解大型电商网站的高效能测试基础架构是如何在业务的驱动下演进与发展的。

当今大型电子商务网站的测试基础架构和其他行业的测试基础架构相比，最大的特殊性在于“快”。一般传统 IT企业的产品发布是以“月”为单位的，所以在这种大背景下，测试执行的时间，测试用例的维护工作量以及测试用例的稳定性要求都不会成为关键问题。但是对于电子商务网站，尤其是具有全球业务的大型电商网站，产品上线周期都是以“天”甚至是以“小时”为单位的，这样就对全回归测试的执行时间，测试用例的维护工作量以及测试用例的稳定性有极高的要求。

比如全回归测试的时间不能大于 100分钟，API测试的稳定性要在 99%，GUI测试的稳定性要在 95%，失败用例的追踪和修复的时间周期小于 2小时等等，这些要求的实现都会与测试基础架构的设计有着直接的关系。换言之，如果没有一套高效能的测试基础架构和 CI/CD系统的支撑，这些目标的实现就会无从谈起。所以听众会发现互联网产品的测试基础架构设计原则都会围绕“唯快不破”这一基本原则。

围绕这一基本原则本次 Live主要涉及了以下几大块，并在最后结合 eBay的最佳实践介绍了全球大型电商测试基础架构设计概览。

• GUI Automation Test Framework 前世今生

• Test Data Platform 起源与发展

• API Automation Test Framework 演进之路

• Test Execution Environment 演变与创新

• Test Report Platform 演变与创新

GUI Automation Test Framework 的前世今生

这个模块主要从最原始的 GUI测试开始讲起，然后逐渐深入，并从全局发展的维度阐述了 GUI自动化测试框架的发展，其中涉及了 Page-object模型的由来，Flow模型解决的问题和 Unified-Flow模型的原始驱动力等主要内容。

首先是从最原始的手工测试开始。最初的情况是，先有业务需求，然后业务需求会分解成功能需求，功能需求会变成测试需求。（举个例子，功能需求是做 login操作，但是分解成测试需求，就会包含 login的基本功能验证，并发情况下的 login验证，也会做安全相关的的验证，包括 SQL注入，跨站脚本攻击等，那就会有不同层面的测试需求。）然后这些测试需求都是在本地测试环境上进行手工测试验证。

随着手工测试用例的不断增多，以及版本快速发布引发的大量回归测试要求，单纯靠手工测试已完全不能满足项目的要求，于是最初的基于录制与回放技术的 UI自动化测试被广泛应用。最典型的就是 HP的 QTP（现在属于 MF，并且改名叫 UFT了），测试用例经过简单的录制就可以顺利回放，很大程度上减少了测试执行的人员工作量。

但是随着录制的测试用例数量不断增加，这些用例的维护就成了问题。录制 10个用例是很好，你录制 100个也觉得挺好的，但是当用例数量达到成百上千后，万一 UI有改动，所有脚本全部要跟着一起改，这样的维护工作量完全是不能接受的，尤其是对于大型项目。所以在这个基础上，我们为了解决大量脚本代码的应对 UI变化的可维护问题，我们把一些基于操作的测试步骤单独录制并定义成可重用的脚本 step，然后通过编辑的方式合并这些 step成一个真正能跑的测试脚本。我们把这种设计称为“基于操作的可重用脚本片段”。一个典型的应用例子是把 Login做成一个可重用的脚本，Logout一个可重用的脚本，然后当中的其他业务操作做成多个可重用的脚本，然后测试用例自己随便去拼接这些脚本以覆盖测试的场景。这种情况下，比如当 Login的 UI发生了变动，只需要修改 Login的脚本，而其他所有调用 Login的测试用例不需要做任何的改动。

虽然基于操作的可重用脚本很大程度上缓解了测试用例的维护工作量，但是这样的脚本片段的粒度控制还不是最高效的。举个实际的例子，由于前端控件升级，原本的输入框控件发生了变化，那么所有脚本中有输入框控件的都需要更新，另外的例子是如果某个页面元素发生了变化，那么所有涉及到这个页面的基于操作的可重用脚本都需要随之变动。所以更好的的设计应该是基于控件 +页面的可重用抽象，这就是非常典型的 Page-object模型。每一个页面都可以被封装成一个类，这个类里包含了页面上元素与控件的定义，测试用例是由调用页面元素的操作构成的集合。

进一步，为了让测试用例的拼装更接近业务，可重用脚本可以基于业务流程进行抽象封装。这样面向终端用户的 UI测试用例就是对业务流程脚本的拼装。这样的测试用例脚本就会更接近业务驱动 BDD，而且不仅测试人员可以拼装测试用例，产品经理或者项目经理也可以快速方便的拼装测试用例。

更进一步，为了应对电商业务的全球化发展，很多业务流程在不同的国家都会有轻微的差异性，比如同一个商品在美国售卖没有问题，但是在某些欧洲国家售卖就需要提供额外的信息，甚至是压根不允许售卖。为了应对这种业务差异性的需求，业务流程就会有在各个国家都有不同的·版本，对应地，测试的业务流程脚本就必须能够处理这种轻微的差异性，比如同一业务脚本可以支持不同的入口 page和出口 page，业务流程内部可以根据业务功能开关支持不同的分支等等，这就形成了 Unified Business Flow框架。同时，为了进一步降低 Page代码的维护工作量，我们还引入了自动化的 Page Code Generator。

全球大型电商测试基础架构的设计概览

核心理念是 Everything is a service，并由此提出了 Automation as a Service的架构。希望读者能从中根据自己公司的业务上下文对其进行裁剪或者进一步扩展改进。

......

最后我们谈一下优秀的测试基础架构所应该具有的特点来结束本文。

• 专一性：优秀的测试基础架构应该让测试开发者只需要关心自己的测试逻辑，而不需要去关注诸如测试在那里执行，测试数据怎么生成等非业务测试相关的内容。

• 统一性：优秀的测试基础架构应该能很方便地和各种 CI/CD集成，理想的情况就是 Unified Test Execution as a Service. 只要一个简单的 Restful调用发起测试请求，至于后台的测试框架，测试执行环境，测试报告等都对 CI/CD系统透明。

• 扩展性：当有新的测试框架（比如 Puppeteer，NightWatch等）需要接入的时候，基础架构的改动越小越好，甚至可以做到无缝接入。

• 灵活性：测试基础架构的各个模块可以按需加载使用，比如在我们的系统中，基于 AI的 Defect分类模块，多语言全球 Site测试比较报告模块等都是按项目或者 Phase加载的。

公众号后台回复关键词“高效能架构”获取完整直播视频

除茹炳晟老师之外，全球架构师峰会深圳站还邀请了诸多国内外顶尖架构师前来详解：

• 微信数百亿消息收发背后的 Yard平台设计

• 菜鸟全球跨域 RPC架构

• 滴滴地图引擎架构实践和 AI技术应用

• 微博个性化推荐引擎

• Facebook万亿级混合复杂时空数据的处理决策

• Google研究院：TensorFlow在深度学习中的应用

• ...

更多内容欢迎识别下方二维码或点击 阅读原文，目前 ArchSummit限时报名，席位有限，如需帮助可直接联系票务小助手豆包（微信：aschina666，或致电 010-84780850）