“618”成功背后的秘密：京东大促互动营销活动测试体系建设

点击上方“DevOps时代”，关注并星标，精彩好文章，关注不走丢~

嘉宾简介：金强强，现任京东零售测试架构师，负责公司互联网测试及质量管理体系建设，以及效率平台化的构建实践工作，历届京东T级大促活动质量及效能提升负责人，对测试思想、测试模型搭建、工具选型建设、全栈式测试等领域有深入探索和实践。

说明：本文根据金强强老师在 GOPS 2021 · 深圳站的速记整理而成，更多精彩，请关注 DevOps时代公众号。

围绕着整个京东互动活动展开来讲，分为四个部分：

• 第一：互动测试认知
• 第二：测试流程及SOP
• 第三：互动测试过程
• 第四：互动框架及平台化

一、互动测试认知

什么是互动？

互动是为了提升DAU、拉新或者从传统买买买的电商平台慢慢转变成为让用户玩起来的平台。618、双十一和年货节的所有主题，主要的玩法在养成、PK和强裂变。养成类就是要把用户的心智培养出来，今天来了京东明天还想来，养成用户的行为习惯，PK为的是让用户玩起来，而非单纯枯燥的购物流程，在“玩”中体验购物客诉，并通过分享裂变带动更多的人来玩，实现场景中分发引流，为平台带来DAU、GMV等等。

互动测试有什么特点？

互动测试的特点是时效性、复杂性、场景化和用户属性等，而且玩法是自闭环，所有的内容不依赖于平台其他的玩法，自成一套玩法体系。

我们该如何针对这些特征进行测试破局，大概思考以下四个方面：

• 一是测试思路转变：要从以前单接口单场景的测试转变成场景化的贯穿测试，从分端的思路转变成分场景思路；
• 二是测试流程制定：我们当前制定的测试流程更加偏向于固化迭代类型的测试，对于互动类这种新型的测试模式会存在流程上的漏洞及不足。从产品到研发测试，再到最后运营、运维是整条链路线，每个环节都需进行质量保证。在测试保障上面有左移和右移的测试体验，左移有需求分析及研发自测门槛，右移到线上监控。
• 三是测试效率提升：测试周期非常紧，如何在有限的时间内最高效的保证质量，靠人力堆积的时代已经过去，按照组件化思路，将当前测试内容原子化，最大范围的赋能，包含脚本自动化骨架建设、用例骨架建设、测试垂直化工具建设等。
• 四是测试能力的拓展：要把当前的测试从所谓的“黑盒”往“灰盒”转变以及从“灰盒”往“白盒”转变；横向的扩展业务视角，扩充场景用例，纵向深入代码框架层，从代码层面提炼可以为测试服务的点，目标将“代码学习”真正往“测试应用”层面的转变。

如何看待被测需求，拿到需求之后该怎么做？

不单单是京东，其他的互联网公司都是相类似的研发架构，只要软件形成一定规模后会发现协同的重要性，为了提高研发测试效率，减少重复造轮子的问题，需要将能力组件化、原子化、SaaS化。

作为前台业务层来说，我们更多的是进行组件的拼装，在组件层面基础上进行自定义逻辑的编码，满足业务方的需求，从上图来看，中间的服务端SOA和客户端就是我们的测试对象，其他依赖的各种组件就是我们的上游，我们的核心测试功能就在自身的SOA层及客户端模块层，而非依赖的组件层，需要做到精准测试，而非同样的时间捡了芝麻丢了西瓜。

服务端依赖的上游以及客户端依赖的其他组件，在用户的眼中仅仅是我们前台的实现的页面，他们没有感知，但是在专业的测试同学眼里应该是整个的贯穿流，这点非常重要，透过现象看本质是作为一个专业测试的基本要求，页面中做的任何操作行为所触发的是什么接口，什么组件，你需要知道这个数据的源头是哪里、下发数据流格式、最终数据呈现形式。

