● 目的：保证需求质量

　　● 手段：针对需求开展测试设计

　　● 测试设计面临的挑战：

　　1、测试准则不确定（测试是比较预期结果与实际结果的过程，预期结果最了解的人群是开发、需求人员还是客户？答案未知，但是如果需求的质量更高些的话，会更利于更准确的知道预期结果）

　　2、测试无穷尽：要用少的用例覆盖尽可能多的需求，如何挑选合适的用例显得尤其重要

　　3、用例执行pass是否真正代表对应场景或功能就pass =>缺陷隐藏效应证明不一定，那么在挑选用例时如何做到，RBT会有所考虑

　　RBT是如何实现上面所提挑战的？

　　● 为什么要基于需求来开展测试？

　　1、导致软件失败的原因如下：

　　a）需求不完整

　　b）需求多变

　　c）需求缺少来自用户的实际输入

　　从而导致仅有60%~70%的需求交付量，且此其中50%左右的需求未被使用过，而开发团队针对这些未使用过的需求，投入了大量精力，存在一定程度的浪费。

　　2、BUG分析缺陷来自哪个阶段？=>60%来源于需求阶段（怎么有效区分BUG是哪个阶段？）

　　● RBT解决的是偏重型的测试问题（考虑项目的可适用性），是针对每条需求进行分析设计

　　● RBT倡导的思维是先测试，再构建

　　● RBT过程两大步：需求模糊度分析、因果图方法进行测试设计

　　1、需求模糊度分析

　　实际是分析需求是可测试的、可观察可触发的、结果是确定的（结果是确定的指：给定输入后，能准确得出其唯一的结果，对于输入A，结果为C，再次输入A，结果为B的情况则是不符合“结果是确定的”原则。当出现这种情况，则需求是肯定有问题的）

　　2、因果图方法进行测试设计，以下是几类设计方法的对比分析

　　a）根据用户实际使用场景、环境参数来设计用例的情况：30%左右的覆盖不乐观，且异常考虑不充分，依赖时间的场景无法覆盖

　　b）依据直觉进行设计的情况：依赖测试者经验，覆盖不确定，只能代表执行过的是OK，不能证明其完整覆盖度

　　c）组合测试设计的情况：所有场景组合全部覆盖，量太大

　　d）因果图方法设计的情况：借鉴了硬件领域的一些工程算法，覆盖率高

　　● RBT方法选择用例的标准：

　　1、体现变量间的各种逻辑关系

　　2、体现每个变量各种状态间的约束

　　3、考虑各节点的可观察性，如下面的例子

　　例子：

　　A、B、D、E全为T，C、F、G均为True，假定当A恒为False的缺陷存在时，直接通过对G的观察是无法发现此缺陷的，因为C、F是不可观察的

　　4、需测试哪些功能块