评审介绍

评审类型：管理评审，正式同行评审，非正式同行评审及走查四种
评审结论：评审通过、需要修改通过、评审不通过。
评审的标准：（1）存在的紧急缺陷时，评审不通过，需要重新评审。（2）无紧急缺陷，存在一般缺陷数量大于10个，评审不通过，需要重新评审。(3）无紧急缺陷，存在一般缺陷数量小于10个，需要修改后，并得到各评审确认后，评审通过。(4）无缺陷，不需要修改评审通过。评审的严重程度分为：紧急，严重，一般，建议。
1:评审的过程 A:开始前做好如下准备 1、确定需要评审的原因 2、确定进行评审的时机 3、确定参与评审人员 4、明确评审的内容 5、确定评审结束标准 6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。 7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。 8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。 B：开始评审 1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。 2、 通用邮件与相关人员沟通 3、 通用IM工具直接与相关人员交流 4、根据评审内容进行评审 2：评审内容 1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。 2、 优先极4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。 5、 是否已经删除了冗余的用例。 6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。 7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。 8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。 3：参与评审人员（这里会分为多个级别进行评审） 1、 部门评审，测试部门全体成员参与的评审。 2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。 3、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
管理类评审主要有项目计划（集成项目中了测试计划，配置计划，质量保证计划，评审计划，培训计划，度量计划）、软件需求说明书、里程碑评审等。同行评审：概要设计说明书、详细设计说明书，单元测试用例、集成测试用例、系统测试用例的评审。
评审目的是尽早地发现工作成果中的缺陷，并及时消除缺陷，从而有效地提高产品的质量。
同行评审流程：作者提出评审申请，由项目经理确定评审的参加人员，提前发通知（通知内容：评审时间，评审的工件地址、评审检查表等）给评审参加人员。召开评审会议，指定会议记录人员，会议一般由项目经理主持，作者讲解待评审的内容；在评审过程中，作者需要回答评审人员的提问。评审的结果记录在《评审记录》中。问题由相关人员进行修改，修改完后，由评审人员进行验证，项目经理、QA跟踪直到关闭。项目经理汇总《评审记录》的缺陷，编写《评审统计表》对缺陷进行汇总及分析。 同行评审产生的工作成果：《评审计划》、《评审记录》、《评审统计表》，放入配置库的管理库中。