测试过程效率的提升和演变

昨天看到这样一个很有意思的问题：

一个月发布一个版本，核心需求经常变更，导致影响范围大不好评估，但对交付质量的要求比较高。单元测试、自动化测试才开始建设，为了保障质量只能投入大量资源做回归测试验证，但每个版本留给测试的时间又不够充足。这种尴尬的阶段，该如何保障产品质量？

这是一个很典型的案例，在很多公司的研发团队曾经都存在类似问题，甚至现在依然存在。它集齐了需求(频繁变更)、开发(代码经常修改)、测试(测试手段匮乏)这三大软件研发交付环节最严重的几点问题，要提升产品质量就势必要解决这些问题。

这篇文章，我会结合自己的实践经验和思考，尝试给出这个问题的一些解决方案。

软件研发交付的发展史

最早也是最为大家熟知的，应该是瀑布式的软件迭代交付模型，如下图：

PS：网图侵删。

在软件设计之初，就确定好要实现的需求，然后进行设计实现，工时资源预估，按顺序一步步实现并上线交付。因为要实现的需求是稳定的，编码也只需要按照设计的方案来实现，测试要验证的范围以及边界更好评估。虽然瀑布模型的迭代周期一般比较长，但整个过程稳定可控，交付质量相对也比较高。

后来随着商业环境的变化速度不断加快，软件交付模型也在跟随着快速发展，进而衍生出了多种交付模型，比如 V 型、W 型、双 W 型、版本火车、敏捷理念。这些模型的出现，一方面提升了需求的交付效率，可以让需求更快的发布上线为用户提供服务；另一方面，对软件测试这一环节来说，也带来了很大的促进和改变。

提升产品质量的整体方案

在瀑布模型中，测试只是整个软件迭代交付中的一个环节，大家按部就班的分析需求，设计测试用例，执行用例跟进缺陷修复和验证即可。但到了当下这种提倡快速迭代交付和敏捷的时代，大家对软件测试的定位已经不仅仅是其中一环，而是要贯穿整个软件迭代交付的生命周期，做全周期的质量保障工作。主要体现在如下几点：

需求和设计阶段

评估需求的合理性(是否有遗漏、描述不清、存在逻辑漏洞)、可测性(将大需求拆分为测试可介入的小需求)以及设计是否满足需求要求、是否美观、交互友好性等。

方案和编码阶段

针对技术方案进行评审(方案实现难易程度、可测性、是否需要更多资源)，针对项目排期和发版计划评估对应的资源投入(资源/时间/成本三者需要根据对质量的要求做平衡抉择)。

测试活动的开展应该尽早介入，比如在编码和研发自测阶段，测试可以充当研发自测的辅助，提供测试用例、测试数据，让问题在编码自测阶段就充分暴露。

测试和交付阶段

该阶段我个人认为主要做好两点工作，质量门禁+测试计划。质量门禁(提测准时率、构建成功率、缺陷收敛率、缺陷 reopen 率)的作用在于避免风险向下游传递，放大影响范围和修复成本；测试计划的重要性在于通过合理可控的方式来逐步验证交付的软件是否符合需求设计和质量要求。

上面的内容出现了好几次评审，很多人会认为评审太过于虚浮，不真切。但评审真正的价值在于从用户使用场景角度出发，通过评审提问，把需求逐步澄清并形成验收条件，产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。

上述的三个阶段要做的事情，其实近几年在很多公司已经有了落地实践，其实就是测试左移+测试右移。

详细内容请看我之前的文章《测试左移右移，到底是什么？》

提升测试过程效率的手段

回到文章开头的这个案例，面对需求(频繁变更)、开发(代码经常修改)、测试(测试手段匮乏)这种情况，我们该通过哪些具体的手段来解决问题，提升交付质量。

首先面对需求的频繁变更，在需求评审阶段就要将变更可能带来的风险列举出来，并对可能带来的影响准备应对预案。同时做好提测和发版计划，让问题更早暴露，将问题的影响范围控制在更小的范围内。

其次将大的版本需求拆分为小的测试可介入的需求，做好版本和分支管理，分批提测。这样即使需求变更，所影响到的也只是变更的这部分，而不是影响整体的交付进度和效率。这样做还有一个好处是降低一次性提测带来的集成测试成本和难度。

当然，版本和分支管理，需要较好的持续集成流水线来支撑，并辅以一定的自动化测试加快验证，缩短信息反馈耗时。对于不同批次提测的需求，如果彼此之间有调用依赖，则提前约定好兼容方式，最好是制定一个兼容规范。针对分批提测，还有一个辅助手段则是做好 Mock，避免上下游依赖方未提测导致阻塞了当前批次的测试进度。

最后，做好监控告警(原则上每次上线的代码，与其匹配的监控手段也应该在线上发布时一同发布)，即使出现问题也能及时的感知和修复，避免问题扩大。当然监控告警是一个滞后手段，线上还可以通过自动化的方式进行关键流程与核心场景的巡检，实时检测。

很多时候影响测试过程效率的并不是技术手段的匮乏，而是在需求和计划阶段没有考虑周全。技术手段只能治标，要治本还是要在管理和流程，评估和计划方面尽早考虑。