用例评审的正确姿势，2个要点不容忽视

，点击蓝字👆 关注Agilean，获取一手干货

导语

用例评审的作用已经不言而喻，但是在很多组织的实际落地过程中，却收效甚微。研发管理人员常常会发现即使做了用例评审，一些显而易见的问题还是会出现：缺陷逃逸、开发未适配、测试漏测等。

为什么会这样呢？问题大概率出在了用例评审过程中。

笔者在经历过众多用例评审实践后，发现实际评审中常常遭到忽视的两个要素。基于此，尝试以新的视角，为读者们提供用例评审的优化新思路。

在软件研发过程中，用例评审是一个常见的实践活动，实践的形式也多种多样，比如：

• 同行评审：测试内部的同行评审，由更熟悉资深的测试人员评审新手测试人员；

• 管理者评审：只有开发对测试用例进行的评审，由开发小队长评审小队内测试人员的测试用例是否符合标准；

• 业务评审：只有产品经理对测试用例进行的评审，目的是评审用例是否覆盖了需求所描述的所有业务功能；

   ......

出于不同的目的而进行的不同的评审方式各有其适用场景。

本文讲述的用例评审是指：由测试人员主导开展，开发人员、产品经理共同参与的用例评审会议。其他形式的用例评审不在本文讨论范围内。

这种形式的用例评审，主要是为了帮助产品经理、开发、测试三方对齐需求，达成的一致理解。从而消减缺陷在测试环节缺陷逃逸的隐患，避免测试的遗漏、返工与产能浪费。最终达到保障产品质量、提升研发交付效率的目标。

你还在这样做用例评审吗？

以下是一个常见的用例评审过程：

迭代开始的第四天，测试负责人人员小张提前会议邀约测试、产品、开发人员进行用例评审会议。

会议期间，小张熟练的打开脑图，对着自己负责的用户故事，逐字念着用例描述。在念完一个故事的用例中途，询问开发、