作者：京东科技 刘刚
用例评审对于质量同学是再熟悉不过的一个重要环节，用例评审也是非常有效的保障测试质量的手段，但我们质量同学做了这么多次的评审，有没有去思考怎样去进一步提升用例评审的质量，使用例评审更加有效呢，这里呢抛砖引玉，总结一下我个人对用例评审的思考，希望能给大家带来一些启发。
对于用例评审，我们要首先要想清楚通过用例评审可以带来哪些价值和收益，而不只是停留在表面和流程上，要持续的去思考和提升用例评审效果，这样大家专门花时间进行用例评审才能更有意义，这里我提出四点价值：
共识需求
• 开发、测试、产品碰撞自己理解需求是否正确的过程，进一步排除分歧，达成共识。
• 帮助开发进一步理清需求，补充开发未考虑到的场景。
补全场景
• 帮助测试发现用例中存在的场景欠缺，避免需求遗漏，并补全测试场景。
• 引导产品进一步思考，补全考虑不周之处。
风险规避
• 对测试重点、风险点、测试范围团队共识
附加价值
• 引导团队质量意识提升
• 体现测试价值
在正式评审前，我们需要提前做些准备工作，这样才能有效保障我们的用例评审效果。
有质量
• 如果本次需求较为复杂或自信心不强，强烈建议在正式需求评审前进行一轮测试内部评审，使用例达到比较完备的条件。
划重点
• 适合评审会上共同讨论的需求中疑问点和优化建议，提前在用例中做好标记（注意大部分疑问点应线下提前沟通明确，避免会上过多讨论）
• 用例要有逻辑清晰的结构呈现，并且提前划分好用例优先级和评审重点。
降成本
• 用例较多时，将用例按前端用例、后端用例做好分类，以便用例评审时可分开review，节省时间。
• 建议提前一天，将用例提前发给相关人员查阅，并提前发出会邀，预约好时间。
• 评审前五分钟，提前去会议室准备好，并将相关用例、需求页面、开发设计页面、原型图打开。
为保障用例评审效果最大化，最迟应该在开发提测前进行评审，最佳评审时间为开发中后期，这时开发对需求已有较为全面理解，程序架构也基本成型，用例评审时开发可给出较多建议和补充。
不同角色的人员到场要求如下：
• 前后端开发（必须）
• 产品（必须）
• 设计（看情况）
• 其他（如：量化、运营同学）
怎样的用例评审才算好的评审，这里我提出三点，供大家参考：
共识需求
• 共识需求细节，排除疑惑，避免需求理解分歧
补全场景
• 业务/测试场景及技术方案考虑周全，能够给产品、研发较多有效输入
• 引导产品和研发思考，促其提出有效建议和补充
高效评审
• 能够提高用例评审效率和效果
这里绘制了一下用例评审的流程环节，清晰展示用例评审相关的各个节点和动作，共大家参考。
会前准备
• 用例设计，结构思路要清晰，表达要准确(尽量采用开发/标准的表述)，避免有歧义的语句
• 对有歧义的问题，最好是在评审前找对应的开发/产品确认下
会议阶段
• 评审会议时长最好控制在1H，若东西太多，可以分多次评审
• 评审时可视化结合，比如针对页面用例，可先打开对应的UI页面/原型/设计图
• 用例陈述时，要有主题和层级，若主题/层次切换，要有对应的过渡
• 评审过程中，参与人员会存在视觉和听觉疲劳，主讲人要抓住重点和重要人员，并做好引导和提醒
• 评审过程中的问题，要及时做好标记
会后阶段
• 用例评审后，需对用例评审中的问题，跟进/补充用例/告知大家已完善
• 用例修改后，需对用例进行管理更新
最后，补充一下，对于用例评审，我们质量同学要注意结合团队特点，做出相应的调整，没有固定不变的流程，只有不适合团队的流程。只要我们用心去做评审，用心思考过程中遇到的问题，真正的从整个团队维度去思考解决，并有持续改进的思想，相信我们质量工作会越做越好，在整个产研团队中也更有价值。