1.用例评审的目的

　　·为了减少测试人员执行阶段做无效工作，执行无效case，提交无效缺陷（可以友情提醒研发同学，讲到自己负责的相关模块时，注意下是否存在异议点）

　　· 为了避免三方（产品、研发、测试）需求理解不一致；

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

　　2.评审前的准备工作

　　2.1用例编写

　　需求评审结束后，可以把需求拆分为功能点

　　测试点梳理时，要关注横向逻辑，即功能点本身，更要关注纵向逻辑，即业务流。

　　工具：建议用XMind

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

　　具体用什么工具方法，大家可依个人喜好和项目需要而定，不过目标都是让用例评审高效快捷的开展，并产生价值。

　　把功能点分解为具体的测试用例

　　需在思维导图上补全明确的操作步骤、预期结果；执行阶段可以追加实际测试结果，便于测试结果跟进。

　　用XMind写思维导图的方式设计用例更便捷，思维导图层级可以按照用例模板进行定义，方便用例评审结束后导出excel备份。

　　用例自检

　　整体把控用例组成，让评审讲解更清晰、有序

　　针对有疑问的点罗列出来，可事先跟产品、开发讨论，确定结果后完善用例

　　讨论后仍有疑问的可先做标记，评审会上抛出一起讨论。

　　标注重点：【未在需求文档中明确描述&在设计测试用例过程中已同产品确认】，需要在用例评审中着重提醒开发，保持信息同步。

　　·需求疑问：在经过产品确认后，输出具体测试用例，记得同步给研发

　　· 设计交互：未提供交互，需求文档未描述的功能的实际交互细节，提出讨论

　　提前发出用例

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

　　2.2用例评审通知

　　用例评审参加人员

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

　　约定用例评审时间、评审方式

　　评审时间：根据实际情况提前约定

　　评审方式：会议（具体的会议室或线上会议）、邮件等

　　评审时长

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

　　如果项目需求复杂，功能点太多，建议：

　　· 对功能点划分优先级，优先评审优先级高的用例

　　·再针对疑问多的用例评审

　　· 最后对于功能简单的用例可简单带过。

　　3.正式评审

　　3.1评审形式

　　3.1.1逐条评审

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

　　传统评审方式的特点：

　　·费时，不分主次，参会人员的热情与注意力逐渐降低

　　· 整个用例评审效率低，往往讲的口干舌燥，达到的效果却是事倍功半。

　　相信有过这种评审经历的同学，一定不喜欢这种方式，因为它流于形式，整个评审过程随着时间的推移，大家互动热情逐渐降低，往往效果不及预期。

　　现状是业务流程较为繁长的测试用例条数较多，少则上百，多则上千，逐一讲解，不论是对开发或产品，甚至测试本身，都会出现前后文衔接不上。本着最重要的事最先做的原则，我们对用例评审形式作出如下改进：

　　3.1.2逻辑概述+核心评审

　　“全局流程+局部细节”的方式评审测试用例，先对核心流程、功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。

　　全局流程-逻辑概述

　　借助“Xmind”思维导图，进行简要的逻辑概述，阐述用例描述的基础流程。该阶段描述后，经产品和开发确认无疑问，则进行用例评审时，可略过该部分的基础测试用例。

　　比如，某某系统要实现什么功能，具体包含模块1、模块2、模块...，涉及的业务流程和数据交互有1...2...3...，是用例的评审重点，等下我们优先评审。同时我在用例设计时主要包括了哪些场景，具体有页面展示的校验、功能按钮实现的校验、页面元素必填项校验、字符类型校验、字符长度校验、异常场景校验等。（具体的页面元素、字符类型、字符长度、异常场景可以粗略带过）

　　局部细节-突出核心细节用例

　　除了基础业务流程外的，一些特殊场景细节的测试用例，可能影响业务流程或对公司造成损失，使用加粗/颜色标注，在用例评审时着重提醒开发。

　　比如某系统的内容引用功能，被引用内容下线，对内容会产生不良的影响，这种容错性的处理逻辑的校验。

　　改进后的评审方式特点：

　　·测试人员要全局了解项目目标、业务流程（想得明白才能讲得明白，可以促进测试同学多多思考）

　　· 评审刚开始时，大家注意力集中，参与激情高，讨论有难度、有疑问的问题，效率高。

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

　　3.2评审原则

　　评审要按用例的优先级，核心业务流优先、再按功能的复杂程度进行；

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

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

　　（正式评审过程中需要注意几个细节，如果你都做到了，相信整个评审会是非常成功的，有成就感的。）

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

　　总结用例评审会议纪要，包含需要作出的修改点、未确认的项和对应责任人、是否有需求变更或延期情况等。

　　·用例评审会议纪要需同步给项目组其他成员，做好信息共享。

　　整理补充测试用例，把修正的内容重新整理补全。

　　· 编写用例修改记录（如修正了哪些功能点，补全了哪些？等），修改后的用例重新发出供大家评审。

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

作者：laofashi2015    

来源：http://www.51testing.com/html/28/n-7798028.html