摘要：随着双 11 全球狂欢节的深入人心，在大促规模越来越大的同时，难题也摆在阿里测试人面前。如何既遵守大促保密性要求不提前透露玩法，又能提前验证到大促当天运行的功能？本次分享再现大促历史性难题的解题过程，并由此展开，谈到从一个大促保障平台产品，将该产品的底层能力分拆和下沉，为阿里巴巴集团各业务测试团队提供创新的底层能力。
演讲嘉宾简介：
李子乐（太禅），阿里巴巴资深测试开发专家。毕业于浙江大学信电系。2010 年初加入淘宝，负责 PC 自动化测试框架的设计，包括淘宝全网 Web 自动化和旺旺客户端自动化等测试体系的构建，是淘宝开源自动化测试框架 automan 的架构和主要开发人员。从 2011 年接触无线，开始搭建团队，负责设计无线自动化测试框架，及无线自动化持续集成体系，并完成阿里第一套无线自动化框架 athrun 的开源。2013 年 all in 来往，后于 2014 年加入天猫，负责手机天猫测试团队，现为新零售技术质量测试效能与飞猪质量的负责人。
点击直播视频精彩回顾
以下内容根据演讲视频以及 PPT 整理而成。
一、背景-大促活动保障难点
玩法极其复杂： 阿里大促保障活动中的玩法极其复杂多样，如下图中的几个页面。第一个页面是日常态玩法，包括红包和店铺优惠卡券。但在双 11 玩法会增加很多种类，如第二个页面中的预设玩法，第三个页面中双 11 当天的售卖情况，以及最后一个页面中的双 11 整体的优惠情况，其中包括购物津贴、店铺卡券、满减、限时优惠等等非常丰富玩法。
无法真实验证： 此外，阿里做预演时无法提前预演双 11 当天的活动。目前的验证方法一般通过构建一个测试活动或者预发项目 debug 的方式验证。以上两种验证方式效率非常低，而且无法验证真实的场景。
量级大： 数据显示，2018 年双 11 达到了 2135 亿的 GMV，菜鸟数据显示 2018 年线上包裹量约为 10.24 亿。如此量级的包裹数量无论对于交易还是履约或者物流系统都是极其大的考验。
在此情况下，阿里希望有一套方案，可以解决大促难点。首先，可以提前模拟大促情况，且覆盖新老玩法，并且需要关注在老玩法叠加新玩法的情况下，系统是否会产生额外的问题。
其次是模拟真实用户场景，包括用户会在优惠活动之前以及预热时提前凑单，提前加购等场景。最后是场景聚类分析。一旦模拟真实场景下的用户行为，需要分析覆盖了多少用户，覆盖度如何，弄清楚哪些用户没能覆盖，这些场景都需要聚类分析的能力。
二、全链路功能-能力建设与实现
1. 环境能力
JVM 修改时间： 环境能力是从阿里两三年前开始构建的，当时是隔离环境，专供给压测使用的。当时的能力可以将环境隔离出来且不会影响线上。隔离能力是之前压测所具备的一个基础能力，在隔离能力之上，阿里开始研究是否需要具备时间修改的能力。时间修改主要是两个方案。首先是修改机器时间，其缺点是需要改很多物理机或者物理机上某几台虚拟机，但虚拟机可能不在隔离环境，可控性非常差。阿里最终选择了第二套方案，JVM 修改时间。将系统时间在初始化在界面布置时做一个偏移，可以令系统在启动时的时间设为已经偏移好的系统。JMV 修改时间最基本的时间控制的能力。
隔离环境： 阿里起初建设的隔离环境时并没有很完善，其中包括环境的 HTTP 入口，ACL 的流量，或者直接从 VIP 入口过来。入口梳理不全会导致被修改过时间的系统上跑了一些线上的流量，这是极其可怕的。
流量大图： 有了流量大图之后，非预期的流量可以看得非常清楚，可以作为兜底保护。在发现有非预期的流量进来之后，执行一套控制机制。如一些应用在隔离环境上部署，而有一些应用是隔离环境上没有部署的，应用之间相互调用时，一旦发现下游的应用没有在隔离环境里出现，则会有一个 fall back 机制重新让它回到线上。进行了整体的逻辑梳理后，可以分清哪些应用需要修改时间，哪些应用不需要修改时间。
灰度环境： 2018 年阿里开始做灰度环境，灰度环境是隔离环境的升级版，其最主要特点是具备多套环境能力。一旦环境的使用方越来越多，可以在多套环境之间切换。
能力升级： 除了多套环境之外，阿里还开发了一些能力的升级，如流量定制，资源管控和灰度流程。流量定制可以定制比如 8 套环境，定制不同流量到到不同的环境中，可以互不干扰。资源管控包括环境的申请，业务方可以通过接口方式调用申请环境，也可以对环境进行扩容或释放。并且整个发布流程跟阿里的发布系统 Aone 进行了打通。越来越多的发布需要走预发环境，beta 环境，或者 SPE 环境。灰度环境跟 Aone 打通之后，预发环境执行完后可以走到灰度环境进行发布，灰度环境验证通过之后再上线。
2. 数据能力
业务关联表的维护：数据层面真正需要关心的业务很多。如用户层面包括用户收货地址、积分、淘金币、卡券红包、资产类和购物车等信息，以及用户信息的脱敏，包括用户手机号、收货地址等。商品层面包括商品优惠、运费模板、服务、库存和店铺卖家信息等。业务关联表的维护包含两部分。首先是购物车方面，既用户层面的加上商品层面。另外一部分是新玩法的模拟。如预售时 N 免 1 或者双 11 购物券，需要将相应玩法的库表进行同步。预售商品还包括预售订单以及后面尾款的推进。根据 2017 年数据，整体具备的能力达到 1.07 亿用户，4379 万的商品，165 台机器 12 小时做整体的数据同步，数据同步的量级达到 65 亿。
3. 执行
执行需要做全链路模型的构建。首先，必填项不会修改，且会相应完善，如果没有必填项信息则无法下单，如选择门店、身份证、手机号等。此外，按最优尽量多的覆盖逻辑，比如收货地址会选择当前地址首选收货地址、卡券红包默认勾选、购物车尽量多的选择用户当前购物车里面的商品。按比例模型包括 PC 无线固定的占比、购物车立即购买、淘金币积分的比例。
4. 校验
此外，阿里在下单方面补充了校验能力。通过执行大量用例衡量测试效果，构造过程中的失败分析。构造完之后去下单并返回返回值，再校验返回值。BCP 是阿里通过规则做校验的框架，用来做消息的校验和数据的校验。
5. RBC—基于请求的代码覆盖
发现有错误码之后，需要逐个对错误码进行分析，这时就引出 RBC。错误码一旦真正跑出来，由于用例非常多，发现的错误也非常多。此时需要一个机制做不同的错误码的分析。即使是相同的错误码，经过的路径可能是不一样的。因此阿里实现的 RBC—基于请求的代码覆盖工具，起初在发现很多错误码情况下做错码的分类，目前可以做当前执行情况的分析。
RBC 的特点首先是基于请求的代码覆盖，与传统的代码覆盖不同，传统代码覆盖是跑一两个小时或者跑半天，然后停掉覆盖率，再覆盖数据收集上来。而 RBC 会将每一个请求生成一个覆盖率的文件。另外，RBC 具备跨应用聚合能力，在不同应用间通过 trace 做聚合。在跑很多用例之后，RBC 可以推荐真正有效的用例。后续可以通过有效用例集做持续集成回归。
三、全链路功能-结果
1.2016 年双 11
自 2016 年，阿里开始实现全链路功能，可同步 1.07 亿的买家，4379 万加购商品，覆盖八大类优惠，7 种红包玩法，覆盖积分，淘金币等 4 类资金交易工具，覆盖天猫超市，国际等 6 大垂直业务。执行用例达到亿级，并发现了三个隐藏的 bug。
2.2017 年双 11
2017 年除了购物车提前下单之外，覆盖了一些新的核心玩法。同步 6200W 买家的加购商品 5896W 个，包含优惠 313 种，红包 17 种。核心玩法对接了多种玩法，涵盖 2017 年双 11 核心玩法，包括预售、抢先订、买返、全渠道、智慧门店、天猫出海、以及 TP3 迁移等风险较大的业务。2017 年提前发现问题 19 个，其中 7 个问题是通过线上数据订正或者是线上配置解决的，7 个是一定要线上发布的，因为全链路功能基本是在 11 月 1 号之后开始测试，7 个线上发布的 bug 都需要紧急发布。另外，发现 5 个影子问题，主要是影响压测的风险。
3.2018 年双 11
在购物车具体玩法覆盖的基础上添加了用例精简的回归。精简回归将购物车仿真的用例通过 RBC 的能力精简出来，精简用例可以反复运行。2018 将 3000 万的用例精简到了 46 万，46 万基本上在双 11 之前进行每日的回归。2018 双 11 新业务接入了所有核心的业务，包括飞猪回迁和新零售。此外，接入的新玩法包括信用购、新预售、零售通、优惠精简等。接入的行业大型项目包括 1 小时达与超市主站融合、招商商品大促多报项目、阿里健康 OTC 首报大促项目。贴近重点玩法提前发现了 34 个 bug，其中包括 11 个预售问题，以及 164 万笔订单无法支付尾款问题。
四、测试水电煤-数据、环境、RBC
在全链路功能演进过程当中，数据、环境和 RBC 作为整个测试的基础设施，正在慢慢变成业务测试创新的驱动力，可谓是不可或缺的水电煤。
数据能力
数据具备怎样的能力？首先数据需要具备从线上同步到影子的能力。其次，数据需要具备脱敏规则。另外，数据可以指定商品增量同步。阿里刚开始做了全链路同步，包括同步购物车、亿级的商品、庞大的用户，都是一次性同步，量级达到 60 多亿。后来实现增量增量同步的功能，一旦指定了某个商品进行同步，商品对应的后端所有库表都可以被同步。
环境能力
环境能力包括多套环境，如两个相互的业务方都依赖同一应用，之间不会相互冲突。其次是动态扩缩容，无论在 beta 环境还是 SPE 环境，在环境里面机器相对来说是固定的，环境的资产投入是一次性的。动态扩缩容需要用某一套环境做一个大型活动，可以临时的去其它环境或者从线上临时将机器挪过来。动态扩缩容可以节约很大的成本。自定义引流策略支持的能力可以根据相应的 HTTP-head 信息，用户 id 或者根据相应的 IP 地址的规则进行自定义。
RBC 能力
RBC 具备跨应用聚合能力，在不同应用间通过 trace 做聚合。流量按代码覆盖聚合，将每一个请求生成一个覆盖率的文件，报告覆盖率。在跑很多用例之后，RBC 可以推荐真正有效的用例。
1.数据能力
数据赋能-零售通-全链路精准自动化平台
零售通是流动式的小店，包括校园店，夫妻店等店。零售通本身逻辑非常复杂，可分成几个区块。第一区块是商品区域化售卖，其中包括仓配和店配。其次是整个复杂的区域化的营销。供应链的体系包括仓组的体系，区域，城市到前置仓分级的体系。另外是仓库路由，仓库路由包括从仓到供应链的关系。零售通的背景模型组合较多，并且数据复杂。由于零售通线上数据很多，通过手工测试极其容易遗漏。此外，零售通业务迭代非常快，模型改动非常频繁。零售通会经常做较大的重构，玩法更新较快。
零售通的解决方法是实现了一个实时构建的模型系统。查出线上模型的模型体系，考虑商品是一口价异或是不同的单品优惠，以及店铺优惠的使用的情况，还有各个仓配的模型。模型从现场拉下来之后，可以根据模型实时匹配出线上的数据，将其同步到影子表。零售通的案例与全链路功能的案例相似，都是模拟整个下单交易的体系，相对复杂的地方是交易和优惠等部分。零售通不同点是 Join 能力，零售通复用了 PC 自动化能力和无线自动化能力。首先在线上将具体单子跑下来，线上基准模型，再与预发上的模型进行比对，做图片对比校验。下图应用了从线上读，并同步到影子写的场景。同步的库表包括会员的大量库表，商品和营销的库表。零售通整体结果是支持 100 多个项目，整个模型构造的速度达到五分钟以内。当前用例数达到 4 万，整体执行效率每分钟 2000 个，发现 30 多个 bug。
数据赋能-菜鸟-神舟
菜鸟和阿里集团体系不同，菜鸟的特点是整体链路较长。菜鸟分为下单、发货、接单、下发仓、仓接单、仓出库、具体的分拨、干线揽收情况，快递员配送，以及最终妥投。整个链路涉及到两百多个应用。另外，菜鸟无法复用交易下单能力。全链路压测功能构建起来的影子体系难以复用。此外，菜鸟整体变更较多，架构升级非常频繁。架构升级频繁意味着菜鸟需要通过全链路的方式做保障。
神舟依赖影子链路和数据同步的能力，将商品、买家、卖家信息等基础数据进行同步，再分析线上订单情况，对线上订单进行分析和聚类后，做相应的订单的偏移。菜鸟没有直接同步订单，而是找开发包装了一个接口，接口会直接创建物流单。线上原来有个物流单，做偏移之后创建的物流单可以开始往下流转，跳开链路中下单的过程。创建物流单之后再往下去流转，与线上进行对比校验。这导致整体方案对比校验难度较高。菜鸟的校验是使用 DB 层 binlog 对比，对过程数据进行校验。记录线上快照写入的字段，维护映射关系。影子再向 DB 层插一条数据，与原来线上插入的数据进行对比。神舟开发了多种执行策略，包括预发/线上影子链路，执行模式有区间式，全链路和单链路。区间式在全链路中选择几个应用。神舟整体结果到 2019 上半年用例数达到 60000+，发现 207 个有效 bug。
2.环境能力
环境赋能-中间件-灰度验收平台 MASA
Pandora sar 包是一个隔离 jar 包依赖之间复杂性的容器。中间件测试团队负责维护 sar 包，包括 sar 包版本的迭代和升级。中间件测试团队遇到的困难首先是测试环境真实性不足，导致 Pandora sar 包频繁重发。在日常环境中很多情况测试不到。预发环境除了数据库共用一套之外，机器、网段和机器的配置都和线上不同。此外，Beta 环境中部分应用没有 beta 机或者没有绑定 VIP，没有隔离或者隔离不干净。小淘宝配置和代码与线上环境千差万别，导致无法非常好的应用环境。另外一个痛点是应用非常多，且用法各异。上万个应用，每个应用的用法都不同，如不同二方包的依赖，类加载顺序的不同，插件配置的不同都会导致 Pandora 启动失败。
中间件测试团队的解决方法是首先使用灰度环境。从线上动态的划分机器到灰度环境里面。其优点是不需要实时保持机器都在灰度环境里，日常或许只需要 100 个应用，或者再上云验证时再多拉取一些应用。定向引流引的是功能流量和压测流量。起初 MASA 只使用了压测流量，但只有压测流量不能提供很好的服务。功能流量像现有的自动化流量，支持全链路自动化功能，创建回归的能力，中间件等。MASA 的结果在 2019 年验收 sar 包 1292 次，即表明 MASA 通过不同的策略做了 1000 多次验证。在灰度提前发现了 38 个 bug。
环境赋能-新零售终端-天狼灰度平台
新零售终端服务的业务还是较多的。终端指店员手持的终端 POS 机。目前零售通，居然之家，红星美凯龙，盒马都在使用新零售终端的 POS 做线下业务。而线上业务与线下业务在具体问题上是非常不同的。首先是线下业态直接进行灰度发布风险较大。在超市结算排队的场景，传统的灰度可能 100 台机器会灰度一两台机器，可能在某一单中顾客购买了 20 个商品，其中一个商品下单、结算时会出现问题。这个概率可能达到 1/4~1/5。灰度过程中如果按照传统方式做灰度，百分比流量的影响面是不可控的。其次，灰度一旦发现问题，回滚非常慢，若想将线上发现问题的机器回滚掉，可能需要半个小时到 1 小时。线下体验的故障影响时常是不可控的，缺乏快速恢复的能力。如果出现线下故障导致 POS 机不能结账，消费者就会把购物车丢到排队线上，还需要保安维护秩序。顾客线下购物的成本非常高，如花费半个小时到超市，又花半小时挑选物品，这时顾客得知不能结算，在线下体验会非常差。整体的风险需要额外方案去保障。
对于终端服务的解决方案是使用整个环境的能力做流量定制。按 POS 做灰度，比如一共有十条 POS 线，其中一条 POS 线是可能会坏掉，则可以请顾客先不要在这条线排队，告诉顾客这台机器坏掉了，请到其它线排队，相对来说顾客会比较理解。另外一个好处是可以做到快速回滚，因为按 POS 其实是一个引流规则，引流规则可以很快的删掉，快速切流回滚，恢复线下消费。天狼灰度平台的结果是整体灰度发布验证 345 次，提前发现 13 个问题。
新零售终端和天狼灰度平台还在一起建设灰度有效性度量标准。因为无论是通过灰度环，还是通过安全市场，灰度规则的设定还是偏向于“拍脑袋”决策。共建灰度有效性度量标准会做整个灰度的测试报告，灰度整体流量的情况做灰度范围的确定。比如，新发布的代码是否都已经被灰度流量覆盖到？如果没有覆盖到，则会有一个灰度报告出来，到灰度报告里去确认流量都是有自己线下手工验证过的，或者再补充手工测试用例确保可以覆盖到那部分代码。
3.RBC—基于请求的代码覆盖
RBC 赋能-蚂蚁国际-精准回归
目前阿里庞大的单元测试用例，接口用例，导致回归耗时很长，以蚂蚁国际某一个核心支付应用为例，4000 个自动化的用例，通过持续集成和持续交付，代码合并之后跑一次需要 60 分钟，整体的回归非常慢，持续交付价值难以发挥。传统做法是对用例筛选分类，如通过应用或者接口做分类，维护某几个接口分别对应的用例，更新接口时只需要跑一部分用例。另一个痛点是维护关系需要定期维护。这种方式相对来说粒度较粗，准确度不高，人工投入较大。蚂蚁国际的解法是通过将用例执行引擎，接入 RBC，记录用例经过的具体代码，根据代码变更去推荐用例，做到精准推荐和精准执行。上线新的代码，相应的代码在之前执行用例时 trace 被记录下来。一旦 trace 修改过，将之前已经执行过的用例筛选出来重新做执行。
目前，蚂蚁国际有 180+应用在使用精准回归。蚂蚁国际精准回归的应用叫 Compass。Compass 每月支持 1.25 万次精准测试的构建，单次平均节约时间 12 分钟，累积节省回归等待时间 14.4 万分钟。
RBC 赋能-新零售-暴雪
暴雪采集线上真实的流量做回放。通过采集记录应用入口流量以及下游调用的其它应用的流量，在下一次回放时直接依赖之前记录的数据做回放，生成自动执行的接口测试用例。暴雪的特点是门槛低，无需提前准备数据，也不需要提前编写脚本。暴雪第一个版本的缺点是大量的录制回放用例重复度非常高。每天有不同的消费者在下单，请求跟请求之间的逻辑覆盖差不多，并且回归的时间非常长。其缺点是执行场景不可控，而且没有沉淀，无法得知覆盖是否足够。针对上述痛点尝试对用例进行相应的打标，如识别优惠券使用的情况。打标需要对业务逻辑进行人工梳理，成本较高，整体投入非常大。
暴雪的解决方法是与 RBC 合作，通过对流量逐个请求代码覆盖收集。对流量进行精简，筛选一致和不一致的流量，提取并保存出不一样的流量。再进行用例推荐，如跑了两三天或者一星期存了很多的流量，后面又跑了一天跑出新流量，新的流量会被推荐出来，推荐给测试，测试确认新的流量确实有新的业务含义，则保存下来。同样，RBC 也被广泛使用到业务平台的天启，以及菜鸟青龙的自动化平台。目前暴雪推荐用例数目超过 50 万，整体发现 bug 的能力上佳，用户上报发现的有效的 bug 数统计超过 70 个。
最后，希望有越来越多的测试产品下沉，成为驱动测试创新的水电煤。目前的一些产品，如流量的采集和回放，都可以变成一个基础设施。希望效能团队真正做出一个产品后，不停深挖每个能力。做出一个创新之后，创新所依赖的非常多的底层能力可以沉淀出来。沉淀出来的功能可以赋能非常多的产品去做创新。这时业务测试同学也可以有自己的创新空间，效能同学也会有动力更好的维护下沉的产品，更好的做测试创新，成为驱动测试创新的水电煤。最后，希望有越来越多的测试产品下沉，成为驱动测试创新的水电煤。目前的一些产品，如流量的采集和回放，都可以变成一个基础设施。希望效能团队真正做出一个产品后，不停深挖每个能力。做出一个创新之后，创新所依赖的非常多的底层能力可以沉淀出来。沉淀出来的功能可以赋能非常多的产品去做创新。这时业务测试同学也可以有自己的创新空间，效能同学也会有动力更好的维护下沉的产品，更好的做测试创新，成为驱动测试创新的水电煤。
文章来源：阿里巴巴技术质量
开发者社区整理
