有效测试的 50 条建议 - 测试设计和测试文档（20）

测试设计和测试文档时测试组的主要工作。结构化的方法有利于测试过程，这种方法定义了测试过程操作的级别、测试过程文档的格式、选择的测试技术。在需求和设计的评估过程中，通过了解架构、评审原型、现存的应用程序，测试组能够在保持预算和进度的情况下，把各种测试任务 “分而治之”。

第 20 条：分而治之。

为了理解用来定义当前测试项目的测试目标、测试范围、测试方法的环境和框架，设计测试过程的第一步是回顾测试计划。
为了分解测试任务，需要回答下面几个问题：

• 应该测试什么？哪些内容要测，哪些内容不需要测，把他们作为测试范围的一部分写入文档。
• 何时开发测试过程？一旦得到需求，就应该马上开发测试过程。
• 哪些内容需要先测试？应该了解测试的优先级，熟悉版本和发行的时间表。用于测试高优先级功能的测试过程应该先开发，但是有一个例外：有些功能的完成是其他功能的前提和基础，那么必须首先运行这些前提功能。此外，为了帮助划分测试优先级，应该使用风险分析，如果不可能测试所有内容，那么测试只能关注最重要的元素，风险分析提供了确定这些元素的方法。（见第 7 条）
• 测试过程应该如何设计？系统不同部分，测试过程使用的设计方法也不同，对测试这些部分来说必须是最恰当和最有效的。
• 谁应该负责测试开发工作？确定了测试内容、何时开始测试工作、完成测试的方式，那么根据各类测试人员预定的角色和职责，确认执行测试任务的人员就容易了。

除了上面几个问题外，还会出现下列疑问和问题：

• 如果没有书面的需求文档怎么办？有必要想客户代表、技术人员当面咨询，同时还有必要阅读任何可以利用的文档。如果存在遗留系统，要讨论风险，以及得到开发过程的设计文档。但要注意，文档不一定正确描述客户需求，某些情况下，可能需要使用逆向工程和探索测试。
• 黑盒和灰盒测试结合。
• 需要开发自制测试工具吗？系统中的某些组件只能用自制测试工具来测试，例如：测试计算疫情，我们需要大量的数值来验证。
• 应该使用什么类型的测试技术？
• 应该使用记录/回访工具或者其他测试工具吗？测试策略的定义需要确定程序的哪些部分应该使用自动测试工具，哪些部分使用自制测试工具，哪些部分必须手动测试。在测试过程中应该避免过分依赖自动测试工具的记录/回放功能。
• 哪些测试应该自动执行？
  • 需要多次执行的测试。
  • 风险高的测试项目。低风险的元素不值得使用自动测试方法。
  • 运行有规律的测试。这样的例子有冒烟测试、回归测试、平凡测试（许多简单和重复的步骤、并且必须反复执行的测试）。
  • 用手动测试不可能完成的或者代价过大的测试。
  • 用多种数值对统一动作的测试（数据驱动的测试）。
  • 在不同配置下运行的基线测试。
  • 结果可预测的测试。如果某项测试的输出不可预测，那么使用自动测试就不划算。
  • 对基本稳定的系统的测试。功能、实现和技术都不轻易发生变化。
• 需要什么样的测试数据？

同时考虑可供支配的预算和时间表也是非常重要的。

本文章援引《Effective software testing》一书内容，为个人读后笔记，特此声明