如何评审测试用例

导读

是否遇到过这样的问题：

1. 用例评审一直做，但没有多大效果？

2. 用例评审时按着用例一条条讲，讲到最后自己都不知道该说什么了，好像大家都挺懵逼的？

3. 用例评审开发人员不愿意参与？

4. 评审时，外部人员提了好多用例的问题，他们怎么做到的？

我们今天来聊一下评审用例的话题。

用 例 评 审 标 准 区分是测试组内的评审还是项目组内的评审。内部评审和外部评审在内容方面会有不同。

测 试 组 内 评 审 1、用例描述是否清晰：比如看到用例标题就能明白这条用例测试的是什么（而不是直到看到期望结果才明白这条用例的目的）， 执行步骤和期望输出是否有歧义。 2、操作步骤是否有可执行性：

• 其他人读完你的操作步骤，是否明白如何去操作；
• 一条用例多个测试点，这可能导致其他人执行你的用例时产生遗漏；
• 测试点是否有连贯性，是否贴近测试执行时的步骤。

3、是否考虑到测试用例的编写效率：即复用性要强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。否则写用例和执行时阅读用例都会花费很多时间。 4、是否考虑到了执行效率：用例怎么跟版本迭代结合？（我的期望是可以快速筛选出每次冒烟、系统测试、回归测试的用例，回归用例包括bug回归、功能新增回归、功能修改回归、 验收前整体回归）。 5、是否覆盖了所有的软件需求？测试人员对需求的理解是否透彻？期望结果是否与需求一致？ 6、异常测试点：可以从测试思维框架（群里有）和以前的bug中找找看。 7、其他，比如是否优先级安排是否合理；二次评审时是否修改/删除了之前说过的问题。

项 目 组 内 评 审 外部评审涉及协调外部资源，需要注意： 1、确定参会人：一般情况下我们会跟产品、开发一起评审，但并非所有情况下都是如此； 2、提前约时间：在外部的人看来，用例评审并不是本职工作，是给测试人员帮忙的，也有的会认为评审需求跟产品评审就好了。加上开发人员一般开发任务都紧张，所以测试人员要提前跟别人约时间。 3、确定评审内容：我一般在外部评审时只讨论测试范围和测试执行时可能有的风险。比如有的测试数据测试人员不能自己做，需要研发配合做程序改动。尽量避免在会议上讨论别人一句话或几句话就能说清楚的需求问题（显得不专业，浪费大家时间。这些内容应该在会前确认）。 4、评审形式：思维导图形式进行。使用思维导图的优点可以参考我这篇文章《思维导图整理测试点》

推荐阅读

如何使用思维导图整理测试点？