03　测试驱动模式下科大讯飞的高效交付能力提升之路

作者介绍

王杰　科大讯飞AI营销平台业务群测试总监，测试架构师。2012年加入科大讯飞，先后负责讯飞多个重点业务的质量保障工作，2015年加入讯飞集团消费者BG-AI营销平台业务群。拥有丰富的服务引擎测试、引擎类自动化测试、高并发性能测试、现网优化和电商节质量保障经验，在上游质量内建和测试效能提升上有着丰富的实战经验。

案例背景

随着业务敏捷化能力的不断深入落地，敏态业务在交付频次上有了显著提升。但是，交付频次并不意味着出色的交付能力，它只代表效率，而效果或者说质量也是交付能力必须要考虑的特性内容。所以在敏态业务模式下，我们不仅要保障整体的测试质量，也要适当跳出角色限制，以全局的高度来审视测试工作，协同团队，实现更好、更快的交付，赋能整体交付组织。如何更好地赋能业务、实现出色的交付能力，对测试团队来说不仅是一份责任，更是一份挑战。

本文主要介绍科大讯飞AI营销业务的测试团队如何一路披荆斩棘，以测试赋能业务、重视质量内建、高效协同上游团队，将研测团队效能、版本质量和交付能力不断推向新高！下面我们就来揭秘测试团队是通过什么样的丰富实践促使业务更好地实现交付能力，助力业务发展的。实践主要从3个维度展开介绍，分别为缺陷预防能力建设、测试技术能力驱动、交付流程精益优化。

案例实施

1.缺陷预防能力建设

（1）质量内建的必要性

缺陷是研测阶段最重要的产物。缺陷若在需求设计阶段被发现，处理成本较小，但如果在测试环节被识别，修复成本将指数级增加。

业务快速扩张，需求会越来越多，如果每个版本都经历“缺陷修复，发版，重新测试”这样的过程，甚至不止一轮这样的过程，在测试人力有限的前提下，就会造成需求或版本积压。反思整个流程，我们从2017年开始重点完成了测试工作前置的落地，通过缺陷预防能力的建设，实现在上游的质量内建。

（2）背景切入点

缺陷预防能力建设的切入点，也就是交付过程中我们所面临的一些主要问题，包含以下5个方面：

1）研发团队对自身交付提测产物的质量关注不足，提测行为不负责。例如，研发团队不自测就直接交付给测试团队进行测试，在这样的情况下，测试团队仅通过常规正常功能测试流程就能发现较多的低级缺陷、严重缺陷，会花费更多的时间在低级问题、阻碍型问题的反馈、跟踪处理上，而无法挖掘更深层次的缺陷。

2）重视服务端需求交付，但缺乏对服务端研发设计细节的交接和传递，增加了测试获取未知内容的成本。为了获知更多未知内容以实现全面测试评估，测试团队需要找研发团队进行多轮沟通来获取相关实现信息，这对彼此都是一种打断和消耗。如果有些未知实现内容未获取到，未来还会成为一个线上问题的质量风险点。

3）在研发团队已开始关注自测交付质量的情况下，面对大需求或大版本交付时，他们的自测交付质量会无法令人满足，到测试时还是会发现很多缺陷，大而全及整体的复杂度会让研发团队难以兼顾需求整体。

4）刚才提到缺陷是研测阶段最重要的产物，缺陷修复完成之前大家都相对重视，因为缺陷会影响到上线交付，但当缺陷解决、验证关闭之后，大家很容易忽视缺陷带来的反哺价值，对缺陷修复的细节草草了事，导致后期类似的问题不断冒出，不见改善。

5）随着研发交付质量的提升，整体质量的问题会发生一定的转移，此时研测开始关注更上游的交付质量。为了改善更上游的交付质量，需要研测共同解决闭环机制的问题。

（3）实践要点

为了解决以上这些问题，我们主要从以下5个要点进行实践落地。

版本质量度量体系，让质量成为研发的“紧箍咒”

