测试用例评审总结与规范

什么是用例评审？后端

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

·用例评审的目的工具

为了减小测试人员执行阶段作无效工做；（执行无效case，提交无效问题）
为了不三方需求理解不一致；
为了每一个测试人员的质量标准与项目要求标准达成一致。

测试用例评审加入测试流程规范并试用2个多月了，期间根据各方人员的反馈，及为了提升用例评审的效率，特制定如下用例评审规范：测试

1、评审前须要作哪些准备工做设计

一、需求评审结束后，就能够着手把需求拆分为功能点。开发

工具：建议用XMind，需包含预期结果和测试结果，Android和iOS测试结果可用标签区分标注。优势：用画思惟导图的方式，逻辑清楚，便于评审人员（产品和开发人员）快速查看，评审效率高。同步

这里须要说明的是，不少测试者喜欢用Excel设计用例，我也不例外，可是根据一段时间的试验，和开发产品沟通后，你们都以为用XMind写思惟导图的方式更好，看起来更便捷。因此具体用什么工具方法，你们可依我的爱好而定，不过目标是同样的，让用例评审高效快捷的开展，并产生价值。产品

二、把功能点再分解为具体的测试用例。思维导图

这里需在思惟导图上补全预期结果和实际测试结果，便于测试结果跟进。class

三、用例写完后，本身先作好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，肯定结果后完善用例，仍有疑问的可先作标记，评审会上抛出一块儿讨论。效率

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

2、用例评审参加人员

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

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

3、用例评审时间

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

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

4、用例评审的形式

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

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

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

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

这种作法，有不少优势，评审刚开始的一段时间，你们注意力集中，参与激情高，这段时间讨论有难度有疑问的问题，效率高。最重要的事最早作。

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

5、正式评审

正式评审过程当中须要注意几个细节，若是你都作到了，那么能够说整个评审是成功的，有价值的。

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

二、评审过程当中尽可能作到，思路清晰，用最简洁的语言阐述每个功能点；

三、超过5分钟没法肯定结果的问题留做会后讨论跟进。

6、评审结束后须要作些什么事？

不是说评审会结束了，就完事了，其实对于整个用例评审，这才作了一半。

评审结束后，第一时间整理测试用例，把修正的内容从新整理补全。

会上未肯定的内容，会后继续跟进，直到肯定结果。

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

好了，整个完整的用例评审及须要注意的地方大概就是这些，但愿测试组人员认真去看，并落实到具体的工做中。个别地方根据项目实际状况可灵活变更，最后，有问题欢迎随时交流沟通。