如何落实RBT测试最佳实践？

RBT测试方法的核心思想是一切从需求出发构建测试过程。围绕这个思想，RBT提出了三大最佳实践，作为实施RBT测试的原则方法：尽早测试，频繁地测试；不要单凭经验测试；测试过程中要保持度量。

该如何落实这三大最佳实践呢？谈下我的理解。

一、     尽早测试，频繁地测试

所谓“尽早”的意思，就是应该在需求出现的地方开始测试，而不是在设计出现或者软件、产品出现时才开始。要做好“尽早”测试，测试人员必须弄清楚什么是关键需求？软件的价值一定是围绕关键需求展开的，但是通常，用户倾向于提出所有想要的需求，不会对需求的重要性做清晰的划分；好的设计人员会从用户的需求中萃取出关键需求，但由于要频繁考虑技术实现问题，经常会将角度部分转向关键需求实现方面，最糟糕的情况是从关键需求实现完全转向关键技术实现，与用户关键需求产生较大偏离。这时，测试人员可以首先分析用户的关键需求，然后和设计人员的关键需求实现进行对比，从印证中发现其中的差别，测试这种差异性对用户的影响。这时的测试需要测试人员对需求的洞察力和沟通能力，这种能力越强，测试可以开始的越早。如果一时达不到这种能力，可以适当推迟测试的开始时间，不要贸然开始。但无论早晚，上述应该做的事情是一致的：抓住关键需求。

频繁测试潜在的风险是测试的成本问题，如果频繁测试，但很少发现问题，测试的经济性就会下降。降低这个风险的办法是保持前后测试行为之间的相关性。后一个测试应该是对前一个测试在广度上的有限扩展或者在深度上的有限延伸。如果上次测试后设计部门对有测试问题的部分进行了改进，同时又提供了新的部分的全新功能，这时测试时应优先考虑对改进部分做回归测试，再增加新部分的测试内容。另一种保持相关性的方法是跃迁，比如性能测试中，在方案中设计条件用例，如果测试中软件达到第一测试性能，就提高一个数量级测试软件是否达到第二测试性能，并以第二测试性能作为测试结果。这样做的好处是可以尽早的发现软件的价值或者缺陷，将下一次测试的内容前置，再次执行了“尽早测试”的原则。

二、     不要单凭经验测试

依照需求规划测试，有时会落入一个陷阱：软件需求，尤其是初期的需求，一般会比较关注需要软件做到什么，而只用少量笔墨描述不要软件做什么。造成软件经常会做一些不应该做的事情。RBT的这个原则是规避这种陷阱的好办法。

在实践中会发现，采用系统、严格的测试用例设计方法可以大幅提高设计用例覆盖的有效性。我的经验是，一方面通过需求获得用例，另一方面通过系统化的标准获得用例，然后将这两种用例中进行匹配。注意在深思熟虑之前，不要轻易决定删除任何一个显现矛盾的细节，因为这样的细节往往有助于发现需求的不完善性。

匹配过程中最痛苦的是对用例整体结构和用例合并与分解的取舍，但这样的痛苦是有价值的，因为这促使测试人员充分衡量用例对提高软件价值的贡献程度。好的测试人员经过这个过程，有可能获得比用户和设计人员更加完整的视野，第一个对最终产品形成清晰的认识图景。实际上，需求与实现上的很多细小问题都是在这个过程中被发现的。

三、     测试过程中要保持度量

在测试过程中保持需求的可度量性，与其说是检验测试人员的能力，不如说是在考验测试人员的态度和毅力。

实践中，解决需求的可测性问题会时刻受到将需求削减为可测的诱惑，这样的诱惑不仅来自于测试人员的本身能力，也来自其他部门人员和环境的压力。

将需求变得可测需要测试人员具有较强的创新能力，能够以独特的视角找到测试需求的方向，某种程度上和寻宝一样，要在所有的钱没有花光之前找到宝贝有时是很艰难的，其间会一次又一次的怀疑是都真的有宝藏存在。

另一方面，摆在测试人员面前的很多需求是具有迷惑性的，这点在RBT理论中举的例子中可以鲜明的看到。要拨开层层的迷雾，需要测试人员充分的挖掘真实的信息，而这样的信息并不是所有人随时都愿意提供的。

对需求的怀疑和对发现的怀疑交织在一起，退缩就是一个看似明智的选择。然而，如果在一个地方退缩，就会在另一个地方重复，最终将削弱测试给软件带来的价值。

我们只有坚信一点：能够实现的需求就一定是可测的。

 

RBT测试方法是一件极为精准的武器，能不能获得收获，取决于我们内心的坚守和在恰当时机的致命击发。