一、背景：这周的软件测试课堂上我们在自行分组的情况下，对姚同学的汽车停车位定位管理系统进行了Peer Review,中文就是同行测试。这也是我第一次接触同行测试，那接下来我先介绍一下Peer Review吧。
二、Peer Review的定义:是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。需要进行同行评审的特定产品在定义项目软件过程的时候被确定并且作为软件开发计划的
一部分被安排了进度。
三、Peer Review的人员分配：
在这其中需要用到评审小组，评审小组至少由3人组成（包括被审材料作者），一般为4至7人。通常，概要性的设计文档需要较多评审人员，涉及详细技术的评审只需要较少的评审人员。评审小组应包括下列角色：
- 评审员（Reviewer、Inspector）：评审小组中的每一成员，无论他（她）是否是主持人、作者、宣读员、记录员，都是评审员。他们的职责是在会前准备阶段和会上检查被审查材料，找出其中的缺陷。合适的评审员人选包括被审材料在生命周期中的前一阶段、本阶段和下一阶段的相关开发人员。例如，需求分析评审员可以包括客户和概要设计者，详细设计和代码的评审员可以包括概要设计者、相关模块开发人员、测试人员。
- 主持人（Moderator）：支持人的主要职责，在评审会前负责正规技术评审计划和会前准备的检查；在评审会中负责调动每一个评审员在评审会上的工作热情，把握评审会方向，保证评审会的工作效率；在评审会后负责对问题的分类及问题修改后的复核。
- 宣读员（Reader）
宣读员的任务是在评审会上通过朗读和分段来引导评审小组遍历被审材料。除了代码评审可以选择作者作为宣读员外，其他评审最好选择直接参与后续开发阶段的人员作为宣读员。
- 记录员（Recorder）
记录员负责将评审会上发现的软件问题记录在“技术评审问题记录表”。在评审会上提出的但尚未解决的任何问题以及前序工作产品的任何错误都应加以记录。
作者（Author）
被审材料的作者负责在评审会上回答评审员提出的问题，以避免明显的误解被当作问题。此外，作者须负责修正在评审会上发现的问题。
在我们的课堂测试中，我们小组六个人，评审员有两位，其它各一位。我担当的是作者的角色。
四、peer Review的目的：
- 尽可能早的发现并确定软件产品中的缺陷。
- 尽可能早的发现产品中应该改进和提高的部分，并及早实现。
- 项目成员通过同行评审，可以更好的理解软件产品，防止部分错误的发生。
五、peer Review的流程：
在网上找的两个流程图：
在这次的模拟同行测试里面我们针对姚同学的项目，评审提出了一系列的问题，而我作为作者对他们的问题进行解答或者给出改进方案，从而更新项目方案。最终总体来说还是对姚同学的项目有着一定的帮助的。
六、收获
这次的模拟同行评审给我带来的感触就是不同的视角会产生很棒的化学反应，往往你通过别人的视角可以看到自己项目的不足也可以在自己的项目里找到发光点从而对其进行改进、优化。这是对于整个团队都有很大推动力的活动。