阿里QA导读："大中台小前台"的组织和业务体制已经是互联网老生常谈的问题了，外卖场景作为最火热的线上线下场景，日均单量动辄千万量级，想要把交易流量融入到集团统一的中台架构体系中，难度无异于在给高速行驶的汽车换轮胎，对项目组尤其是质量守护同学提出了巨大的挑战，该如何应战？本地生活的雨清同学给大家带来架构升级质量保障的手段和思考，希望对大家有参考价值。
引言
2020年外卖业务经历了大范围的架构升级，将外卖的交易流量融入到集团统一的中台架构体系中，前后耗时半年，参与的技术同学超过了200+，代码量200W+，用例量10000+，从数据上不难看出项目的浩大和紧迫。除此以外，这个半年中，技术团队照常承接业务需求，大部分项目经历了在原有的弹外链路研发上线之后，在切流前在弹内链路追平需求的过程，整个项目过程类似于飞行中切换引擎。一个日均单量几千万级的业务，任何的质量问题都会被放大，都有可能引发重大的故障，因此对于测试团队来说是一个非常大的考验。从另外一个角度来看，深入参与到这么具有挑战的项目的机会是非常少的，在过程中踩过的坑、做过的一些思考也是非常难得的，本文记录了过程中几个真实的场景，通过分析当时的目标、遇到的困难、应对的手段和思考，希望能给大家带来一些有价值的参考。
背景
架构升级项目的目标是通过技术升级将外卖业务融入到中台体系中，与各个BU充分协作形成合力。项目的范围主要包括了：商品、店铺、导购、营销、交易、支付、结算等多个域，简单来说，就是涉及到交易流程中的各个相关方。
项目的主要挑战
这一小节简单说明一下项目过程中遇到的三个主要的挑战，方便大家理解后面的具体场景下的选择。这几个挑战是贯穿整个项目，也是测试过程中的“上下文”。
团队协作
因为项目而组合起来的几百人的技术团队，来自不同的BU、不同的部门，有各自的工作模式和规范的流程，这带来了最主要的一个困难是，大家对于研发流程的SOP理解不一致，对于提测质量的重视程度也不一致，最终导致了交付质量不合格，对于测试进度的冲击非常大。
任务重、风险高
就像背景中描述的，项目工程大、时间紧，除此之外，从测试的角度看，质量要求高、保障难度大。一个成熟业务背后的技术升级，必须要保证业务的功能性、可用性、稳定性、安全性等各个方面跟升级前不能有较大的偏差，因此在测试过程需要考虑的东西就会很多；此外，在大流量的背景下，所有的小概率事件（异常场景、极端场景等）都必然会发生，因此对于测试全面性的要求就非常的高。
非常不幸，正如大部分的大型项目都会遇到的头号风险--进度风险，在这个项目中体现的淋漓尽致：每一个重要的时间节点上，我们都遇到了非常大的质量挑战。
意外频发
项目的过程完全应验了墨菲定律，几乎所有可能遇到的状况，最终都成为了意外状况。主要有：环境问题突出、交付质量不及预期、性能问题、仿真延期、以及各类进度风险等。
其中环境的坑就从头到脚的踩了个遍：从弹外线下环境下线、弹内预发环境没有DB资源，到生产环境的中间件资源到位时间不及预期。其中生产环境的单元DB迟迟不能到位，也曾使我们面临选择：是等资源到位后在发布，还是修改TDDL层通过中心化先发布等到资源到位后再重新改回来？考虑到整体的节奏以及多个BU之间发布的依赖性，最终选择了后者。
质量保障架构的取舍
每个项目的质量保障基本都可以划分为四块内容：流程优化，基础建设，线下测试，线上质量，每一块又根据各个团队的实际情况划分为不同的内容，这些内容一旦固定并沉淀下来，就成为测试团队的“工具库”，在后续的项目中可以随取随用。外卖入淘项目给原来的质量保障架构带了非常大的冲击，基本摧毁了整个“工具库”。在项目过程中重建这一套保障架构是非常困难的一件事，简单来说可以概括为三个字：无、难、急。
基础质量保障
本地生活平台的质量保障架构主要内容部分如下图所示，通过“流程优化”来规范人的部分，从而保证过程质量、发布质量；通过“基础建设”来保证测试的“水电煤”--环境、数据、工具；通过“线下测试”来保障新旧功能；通过“线上质量”来保障线上的稳定性。在每次项目迭代过程中，质量架构中大部分的模块是现成的可以直接使用，只有少量需要跟随项目进行部分的更新。
架构升级项目质量保障
本期项目中，由于整个外卖平台的架构进行了升级，测试环境、链路、数据、回归体系、工具建设、线上保障等等全部被推翻，导致了整个质量保障体系被击穿。如何在项目过程中重建保障能力，成为了当时最大的一个难点。
无：
- 无规范的研发流程
- 无现成的测试环境
- 无现成的测试数据
- 无回归体系
难：
- 测试全面性难以保障
- 校验的全面性难以保障
- 核对监控的正确性难以保障
急：
- 项目周期短，测不完
分析了以上困难后，我们在项目过程中将保障能力划分为核心保障和基础保障。简单来说，核心保障是保命的，必须要在外灰前建设完毕的；基础保障是不完成，也不会出现大范围的线上问题或者导致项目延期的保障能力，基本都放在了外灰之后进行建设。举个简单的例子，在9月初的时候，稳定性小组的两个子项目寻求测试资源，一个是灰度中心、一个是仿真项目。考虑到灰度中心是决策每一笔交易流量走弹内新链路还是走弹外老链路，如果出错将是“要命”的，所以灰度中心是需要核心保障的，投入了专门的测试人员；仿真项目，本身是作为测试覆盖的补充，在测试人力吃紧、基于经验设计的测试用例还在不断发现bug的前提下，仿真保障的优先级就相对较低，最终没有投入测试人员（在此，感谢稳定性小组同学的理解和支持）。
图中红色部分都是项目过程中重点投入人员保障的部分；蓝色部分是在核心保障建设完毕后，才投入保障的部分。需要说明的是，蓝色部分并非不重要，而是基于当时的节奏、人力、质量的一种取舍，而每一次取舍都会有相应的收益和代价。基于这样一个质量架构分时段建设的策略，我们在大促前顺利的完成了切流的目标，没有出现重大的线上故障；同时，我们也付出一些的代价，以图中“线下测试“中的“异常场景验证”为例，交易、营销平台都是对于异常处理非常敏感的平台，由于外灰前没有进行充分的异常验证，最终导致这两个平台在灰度期间出现的几十个线上问题中，近一半是异常处理的问题（发生概率低，没有达到P级）。
另外值得一提的是，本期项目中引入了“基础建设”下的“数据报表”，并作为了核心保障能力。这是因为，在整个灰度切流过程中，我们需要大量的数据分析来验证线上的真实情况。以“加购到下单的转化率”为指标，灰度期间需要精确分析，小到同一个门店下走新链路的用户转化率和走老链路的用户转化率，是否出现了较大的差异；大到同一个城市下，是否出现转化率的差异等等。此外还有非常多的指标，只有确认每一次增量切流后，各个指标正常，才能计划下一次的切流。简单来说，数据报表是切流的依据，也是“生命线”。
总结来说，质量保障体系的建设需要因时、因事而定，需要考虑时间、成本、风险、效果等因素，每一个选择都有它的利弊，没有绝对正确的决策，只有更适合当时情况的选择。个人的一点建议是，平时需要针对所负责的业务梳理出完整的质量保障大图，并深刻理解其中每个质量保障专项的内容、成本和效果，这样在应对大型项目冲击的时候，能快速的理清利弊，筛选出必要的专项。