当只有知道了整体的系统架构才能评估风险，因为你知道哪些是你的风险，哪些是别人的风险，哪些是你需要推动别人来解决的风险，这样便能明确你的测试范围，做到有效的测试策略制定。

我们如何来着手互动？

我们摸索了一套互动测试的四象限，分别从测试广度、测试深度、测试左移和测试右移四个层面来展开。

测试广度：不仅仅限于测试视角范畴，要从业务方层面看看当前针对的人群、场景玩法所实现的目标等，这样才能够知道测试场景的构建，需要在哪个方面做到测试倾斜，因为不同的人群或者场景目标对于测试范围的设定以及测试用例的扩展是至关重要的；另外对于测试策略层面不能局限，不单单是测试过程需要质量保证，而是在整个产品的生命周期中需要质量保证，就包含的上线前和上线后的各类沟通、串联、监控的各项事宜。

测试深度：测试工作不单单是测试人员的事，这点思想层面上整个团队中达成共识，需要与研发一起来共建质量，进行“可测环境”、“测试工具”、“测试数据”的建设，在研发质量门槛、ERD评审、代码diff测试以及脚本自动化的高度运用，从当前的业务场景测试 -> 代码实现层的评审 -> 代码diff的测试范围评估 -> 白盒层面的单元测试，做到层层递进。

测试左移：为保证整个测试过程顺畅，提测前期将沉淀的各类规范同步至到产品和研发，与产品沟通需求背景，与研发沟通需求实现方案，做好前提的需求分析，提测时给到研发自测门槛，保证流转到测试这边时是一个稳定可测的版本，减少提测打回的情况，降低风险遗留到测试阶段，影响上线节点的情况，保证整个测试流程顺畅。

测试右移：我们需要做好上线前的自检以及上线后的线上监控，同时关注线上运营数据，对被测对象的线上运营情况做到了解，为后续的测试资源投入提供指引。

二、测试流程及SOP

测试流程应该怎么制定？

所谓没有规矩，不成方圆，所做工作若不成体系，最终质量可想而知，结果也只是游击队。我们需要以结构化的思路来看待测试工作，不能局限于某个“点”，否则就是井底之蛙，需要由“点”及“面”的打开我们的视角，线性的贯穿整个测试过程，这样才能够知道哪些测试策略不足，从哪些方向去击破痛点问题，最终形成全局的互动体系。

整个测试流程分了三大块：第一是测试左移的几块实践方向；第二是测试过程、方法、效率化的方向；第三是测试右移的时间方向。

依据测试流程，细化了SOP测试流，从全局认知的基础上细化到各个环节的测试内容，及时让新人来也能够做到细节把控，从头到尾按照测试流贯穿式测试把控质量，降低人员流动所带来的风险。

三、互动测试过程

我们就针对上面所说的这些流程做一下各个子节点的拆解。

1、测试准备

测试准备阶段至关重要，准备的充分与否，决定了测试过程以及上线的风险指数，避免“滥测”“盲测”，需要从两方面来出发：

一是精准测试

测试过程需要明确场景、明确测试的逻辑范围、上下游依赖关系、涉及的项目系统，提升测试广度，在测试视角上得到的延伸。

二是测试效率

测试效率不要局限于平常所提到的自动化能力，一切可以提高测试交付能力的事项都是效率提升所需努力的方向，除了自动化能力外，前期的研发ERD和架构的评审、活用“测试环境”（时间mock、上游mock等）、脚本自动化、研发测试协同模板、测试工具集。

2、测试的协同框架

一个项目的测试通常情况下不单单就1个人，我们一个大型的活动，会涉及到5+的测试人员的投入，如何保证多人操作的协同，如何保证重复的问题不要重复问、研究和追查，既要降低沟通成本，也体现测试团队专业性。