质量是研发交付的必要特性，不能任意妄为。版本质量度量体系的建立必须得到研发主管的支持和认同，因为度量会影响研发成员的绩效和质量口碑。版本质量度量体系的建立实践步骤如下所示。

•共识度量标准：不同的方向和不同的交付研发模式，其度量标准有一定的差异，如前端、服务端的缺陷密度是不一样的，不能一刀切，需要结合实际来制定。具体的，我们先建立了基准度量指导标准，然后根据各方向自身需要进行定制，以加分激励为主。通过度量标准的建立，版本质量具有了可视性，不再是仅有的缺陷感知。

•研发绩效激励：有了单个版本的度量，就能得出每个人每月的综合度量，此时自然会有“高个子”和“矮个子”。“矮个子”会有要提高自身质量交付水平的压力，“高个子”也会继续努力，不断突破。我们会把每月度量结果汇总，并在团队内公示。把相关质量加分变现为研发绩效加分，让那些质量加分明显的同学能够获得绩效优势，营造研发内部质量内建的风尚。把抽象的质量意识转化为实在的可触摸的绩效，促进高质量版本的诞生，从而达到预防缺陷的目的。

•弹性提高标准：随着度量体系的落地，研发的质量交付水平有所提高。基于这样的情况，我们需要阶段性地审视度量标准，适时地优化和提高。

这套体系最初落地时，我们曾做过一个统计，从版本提测到最终上线，减少了30%的时间周期，也就是原来3天的测试周期缩减到了2天。度量的最终目的不是考核，而是为了引导研发团队建立良好的交付习惯，对自身的交付质量负责任，促使研发人员建立基础的测试思维。整个度量体系也是在不断演进的，需要在过程中持续不断地精益改进，例如可以考虑半年审视一次，进行必要的调整。

版本交付测试规范，增强研测交付顺畅度

•建立规范前，首先要解决概念性的理解偏差问题。有这样一种说法，“工作的软件高于详尽的文档”，于是有人觉得我们不再需要文档了，或者说为了强调速度快，我们可以舍弃文档的建设了。但是，没有必要的文档，我们就会面临着低效沟通、低效交付、高风险的问题，长久来看还会影响到团队的业务能力传承。因此，为了提高研测交付的顺畅度，我们主要推进了两个交付材料的规范化，分别为设计材料说明的规范化和版本发布构建的规范化。

•设计材料说明规范化：通过设计材料说明的规范化和提前交付规则，帮助测试团队提前获知研发设计实现细节，提前进行测试准备。这些内容的提前获取一方面可以帮助测试团队在准备过程识别到风险和漏洞，及时、快速反馈，避免将风险遗漏到测试环节；另一方面可以有效减少测试环节未知信息阻碍型因素，使测试工作的推进更加顺利，整体测试工作更加主动。设计材料的颗粒度以及结构可通过传递优秀的案例进行引导。设计材料不是文字越多越好，而是越易懂越好。我们曾统计一组数据，通过设计材料说明规范化，测试人员掌握、理解整体需求的时间可以缩减50%。

•版本发布构建的规范化：这个规范化来源于一次现网故障，研发人员因在代码中增加了一行与交付功能完全无关的测试代码，且没有任何构建说明，基于功能范围评估也无法测试到，问题就引入了现网。因此，针对版本发布构建，研测双方进行了强化规范，形成了更有效的发版处理机制，对多人模式合作下的代码提交提出了规范要求，同时也对版本发布需要包含的内容进行了明确的引导规范说明，使整体交付说明更完整、更具体。减少构建报告不准确、不完整的问题隐患，比如说没有说明影响范围，内容有错写和漏写，甚至代码提交错误的情况。这次现网故障也额外加速了我们测试团队精准测试能力的落地。

通过这些规范化的文档建设，我们实现了交付环节信息的高度共享，不仅提高了研测交付顺畅度，还加速了测试准备过程。同时，我们也发现研发人员通过撰写这些材料，自身的交付质量也有所提高。撰写材料的同时也是对既有实现的总结、梳理与审视。

