IBM公司报道，进行1个小时的评审可节约20小时的测试，如果在发布的产品中遗留了审查所发现的缺陷，则所需的返工时间为82小时。
贝尔北方研究中心审查了250万行实时系统的程序代码，避免了平均每个缺陷33小时的维护费用。通过审查发现缺陷的效率是测试的2-4倍。
——Karl E. Wiegers, Peer Review in Software
什么是同行评审
根据CMMI定义，同行评审：“在工作产品开发期间由同级人员执行的工作产品评审，来识别缺陷以便移除”。
为什么要进行同行评审
同行评审是为了及早和高效地从软件工作产品中识别并消除缺陷，让软件变得更易读和维护，同时减少最终逃逸到产品发布后的缺陷。
有些工作产品在早期阶段可以通过同行评审去发现缺陷，但无法对其进行测试；即使到了编码阶段，测试活动也不能发现特定类型的缺陷（例如违反编程规范）。
图1 开发各阶段缺陷放大图
如图1可以看出，随着开发的不断开展，缺陷不断泄露和放大，最终形成的产品是灰色的、距离用户真正需求很远的一个“东西”。
同行评审的准备、活动和跟踪需要花费一定的时间和工作量，但这些可以在测试中节省更多。从经济学角度考虑，许多缺陷是在早期阶段注入的，越早消除缺陷就越能降低开发成本。所以，发现缺陷的手段需要引入同行评审而不能完全依赖测试。
同行评审的分类
根据CMMI模型，同行评审可分为3类
（1）正式评审（Inspection），通常是由经过同行评审培训的项目经理或QA主持，规模在3～7人之间为宜，一般在完成了一个工作产品后对其进行的评审。正式评审的目的在于定位并除去工作产品中的缺陷。
（2）技术审查（Technical Reviews），或称内部评审，通常由技术负责人或项目经理召集，三人以上参加。技术审查一般是在工作产品的中期进行或完成了某部分独立的工作产品时进行，也可在书写草案遇到问题时就其中专门的一两项问题讨论和审查。也可以是检查工作产品与规程、模板、计划、标准的符合性或者变更是否被正确地执行。技术审查的目的在于通过对开发人员的工作产品的技术审查，提出改进意见。
（3）走查（Walkthrough），又叫代码走查或代码走读，审查的范围根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。通常是小型讨论会，一般是在工作产品形成的早期进行，作者有一定的想法时，希望从中获得一些帮助或补充一些想法。当然也可以在编制工作产品的任何阶段进行，两三个人参加，由作者主持，主要是评估和提高工作产品的质量或教育参加者。
其中，"正式评审"是正式的，"技术审查"和"走查"是常用的非正式同行评审方法。
同行评审的过程
根据同行评审的重要程度，正式评审、技术审查和走查三种形式的流程和成果物的使用力度不尽相同，但其主要的步骤和内容大体一致，参见图2所示。
图2 同行评审的流程
工作产品的同行评审方式
对开发过程中产生的工作产品采用的同行评审方式，可参考表1。
表1 同行评审的策略
特别说明：最近，我们推出了项目问题通报批评八条警戒线。其中，对于需求分析报告，因为它的不确定性和不完善会给软件的后期开发带来极大的风险，所以必须采用同行评审。对于代码产出，代码的可读性、可重用性、可理解性，是软件内在质量的重要特性，所以也必须使用同行评审。
参考文献：
[1] 于波 姜艳 软件质量管理实践 电子工业出版社
[2] 仁甲林 术以载道-软件过程改进实践指南 人民邮电出版社
[3] 朱少民 软件质量保证和管理 清华大学出版社
[4] CMMI-DEV, V1.3
[5] Karl E. Wiegers, Peer Review in Software
大家说
交易所事业部/王俊永
同行评审是保证质量的一项重要措施。在工作中，实际实施的有三种：代码走查、代码集中评审、文档评审。这里重点对前两种进行说明。
代码走查：
代码走查我觉得应该尽量频繁，及时一些。这是一个集体智慧设计的过程。所以，一般来讲，走查的代码应该是一天内开发的，而且不超过千行。但是在代码走查前，开发人员要做到自查：1.编码规范问题， 2.注释充分性问题。这些都是应该自我要求、自我约束的。其他人对开发人员代码的走查，更多应该关注于逻辑、设计方面。在代码走查后，把合格的代码及时提交到开发库中，保证代码的安全性。
代码集中评审：
该过程是在一个模块或者一个迭代开发完成后进行的。这个我觉得是一个发现缺陷比较有效的过程，是代码走向集成和系统测试的最后一道关卡。在我负责的项目组内，我一直在不断强调和推行该过程。首先，开发人员对代码的整体讲解是一个自我反思的过程，如果讲解不清楚，应该是没有想清楚，而没有想清楚的话，问题很可能就藏在里边；其次，参与评审人员跟随开发人员逻辑去理解，会从自己习惯的角度去分析和思考，能够很好的补充开发人员思考的不足；再次，代码集中评审是一个相互学习，相互提高的过程。
综上，我觉得通过同行评审的手段，在开发过程中保证质量是能够节省精力和成本的。毕竟，“质量是免费的”，保证质量措施的回报是值得为其付出努力和成本的。
金融产品开发部/郭晓刚
一个人不管能力多强，看问题的角度总会受到限制，写出来的程序或文档也一定不是十全十美的。如果能让懂行的同事审阅一下，那么势必会减少软件产品中的缺陷，取得个人难以达到的效果。因此，同行评审流程对于广大的软件工程师来说，是十分重要的，也是不可或缺的。
同行评审并不是对个人的工作不信任，其目的是尽早有效地消除软件工作产品中的缺陷。同时，通过评审还可以让软件变得更加易读和易维护。
对于软件产品来说，缺陷发现得越早，纠正缺陷所需的费用就越少。因此，在软件的开发阶段，如果严格进行同行评审，那么后续流程中出现的错误就会越少，这也可以为公司节约纠错的成本。开发人员分析测试人员反馈的问题时，经常陷入一个思维怪圈，只关注业务和处理逻辑，忽略了一些非常明显的简单错误，然而正是这些简单的错误导致了不确定的后果。通过代码走查可以很容易的发现这些问题，最终降低开发成本。
同行评审过程中发现的错误可作为案例传递下去，避免开发人员再次掉进同一个陷阱。“前事不忘，后事之师”，别人所犯的错误对自己有警示的作用。特别是对于新员工来说，经常参与同行评审，可减少犯错的次数，也能够达到对新工作及早上手的目的。
软件测试中心/刘源
众所周知在软件项目中，缺陷发现的越早，用于解决缺陷的人力成本、资金成本也就越低。因此，很多项目会要求测试人员尽早介入，但这样是否就足以做到缺陷尽可能早的发现和消除？答案是否定的！因为，并不是所有的缺陷都会通过测试发现，尤其是产品早期产出（如：《原始需求》、《需求规格说明书》），是无法进行有效测试的；即使有了可测试的产品，有些缺陷同样不会被发现，如：代码级别存在的漏洞。鉴于以上种种原因，我们急需在项目过程中引入同行评审。
同行评审不是我们狭义上理解的代码走查，也不是仅仅由开发人员开展的活动，而是各个角色在项目的各个阶段都可开展。同行评审有正式评审、技术审查、走查多种方式，其目的是参与人员多角度的去分析、考虑问题，集思广益。我们在具体的实施过程中，可以采用多种评审方式的结合，去及时的发现缺陷。
交易所事业部/焦林枫
我国有句古话叫做“当局者迷，旁观者清”。无论我们写文档还是写程序，当陷入到细节中去，就很容易出现一些疏忽，从而导致产品出现质量问题。同行评审就是一种很有效的手段，能够在设计之前，在编码之前，在测试之前，及早的发现问题，减少产品缺陷。
然而，如果一个好的方法只浮于表面，评审者仅走个形式，发现几个错别字，这种评审会议不仅浪费了这个易于发现错误的机会，还耗费了评审者的时间和精力。同行评审，“同行”二字，明确的指明了参与评审者的角色。显然，只有对评审材料有一定水平的理解，才能够有效地发现关键的问题。因此，一方面要保证评审者在要评审的领域达到一定的水平，另一方面要求评审者在评审会议之前用一定的时间去阅读评审材料，提前发现问题。这样评审会议才能够高效地进行。如果组织内部缺少熟悉评审内容的专家，就需要我们调整评审方法，让作者讲解评审材料，在讲解中发现自己写的文档或程序中的缺陷。选择适当的同行评审方式，同行评审才能够达成预期的目的。
谬论原则
每一行都有每一行的做事原则，理解和坚持这些原则是在这个行当发展的基础。
对于软件测试，ISTQB 为测试活动列出了七个原则，其中最后一个原则称为“不存在缺陷的谬论（Absence-of-errors fallacy）”。 具体是说“假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的”。有人说，这个原则不能算是一个合格的原则，而我倒是觉得这个原则应该是测试活动的第一原则。
首先，这个原则说明了，软件的质量不在于有没有所谓的“缺陷”，而在于能不能完成客户的需求和期望（注意，这是一个悖论，因为从某种意义上讲，不满足客户就是缺陷）；其次，该原则表明测试不能是孤立的，脱离了研发和客户需求的测试活动是没意义的；另外，该原则明确指出，对客户需求和期望的满足是测试人员的工作基础，同时也是最终目标。
所以，这个原则很重要！违背了这个原则，测试人员就忘了本。要么沉浸在单纯的测试技术和测试流程中，要么成为验证工具，测试的意义也就大打折扣。
