● 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”标识，点击后会显示原因