制定测试计划需要考虑哪些方面！

由 乔梁 | 2022-03-05

创建测试计划通常是一项复杂的任务。理想的测试计划是通过应用成本效益分析和风险分析的基本原则，以最佳方式平衡这些软件开发因素来实现的：

• 实施成本：针对特定场景实施可测试功能和自动测试的时间和复杂性会有所不同，这会影响短期开发成本。
• 维护成本：一些测试或测试计划可能从易于维护,也可能难以维护，这会影响长期开发成本。如果选择手动测试，这也会增加长期成本。
• 货币成本：一些测试方法可能需要付费资源。
• 好处：测试能够在不同程度上预防问题并帮助提高生产率。而且，它们越早发现开发生命周期中的问题，收益就越大。
• 风险：故障情况的概率可能即可能很罕见，也可能很常见，其后果可能从轻微的干扰到灾难性结果。

在计划中有效地平衡这些因素在很大程度上取决于项目的关键性、实施细节、可用资源和团队意见。许多项目可以通过高效益、低成本的单元测试实现出色的覆盖率，但它们可能需要权衡大型测试和复杂的 Corner 案例。任务关键型项目必须尽可能降低风险，因此它们将接受更高的成本，并在所有级别的严格测试中投入大量资金。

本指南让读者有责任为他们的项目找到正确的平衡点。此外，它不提供测试计划模板，因为模板通常太通用或太具体，很快就会过时。相反，它侧重于在编写测试计划时选择最佳内容。

测试计划 vs. 测试策略

在继续之前，需要澄清定义测试计划的两种常用方法：

• 单一测试计划：一些项目只有一个“测试计划”，描述了该项目所有已实施和计划的测试。

• 单个测试策略和多个测试计划：一些项目有一个“测试策略”文档，以及许多较小的“测试计划”文档。测试策略通常涵盖总体测试方法和目标，而测试计划涵盖特定功能或项目更新。

其中任何一个都可以嵌入并与项目设计文件集成。这两种方法都很有效，所以选择对你的项目有意义的方法。一般来说，稳定的项目受益于单一的计划，而快速变化的项目最好通过不经常变化的策略和频繁添加的计划来实现。

在本指南中，我将这两种测试文档类型简单地称为“测试计划”。如果你有多个文档，只需将下面的建议应用于你的文档聚合。

为你的测试计划创建具体内容的一个好方法是：从列出所有需要回答的问题开始。下面的列表提供了一系列重要问题，这些问题可能适用于你的项目，也可能不适用于你的项目。浏览列表，并选择所有适用的选项。通过回答这些问题，你就可以找出测试计划的内容，并且应该以团队喜欢的任何格式围绕所选内容构建测试计划。在做决定时，一定要平衡上述因素。

• 你需要测试计划吗？如果没有项目设计文档或产品的清晰愿景，那么编写测试计划可能还为时过早。

• 项目设计中是否考虑了可测试性？在一个项目进入实现阶段之前，所有场景都必须设计成可测试的，最好是通过自动化方式可测。项目设计文件和测试计划都应根据需要对可测试性进行评审。

• 你能及时更新计划吗？如果是这样，请小心不要添加太多细节，否则可能很难维持计划。

• 该质量工作是否与其他团队重叠？如果是这样，您是如何消除工作中的重复数据的？

• 是否存在任何重大项目风险，你如何缓解这些风险? 例如，可以考虑以下方面:
  • 用户数据的安全性和完整性
  • 公司系统的安全性
  • 硬件或财产损坏
  • 法律和合规问题
  • 泄露机密或敏感数据
  • 数据丢失或损坏
  • 无法恢复的场景
  • 对其他项目的影响
  • 其他项目的影响
  • 对公司公众形象的影响
  • 生产力损失
• 该项目的技术漏洞是什么？考虑:
  • 已知的被黑了、脆弱或非常需要重构的的那些特性或组件
  • 经常导致问题的依赖项或平台
  • 用户对系统造成损害的可能性
  • 过去几期的趋势

• 测试的界面看起来是什么样的？它是一个只有一种方法的简单库，还是一个有大量用例组合的多平台客户端——服务器状态系统？以突出可能的故障点的方式描述系统的设计和体系结构。
• 支持哪些平台？可以列出一个应该支持的操作系统、硬件、设备等的清单。同时，描述如何对每个平台进行测试和报告。
• 有哪些特性？考虑制作所有特征的摘要列表，并描述针对这些分类后的特性，如何做测试。
• 什么不需要测试？没有一个测试套件能涵盖所有的可能性。你最好在这一点上保持坦率，并提供不测试某些案例的理由。例如：低优先级的低风险区域、低优先级的复杂案例、其他团队覆盖的区域、未准备好测试的功能等。
• 单元（小型）、集成（中型）和系统（大型）测试，都包括哪些内容？总是在小型测试尽可能多地测试内容，为大型测试留下较少的测试案例。描述特定类别的测试用例如何根据每个测试规模进行最佳测试，并提供基本原理。
• 哪些是手动测试，哪些是自动测试？在可行且经济高效的情况下，自动化通常是最好的。许多项目可以自动化所有测试。然而，选择手动测试也可能有很好的理由。描述一下将做手动测试的案例类型，并提供理由。
• 你是如何覆盖以下每个测试类别的? 可考虑以下因素:
  • 国际化与本土化
  • 性能、负荷、压力和耐力（又名 soak ）
