在可测性方面衡量需求

　　需求有意义是非常重要的。然而，“可测性”通常定义为“有利于完全可靠，一致性和可观测性的度量，从而决定是否顺从需求”。这个观点强调除非我们能够度量是否成功，否则我们永远不能知道我们是否完成测试。

　　首先我们应该重新认识一下测试员，他们不是懒汉，他们拥有普通人的洞察能力和推理能力。一个典型的测试员应该能够探索需求的含义和潜在意义，而不一定需要这些信息，像一个濒临绝种的小秃鹰被滴入眼药水一样。事实上，尝试通过简化需求说明从而达到可测试程度，进而减少测试人员的麻烦，这种做法有可能造成更大的麻烦。

　　看一下一个真实的例子：显示控制器应该在300毫秒内响应用户的输入。

　　当一名测试员看到这个需求的时候，他以为要买一台特定的仪器来测量产品的毫秒级性能。后来他意识到：一个正常人能辨别正负50毫秒的分辨率，也许这已经足够精确了。再后来他意识到：也许这个需求项指定到毫秒级不是为了使需求更有意义，而是为了使需求更具衡量性。当他问到设计者时，发现真正的需求是：响应时间“在这个版本的产品中不要慢得烦人”。

　　因此我们看到实际的测试不一定需要精确的需求说明，测试是通过有效的和有意义的沟通进行的。

　　需求，测试与挑战软件

　　1、我们认识产品的问题的能力是受限于我们对问题可能产生的地方的理解。需求规格说明书是一个问题信息的潜在来源。

　　2、我们招致风险取决于发布产品中包含的重要问题的程度和范围。测试的真正任务是把这些风险暴露出来。而不仅仅是展现特定需求的不一致性。

　　3、特别是在高风险的情况下，如果我们能证明测试策略与定义的质量之间的关联，测试过程应该会更具说服力。这超出了至少一个测试对应一个需求项的范畴。

　　4、如果需求说明更多地关注什么才是关键的要求，关注风险、益处和每个需求项的重要程度，则测试过程会更有效。目标可度量性在某些情况下是需要的，但是它不足以产生健壮的测试。

　　如果把这些规则应用到高风险或复杂的软件会发生什么事情呢？

　　随着风险和复杂度的增加，如果测试过程要想完成任务，测试参与到需求的对话中显得尤为重要了。需要更多的测试技巧，作为与开发更好的配合，与用户更好的沟通。在这个关于我们要什么的对话中，测试员应该寻找沟通的更多渠道：更多文档的原材料，图表，演示，谈话和用例。在关于我们能构建什么的对话中，测试员应该熟悉采用了什么技术，并且与开发人员一起为产品构建可增强可测试性的特性。

　　在整个过程中，测试员应该注意项目的风险和复杂性是否超过了测试的能力。