通过测试协同框架，能够引导团队成员知道如何进行项目信息的沉淀，知道有哪些信息需要和研发确认，成员之间能够提高沟通效率，做到项目信息的聚拢和透明，在测试完成的节点也是项目材料沉淀完成的节点，无需再做后续的二次维护。若项目后续迭代，或者项目成员变动的情况下，能够保证项目材料的可复用性，而非临时一股脑式的资料打包，杂乱无章的材料无特别的实用价值。

3、可测环境搭建

如何去搭建可测环境，抛开传统思维比如安装包、测试环境、测试数据之类的，这边指的“可测环境”其实是泛测试环境的范畴，就是能够协同各方的力量方便去做测试的方式。一直主张测试并非测试工程师一个角色的事情，我们需要通过各种方式协同工作，达到最终的质量目标，测试过程要有测试的巧劲，要知道被测的对象是什么、被测的范围是什么，要知道哪些该测、哪些不需要测，要知道研发需要协同、哪些需要产品协同等等。

举个例子，活动里面很多用户属性，不同用户属性有不同的推荐数据。如果需求说我们当前支持三种用户类型：分别是校园用户、老年用户、青年用户，我们应该怎么测？按照一般思路是不是直接要找各种账号呢？找不到又怎么办呢？在理解到一开始说的，我们都是调用上游组件来进行逻辑判断的，这块的测试范围就清晰了，我们完全可以在调上游过程中加一个白名单，把帐号输入白名单。

这个名单下应该显示学生的数据或者老年人的数据，因为我们测试的核心流是上游返回用户属性后的判断逻辑，而非上游返回值的校验，我们更多的是校验上游接口连通的正确性，这样不用找帐号来测，会省去很多麻烦。

4、左移实践 - 需求分析因子

测试左移在我司的最佳实践当属于需求分析模型了，我们将需求分析过程线上化运营。

测试、研发过程中会遇到的各种各样的问题，我们将这些问题做了提炼和归纳，按照二八原则，重复在犯的问题中都集中在20%里面，即使平常看来非常LOW或者不可思议的问题就是实实在在的发生了。

针对这些问题提炼成了因子，针对不同的角色、不同的业务形成不同的需求分析因子固化及沉淀至平台库中，在PRD评审后，输出各模块特定的需求分析单，根据需求分析单有效的对当前需求进行分析，避免临时问题重演，减少口口相传，避免因新人遗漏评估点等风险。平台对需求分析因子进行操作后，能够推送相关涉及因子的解决方案，大大提高的分析有效性及历史经验流传，是非常具有测试价值的。

5、左移实践 - 自测门槛

为保证研发提测质量而设立的研发自测门槛，但如何保证研发自测用例的高效性也是摆在我们面前的难题，因为迭代速度非常快，对于研发自测用例都需要测试人员单独编写提供，但就活动类测试而言，不难发现其实测试点很多是通用的，在核心思路的基础上加了特有场景而已，按照原子化思路，研发自测用例是否能封装成模板？针对互动活动的特性，沉淀了研发自测通用例，保证的自测覆盖率的同时也大大减轻的测试人员编写自测用例的工作量，按照统一的标准来自测，各种活动的提测门槛就有了统一的保证，当前通用例不涉及太多业务层面逻辑，若需要业务层逻辑的话就由测活动的测试人员自行来编写，通用例+业务用例组合成最终的自测用例，灵活而且省心。

6、场景用例骨架

测试原子化赋能思路贯穿于测试各个过程节点上，活动测试用例也同样，研发能够沉淀出组件，测试一样能够针对研发组件沉淀出相应的测试用例及骨架，所有活动都是基于骨架而生成用例，并非从0开始，当活动都是基于骨架生成的话，用例架构和测试策略、用例场景得到最大程度的复用，用例质量也就得到保障，对于后续的自动化沉淀也非常有帮助，经实践，我们的测试用例生成实践缩减了50%。

7、矩阵用例骨架

