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

第 24 条：利用系统设计和系统原型

原型有助于检测需求中的不完整性和不一致性，并且为开发定制工具奠定了基础。如果及早的为高风险和高复杂性的部分制作原型，那么我们就能在整个过程的早期开发出正确的测试机制（例如：自制测试工具），并不断加以改进。原型还有助于利用功能性测试工具的自动测试工作的设计。

第 25 条：设计测试用例场景时采用经过检验的测试技术

经验表明，综合使用多种测试技术比单一的测试技术更有效。例如：

• 功能分析法。
• 等价类划分法。
• 路径分析法。
  • 白盒测试。单元测试通常在这个层次完成，在代码开发完成或者修改后由作者或程序员马上完成。
  • 黑盒测试。
• 边界值分析法。
• 正交排列法。最小的测试过程集合获得最大的测试覆盖率。

第 26 条：在测试过程中避免包含限制和详细的数据元素

为了保持测试过程模板的可维护性，应该用通用的方式来编写模板。在测试过程中包含详细的测试数据不是一种好做法，因为这样会带来不必要的重复。
为了使测试过程容易维护，应该把特定的测试数据输入和响应的预期输出结果单独放在一个场景文档中。测试数据场景信息可以保存在数据表或者数据库中，其中每行定义一个单独的测试用例，这些场景可以被测试过程引用，同时引用的还有反映具体数据的、用于每个测试过程的场景示例。为了参考对数据的限制应该查阅数据字典。确保这些测试过程时可重用的以后，就可以避免维护困难的问题。造成测试过程维护困难的主要原因是：测试用例中出现了非常底层的细节以及把数据绑定到特定场景的测试过程的硬编码。

为全部测试过程形成如图的测试数据场景文档需要巨大的工作量。如果只把主要的测试过程应用的测试数据保存在单独的数据表或者数据库中，那么会使维护变得更容易。
如果数据元素没有包含在主要的测试过程中，是单独放在其他分开的位置，那么这样的测试过程文档对于自动测试尤其有益，并且还能成为其他测试过程的基础。无论是手动还是自动测试过程，都应该把数据元素和他们的测试脚本分开保存，在脚本中应该使用变量而不要使用硬编码的数值。

第 27 条：运用探索性测试

• 对系统缺乏了解。如果没有明确的需求、设计、测试文档，可以通过探索性测试理解系统。
• 用迭代的方法确定测试条件。在测试工作早期发现的问题模式有助于指明以后测试工作的方向，比如早期的研究表明某个部分错误成堆，另一部分错误较少，那么我们就要调整测试工作的中心。
• 确定某个特定功能的阈值。如果需求没有指定某个功能的阈值，客户和开发也没有具体的答案，测试人员有必要设计和执行一个测试过程，来确定这个阈值，在经过客户、产品确认认可后，把这个阈值公布给所有涉众。 由于探索性测试的指导思想是具体问题具体分析，所以他们是不能预先规划的。但在执行前和执行后，把探索性测试文档化，并且把他们加入回归测试中绝对时一个好办法。

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