下载掌阅APP，畅读海量书库
立即打开
需求的可测试性，就是要求需求明确，需求定义前后一致，没有矛盾，没有二义性。需求可测试性，包括功能性需求的可测试性和非功能性的可测试性。对于功能性需求，可以要求通过一定的规格、格式来明确需求，例如用敏捷方法的用例或用户故事来描述需求，如图3-6所示，角色、操作及其背景都是很清楚的。
图3-6 用户需求描述的模板和示例
当然，需求的描述往往不能如此简单。系统设计的简单性或代码的简单性将有利于测试，但需求描述过于简单，会导致每个看到需求的人，其实际的理解是不一样的，大家对需求的理解不一致的话，那么需求是模糊的，缺乏可验证性。为了使需求具有更好的可测试性，需要对用户的实际需求有一个更明确的说明。例如，对于网上在线预订系统的“取消预订”功能，我们可以描述为：
作为一个旅行者，我不需要一项一项地取消订单，而是可以容易地取消整个订单。
但这样的描述还不够，因为我们会有如下一大堆的问题：
●什么情况下可以取消？什么情况下不能取消？
●多长时间的订单可以取消？
●取消一个订单，要不要额外收费？
●取消订单前，是否需要确认？
●取消成功后，如何通知用户？
所以，我们需要确定该项功能的具体验收标准，例如：
●离订单开始时间大于24 h，才可以取消。
●需要额外收取10%的费用。
●需要用户确认。
●在确认前，清楚地显示要取消订单的详细内容。
●取消过程在2 h内完成。
●取消完成后，发送短消息到用户手机。
需求定义中不应该使用不确定性的词，如“有时、多数情况下、可能、差不多、容易、迅速”等，而应明确指出事件发生或结果出现所依赖的特定条件。对说明书中所有的术语（terminology）进行仔细检查，看是否事先对这些术语有清楚的定义，不能用同一个术语来描述意义不同的对象，同一个对象也不宜用两个以上术语去描述，力求保证术语的准确性，不会出现二义性。这样，功能需求是明确的。而对于非功能性，也需要明确的定义。例如，对性能的要求，不能仅仅说明“系统要足够快”，而是要给出如下这些具体的性能指标：
系统能够每秒接受 50 个安全登录，在正常情况下或平均情况下（如按一定间隔采样）Web 页刷新响应时间不超过3 s。在定义的高峰期间，响应时间也不得超过12 s。年平均或每百万事务错误数要少于3.4个。
记得有一次，在某个会议演讲之后，有个与会的测试工程师问，如何进行可靠性测试？大家可能会将可靠性计算公式告诉他，然后告诉他可以用压力测试来进行可靠性测试。但这不是最有效的方法，我告诉那个测试工程师，“您首先要问系统架构师或系统设计人员，他们是如何来保证系统可靠性的？有冗余设计吗？有故障转移设计吗？安全性是如何保证的？了解了可靠性实现方法，就可以验证这些方法是否有效，这样的测试方法才会有效”。这也就是说，先要保证系统可靠性的可测试性，有了相应的测试途径，测试才能有效执行；否则，可以用压力测试方法进行高负载的测试，可以发现像内存泄露这样的问题，或瞎猫碰到死耗子，发现其他问题，但这样不能完成对可靠性的充分测试，即在测试完成后，依旧对可靠性没有信心。