RBT测试

RBT

测试

测试

人员 的首要职责是找

bug

，

但是最重要、

最根本的职责应该是在软件产品发布前确保

公司的软件产品满足 顾客的需求。

< br>测试组采用

RBT

（

Requi rements-based testing

），基于需求的测试方法会使测试更加< /p>

有效，因为它使测试专注于质量问题产生的根源。

研究报告指出，多年来，大部分的软件项目不能按计划完成， 不能有效控制成本。大部分

项目失败的首要原因是软件质量差，导致大量的返工、重新设 计和编码。

其中软件质量差的两大原因是：软件需求规格说明 书的错误、有问题的系统测试覆盖。

需求规格说明书中的错误

我们经常听到最终用户抱怨、

不用我 们的软件，

而这些软件还通过了严格的测试和

QA

。

对于这点我们不会感到惊讶，原因是我们知道需求从一开始就是错误的。< /p>

一项调查（

James Marti

n (“An Information Systems Manifesto,” Prentice Hall, 1984

）

表明

56%< /p>

的缺陷其实是在软件需求阶段被引入的。而这其中的

50%

是由于需求文档编写有

问题、不明确、不清晰、不正确导致的。剩下的

50%

是由于需求的遗漏导致的。

有问题的测试覆盖

要获得满意的测试覆盖率是很难的。

尤其现在的系统都比较复杂，

功能场景很多，

逻辑

分支很多，要做到完全的覆盖几乎不可能。

再者，需求的变更往往缺乏控制，需求与测试用例之间往往缺 乏可跟踪性。

RBT

三大最佳实践

1

、

Test

early and often.

尽早测试，频繁地测试

确认需求的业务价值。

各利益相关方应该对需求进行评审。

通过用例检查需求的完整性

应用语言分析

技术

确保需求文档清晰一致，不会引起同一问题不同人有不同的解释。

2

、

Test with your head, not your gut.

不要单凭经验测试

不要依赖测试人员的经验来设计测试用例，应该采用系统、严 格的测试用例设计方法，

而不是依赖有经验的测试人员的技巧。通过这样的方式来增加测 试覆盖的有效性。格式化、

结构化的需求文档有助于测试人员评估需求的测试覆盖率。< /p>

通过测试 用例评审来检查测试用例存在的错误，并且找出需求的不足之处。

3

、

Test with measurement and improvement in mind.

测试过程中要保持度量

在使用基于需求的测试方法的过程 中，

保持对需求的可追踪性非常重要。

保持需求与测