京东购买链接：https://item.jd.com/10205955087769.html
6.4 测试计划和测试用例
传统的测试文献中，到处都是与测试计划相关的内容。我们认同计划的重要性，但老实说……我们并未完全理解那些提倡详尽测试计划的人究竟想要表达什么。因此，我们决定引用一些关于计划的论述，然后尝试对其分析，以此来深入了解其背后的思想逻辑和实际应用的意义。
不去计划就等于计划着失败。—雷内·布尔洛克于 1995 年夏天
没有任何作战计划在与敌人遭遇后还有效。—普鲁士元帅赫尔穆特·冯·莫尔特克
计划是没用的，但是整体的规划是无价的。—美国总统德怀特·戴维·艾森豪威尔
每个人都有自己的计划，直到他们嘴上挨了一拳。—拳王迈克·泰森
这些名言传达了一个核心观点：完全遵循预设计划往往是徒劳的，因为实际情况总会有变数。因此，当人们谈论“测试计划”时，我们难免感到诧异。接下来，我们将拆解测试计划的含义，它是如何被执行的，实际中会发生什么，以及如何有效地进行测试计划。
有些人认为测试就是重复执行他们已经设计好的所有测试场景，我们将这些场景称为“测试用例”。通常，测试用例用来检查某个特定的功能，以及可能的功能组合。
这种理念似乎意在建立一个测试用例库。测试人员或者计算机可以逐个检查测试用例，执行后标记为通过或失败。完成后，再把测试用例“归位”。在某个地方，有人负责追踪哪些测试用例通过，哪些失败。如果发现了需要修复的bug，那么这个测试用例就会被标记为失败。当 bug 被修复后，再重新运行这些测试用例，然后测试继续进行，直到所有需要修复的 bug 都被标记为已修复，且相关的测试用例全部通过，或者测试时间耗尽为止。
坦率地讲，我们并不知道测试计划的主线具体是什么。似乎是一个文档，将所有测试用例整合在一起，可能还会描述由谁做哪些内容，以及哪些测试（比如安全性测试）没有执行，或者声明测试的边界。
此处描述的情况并不符合我们的实际经验。因此，让我们花些时间来谈谈我们在项目中实际观察到的情形。
如今，人们使用的测试用例，可能只是对某个微小功能进行测试。这类测试通常非常详细具体，编写起来会相当费神。编写测试用例的人可能具备一定的水平，随后将这个用例转交给水平较低的人执行。随后，这个测试用例将被用于手工测试那个微小功能。有时，也有人会编写类似的工具，执行类似的操作，并将其加入回归测试套件中，实现自动化。
软件发布时，公司通常会遵循一套固定的发布流程。如果变更仅涉及单个组件（比如 API），并且该 API 经过了测试，所有的自动化回归检查也全部通过，那么变更可能会立即部署到生产环境并接受监控。但是，如果这一变更不能单独部署，而是与其他多个变更混合在一起，那么这一变更将会被保留，之后与其他变更一起发布，可能是在“冲刺”末尾。在冲刺结束时，公司会进行一系列检查工作，有时称之为回归测试，具体实施过程可能是自动化工具和人工测试的结合。
虽然很难一概而论，但我们会发现，回归测试过程更侧重于模拟用户旅程，并且功能测试（“测试用例”）更紧密地围绕特定功能及其相关变更时，会取得更多成功。这种方法区分了功能测试和回归测试的风格。同样地，当我们看到用户界面测试被自动化时，经常会发现有许多小的检查点，这些检查能在几秒内完成，每次只验证一个具体事项。一旦这样的测试体系建立起来，就可以利用工具以随机顺序执行这些检查，利用冗余和重复验证增强测试的健壮性。
事实证明，那些详尽记录、使用自然语言编写（而非代码）、按步骤说明的测试用例，编写成本高昂，且容易过时，很少能产生大量价值。但它们确实包含了一些有价值的信息，比如确切知道如何准备复杂的测试前置条件。我们把这些称为“配方”，并认为它们应当成为流程的一部分。本书第 9 章将探讨如何构建一个更佳的流程来涵盖这部分内容。
目前，你应该知道，“测试用例”这个词可以指代很多不同的内容，它们服务于不同的受众群体—项目经理对测试用例的关注可能与测试人员截然不同。测试计划也是如此。
我们确实认为，在测试过程中使用一定的度量标准是有必要的，也是合理的。比如，“通过的测试用例数量除以计划的测试用例数量”能给我们一个简单易懂的百分比，可以用来讨论进度、发布时间表和“完成度”。对于那些发布周期超过几周，并且拥有较长回归测试周期的团队来说，通过的测试用例百分比听起来颇具吸引力。但是，为了这样一个指标投入大量精力，实际可获得的价值却是有限的。
一节，我们一起来看一看度量指标。