测试人员的首要职责是找bug，但是最重要、最根本的职责应该是在软件产品发布前确保公司的软件产品满足顾客的需求。
测试组采用RBT（Requirements-based testing），基于需求的测试方法会使测试更加有效，因为它使测试专注于质量问题产生的根源。
研究报告指出，多年来，大部分的软件项目不能按计划完成，不能有效控制成本。大部分项目失败的首要原因是软件质量差，导致大量的返工、重新设计和编码。其中软件质量差的两大原因是：软件需求规格说明书的错误、有问题的系统测试覆盖。
需求规格说明书中的错误
我们经常听到最终用户抱怨、不用我们的软件，而这些软件还通过了严格的测试和QA。对于这点我们不会感到惊讶，原因是我们知道需求从一开始就是错误的。
一项调查（James Martin (“An Information Systems Manifesto,” Prentice Hall, 1984）表明56%的缺陷其实是在软件需求阶段被引入的。而这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的。剩下的50%是由于需求的遗漏导致的。
有问题的测试覆盖
要获得满意的测试覆盖率是很难的。尤其现在的系统都比较复杂，功能场景很多，逻辑分支很多，要做到完全的覆盖几乎不可能。
再者，需求的变更往往缺乏控制，需求与测试用例之间往往缺乏可跟踪性。
RBT三大最佳实践
1、 Test early and often.尽早测试，频繁地测试
确认需求的业务价值。
各利益相关方应该对需求进行评审。
通过用例检查需求的完整性
应用语言分析技术确保需求文档清晰一致，不会引起同一问题不同人有不同的解释。
2、 Test with your head, not your gut.不要单凭经验测试
不要依赖测试人员的经验来设计测试用例，应该采用系统、严格的测试用例设计方法，而不是依赖有经验的测试人员的技巧。通过这样的方式来增加测试覆盖的有效性。格式化、结构化的需求文档有助于测试人员评估需求的测试覆盖率。
通过测试用例评审来检查测试用例存在的错误，并且找出需求的不足之处。
3、 Test with measurement and improvement in mind.测试过程中要保持度量
在使用基于需求的测试方法的过程中，保持对需求的可追踪性非常重要。保持需求与测试用例及测试之间的可追踪性有助于监视进度、度量覆盖率，当然也有助于控制需求变更。
