本文章转载于搜狗测试
一位测试工程师在自己的经验、知识、思维的束缚下，总是存在一些设计屏障，致使用例缺失，从而可能导致一个隐藏的却很严重的线上事故发生，故多位测试工程师聚集在一起，进行一场用例评审显得尤为重要，小编对组内的用例评审流程规范和方法进行了如下总结，请大家参考。
用例评审时间
在项目测试阶段，有重要模块改动或者全新模块需求时，对相应的用例设计大纲要进行评审。
评审用例时间尽量选择在一轮测试之前，不应该晚于二轮测试。
用例评审内容
项目测试阶段，重要模块改动或者全新模块需求的用例需要评审。用例评审内容来源渠道：
1、项目负责人（即，负责项目质量、进度的测试人员）负责收集当前版本需要评审的用例，也要及时上报评审。（该渠道为评审用例的主要来源）
2、组内人员主动希望进行评审的用例也可以进行上报评审。
3、如果用例非常庞大且时间紧张的情况，用例评审人需要整理出重要的逻辑，从而在时间紧张的情况，可以让用例评审参与人集中评审重要逻辑部分。
用例评审准备
1、用例评审人要在评审前将需求、测试大纲准备好。
2、用例评审人需要在评审前将需求中，存在明显问题的内容进行确认。
3、用例评审人需要将测试大纲结构整理清楚，评审时不能存在严重的结构问题，以免影响到整体用例评审效率和进度。（如果用例评审人对自己的用例结构有所疑惑，应该找到项目负责人或者用例评审负责人进行初审）
用例评审会议邀请
1、用例评审负责人（大家可以选出一个专人，对用例评审进行组织负责，即为用例评审负责人）负责与各个平台项目组负责人协调具体会议时间，并且发送会议邀请。
2、会议邀请中，要包含需求、用例设计大纲。
用例评审会议流程
1、用例评审参与者尽量提前阅读了解需求。
2、用例评审人讲解需求。
3、用例评审参与人员对需求提出问题，用例评审人进行解答。
4、对于流程性较强的，用例评审人需要给大家梳理一次流程，最好有提前准备好的流程图。（不建议现场画制）
5、用例评审人讲解测试大纲，按照用例层次讲解；首先对自己的子功能、子子功能划分情况进行说明；之后到检查点；最后到影响因素。
6、在5的整个过程中，用例评审参与人员可以随时对评审人员的用例进行提问、给出建议等。
7、用例评审人要积极准备，用例评审参与人员要积极发言。
8、最后会议记录者要将会议记录及时发出，做好todo备忘。
9、本次会议完成。
用例评审会议内容
1、用例结构
前面已经提到少做用例结构的评审（是为了用更多的精力去扩大用例覆盖度），但是对于一些典型的功能模块，可以适当进行用例结构评审。例如一些流程较多，较复杂的，大家可以一起梳理一下流程，同时对用例结构完成检查评审。
2、代码层面
对于一些较为复杂的功能模块，有些甚至不涉及到界面，只是一些内部方法的逻辑处理（如果浏览器的热修复、云同步等功能），需要挖掘到类和方法层面，故用例评审人要了解代码实现，并进行讲解。
3、影响因素发散
对于使用场景较为复杂的功能模块，需要重点进行影响因素的评审，大家在了解需求和实现流程的基础上，一起进行影响因素的发散思考，将各种场景在用例设计阶段思考到位。
4、服务端用例设计
对于服务端的用例，要单独进行用例设计，与客户端分离评审。必要时，需要设计接口测试相关用例。
用例评审后期
1、用例评审人修改用例后，需要将大家的审核建议整理后，修改测试大纲，并且更新到SVN上。
2、用例评审人要将会议中的建立的todo完成，如与开发、产品沟通某些会上提到的细节问题、完善模块说明文档等。