• 您会使用静态和/或动态分析工具？静态分析工具和动态分析工具都可以发现在代码评审和测试中难以捕捉的问题，所以应该考虑使用它们。
• 在测试过程中，系统组件和依赖项将如何被 Stub、Mock、Fake、staged 或者就直接使用？每一项都应有很好的理由，而且每一项都会对覆盖率产生独特的影响。
• 您的测试运行的是什么样的版本上？测试是否针对Head 构建（又名tip）、UAT构建和/或候选版本运行？如果只从 HEAD 开始，您将如何测试版本构建（为发布选择单个变更列表）和系统配置更改，这些变更通常不会被 HEAD 的构建看到？
• 什么样的测试将在你的团队之外进行？例如：
  • 吃自己的狗粮
  • 外部众包测试
  • 公开的alpha/beta版本（发布前将如何测试它们？）
  • 外部的忠实测试人员
• 数据迁移是如何被测试的? 吃自己的狗粮，你可能需要一睦特殊测试，来比较迁移前后的结果。
• 你需要关注向后兼容性吗？您可能会有以前就分发出的客户端程序，或者可能有其他系统依赖于您的系统的协议、配置、功能和行为。
• 您是否需要测试服务器/客户端/设备软件或软件使用的依赖项/平台/API的升级场景？
• 你是否有行覆盖率目标？

工具与基础设施

• 你是否需要一个新的测试框架? 如果是的，请在测试计划中描述这些工具框架，或者添加一个该工具的设计链接。
• 你是否需要建立一个新的测试实验室（ test lab ）? 如果需要，请在测试计划中描述它，或者添加一个它的设计链接。
• 如果你的项目为其它项目提供一个服务，你是否为这些用户提供了测试工具？ 考虑为他们提供 mocks，fakes，和（或）可靠的 staged servers，让他们测试与你的系统的集成。
• 对于 end-to-end 的测试, 如何管理测试基础设施、测试中的系统和其他依赖关系？ 它们是如何部署的？持久化是如何设置或清除的？您将如何处理从一个数据中心到另一个数据中心所需的迁移？
• 您是否需要工具来帮助调试系统或测试失败?你可能会使用现有的工具，或者需要开发新的工具。

• 是否有测试时间计划的要求？做出了什么时间承诺，哪些测试将在什么日期进行（或提供测试反馈）？一些测试是否比其他测试更重要？
• 构建和测试是如何持续运行的？大多数小型测试将由持续集成工具运行，但大型测试可能需要不同的方法。或者，您可以根据实际需要，有选择性地运行大型测试。
• 对于构建和测试结果，如何报告和监控？
  • 你是否有团队轮换来监控持续集成？
  • 大型测试可能需要有专业知识的人进行监控。
  • 你需要有一个测试结果和其他项目健康指标的仪表板吗？
  • 谁会收到电子邮件提醒？如何收到？
  • 监控测试的人只是需要简单地与团队进行口头交流吗？还是别的流程
• 在发布时，那些测试用例是如何使用的？
  • 它们是只针对某个候选版本运行的，还是发布过程只依赖于持续测试的结果？
  • 如果系统组件和依赖项是独立发布的，那么是否针对每种类型的发布运行一些测试用例？
  • “阻塞发布”类型的 bug 会真地阻止实际发布吗？是否就阻止发布的标准达成了一致？
  • 在执行金丝雀发布（又名 滚动发布 rollouts）时，如何执行监控和测试进度？
• 外部用户如何报告Bug？考虑通过用于反馈的专门链接或其他类似的工具来收集和汇聚报表。
• Bug 分类是如何工作的？考虑 Bug 的标签或类别，以便它们正确地分到在 Bug 分类桶中。还要确保负责归档和（或）创建缺陷报告模板的团队知道这一点。您是使用一个 bug 跟踪器，还是需要设置一些定期地自动或手动导入程序？
• 您是否制定了相应的规范？在关闭Bug 的同时，必须提交一个与其对应的新的自动化测试。
• 对于还没有提交的变更，如何使用这些测试用例？如果任何人都可以对一个试验性的构建运行所有的自动化测试（这是好事），应该考虑提供一个“如何做”的指南。
• 团队成员如何创建和调试一个测试用例？你应该考虑提供一个“如何做”的指南。

Utility

• 谁是测试计划的读者? 有些测试计划只有少量读者，而另一些测试计划的读者可能有很多人。至少，你应该考虑从所有的利益相关者那里得到评审(项目经理，技术负责人 tech leads, 特性负责从 feature owners）。当写这个测试计划时，确保你知道预期的读者是谁，为他们提供给足够的上下文来理解这份测试计划，并回答你认为他们会提到的所有问题，即使你的回答是“我现在也不知道”。另外，考虑为这个测试计划加上联系人，以便任何读者都能从联系人那里得到更多的信息。
• 读者如何评审这些实际的测试用例呢？ 手工测试用例可以保存在一个测试用例管理工具中，或在另外一个文档中，或者就写在这个测试计划中。同时，也要提供一个链接，指向包含自动化测试例的目录。
• 你是否需要在需求 Requirement，特性 Feature 和测试用例之间提供跟踪能力？
• 您是否有通用的产品健康或质量目标，以及如何衡量成功? 可以考虑使用下面这些:
  • 生产环境中，被用户发现的 Bug 数
  • 在发布测试过程上发现的 Bug 数
  • 随着时间的推移，打开的 Bug 数
  • 代码覆盖率
  • 手工测试的成本
  • 创建新的自动化测试的难度

谷歌的大多数项目没有手工测试，完全依赖自动测试，对于后端/核心/基础设施项目尤其如此。

如果你问我们的测试是下面两种状态：

1. 是否已经自动化了我们认为必要的测试？
2. 是否已经真正自动化了所有可能的场景和输入/状态的排列组合？

通常是前者，因为成本因素通常会阻止我们测试所有的可能性。

发表时间：July 2006, 2016

原文作者：Anthony Vallone

原文链接：The Inquiry Method for Test Planning