互动的场景是负责的，单纯通过X-Mind的脑图方式已经不能满足交叉条件的覆盖，所以对于场景交叉的矩阵化建设应运而生，这种矩阵应该如何搭建？最后我们也出了一套通用的条件矩阵方法来做到复杂场景的覆盖，与xMind方式相互补充，并最终脚本化实现矩阵场景用例，提高效率。

8、核心逻辑骨架

互动活动最大的核心就是资金不能出现资损的情况，因此我们把与资产相关的交易逻辑做出了一套规范，所有与资产发放，与用户缓存机制相关的都需要做统一的逻辑处理。除此以外高频的使用场景及问题做到用例级别的输出沉淀，所有活动的必验法则，有了核心逻辑法则的加持，整个一年活动下来的质量度非常高，未出现同类型的资金或者逻辑问题。

9、兼容库建设

兼容性在移动端的痛点深入人心，拥有各种兼容性问题，大家是否想过兼容性如何做保证？我们需要看一下兼容性到底影响了什么，如何能够在研发过程中就将兼容性的问题暴露出来，而非遗留至测试阶段，将兼容影响的根因问题提炼成了兼容性的规范库，比如说很多ES6语法不兼容、字符编码不兼容等等，只要知道底层是哪个不兼容性之后，形成兼容性案例库就可以生成两套方案：一是兼容性测试规范，为了手工而准备；二是代码扫描规则，为了自动化而准备，将这些规则做到了静态代码扫描规则里面，代码提交的时候就可以进行及时发现并修改。

10、脚本场景化

传统接口测试都是单接口层面的测试，如接口的出参、入参要符合接口文档。但反观互动活动这块，单接口测试已经不能满足，而是要进行接口场景化的考虑才有价值，因为接口间逻辑数据相互间都存在影响，单接口测试意义不大，并且要从“单纯接口层测试”到“接口辅助测试”的思路转变。

第一：互动接口下的返回字段都有上百个之多；第二：接口入参特别简单，甚至入参为空，不同的用户账号在不同时间点的返回值都是不同的，因为它带有场景化和个性化的原因，单独的接层测试会发现效率特别的低下而且覆盖不全。所以我们提出的场景式贯穿法来解决这个问题，不分前后端，按照场景逻辑思路来进行前后端的贯穿式的整体验证，接口层更多要承担测试场景构造的责任。

11、场景化的分层思想

上面提到的接口测试场景化，在一定意义上来将完成的前后端业务场景的逻辑测试，但实际的接口层也存在很多重要的验证点，为了清晰化这块的测试认知，将接口场景化进行分层思考，我们从以下几个角度来考虑的。

• 通用场景：这是最传统的照本宣科的方案，单接口、业务场景和专项类测试，这是在垂直领域细分出来的方案。
• 单接口场景：更多是接口状态码、兜底校验、单独业务流等方面；
• 业务逻辑场景：是围绕业务场景来做，从接口层面完成业务逻辑，减少手工的投入，同时也能够做到接口层的回归工作；
• 专项类场景：涉及到幂等校验、防刷校验、并发校验、概率性校验等场景，一般这种业务场景所测不到，需要专项的接口层来进行覆盖，这在活动中也是重要的一环。

12、脚本场景化的案例

互动活动更多的还是重后端逻辑，不同的时间点进来和不同的方式进来都会有不同的前端效果。把场景做到了矩阵化，最终将矩阵化做成脚本化。这样既保证了覆盖的全面性，也保证了测试的效率性。

13、脚本骨架的建设

上面提到了脚本场景的分层，如何将这种分层思想给框架化？我们将所有的分层逻辑结构化成的脚本脚手架，并维护在Master分支上，将公共方法和思路封装起来，测试主要着重关注自身的业务测试流即可。各活动提测后，都基于Master分支生成自己的活动测试分支，提供当前接口的FounctionID，就可以根据你填的参数初始化完成所有基础脚本场景，为活动接口场景测试提供快速便捷的方式。

14、系统框架图的测试视角

我们一直在提这个框架图，这个框架图有什么用？

