如何有效的进行用例评审

作者：京东科技 刘刚

用例评审对于质量同学是再熟悉不过的一个重要环节，用例评审也是非常有效的保障测试质量的手段，但我们质量同学做了这么多次的评审，有没有去思考怎样去进一步提升用例评审的质量，使用例评审更加有效呢，这里呢抛砖引玉，总结一下我个人对用例评审的思考，希望能给大家带来一些启发。

用例评审的意义

对于用例评审，我们要首先要想清楚通过用例评审可以带来哪些价值和收益，而不只是停留在表面和流程上，要持续的去思考和提升用例评审效果，这样大家专门花时间进行用例评审才能更有意义，这里我提出四点价值：

共识需求

• 开发、测试、产品碰撞自己理解需求是否正确的过程，进一步排除分歧，达成共识。

• 帮助开发进一步理清需求，补充开发未考虑到的场景。

补全场景

• 帮助测试发现用例中存在的场景欠缺，避免需求遗漏，并补全测试场景。

• 引导产品进一步思考，补全考虑不周之处。

风险规避

• 对测试重点、风险点、测试范围团队共识

附加价值

• 引导团队质量意识提升

• 体现测试价值

前置准备

在正式评审前，我们需要提前做些准备工作，这样才能有效保障我们的用例评审效果。

用例评审前的准备工作

有质量

• 如果本次需求较为复杂或自信心不强，强烈建议在正式需求评审前进行一轮测试内部评审，使用例达到比较完备的条件。

划重点

• 适合评审会上共同讨论的需求中疑问点和优化建议，提前在用例中做好标记（注意大部分疑问点应线下提前沟通明确，避免会上过多讨论）

• 用例要有逻辑清晰的结构呈现，并且提前划分好用例优先级和评审重点。

降成本

• 用例较多时，将用例按前端用例、后端用例做好分类，以便用例评审时可分开 review，节省时间。

• 建议提前一天，将用例提前发给相关人员查阅，并提前发出会邀，预约好时间。

• 评审前五分钟，提前去会议室准备好，并将相关用例、需求页面、开发设计页面、原型图打开。

用例评审时机要求

为保障用例评审效果最大化，最迟应该在开发提测前进行评审，最佳评审时间为开发中后期，这时开发对需求已有较为全面理解，程序架构也基本成型，用例评审时开发可给出较多建议和补充。

用例评审人员要求

不同角色的人员到场要求如下：

• 前后端开发（必须）

• 产品（必须）

• 设计（看情况）

• 其他（如：量化、运营同学）

评判标准

好的用例评审具备哪些特点

怎样的用例评审才算好的评审，这里我提出三点，供大家参考：

共识需求

• 共识需求细节，排除疑惑，避免需求理解分歧

补全场景

• 业务/测试场景及技术方案考虑周全，能够给产品、研发较多有效输入

• 引导产品和研发思考，促其提出有效建议和补充

高效评审

• 能够提高用例评审效率和效果

流程规范

用例评审流程

这里绘制了一下用例评审的流程环节，清晰展示用例评审相关的各个节点和动作，共大家参考。

用例评审补充建议

会前准备

• 用例设计，结构思路要清晰，表达要准确(尽量采用开发/标准的表述)，避免有歧义的语句

• 对有歧义的问题，最好是在评审前找对应的开发/产品确认下

会议阶段

• 评审会议时长最好控制在 1H，若东西太多，可以分多次评审

• 评审时可视化结合，比如针对页面用例，可先打开对应的 UI 页面/原型/设计图

• 用例陈述时，要有主题和层级，若主题/层次切换，要有对应的过渡

• 评审过程中，参与人员会存在视觉和听觉疲劳，主讲人要抓住重点和重要人员，并做好引导和提醒

• 评审过程中的问题，要及时做好标记

会后阶段

• 用例评审后，需对用例评审中的问题，跟进/补充用例/告知大家已完善

• 用例修改后，需对用例进行管理更新

最后，补充一下，对于用例评审，我们质量同学要注意结合团队特点，做出相应的调整，没有固定不变的流程，只有不适合团队的流程。只要我们用心去做评审，用心思考过程中遇到的问题，真正的从整个团队维度去思考解决，并有持续改进的思想，相信我们质量工作会越做越好，在整个产研团队中也更有价值。