需求解耦版本切割，降低研发自测保障难度

通过需求解耦版本切割，可以降低研发自测保障难度，也可以更好地提升研测双方工作的灵活度。

•问题原因认知：大而全的交付中，场景分支太多，存在考虑不周的情况。同时，大而全的交付一般也涉及多人联合开发，开发成员的自测保障通常聚焦于自身所做的功能，很难兼顾整体。功能混杂或需求合并不仅会导致版本迭代慢、项目周转不灵活，更容易滋生风险，一旦出现需求变更，会牵动整个版本的进度。此外，完成一个大而全的版本测试，首轮测试的测试反馈周期也比较长。

•测试优势发挥：面对这样的情况，测试可以从自身职能中适当跳出来，充分调动测试团队对全局性业务的理解优势，帮助并引导产品人员放弃或减少那些覆盖用户密度小、使用频次低、使用强度弱的需求。理性面对需求，勇于对拆分不清的需求表达否定意见，并协同研发人员推进需求降解。需求降解之后，研发人力调度和整体交付会更加灵活。我们有时还需要考虑版本的切割引导，通过切割引导让测试团队的处理更加灵活，比如可以考虑把若干个小需求集合在一个版本进行提测，若交付的版本较大，可以评估能否进行过程划分，若可以，则将其分为多个版本提测。在满足业务需要的前提下，对如何发版、如何规划版本给予合理的评估意见参考。

•小步快跑加速：通过需求的降解和版本大小的规划，加速小步快跑的交付。交付内容具有业务层面可测试性，即需求版本的合理划分，无论多小的交付，都必须能实现一个完整的业务场景。

缺陷点数是我们业务上建立的概念，是缺陷影响程度的加权求和。缺陷点数＝缺陷加权求和＝致命缺陷×10＋严重缺陷×5＋一般缺陷×3＋细微缺陷×1，点数越大，说明该方向在研发阶段产生的缺陷影响越大。如图3-1所示是某业务方向版本数和缺陷点数的数据，可以看到，6月份版本切割后，交付频次增加，版本迭代由每周1次上升到每周2、3次，与此同时缺陷点数在明显下降，这说明我们的研发交付质量在持续上升。

合理的解耦切割粒度，不仅能够提升编码实现和测试反馈的效率，更能有效地减少缺陷。当整个交付团队形成默契之后，需求解耦、版本切割就很自然地实施了，之后测试团队能参与的也就不多了。

图3-1　1～12月份版本数与缺陷点数趋势图

缺陷复盘回顾机制，打造完整价值闭环

建立缺陷复盘回顾机制，重视缺陷的价值，打造完整的缺陷价值闭环，实践要点如下。

•缺陷起因追溯：为实现缺陷引入的根因定位，研发需要对缺陷起因认真书写、认真对待，拒绝随意填写，针对随意填写进行打回处理。缺陷起因是研发人员对缺陷引入原因的强化认知，若仅是填写“已修复”三个字，不仅浪费了强化认知的机会，同时也让测试人员无法理解缺陷的引入原因。更重要的是，等到缺陷复盘回顾的时候，研发人员自己去解读缺陷时往往也会不知道缺陷究竟从何而来。

•缺陷多维分析：每月形成有力的缺陷多维分析报告，通过报告让研发团队内部对版本质量水平和各成员贡献程度有清晰的了解，从研发内部形成压力，提升组员质量意识。同时要有针对性地分析，尽可能透过偶然性去发现必然性，找出下一阶段的缺陷避免方法，在复盘时进行讨论。

•月度缺陷复盘：在前两个措施都落地的情况下，每月研测人员应对所在方向的缺陷进行会议复盘，复盘时由缺陷引入者讲解自身引入的缺陷，通过复盘讨论的方法客观地追踪问题本身，形成可落地的执行方案。即使是负面案例也要积极复盘，当然，我们更支持优秀案例的复盘，传递经验。

