需求质量验证-测试需求

通过阅读软件需求规格说明，通常很难想像在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作可以解释需求的许多问题（ Beizer 1990）。如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。
编写关于黑盒子或功能上的测试用例可以明确在特定条件下系统运行的任务。因为你无法描述可能的系统响应，在你面前将会出现一些模糊的和二义性的需求。当分析员、开发人员和客户通过测试用例进行研究时，他们将对产品如何运行的问题有更清晰的认识。
在开发过程的早期阶段，可以从使用实例中获得概念上的功能测试用例（ Ambler 1995;Collard 1999）。然后，你就可以利用测试用例来验证文本需求规格说明和分析模型（例如对话图）并评价原型。这些基于模仿使用的测试用例可以作为客户验收测试的基础。在正式的系统测试中，可以把它们详述成测试用例和过程（ Hsia, Kung and Sell 1997）。在客户定义他们验收的标准时，你询问客户的基本问题是：“如果开发出你们所期望的软件，你是怎么来判断开发出的软件是你真正所需要的？”如果他们不能回答关于每个特性或使用实例的这种问题，他们就必须澄清需求。

在前面的章节中，我提到过一种情况：我让开发组中的U N I X脚本专家C h a r l i e为我们正在使用的“商业错误跟踪系统”编写一个简单的电子邮件接口扩展。我写了许多需求， C h a r l i e觉得这对他很有帮助；因为他以前编写脚本时，别人从未给他提出需求。不幸的是，在我为电子邮件功能编写测试用例之前却延误了两个星期。后来，我找到了错误，那是因为二十多个测试用例中代表的我对电子邮件功能的认