测试用例评审

测试用例评审总结

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

1.评审目的

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

2.评审内容

1.用例设计结构是否清晰、合理，对需求进行高效覆盖；

2.用例优先级安排是否合理；

3.是否覆盖测试需求上的所有功能点；

4.用例是否具有很好可执行性；

例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确，期待结果是否有明显的验证方法。

5.确认没有冗余的用例；

6.是否包含充分的负面测试用例；

充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。

7.是否从用户层面来设计用户使用场景和使用流程的测试用例；

8.是否简洁，复用性强；

例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

3.评审前准备工作

1、需求评审结束后将需求拆分为功能点。

工具：可用思维导图工具：XMind，freemind等，需包含预期结果和测试结果，针对不同系统如Android/IOS测试结果可用标签区分标注。

优点：用画思维导图的方式，逻辑清楚，便于评审人员（产品和开发人员）快速查看，评审效率高。

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

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

3、用例写完后，先做好自检。

（1）罗列疑问点与产品开发讨论确认；

（2）无法确认先标记，评审会上抛出一起讨论；

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

4.评审会议预约

1.时间地点人员

评审时间约30min

2.本次评审文件

（1）测试用例

（2）评审需确认项目重点罗列

（3）会议确认后在评审结果中反馈

5.正式评审

1.项目业务流程简介；

2.确认疑问；

3.重要功能-基础功能；

4.按业务流程进行；

业务流程性较强的需求，需要有业务场景和逻辑，按一定的顺序来。

5.按测试数据进行；

涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据也是按不同的业务场景来设计的，但直接用测试数据来评审你的测试点，会更清晰，跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方，从而有效的评审测试用例。

6.评审无法快速给出结论先记录，会后跟进；

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

6.评审结束后需要做些什么事？

1.会上确认内容进行重新整理补全；

2.会上未确认内容，会后跟进确认；

3.用例评审会议总结；

如修正了哪些功能点？

补全了哪些？

哪些模块功能有变动？

哪些功能推迟到下一期做？等

4.评审总结同步给项目组其他成员；

7.用例评审需要避免

1.测试点含糊用语；

每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该确认下来，不能含糊不清。

2.有顺序有逻辑的进行评审是很重要的一点；

　　测试组内部的评审着重于：

　　（1）测试用例本身的描述是否清晰，是否存在二义性；

　　（2）是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

　　（3）是否针对需求变更进行跟着，覆盖了所有的软件需求；　　

　　（4）是否尽可能多的覆盖了异常流程和异常测试点。

 

参考文献：http://www.51testing.com/html/85/n-3721585.html