2018年业务测试团队累计处理版本数超过1000个，严重缺陷占比降幅达70%，而缺陷复盘回顾机制正是当年重点强化落地的实践举措。由此可见缺陷复盘带来的价值体现，期待我们的研测团队能持续重视缺陷的反哺作用，从缺陷中强化学习，让缺陷再多创造一些价值。

需求问题研测归档，初始质量共同建设

需求问题研测归档，引导产研测对初始质量的共同建设，实践要点如下。

•交付团队内部共识：归档是一个敏感的实践，它相当于把产品的问题记录在案，之后阶段性地集体复盘。这个环节的落地对产品团队是有压力的，所以需要产品团队包容性地看待这项工作的价值，在交付团队内部形成共识，并认可归档的意义。需求问题的价值与研测阶段的缺陷的价值相似，需求问题常态下对工期进度的影响不亚于研测阶段缺陷的影响，最开始可能只是少数Bug，后面Bug数量却会“滚雪球”。此项工作应开展于版本交付测试前，需要研测一同参与。

•优化问题管理流程：产研测都会参与到流程流转之中，因此对流程效率和易用性也有要求。为满足归档的要求，我们对问题管理流程进行了优化，实现需求问题与原始需求的直接链接（我们在查看对应需求时，也可以快速地获知历史过程中所提的需求问题），实现新增需求问题识别阶段标识，最终形成需求问题专属看板。

•阶段典型问题复盘：归档之后的问题同样也会根据需要阶段性组织复盘，若归档的问题比较多，就需要研测同学共同商榷并抽取典型需求问题，由产研测三方共同复盘，并由产品团队给出务实的改进措施，形成良性反哺。

2.测试技术能力驱动

现在，我们把视角移至测试职能自身的交付效能提升上，测试组织也要考虑在现有人力规模下，如何提高测试组织自身的测试交付效能，增强产出或提高效率。

深入业务的测试团体，大多可以良好地保障业务的测试工作，但也存在两种相对普遍的现状。

一是“深井”现状带来的低效实施问题。业务测试被独立业务自然分割，不同业务的测试单元通常会因业务的差异而产生交流屏障，在这样的情况下，业务测试人员往往封闭自己，每个人都在做独立的演进。其实很多测试工程方法不会因业务不同而产生明显差异，因此，这样的独立演进从宏观维度来看存在重复造车的现象。

二是“比例”现状带来的执行压力问题。这个现状在整个业界成为一种趋势，即研测比越来越高。在这个背景下，测试人员奔命于业务功能测试，久而久之，业务上的积累变多了，但技术成长上不见突破，感觉遇到了瓶颈，潜能得不到激发和释放。

这两种现状影响着测试交付的效能，所以我们要设法跳出来。这里我们分享三个突破要点：

•建立内部虚拟组织，实现技术能力的整体产出；

•积极评估、接入一些必要的测试能力平台，并参与共建，通过平台优化原有的实施模式；

•通过效能工具或效能脚本对我们的测试执行工作进行提效。

首先，我们来看一下内部虚拟组织赋能。如图3-2所示是我们建立的一些虚拟组织单元，通过这些虚拟组织，我们可以更好地激活团队的整体力量。每个人在所在方向投入的精力是有限的，但通过团队的虚拟组织和目标导向，团队会增加优秀的技术沉淀，更多地与同事交流切磋。我们发现，聚合之后明显形成了一种团队合力。同时，效能工具虚拟组织也可以走出当前业务群，为其他业务群的测试能力建设提供助力。

图3-2　业务测试团队的内部虚拟组织

其次，我们通过评估接入集团测试能力平台，使我们原有采用工具化或脚本化的能力借助平台实现增效，例如Mock平台的接入为我们节省了一半的人力投入。但这些平台也不是完美的，平台很难完整地适配场景，所以业务团队在使用平台时，要尽可能把场景所需要的能力抽象成公共能力特性。同时，对于这些平台在什么样的业务场景下可直接使用，业务团队也需要不断尝试，通过尝试探索，共享使用经验。

