1:评审的过程
A:开始前做好如下准备
1、确定需要评审的原因
2、确定进行评审的时机
3、确定参与评审人员
4、明确评审的内容
5、确定评审结束标准
6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
B：开始评审
1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2、 通用邮件与相关人员沟通
3、 通用IM工具直接与相关人员交流
4、根据评审内容进行评审
A:开始前做好如下准备
1、确定需要评审的原因
2、确定进行评审的时机
3、确定参与评审人员
4、明确评审的内容
5、确定评审结束标准
6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
B：开始评审
1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2、 通用邮件与相关人员沟通
3、 通用IM工具直接与相关人员交流
4、根据评审内容进行评审
2：评审内容
1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2、 优先极安排是否合理。
3、 是否覆盖测试需求上的所有功能点。
4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5、 是否已经删除了冗余的用例。
6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2、 优先极安排是否合理。
3、 是否覆盖测试需求上的所有功能点。
4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5、 是否已经删除了冗余的用例。
6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
3：参与评审人员（这里会分为多个级别进行评审）
1、 部门评审，测试部门全体成员参与的评审。
2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
1、 部门评审，测试部门全体成员参与的评审。
2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
