● 目的：保证需求质量
● 手段：针对需求开展测试设计
● 测试设计面临的挑战：
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、需测试哪些功能块
● RBT过程12步骤（12步记录不全）
1、分析为什么要做这个需求？（如同敏捷测试中要求一样，即：需求来自于哪里？用户是什么样的群体？基于什么原因提出这样的需求？要解决什么样的问题？有无其它可替代方案来解决？是否一定要做这样的需求？
2、用场景分析方法来分析需求的应用情况
3、进行模糊度分析，即：识别不清晰、不完整、疑惑点的地方（此点更期望是不了解需求的人来做，而非专家）
4、领域专家进行更深层次的审视
5、针对需求建模，理出所有业务逻辑，采用因果图方法
6、用工具检查逻辑不一致问题，可能是需求本身的问题，也可能是建模的问题
7、工具自动生成用例（此处的用例可以理解为是测试验证点，而非具体的测试数据）
8、确认生成的用例是否正确（此处有一个个人问题：既然自动生成的用例已经是很精简了，再进行评审怎么保证评审出的问题是否需要补充到用例的？=>答案：评审的目的一是确认是否正确理解了规则与需求，二是通过评审问题反向识别出需求遗漏的场景（如果可能，要求客户对需求进行review是最合适的）
9、设计编码阶段，用生成的用例进行验证
● RBT工具用途（记录了一些，不全）
1、自动生成测试用例
2、自动生成两张表单：因与果清单、规则VS用例覆盖率的对照表（“X”表示多个用例覆盖此规则，“#”表示1个用例覆盖此规则）
3、生成测试统计数据
4、自动反向生成较规范的需求文档，适用场景：a、review需求时发现的问题确认后，不会更新需求，通过自动生成更新得到全集；b、敏捷项目中适用，项目结束后形成需求与用例的匹配
5、生成用例过程中自动进行功能逻辑一致性校验，并给出提示，如同开发程序编译时的错误提示
6、维护过程会考虑对原有用例的最大程度复用
7、告诉你可优先执行哪些用例
8、支持快速设计（推荐在配置测试中使用，如移动领域测试环境支持验证，可生成基础用例）
9、可定义节点间的状态、约束，以便生成的用例是可执行或真实的组合，对于不可执行的用例前面会有“I”标识，点击后会显示原因