多角色测试用例评审指的是敏捷开发中的多个角色在一起评审测试用例，这里的角色包括但不限于产品经理、交互设计师、开发人员、测试人员、质量分析人员等。
在实践的过程中总结了一些推荐的做法
一、前期准备
为了保证评审的高效进行，在进行多角色用例评审前，不同角色需要做好相关准备工作
测试人员
- 业务分析罗列功能点，和开发对接
- 参与业务、架构、方案评审，提出疑问点
- 尽可能多覆盖功能点用例，再和开发确认用例疑问点
- 发出用例给到多角色提前阅读，组织用例评审会议
- 修改评审建议，改动多，和开发二次评审
开发人员
- 完成业务分析和架构设计
- 构思实现细节，越细越好
- 对于出问题可能性较高的功能模块做到心中有数
- 提前阅读测试用例，为评审做好准备
产品经理
- 首次参与需先与测试沟通，了解会议目的和过往流程
- 提前阅读测试用例，为评审做好准备
- 对评审需求了解度要足够高
- 重点把控主流程，分支流程可以为“开发”和“测试”作补充。
二、用面对面替代文档传阅
之前有尝试过文档传阅的方式进行多角色测试用例评审，大概方式就是：测试人员写好用例后，发给不同的角色评审，并把相关评审意见记录到一个地方。这种方式无法形成思维碰撞，也难以管控评审执行过程，往往还要多次跟进督促才能保证每个角色都完成了评审。
面对面的方式是把相关人员拉到一个会议室（大平板前），测试人员对着用例挨个做简单解释，与会人员从自己的角度提出用例上的补充，这个过程中每个角色都需要带动起来，所以对会议的主持者（一般是测试人员）有一定的要求， 要保证与会人员的参与度，同时避免讨论偏离了方向 。在参与的角色中，开发人员是尤其重要的，开发人员需要从白盒的角度分析用例的完整性，对于各种不同的情况和边界问题，要勇敢的提出来。在这个过程中，往往还能发现一些产品定义和交互设计上的问题，或者彼此之前未能保持一致理解的问题。
三、更加合理的人数（4~6人）
4~6人是推荐的面对面评审人数。
人数过少，难以包括相关方（开发、测试、产品、交互等）；
人数过多，难以保证每个与会人员都高效参与。
实践效果
以下是做了一次实践后各角色的感受：
开发：
白盒测试：
更关注内部实现逻辑
- 优势：
- 对单个函数内部或功能实现测试更加精准化
- 对测试来说，若前期有足够详细的用例积累，后续进行测试的时候，能节省更多的人力和时间成本去测试改动的影响范围，而将测试集中到表现层即可
- 在设计白盒测试用例的时候，可以更加清晰的定义产品的功能点，做到功能的完备
- 不足：
- 需要划分具体的功能点或业务场景
- 需要了解底层的实现原理
- 需要逐步积累测试用例，以达到逐步全覆盖
- 总结：
前期投入成本高，后期测试成本低。在项目中，建议推行这种方式，节约后续的测试成本和保证程序运行的稳定性！
测试：
- 提高了用例覆盖度，能帮助提升测试思维
- 偏底层，而非仅是UI层，能帮助测试更好的了解业务和成长
- 和以往UI自动化对比，只需前期投入高，后期维护低，使用率高
产品：
-优势：
- 加大了对复杂业务的了解程度
- 锻炼对分支场景的敏感度
- 加大对开发实现方式的了解程度
-建议：
- 文字描述较为干扁，经验不足的需求方可能很难有代入感 。建议复杂描述，直接电脑实操示例。
- 需求方可以分需求复杂程度、优先级程度选择性参与，而不是所有需求都参与。
