共计 1536 个字符，预计需要花费 4 分钟才能阅读完成。
作者：京东科技 刘刚
用例评审对于品质同学是再相熟不过的一个重要环节，用例评审也是十分无效的保障测试品质的伎俩，但咱们品质同学做了这么屡次的评审，有没有去思考怎么去进一步晋升用例评审的品质，应用例评审更加无效呢，这里呢抛砖引玉，总结一下我集体对用例评审的思考，心愿能给大家带来一些启发。
用例评审的意义
对于用例评审，咱们要首先要想分明通过用例评审能够带来哪些价值和收益，而不只是停留在外表和流程上，要继续的去思考和晋升用例评审成果，这样大家专门花工夫进行用例评审能力更有意义，这里我提出四点价值：
共识需要
• 开发、测试、产品碰撞本人了解需要是否正确的过程，进一步排除一致，达成共识。
• 帮忙开发进一步理清需要，补充开发未思考到的场景。
补全场景
• 帮忙测试发现用例中存在的场景欠缺，防止需要脱漏，并补全测试场景。
• 疏导产品进一步思考，补全考虑不周之处。
危险躲避
• 对测试重点、危险点、测试范畴团队共识
附加价值
• 疏导团队品质意识晋升
• 体现测试价值
前置筹备
在正式评审前，咱们须要提前做些筹备工作，这样能力无效保障咱们的用例评审成果。
用例评审前的筹备工作
有品质
• 如果本次需要较为简单或自信心不强，强烈建议在正式需要评审前进行一轮测试外部评审，应用例达到比拟齐备的条件。
划重点
• 适宜评审会上独特探讨的需要中疑难点和优化倡议，提前在用例中做好标记（留神大部分疑难点应线下提前沟通明确，防止会上过多探讨）
• 用例要有逻辑清晰的构造出现，并且提前划分好用例优先级和评审重点。
降老本
• 用例较多时，将用例按前端用例、后端用例做好分类，以便用例评审时可离开 review，节省时间。
• 倡议提前一天，将用例提前发给相干人员查阅，并提前收回会邀，预约好工夫。
• 评审前五分钟，提前去会议室筹备好，并将相干用例、需要页面、开发设计页面、原型图关上。
用例评审机会要求
为保障用例评审成果最大化，最迟应该在开发提测前进行评审，最佳评审工夫为开发中后期，这时开发对需要已有较为全面了解，程序架构也根本成型，用例评审时开发可给出较多倡议和补充。
用例评审人员要求
不同角色的人员到场要求如下：
• 前后端开发（必须）
• 产品（必须）
• 设计（看状况）
• 其余（如：量化、经营同学）
评判规范
好的用例评审具备哪些特点
怎么的用例评审才算好的评审，这里我提出三点，供大家参考：
共识需要
• 共识需要细节，排除纳闷，防止需要了解一致
补全场景
• 业务 / 测试场景及技术计划思考周全，可能给产品、研发较多无效输出
• 疏导产品和研发思考，促其提出无效倡议和补充
高效评审
• 可能进步用例评审效率和成果
流程标准
用例评审流程
这里绘制了一下用例评审的流程环节，清晰展现用例评审相干的各个节点和动作，共大家参考。
用例评审补充倡议
会前筹备
• 用例设计，构造思路要清晰，表白要精确 (尽量采纳开发 / 规范的表述)，防止有歧义的语句
• 对有歧义的问题，最好是在评审前找对应的开发 / 产品确认下
会议阶段
• 评审会议时长最好管制在 1H，若货色太多，能够分屡次评审
• 评审时可视化联合，比方针对页面用例，可先关上对应的 UI 页面 / 原型 / 设计图
• 用例陈说时，要有主题和层级，若主题 / 档次切换，要有对应的过渡
• 评审过程中，参加人员会存在视觉和听觉疲劳，主讲人要抓住重点和重要人员，并做好疏导和揭示
• 评审过程中的问题，要及时做好标记
会后阶段
• 用例评审后，需对用例评审中的问题，跟进 / 补充用例 / 告知大家已欠缺
• 用例批改后，需对用例进行治理更新
最初，补充一下，对于用例评审，咱们品质同学要留神联合团队特点，做出相应的调整，没有固定不变的流程，只有不适宜团队的流程。只有咱们用心去做评审，用心思考过程中遇到的问题，真正的从整个团队维度去思考解决，并有继续改良的思维，置信咱们品质工作会越做越好，在整个产研团队中也更有价值。