然后，重视测试执行工作的工具效能化提升。以图3-3为例，服务端经常需要测试protobuf协议类型的请求。过去我们是按图3-3上半部分所示的步骤进行测试，先使用JMeter构建测试计划，然后使用其他JSON转protobuf的工具构建需要的请求，随后使用Linux服务器解密工具对其处理并生成二进制文件，最后使用JMeter添加此二进制文件完成用例发送。在整个测试流程中，每发送一次测试用例需要经过两个JMeter软件之外的处理工作，无疑加大了测试人员的工作量。为了减少测试人员发送测试用例的时间，我们考虑直接在JMeter中集成根据输入的JSON自动生成protobuf请求的插件，集成后测试流程得到优化，如图3-3下半部分所示。通过开发插件，我们大约可减少测试人员70%的测试执行时间消耗。

图3-3　优化前后的手工执行步骤

3.交付流程精益优化

交付不是某一个职能部门的事情，它需要各职能部门密切配合、协同，但团队之间的交付效率有时会受制于整体交付流程协同机制。我们把推进此项工作时面临的挑战划分为2个维度，一个是需求管理带来的挑战，另一个是需求消化也就是实际产研测交付过程带来的挑战。

在需求管理方面，我们会面对种种挑战。以需求对象多样化为例，如需求来源的多样化，来自产品、运营、商务、客户等；如需求面向对象的多样化，这个需求归属于哪些业务线或哪些子项目；如需求属性的多样化，是紧急的、常规的还是技术演进的。如果没有一个很好的解决机制，多样化的需求会额外增加需求管理复杂度和成本，进而导致需求池错综烦乱的问题。

同样，需求消化维度也面临着诸多挑战，团队协同遇到的最多的障碍，是彼此工作的不透明的信息共享问题。这里以进度的频繁打断跟踪为例，比如某职能团队在无法获取当前整体工作进度的情况下，会频繁询问需求进展阶段、预计上线时间等信息，这会导致个人时间严重碎片化。

面对需求管理、需求消化的综合挑战，我们提出了2大核心的诉求，即团队要往高效的需求管理能力和透明的协同流转能力进行演进发展。在这个过程中，测试职能被赋予了牵头优化的职责。

经过一番调研之后，我们创新实现了以JIRA为载体的整体解决方案，通过方案中的需求分类导向解决需求管理复杂度问题，通过方案中的可视化精益看板能力实现透明协同流转诉求。为了打造可视化精益看板，最初的问题类型对应的通用化字段和通用化价值流程是满足不了需要的，我们必须新建需求类型来满足我们的解决方案导向要求，如精益化我们的价值流状态，新增我们期望的字段，去除不必要字段元素的干扰。完成需求类型的创建之后，就需要解决配置问题了。

关于需求的创建，我们实现了主要导向的定制，包括以下9点：

1）分类导向。我们在看板上能够看到需求的分类特征，包括常规演进的需求、产品规划的需求、紧急插入的需求、技术内部演进的需求等。我们通过看板，能够做到有效兼顾，解决需求对象多样性的部分挑战。

2）价值导向。我们实现了需求价值从源头的传递，解决了需求价值意图不明确和需求决策主观干扰大带来的挑战。

3）业务导向。我们能够实现对所有业务线的有效切分，在一定程度上解决需求池错综烦乱的问题。

4）来源导向。我们可以快速了解需求的来源方及来源人，有需要时可以快速、精准地找到对应的人。

5）描述导向。解决了需求描述只有1个，产研测共用面临的覆盖冲突性问题。

6）时间导向。需求方可以书写需求的期望上线时间，给需求管理排期的人员提供一些引导。

7）责任导向。明确此需求的产品负责人和开发负责人，这些信息可在精益看板上直接呈现。

8）模块导向。我们舍弃了原有的模块字段，直接采用epic代表我们需求所在的模块和重要演进。例如当一个需求颗粒度比较大时，可以创建epic，并在epic下面创建多个需求跟踪演进。使用epic的最大好处是，它可以直接在看板上呈现，非常直观。

