RBT测试

http://danielzzu.blog.163.com/blog/static/118515304201091902343768/

　测试人员的首要职责是找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.测试过程中要保持度量

　　在使用基于需求的测试方法的过程中，保持对需求的可追踪性非常重要。保持需求与测试用例及测试之间的可追踪性有助于监视进度、度量覆盖率，当然也有助于控制需求变更。

---

hink we need to break out of the mythology that testing is some kind of robotic process.

我想我们需要粉碎这种测试观点:测试是一种机械的过程

需求开发不是在项目启动时一次搞定的。实际上，需求是贯穿在项目生命周期中的两方谈判。一方在问：我们需要什么？而另一方则在问：我们能构建什么？

这两方对话的质量帮助决定产品的最终质量。

 

我把需求理解成众多想法的集合，它们共同为特定产品定义质量。我把测试定义成开发一套评估系统的过程，用于对产品质量进行评估。

 

RISK AND REQUIREMENTS TESTING 风险与需求测试

至少有四种关于需求与测试的腐朽观点：

1.除非有稳定的需求，否则测试不可能进行。

2.一个软件产品必须满足它的特定的需求。

3.所有测试用例必须可追踪到一个或多个特定的需求项，反之亦然。

4.需求必须以可测的方式描述。

 

然而，当我们考虑到风险，我相信有更丰富的概念出现。

 

Testing without stated requirements 没有特定需求下的测试

满足需求是非常重要的，测试员的工作之一就是确认产品满足需求，所以明显测试人员需要清楚需求。所以上面说的不无道理，并且在大部分情况下是对的。

 但是，由于不完整性和不清晰性，测试不能仅仅认为是一个确认过程。测试同时还是探索需求和实现的过程。因此，测试不仅可以没有特定需求，而且在需求不确定的情况下特别有用。我想我们需要粉碎这种测试观点:测试是一种机械的过程.通过测试和开发的合作会产生巨大的价值。有经验的测试员通过他们对未定需求的理解评价产品，并且通过观察来挑战或提问项目成员对质量的共同理解。

一个好的测试员会对特定需求的差距始终保持警惕，并且解决这些差距到一定的程度：满足特定情况下的风险。

 

Satisfying stated requirements 满足特定需求

如果每一个特定的需求项都是产品的真实声明，然后我们把产品质量定义为这一前提的延伸。那么软件产品必须满足它的特定需求这一观点是成立的。但是那有赖于我们有非常清晰和完整的需求集合。否则，你将被锁定在一个很窄的质量范围内。

 

关于满足需求的更广泛的思考范围是把我们的思维转变到考虑不满足特定需求的风险。好的测试员会努力地回答这个问题：什么是这个产品的重要问题？

 

Tracing test cases to requirements 把测试用例跟踪到需求

需求如果要发挥作用，则测试与需求之间应该有所关联。谈到可追踪性，通常摘要为：

为每个需求项ID，列举关联的测试用例的ID；为每个测试ID，列举关联的需求ID。

测试的完整性被大概地通过“对于每个需求项，至少有一个测试关联”来估计。这是一个很理想的观点。

如果可追踪性的目的是用于证明测试策略已经验证了产品的需求，那么我们应该进一步。我们应该随时准备回答客户的问题。“你怎么知道它证明了？”我们应该能解释我们的测试与需求之间的关系。重要的是需求和测试是如何关联的，并且随着产品风险越高越重要。

 

Stating requirements in testable terms 在可测性方面衡量需求

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

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

 

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

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

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

 

REQUIREMENTS, TESTING,AND CHALLENGING SOFTWARE 需求，测试与挑战软件

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

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

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

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

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

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

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

 

----

记者：那么基于需求的测试从理论、方法、概念到工具都包含有哪些内容？

Richard Bender：我觉得RBT方法被业界广泛认可，一个很重要的原因就是大家都已经认识到，如果不去关注软件需求的话，是没有很好的办法来提高软件质量的。有很多的数据已经表明，缺陷发现的越早，造成的损失就越少，而现在我们很多的软件要等到代码完成以后才进行测试，实际上那时候已经为时过晚。

RBT的方法关注于三个方面，首先是需求，我们曾与几百个项目在一起合作，从来没有发现完全不存在问题的需求。但是其他的很多测试方法，通常会认为需求是对的，接下来的开发和测试也是基于这个需求的。在RBT过程中有很多步骤可以用来保证软件质量的，比如说RBT工具会提供给测试工程师一个检查单，这样很容易就可以清除软件需求说明书里面的故障，可以尽早的避免缺陷，而不是像现在这样等到代码完成以后才去发现缺陷。RBT的一个很重要的步骤是对需求进行二义性评审，实践证明通过需求二义性的评审可以大大减少软件在下一版本中存在缺陷的可能性，数据也表明通过需求二义性评审可以发现大约90%的软件缺陷，从而提高大约20倍的工作效率。

其次，目前软件测试领域面临一个穷举测试的挑战，我们知道即使一个非常简单的软件，要想穷尽所有的可能性都是非常困难的，如此以来就会导致测试用例的数量急剧膨胀。所以，我们面临的挑战，就是在有限的时间内把巨大的穷举测试缩小到我们能够接受的最小的一个集合的数目。对测试用例数量进行缩减也有很多方法，有组合对法、等价类划分，相对来说RBT方法所得到的测试用例远远小于其他技术方法，因为RBT方法是由硬件的逻辑测试派生出来的方法。IBM、波音和CISCO等公司的应用实践也证明，通过RBT的方法可以减少大约1/4的测试用例，这对于提高测试效率来讲是非常重要的。

最后，在软件测试领域还有个亟待解决的问题，就是缺陷的可观察性，目前只有通过RBT方法可以实现。在硬件测试领域中，敏感路径法是很成熟的方法，可以实现硬件测试的可观察性，而RBT正是基于这一方法，根据软件的特性对这一方法做了大约70%的扩展。通过这种方法，测试工程师最终能够通过运行测试用例发现一个或多个缺陷，让其可观测，并在迭代测试中发现其他缺陷。RBT方法可以告诉工程师在代码的什么位置应该预留测试窗口，以观测当前系统运行状况是否正确。比如我们以硬件为例，罗尔斯·罗伊斯公司的航空发动机大约有2000多个硬件检测点；而嵌入式系统因为外部可观察的窗口很少而在系统里预留了很多观测点。反观软件却是世界上唯一一个如此复杂而没有预留检测点的产品，归根到底关键问题还是目前的测试方法比较初级所致。在已经过去的40多年里，RBT的方法和理论已经应用到PC机、大型机、CS软件、嵌入式软件等各个方面，运用RBT方法设计的测试可以发现超过50%的软件缺陷，而普遍代码测试往往只能发现3%左右。通过RBT方法测试过的这些系统一旦成为产品，将不会存在严重程度的缺陷，从而可以帮助客户大大缩短产品上市时间、减少产品研发成本、提升竞争力。所以说RBT的核心思路就是去尽可能的避免缺陷，而不是去像现在这样一味的发现缺陷。