有位网友很执着的希望了解到更多更详细如何测试需求的信息。可无奈最近都太忙或太累，休息时间没有抽空来更新blog。虽然，关于需求质量如何测试的更多细节由于涉及公司知识资产保护不能分享。但是，我可以给大家一些点拨，这些方法是国际通用的需求质量评审方法。
需求质量的把握首先可以从需求评审维度的全面性来支撑评审活动的质量，参考国际通用方法有：
1： 需求描述是否具备完整性；（没有遗漏内容；或描述片面）
2： 需求描述是否有二义性；（没有让不同的人有不同的理解结论）
3： 需求描述是否是正确的；（需求之间没有冲突等）
4： 是否包含有非功能属性的需求；（性能，安全性，可靠性，易用性等）
5： 是否需求是可以验证的；（需求描述具备可测试性）
6： 需求是否可实现；
更多细节，请见这个链接中的内容：
http://download.51testing.com/ddimg/uploadsoft/20100507/reqreview.doc
还有 Delta公司的测试地图，google搜索吧。
其次，关于需求评审的效率。可以采用2个人单独一个房间抽取专门的时间段100％投入进行结对评审的方式。事实证明，一大群能力高低不平的人集中在一个地方开评审会的方式，不但评审不会系统，而且沟通交流效率很低（太多意见不一致，人越多越难达成一致）。采用敏捷2个人结对编程的思想，结对评审能很好的在第一时间发现需求存在的二义性，而且2人还可以马上进行讨论，很快达成一致意见，能大大提高单位时间内需求评审的效率和需求评审质量。
最后，需求文字描述质量的把关。如果我们测试人员无法在需求的有无上进行判断或需求的价值上进行建议，那么测试人员至少可以在需求描述的质量上进行一定的把关。有一个很简单的道理：如果开发人员在需求描述上都存在含混不清，或是描述不准确，不完整，那么后续的程序员在阅读需求时肯定会很吃力，一定会对需求理解产生偏差，在开发实现时与最初需求编写者的要求产生偏差。测试人员在依据需求进行测试用例编写时，也会出现需求理解困难，导致测试用例编写的困难，最终测试未能覆盖到需求编写者的最初想法。
所以，当需求了解和分析被开发人员一家独占，测试人员只能进行辅助工作时，那就在开发人员提供已有的需求描述的材料上，尽可能的进行需求描述质量的测试。只要测试人员坚持做，敢做，尽力去做，需求质量的测试工作一定能开展下去。投入多少，就能得到产出多少，而测试人员的需求评审能力也能持续提升。
在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例，
需求阶段：设计阶段：测试阶段：上市阶段＝N:10N:100N:1000N；也就是说，如果需求的缺陷在测试阶段才被发现，那么用于修复需求缺陷的成本将是需求阶段修复该缺陷成本的100倍，如果在上市后才发现，那么成本将是1000倍。
事实上我一直认为：时间越短的项目，人员越少的项目，越要加强需求质量的测试，绝对投入产出是最大，也是解决时间不足，人员不足的好方法。根据经验，需求中隐含的缺陷如果是在系统测试阶段发现，大部分需求隐含的缺陷都是功能级缺陷，缺陷影响力是比较大的。
任何好的工程方法，好的思想，只是武器。有好的武器能提高好猎手的效率，但是如果猎手能力经验不够，好武器的效果会大打折扣。方法不用贪多，在用好用精手上的方法之前，用好自己的武器胜过再寻找更多的武器。需求评审的方法是“术”，而足够的测试经验、项目经验和责任心则是“道”。同样的需求测试方法，选取不
同的人来实施，得到的效果和结果都是不一样的。我的建议是：需求评审最好选取项目测试经验最丰富的同事来实施。
版权声明：本文出自架构师Jack的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。