测试用例评审

随着IT公司对软件质量的重视提升，软件测试设计用例的方法也变得多样化，而就需要对测试用例进行评审，考量其优劣。

是产品、开发和测试人员针对测试用例能否用于项目的测试而做的工作。

1.为了减少测试人员执行阶段做无效工作；（执行无效case，提交无效问题）

2.为了避免三方需求理解不一致；

3.为了每个测试人员的质量标准与项目要求标准达成一致。

（一）评审前需要做哪些准备工作

1、需求评审结束后，就可以着手把需求拆分为功能点。

2、把功能点再分解为具体的测试用例。

3、用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。

4、和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看。

（二）用例评审参加人员

主要是产品、开发（客户端和后端）、测试、项目负责人、运营。

注：以上人员为必须参加人员，其他和项目质量、进度有关人员，根据实际情况可邀请参加。

（三）用例评审时间

对于敏捷开发项目，建议控制在半小时以内。

如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标，不能流于形式。

（四）用例评审的形式

1、对照测试用例，从上而下，从左到右，逐条念。

这是目前很多公司的做法，如果你也这么做过，相信你并不一定喜欢这种方式，因为它费时，不分主次，参会人员的热情与注意力逐渐降低，整个用例评审效率低，作为主持人也讲的口干舌燥，事倍功半。

2、先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。

对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。

这种做法，有很多优点，评审刚开始的一段时间，大家注意力集中，参与激情高，这段时间讨论有难度有疑问的问题，效率高。最重要的事最先做。

另外，整个评审会主次分明，有高潮有缓点，可以更高效的达到我们评审的目的。

（五）正式评审

正式评审过程中需要注意几个细节，如果你都做到了，那么可以说整个评审是成功的，有价值的。

1、评审要按用例的优先级，功能的复杂程度进行；

2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；

3、超过5分钟无法确定结果的问题留作会后讨论跟进。

（六）评审结束后需要做些什么事

不是说评审会结束了，就完事了，其实对于整个用例评审，这才做了一半。评审结束后，第一时间整理测试用例，把修正的内容重新整理补全。会上未确定的内容，会后继续跟进，直到确定结果。

没有任何有疑问的地方了，再做个简单的用例评审会议总结（如修正了哪些功能点，补全了哪些？哪些模块功能有变动？哪些功能推迟到下一期做？等）这个总结是给自己整个用例评审工作总结，同时需同步给项目组其他成员，做好信息共享，这点很重要。

补充：一般情况下是在用例的初步设计完成之后进行评审，如果需要或时间允许，在整个详细用例全部完成之后还会进行二次评审，三次评审等。

　大体分文三个级别的评审：

　　a）部门评审，测试部门全体员工参与的评审。

　　b）公司评审，这里包括了项目经理，需求分析人员，架构设计人员，开发人员和测试人员。

　　c）客户评审，包括了客户方的开发人员和测试人员。

进阶三 | 测试基础知识之测试用例评审