【GITC精华演讲】ebay中国研发中心茹炳晟：测试基础架构演进之路

导读

11月24日测试测量专场上，ebay中国研发中心测试基础架构技术主管茹炳晟分享了《测试基础架构的演进之路》演讲，介绍测试基础架构的演变。

演讲嘉宾介绍

茹炳晟

ebay中国研发中心

测试基础架构技术主管

演讲主题：

测试基础架构的演进之路

30秒get演讲干货

ebay中国研发中心测试基础架构技术主管茹炳晟为大家介绍测试基础架构的演变：GUI Automation Test Framework的演变；Test Data Platform的演变；Web Service Test Framework的演变 (从单体后端架构到微服务架构的演变)；Test Execution Environment的演变；Test Execution and Management Platform的演变；Test Report Platform的演变。

GUI Automation Test Framework 的演变

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

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

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

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

进一步，为了让测试用例的拼装更接近业务，可重用脚本可以基于业务流程进行抽象封装。这样面向终端用户的UI测试用例就是对业务流程脚本的拼装。这样的测试用例脚本就会更接近业务驱动，而且不仅测试人员可以拼装测试用例，产品经理或者项目经理也可以快速方便的拼装测试用例。至此，测试脚本的封装已经做得比较高效了，接下来测试数据的问题渐渐成为问题的瓶颈。

数据分两部分，一部分称之为Date-driven test date，这是指这个测试所需要用到的输入数据，举个例子，同样的Login Flow会用到不同的测试数据，有可能是合法用户登录，有可能是不合法用户登录或者是密码过期用户登录，这几类用户的测试数据本身就构成了Date-driven test date。在早期的实现中，这些相同脚本但测试输入数据不同的场景会被定义成多个测试用例。引入测试框架后，通常的做法是把这些测试数据统一管理在一个CSV文件或者XML文件里，然后统一的测试用例里面通过Data Provider去解析这些数据并传递给测试用例。第二部分测试数据，做测试的同学都知道，就是测试前置数据。比如说我们做用户的Login。那这个用户我们是已经假定这个用户是存在的，这就要求我们在测试开始之前提前准备好这个用户数据，通常我们会在Before Test这类方法里面调用Test Data Preparation Tool在被测试环境上生成这些测试前置数据。生成这类测试数据通常采用调用API或者直接DB插入的方式，对于功能测试数据的生成推荐尽可能采用API调用的方式以确保测试数据的完整性和正确性，但是对于一些性能测试的前置数据，可能数据量级会非常大，即使采用并发API调用的方式也很难在较短的时间内生成百万级别的数据，所以推荐采用直接DB插入的方式或者后台异步数据生成的方式。

在测试开始之前大量使用Test Data Preparation Tool去生成前置测试数据会带来一个潜在问题，就是这些数据的准备就可能占整个测试脚本执行时间的很大一部分。比如测试用例想要做一个“商品买入”的操作，但是在这之前你可能需要准备卖家，准备卖家的商品，准备买家账号等一系列的测试数据准备，这往往占用了很大比例的测试执行时间，那是不是有办法可以减少这部分的执行时间，答案就是使用Out-of-box Test Data，又称Golden Data Set。具体来讲就是在测试环境准备的环节就把大部分典型测试需要的数据事先导入好，测试用例直接使用这些已知的数据进行测试，那上面的例子来讲，“商品买入”对应的商品已经卖家在测试环境上已经预先准备好了，“商品买入”操作可以直接执行无需数据准备。但是这样的方案也有明显的潜在问题，就是怎么保证这些数据的状态已经用例之间数据的干扰。后面我们在讲测试数据平台的时候还会继续探讨这个问题。

基本解决测试数据的问题之后，我们再回来看看Business Flow。 同一个Business Flow可能在不同的情况下会经过不同的Page，比如说某个业务在美国的站点会经过Page A到Page B，但是同样的这个业务在欧洲的站点会经过Page A到PageX，然后才到Page B,但是业务上讲这两个不用的Page路径对应的是同一个业务流程，这就要求UI automation framework级别需要能够处理Flow Branch的能力。这样就可以做到同一个业务流程只有一个统一的Flow，这个Flow可以根据Site参数的不同自动识别不同的Page Path。

进一步，我们会采用Page Encapsulation Code Generator来自动产生Page类，以降低人工去维护各种页面元素定位的复杂性，同时还会引入Page类的版本管理机制，以确保测试用例的向后可追溯性。HP的QTP中有个叫“页面对象库”的概念，并且这个对象库也可以自动更新，两者的理念是完全一致的。