我们了解了这个框架图的数据扭转之后沟通更加顺畅，因为你知道怎么去问研发，所有的东西不能只是拿而不付出，你需要给到研发或者其他角色以专业性。另外对于BUG定位、问题分析、逻辑清晰、沉淀赋能、精准测试等一系列测试都有很大的帮助，这也是进行精准测试的入门步骤。

15、代码层的精准测试

深入代码层的灰盒测试的典范，并非要直接编写单元测试用例，我们了解完代码的实现逻辑后，就能够知道我们核心的测试范围，磨刀不误砍柴工。

举例：当前业务想要实现一个ABTest的逻辑，根据不同的账号展示不同的样式来反推设计方案的合理性，对于ABTest逻辑是如何测呢？单纯靠多的账号的暴力测试看概率么？我们深入代码层就发现其实就是使用了通用的CRC32的方法来对字符生成唯一的值，这样我们就直接从代码层来检验，场景层就能直接知道会命中哪种方式了，花费很少的时间得到收益。

16、压测实施

所谓的服务端性能，压测是一个很大的课题，压测具体关注哪些东西？

• 压测的核心指标：TP99、QPS、可用例、内存、CPU
• 压测的典型问题：热点 Key，缓存击穿、业务层内存泄漏

这张图做了最终的大屏呈现，我们将整个压测过程流水线化，做到了平台化。这一块对于大家来说，其实现在想来对大家的价值不高，因为没有提到核心的压测指标和压测方法，因为平台化已经将压测方法及指标融合掉了，没有做到细节呈现。因为你们知道压测需要关注什么问题，发生过什么问题，要怎么排查压测的问题，那才是最有营养的。如果大家感兴趣可以联系我进行进一步沟通，这块限于篇幅不展开。

17、上线自检

如何把握住上线的最后一道门槛，我们定义了上线压测的门槛和上线自检的因子，从前端、后端、测试各个角色的通用校验项，比如保证活动的配置项、保证测试代码已注释，保证线上资产类的发放生效等，这都是base且非常重要的校验点。

18、线上监控

线上监控分两个层面：主动监控和被动监控。

• “被动监控”：从实际用户端反馈过来的实时推送，对线上用户反馈能够做到实时的追踪；
• “主动监控”：业务场景脚本自动化监控，上面所提到在测试过程中的脚本辅助，这批脚本在上线过程中作为回归脚本，在上线后修改配置后最为监控脚本，脚本一体化运营；

19、防刷实践

我们对线上进行红蓝对抗演练时间？我们有安全防控能力做线上的人机识别，但如何对人机识别能力的校验，我们作为黑方进行脚本层面的攻击，达到验证效果。

我们有UI层和接口层两方面的脚本攻击能力来进行前后端的分层校验，打磨安全防控。

20、过程治理、组件治理和状态码治理

整个互动测试过程中，存在很多可以改进的地方，我们也同步对我们的流程、工具、方式方法等不停的进行改善，所衍生出了包括过程治理、组件治理、状态码治理在内的多个共建治理方案。

通过整个的治理过程，将各个环节的人为漏洞做到尽可能的屏蔽，将测试过程更加的透明化，顺畅化，大大提高整个交付效率，研发和测试更加的焦点是关注在探索性测试的挖掘上。

四、互动框架及平台化

特有的互动测试框架形成，从流程改善到基础建设，一体化闭环思路。

平台化思考，如何将现有的测试能力已平台化的形式沉淀下来，赋能到更多的测试团队？

将活动SOP转换成了测试流水线，从测试前、测试中、测试后的时间阶段为分界线，不同活动类型会以积木的形式推送不同的测试能力，将思想得以延续，对于后续的思考，更多是提高智能推送的能力。

知识星球：很多业务要做知识的沉淀，如何去做培训、新人引导、测试参考手册，以此目标搭建整个知识星球的框架，形成整个知识仓库，做到能力扩散。