我想我们需要粉碎这种测试观点：测试是一种机械的过程.

　　需求开发不是在项目启动时一次搞定的。实际上，需求是贯穿在项目生命周期中的两方谈判。一方在问：我们需要什么？而另一方则在问：我们能构建什么？

　　这两方对话的质量帮助决定产品的最终质量。

　　我把需求理解成众多想法的集合，它们共同为特定产品定义质量。我把测试定义成开发一套评估系统的过程，用于对产品质量进行评估。

　　风险与需求测试

　　至少有四种关于需求与测试的腐朽观点：

　　1、除非有稳定的需求，否则测试不可能进行。

　　2、一个软件产品必须满足它的特定的需求。

　　3、所有测试用例必须可追踪到一个或多个特定的需求项，反之亦然。

　　4、需求必须以可测的方式描述。

　　然而，当我们考虑到风险，我相信有更丰富的概念出现。

　　没有特定需求下的测试

　　满足需求是非常重要的，测试员的工作之一就是确认产品满足需求，所以明显测试人员需要清楚需求。所以上面说的不无道理，并且在大部分情况下是对的。

　　但是，由于不完整性和不清晰性，测试不能仅仅认为是一个确认过程。测试同时还是探索需求和实现的过程。因此，测试不仅可以没有特定需求，而且在需求不确定的情况下特别有用。我想我们需要粉碎这种测试观点：测试是一种机械的过程.通过测试和开发的合作会产生巨大的价值。有经验的测试员通过他们对未定需求的理解评价产品，并且通过观察来挑战或提问项目成员对质量的共同理解。

　　一个好的测试员会对特定需求的差距始终保持警惕，并且解决这些差距到一定的程度：满足特定情况下的风险。

　　满足特定需求

　　如果每一个特定的需求项都是产品的真实声明，然后我们把产品质量定义为这一前提的延伸。那么软件产品必须满足它的特定需求这一观点是成立的。但是那有赖于我们有非常清晰和完整的需求集合。否则，你将被锁定在一个很窄的质量范围内。

　　关于满足需求的更广泛的思考范围是把我们的思维转变到考虑不满足特定需求的风险。好的测试员会努力地回答这个问题：什么是这个产品的重要问题？

　　把测试用例跟踪到需求

　　需求如果要发挥作用，则测试与需求之间应该有所关联。谈到可追踪性，通常摘要为：

　　为每个需求项ID，列举关联的测试用例的ID；为每个测试ID，列举关联的需求ID。

　　测试的完整性被大概地通过“对于每个需求项，至少有一个测试关联”来估计。这是一个很理想的观点。

　　如果可追踪性的目的是用于证明测试策略已经验证了产品的需求，那么我们应该进一步。我们应该随时准备回答客户的问题。“你怎么知道它证明了？”我们应该能解释我们的测试与需求之间的关系。重要的是需求和测试是如何关联的，并且随着产品风险越高越重要。