9）紧急导向。用于紧急需求创建时，传递紧急原因说明，并做了必填项要求。若不做必填项要求，可能会有很多不紧急的需求贸然采用这个流程。至于需求是否紧急，需求方要评估和同步给需求的参与者，在作用效果上类似价值量化。

关于需求的价值流状态定制，我们定制切分了如下状态。涉及产品团队参与的需求，其定制流程会包括4个阶段，分别为待评估阶段、产品设计阶段、待评审阶段、待开发阶段。当流程进入待开发阶段时，经办人变更为研发经办人。研发经办人实现开发状态的过渡，当进入待测试阶段时，经办人变更为测试经办人，后续的测试阶段一直到最终上线，都由测试人员负责。同时，过程中也存在一个独立的流转状态，即异常终止或打回，需求在任何阶段出现这种情况都可以直接操作。为了兼容更多的真实场景，需求价值流的状态流转支持跨状态流转，便于增强流转的整体灵活性和操作的便捷性。

价值流有两个需要变更经办人的阶段，在触发对应的状态控件时，会弹出对话框，能够便捷地切换经办人，同时也会支持采集此需求的人力投入数据。例如研发将需求交付给测试，若此时存在一些已知的遗留问题，研发团队可以直接填充，测试人员便能直接感知。

需求定制完成后，还需要进行看板的配置。

看板需要进行合理的切分，做到不同业务线需求的彼此隔离，形成所关注业务线的专属精益看板，为此我们需要采用过滤器。以我们某业务线的过滤器为例，业务线的需求最初分布在两个项目中，我们把两个项目中的某种需求作为关注对象，其他类型不在这里干扰显示，通过所属业务线字段来过滤该业务线专属需求。同时，整个项目的epic可能比较多，我们只期望展示与该业务线相关的epic，所以对epic也进行了过滤，减少非此业务线的epic产生的干扰。

我们要对需求的价值流状态映射到看板的列中，一般情况下，一个状态最好只对应一个列。但是，由于JIRA页面在显示的列比较多的时候，需求卡片会产生挤压，导致可视化效果不是非常好。为此，我们进行了取舍，把某些状态列合并在精益看板的某一列一同显示。

完成以上两点，我们就可以实现所属业务线的需求任务状态的价值流动的可视化了。为了更好的可视化效果，例如我们想通过需求卡片获取更多的信息，或者点击需求卡片获取更多团队关注的内容，可以通过配置需求卡片标题下方的可显示字段，也可以通过任务详情视图选择定制需求的重要元素来实现。

这一套交付流程精益优化之后，我们前面提到的协同挑战就不再像之前一样困难了，需求管理和协同流转得到了明显改善，产研测间的协作也更顺畅、更高效了。

需求管理和协同流转的最终目的都是为了持续快速、高质量地交付。这是我们量化度量的效果数据如下所示，以解决方案落地的前后5个月的数据作为对比区间。在交付吞吐率方面，月均交付需求数由原来的54个增长至93个左右，增幅比例73%；需求响应周期，就是一个需求从提出到交付所经历的时间周期，由原来的29.4日下降到17.8日，也就是说我们的响应能力提升了39%。发布成熟能力，以构建交付成熟度来计算，提升了121%，也就是我们因缺陷而产生的版本迭代缩减了，一次性交付能力提升了。质量方面，通过我们的度量机制，研发过程质量效果提升了21%，同时因需求原因引入的缺陷也大幅下降，需求质量效果提升了68%，这说明产品团队的交付质量也提升了。最后，在对外交付质量方面，精益看板很好地解决了协同的问题，落地之后没有再产生因内部协同问题而引入的线上问题。

案例总结

1）审视自身角色定位，适当打破职能局限，化被动为主动，以质量改进为己任，倒逼上游提高产物质量，实现质量内建。

2）内部组织赋能，测试技术升级，完善测试能力体系，提升版本交付的测试效率和反馈效果，完善交付闭环。

3）系统思考，推进产研测流程的整体审视和精益优化，解决团队协同流程痛点，赋能产研测更高效的协同。