新书连载17|设计测试程序--《软件测试策略》

除了测试各个独立组件外，要想将软件工程与协调工作分开其实很难，但我们将尽力把二者区分开。

对于这款牙刷来说，测试主要关注设备与手机之间的交互。通过创建虚拟手机和虚拟设备，我们可以模拟设备行为、驱动交互并观测两者的通信状态。完成单元测试后，测试活动将覆盖新功能的使用场景及异常操作情况。

从测试视角来看，最值得关注的往往是那些会导致软件崩溃、卡死、超时等故障的场景。这类极端场景测试（有时被称为“肥皂剧测试”）通常也能有效覆盖常规使用场景。

由于本书聚焦软件层面，我们不会涉及刷头机械性能测试，仅软件交互部分就有大量测试工作要做。理论上，只要计算机上的模拟器能够准确复现移动应用的行为，硬件团队就能在不依赖真实应用更新的情况下，对新硬件进行测试和联调，从而按照原定计划独立发布新款牙刷。

当然，重大硬件更新与移动端升级仍需协调规划，确保向后兼容。团队将建立自动化冒烟测试流程，覆盖最常见的使用场景。在重大版本发布之前，除了自动化测试，还必须进行一次完整的人工测试。这可以通过两种方式完成：一是直接使用 Web 应用进行端到端操作；二是使用一个专门的模拟工具来触发和观察系统交互。

Web 应用可能会提供调试模式，使测试人员能够在同一环境下选择使用 Web 界面，或切换到模拟方式进行验证。Web 应用是一个独立运行的前端界面，可通过人工进行检查。前端将调用API，这些 API 可以通过服务虚拟化（即在云端或预备环境中运行的模拟服务）来实现。

每个功能在代码提交之前或之后都会经过人工的探索性测试。一旦代码进入版本控制系统，就会触发持续集成的流水行执行检查。为了进行此类自动化检查，公司需要在云端设置一个有固定 URL 的预备环境，并提供一种方法将应用程序的 API 调用指向该环境。

应用还需要在各种浏览器（包括 Edge、Chrome、Firefox 和 Safari）上进行测试。团队需要预先定义对每种浏览器的支持范围和预期测试程度，并明确在每种浏览器上的投入时间。

API 可以通过契约测试来进行验证。由于 API 本身可能会调用其他 API，因此团队编写了一个依赖关系映射器，该工具能够持续追溯依赖关系直至数据库层。借助该工具，团队可以在云端动态生成任意 API 的完整依赖图，并基于这些依赖关系开展针对性的测试。

开发人员可以将规范测试数据集加载到数据库，开展探索性测试，同时为变更添加新的 API 自动化测试。当变更提交至版本控制系统，会触发持续集成流程对 API 进行预期行为的检查。当代码合并到主分支时，这个过程会再次进行。

非破坏性的变更可以随时发布，而复杂或破坏性变更往往需要跨团队协调。三大团队（iOS、Android 和 Nintendo）各自负责测试自己的变更。对于重大的API 变更，将使用蓝绿部署的方式，以便可以快速切换和回滚。

如果缺乏完善的版本控制，团队可能不得不使用命名 API 的方式，即在 API 中嵌入应用版本号。但这种做法长期来看难以维护，因此团队最终需要过渡到更系统化的 API 版本管理方案。

移动应用的测试方式与 API 类似。在持续集成过程中，移动应用需要通过两类自动化验证：一是前端检查，即使用模拟 API 端点来验证界面和功能逻辑；二是端到端检查，即在云端部署完整系统的情况下，测试整个应用的运行情况。

持续集成将生成一个可安装的制品（artifact），测试人员可以将其侧载到物理设备上，进行探索性测试。在这些过程中，身份验证和支付功能都将被有效覆盖。对于重大的变更发布，还会在更稳定的预发布环境上运行最终的集成检查。

儿童应用由一个独立的团队负责，并配备专门的测试人员。团队的组织结构决定了他们的测试方式：核心应用功能、头像、游戏、社交媒体推送以及奖励中心都分别由不同小组负责。虽然这些功能各自独立开发，但彼此之间又高度依赖，例如游戏会展示头像，而头像又依赖于核心应用功能。

因此，该团队采用了类似于 Scrum 或规模化敏捷框架（Scaled Agile Framework）的传统模式，在开发过程中团队不断触发持续集成流程以执行检查，并在每个为期六周的开发周期结束时，安排两周用于跨模块的集成和验证。移动应用的开发也遵循类似的节奏。

除了上述围绕基本功能的测试，无障碍性、负载测试、国际化和安全性也是需要严肃考量的方面，这些测试既可以通过人工探索的方式进行，也可以作为持续集成流程的一部分来运行。

在实践中，始终运行所有测试往往会拖慢构建速度，并且未必会增加太多价值。解决此问题的一个办法就是降低执行频率或采取轮换执行的方式。

在我们的案例中，我们会在代码推送到分支时运行所有内容，而在主分支上，则只会每周运行两次，因为这些测试已经在分支阶段执行过检查，不太可能再出现回归问题。

如果说测试的本质是风险管理，而风险管理的核心在于合理分配资源以降低风险发生的可能性，那么所有持续集成运行所需的云计算资源成本也应该是一个考虑因素。

本章没有足够篇幅逐一深入讲解每个系统，在实践中，我们需要意识到测试覆盖可能存在不足的情况。为此，一个可行的方法是：首先识别系统的主要特性，评估现有测试的覆盖程度，找出覆盖缺口。随后，可以设计具体机制来弥补这些缺口，例如列出风险清单，并在开发周期的各个阶段针对清单内容安排检查，从而确保在不同阶段发现潜在问题。

在某些情况下，团队可能无法编写自动化测试：可能是因为测试编写过于复杂、技术太新以至于无法推动，或者是重大的用户界面变更导致原有检查过时而被弃用。

另外，有时自动化检查过于粗糙，虽然可用作冒烟测试，但不足以全面捕捉缺陷，导致问题仍会逃逸到生产环境。在这种情况下，团队需要回到基本面：列出核心功能，记录测试覆盖情况，绘制覆盖与缺口的“地图”，并将其映射到测试仪表板上，用于每次重大发布前的规划。之后，再去协调测试环境、版本管理以及发布计划。