新书连载18|系统协调与部署--《软件测试策略》

本节的案例听起来很简单：只需要列出所有任务，确保人们做好他们的工作，一切就会顺利进行。但实际上并非如此。在模拟器上运行的持续集成系统可能会让用户产生一种虚假的安全感，同时，它也可能会产生假错误。这些错误表明软件没有按照我们之前期望的方式工作，但它们又是正确的，因为本次变更正是修改了此处的处理逻辑。

要让整体过程顺利推进，就必须有人跟踪重要的变更并协调各个团队。当你在全球拥有六个以上的团队时，移动应用一旦错误发布，就需要等待应用商店审核而导致至少一周的延迟，所以现实中通常有一个预发布阶段。

但是，我们并不推崇将其作为常态，它更多是一种过渡状态。理想情况下，团队应当实现持续、稳定的交付。如果担心发布造成严重的线上问题，且无法在一两个小时内通过热修复解决（尤其是涉及非版本化 API 时），那么发布节奏治理就成了必要的控险手段。

在这种情况下，许多团队会采用“发布列车”的治理模式：像火车班次一样，发布按照固定节奏进行，有助于协调不同团队的交付节奏。例如设置每八周发一班“列车”，其中前六周留给团队独立开发，后面两周集中安排跨团队的协调和测试工作。如果某个特性没有准备好，就不会合并到主分支，必须等下一班“列车”。

从精益的角度来看，理想的目标是将测试时间缩短到一天，把整体的开发周期压缩到一次（最多两次）迭代。当这一目标实现后，剩下的难点主要在于协调那些会破坏兼容性的 API 变更。这类问题可以通过版本化 API 等手段缓解，使各团队基本实现独立部署，只有在涉及关键功能或影响全局的重大变更时，才需要统一协调。

本节的目标是展示如何将本书中的策略结合起来，以解决跨系统及其子系统的测试问题，同时，也说明如何将本书中的工具（思维导图、测试仪表板、风险清单和精益度量）用于改进。

说到这里，不妨想想，还有哪些影响质量的方面可能被我们忽略了。

你可以在此暂停片刻，思考和回顾一下前面的内容。同时，我们会插入一张图片（图 16-1）来占用一点空间，以免你直接看到下面的答案。

图 16-1 占位图（图片来源：Julie Heusser）

上一节梳理的测试策略，足以协调十余个软件团队的协作。如果不考虑 IoT只聚焦纯软件系统，那么“发布列车”模式就能更顺畅地推行，理论上可支持上百个团队的协作。

然而，很多团队依然在软件质量方面面临挑战。他们的持续集成 / 持续部署耗时过长，构建和测试次数过多，并且失败也过于频繁，其中不少失败可能是假错误。

这些错误不能真正反映软件的质量情况，真正的错误往往隐藏在测试没有覆盖到的部分。也就是说，这些“覆盖缺口”才是真正容易被忽略、但潜在风险很大的问题。

前述描述总体上是正确的，但遗漏了一些关键细节，例如测试策略来源以及演变方式。下面，我们换个视角，重新审视前面的示例策略。这个策略包含五个关键部分：

● 各子系统团队的独立测试能力：此处的子系统指 Web 应用、移动应用（多个平台）、API 和牙刷端软件组件。当然，可以采用多栈特性团队（multi-stackfeature teams）的模式，把跨平台、跨技术的开发能力都放进同一个团队，但本例并不是采用这种模式。为实现独立验证，每个团队都会使用本书所述的技术，既用于测试新特性，也用于回归测试。

● 团队对预发布版本质量控制的能力，包括编制功能地图、设定并度量覆盖程度，以及对覆盖情况进行可视化和发布。例如，在集中办公的场景，可将功能覆盖看板悬挂在团队公共区域；而在远程办公的场景，则可通过共享网页实现。团队还应沉淀可执行的测试配方。值得注意的是，文档需要有的放矢，只记录有共享价值的内容。同时也要注意，写得过多会增加维护负担，写得过于全面会增加理解难度（Comprehensive is the enemy of comprehensible）。因此，测试人员不仅需要识别应测内容，还需判断何时、以何种粒度将内容记录为文档，确保文档既突出重点又便于理解。

● 持续集成、制品和测试环境：通过将回归测试左移至构建流程，可以加速测试过程。与此同时，需要在流水线中管理测试环境与数据，例如为每次构建准备一致的环境快照与测试数据，以减少因环境不一致造成的误报。

● 辅助测试：可访问性、负载、安全性和国际化测试可以独立进行，也可以纳入构建流程。在这种情况下，公司会在构建流程中使用自动化工具进行扫描和测试。

● 协调与最终部署：这一环节需要建立统一的状态展示与节奏治理机制。项目信息需要集中呈现，例如关键问题清单、TOP 缺陷跟踪、每日站会要点、项目管理议题列表等，以方便相关人员实时感知与协同。同时，必须由专人或小组来统筹发布的节奏与时间窗口。如果完全依赖个别关键人物来维系节奏，这种“个人能力驱动”的模式在短期内或许有效，但一旦人员离职或变动，组织就会感受到阵痛。因此，管理层应当主动设计冗余与产能保障机制，从而避免形成“单点故障”式的人力依赖。

上面的概括性描述不会详尽地说明我们在前面几百页中建立的所有细节。但若深入剖析，你会发现，这一测试策略的上层设计源自本书测试的构成元素、精益软件测试以及交付模型与测试的相关章节；而在实施层面，它又具体依托于前五章关于测试方法、测试工具、测试数据和专项测试的内容。你的测试策略也是这样的吗？

19 世纪初期，一群工人，主要是纺织业工人，组织了一场针对新技术的抗议示威活动，因为新技术的出现威胁到了他们的生计。在数月时间里，他们趁夜袭击空置的店铺，破坏新工具，迫使雇主雇用传统手工业者。这项新技术就是蒸汽织布机。领导这场叛乱的团体被称为卢德派（Luddites）。

如今，“卢德派”一词被用来指代任何抵制技术变革的人。变革已经到来，并且是受欢迎的！就在几十年前，人们还被雇来按电梯按钮、为每一通电话接线、打字写信，以及帮助每位顾客结账。总体而言，这些工作已经被自助服务所取代。关于人工智能的普遍论点是：测试工作也即将被取代。

对此，我们认为这是荒谬的。不过，既然我们选择了这样的立场，就有责任探讨 AI 工具的现状、其真正的可能性，以及如何利用它们实现一些有限的、渐进式的改进。