再回到Test Data这个话题，之前说过用Out-of-box Test Data会带来测试用例之间数据干扰已经脏数据的问题，同时使用Test Data Preparation Tool也会有API更新的维护问题，那有什么方法可以一并解决这些复杂的测试数据问题，答案是使用统一的Test Data Service.Test Data Service会提供统一的接口去解决所有测试相关数据问题，具体内容会在以后的分享中谈及。

API Automation Test Framework的演变

最原始的API测试通常是基于POSTMAN和SOAPUI等工具，直接在被测试系统上发起API调用并相应验证response的内容。

随着CI/CD的兴起，希望把API测试纳入到整个CI/CD的流程中，所以Code-based API Test Framework逐渐流行起来，很多公司都自己开发了自己的API测试框架，ebay内部就使用MAUI API和Breeze API来做自己的API测试。

随着测试用例的逐渐变多，混合了测试逻辑和测试数据的API测试脚本变得非常冗余，所以就需要把测试数据从测试用例里面分离出来，形成基于数据驱动的API测试脚本。也就是所有的测试输入数据将在统一的数据源，比如CVS或者XML里面统一管理，然后通过统一的Data Provider去传递测试输入数据。

有了统一管理测试数据的地方之后就大大方便了测试数据的设计和排列组合，但是通常的测试更多关注点还是在业务数据的覆盖率，而对于数据边界值很少做测试设计，这就造成很多defect的遗漏。比如说某个API的参数类型是string，但是测试用例的数据没有考虑改参数为NULL和EMPTY等情况，以至于测试遗漏，所以Automatic Test Data Generator被引入来减少此类情况的发生。当Automatic Test Data Generator检测到测试输入参数的数据类型后会自动生成这些数据类型得边界值和极限值以保证测试设计的高覆盖率。

很多情况下需要测试API在并发情况下的潜在问题，比如死锁和性能问题，所以需要引入API并发执行控制器以实现API的并发测试场景，通常需要提供测试并发数，集合点和思考时间等参数给并发执行控制器。

对于后台Service的性能测试，通常会需要进行大规模的压力测试，这时如果单凭一个server去发起测试load显然是不够的，这时就需要引入扩展API并发执行控制器区支持Load Generator Cluster.

随着API测试用例的数量不断增多，有个新问题付出了水面。在传统的API测试中，通常只会assert我们明确需要assert的内容，对于我们没有显示指定assert的内容是不会去做assert的，这就造成有些change并不能被API测试捕捉到。我们希望可以有一种机制可以识别出两次API调用返回结果的差异，以此识别出变化以防止API升级过程中的后向兼容性问题。为此我们引入了一个中间数据库记录不同版本API调用的request和response集合，一旦发现同一个API在相同参数下调用返回的data scheme有不同的时候，就会给出对应的警告。当然对于时间戳，token和ID等动态数据可以通过规则配置方式来排除掉。

随着微服务化的进程不断推进，API测试方法必须符合微服务的测试要求，如图所示，微服务下对API的测试提出了很多挑战。我们急需一种高效的测试方法论以及相应的测试框架来支撑这些挑战。由此“基于消费者契约的API测试”应运而生。以图上的例子来看，Service T是我们的被测试对象，假定T提供了10种API接口供其消费者Service A和Service B使用。以传统的API测试方法，我们需要覆盖所有的10个API接口以及每个API的所有的参数组合，这样的测试覆盖率要求在单体应用时代是可以接受的，但是在微服务时代，由于微服务本身的数量很多，就会造成测试用例数呈指数级增长，以至于在单个release周期内很难执行完所有的测试。那有什么办法可以减少测试用例数量但是又能同时保证质量。现在T是服务的Provider，假定目前只有A和B两个consumer，那么我们只要能够保证A和B对T的所有调用都被测试覆盖到，那就能保证T的质量，所有的consumer对T的调用就构成了T的契约，我们只要能保证这些契约测试能够通过就能保证T的质量。这就是契约测试的原始出发点。那么问题来了，怎么拿到所有的契约呐？

典型的做法就是在T前面放一个代理，所有的request和response都会经过这个代理，那么分析这个代理的日志就能拿到对T的契约。 拿到T的契约后就可以用次来对T进行测试，也可以用于测试过程的依赖解耦。

GITC2017北京站各演讲嘉宾的PPT已经开放下载，请点击底部“阅读原文”下载获取！

原文链接：http://www.wzcl.net/social/youtube/9875.html，转载请注明出处~~~
免责声明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的；不得将上述内容用于商业或者非法用途，否则，一切后果请用户自负。本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！