测试人员代码审查(开发人员测试自己写的代码)

评审尤其是同行评审，是提前发现缺陷，降低开发成本的有效方法；但是很多企业并不重视，或者效果不佳。原因有很多：没有获得合适的专家、组织不合理、方法不当等。针对代码评审，我想简单地谈几点（其实其它工程文档的评审存在同样问题）：1、评审要计划。因为大家都很忙，各领域的专家也都有各自的工作，评审结果的好坏对他们工作绩效没有影响，所以专家投入多少精力来用于评审不受控，完全靠他们自己的职业精神。 所以，这就要求项目经理比较有影响力，能够争取到足够的、合适的专家来参与评审。专家最好要提前协调，当然项目经理首先要知道要请哪些专家（如系统专家、领域专家、测试人员、QA等），这些专家在哪里？能否获得专家资源的支持，是项目经理的项目管理能力一个重要体现。评审时间的投入比例，一般是第一次版本准备时间的3/5以上。2、评审要分层次和重点。作为项目成员，在代码编写完成后，首先是自检，这时发现的缺陷不计算；然后是项目组内的评审，这时发现的缺陷应计算；最后才是外部评审。应提前把相关文档和代码交给评审专家，让他们各自评审；根据项目和评审结果的情况，决定是否召开评审会议，评审会议以确认问题为主，而不是讨论解决方案。对于重要的核心的代码，要投入重点评审力量；另外，对于能力不足的成员所完成的代码，也要重点评审。每个角色也应明白各自评审重点，如QA重点放在编程规范、测试人员侧重在可测性、系统专家侧重在从整体来考虑（如对其它功能的影响、性能等）。3、问题的确认与跟踪。评审专家发现问题后，首先与该代码的完成人进行确认，如果大家达成一致认可这个问题，然后由代码完成人提出解决方案，这个解决方案要得到问题发现者的同意，然后编程人员编码实现该方案，并进行测试和验证，并将验证结果提交问题发现人，问题发现人确认无误后，该问题就可关闭。所以，评审专家发现问题后并没有结束，而是要负责跟踪该问题。总之，评审活动的组织其实比较复杂，也是项目经理项目管理能力的一个重要体现，项目经理对评审活动负有重要责任。
代码review主要就是事前的准备，执行，和后期的跟踪事前的准备也叫做review的输入，这个输入是在什么条件下可以做为输入，可以是个人检查完了，也可以是相互交叉的检查，这里有个检查的标准，如有个检查单什么的，等规定的输入完成之后，进行review的执行在review中，主要就是首先保证什么人参加，这是最主要的，如果找几个没有什么经验的，那review的效果肯定是打折扣的，review的多少时间跟踪，主要是问题的跟踪和后期的数据的度量你上面说的相互评审，主要是项目内部的review，review分好几种，有内部的，专家的，客户的review代码时主要看是否符合编码规范，特别是是否符合设计书（需求）的要求，逻辑是否正确，主要是专家级！！

通常现在团队内部都是不需要签字审批的，git管理分支的方式来进行
程序员写代码是不需要零点签字审批的，这个代码呢是生成一些文件之类的东西，是自己可以更改。
一般是通过流程来控制的，比如要单元测试覆盖率，要开发部署文档等，经理管你要这些流程，你都做完了自然就相当于审核通过了。
写的代码需要单元测试，再提交测试人员测试，代码上线需要审批，有小组长执行代码审核

代码走查和审查区别为：正式性不同、执行人不同、检查内容不同。一、正式性不同1、代码走查：代码走查的讨论过程是非正式的。2、代码审查：代码审查是一种正式的评审活动。二、执行人不同1、代码走查：代码走查由编写代码的程序员来组织讨论。2、代码审查：代码审查由高级管理人员来领导评审小组的活动。三、检查内容不同1、代码走查：代码走查只检查代码中是否有错误。2、代码审查：代码审查除了检查代码中是否有错误，还要检查程序与设计文档的一致性。参考资料来源：百度百科——代码走查百度百科——代码审查
有以下三个区别： 代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法,代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。代码审查列出问题的类型，并有解决情况报告。 一般情况代码走查有专门的工具比如：emma，该工具使用与大型项目，为开源的，代码走查完毕之后需要对结论给出一个代码走查报告。
Workthroughs: Typically, 4-6 individuals in a SQA team. For example, for a specification walkthrough:1.representative from spec. team2.manager from spec. team3.rep. of client4.rep. of “next” phase in the lifecycle (design)5.rep. of SQA group, and chairman.inspectionsuse checklists of potential faultsE.g. in a design document:????each item in the spec. should be in design???? interfaces should be checked???? error handling???? hardware resources for the design need to be checkedworkthroughs VS inspections1.inspections are more formal2.inspections involve checklists and statistics 3.inspections involve fault and resolution documentation

代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。 走查与代码审查基本相同，其过程分为两步。第一步把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当计算机”，即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

提高代码质量 在项目的早期发现缺陷，将损失降至最低评审的过程也是重新梳理思路的过程，双方都加深了对系统的理解促进团队沟通、促进知识共享、共同提高交叉评审——代码走查：团队成员互相检查代码参与者可以是任意两个组员，或开发组长分别与每个组员结对进行时机可以选择在下班前半小时，对当天改动的模块进行评审代码作者讲解如何以及为何这样实现、评审者提出问题和建议每次解决的问题要记录到svn注释或jira每次评审不要贪多，如下图所示：当一次评审超过400行代码时，能发现缺陷数显著降低——事倍功半会审：以项目为单位，召开专门的代码评审会议参与者：包括项目组全体成员，其它组的开发组长也应尽量参加 时机选择：开发进行到某一阶段时，对共性问题进行总结，对好的做法进行提炼和推广
评审尤其是同行评审，是提前发现缺陷，降低开发成本的有效方法；但是很多企业并不重视，或者效果不佳。原因有很多：没有获得合适的专家、组织不合理、方法不当等。针对代码评审，我想简单地谈几点（其实其它工程文档的评审存在同样问题）：1、评审要计划。因为大家都很忙，各领域的专家也都有各自的工作，评审结果的好坏对他们工作绩效没有影响，所以专家投入多少精力来用于评审不受控，完全靠他们自己的职业精神。 所以，这就要求项目经理比较有影响力，能够争取到足够的、合适的专家来参与评审。专家最好要提前协调，当然项目经理首先要知道要请哪些专家（如系统专家、领域专家、测试人员、QA等），这些专家在哪里？能否获得专家资源的支持，是项目经理的项目管理能力一个重要体现。评审时间的投入比例，一般是第一次版本准备时间的3/5以上。2、评审要分层次和重点。作为项目成员，在代码编写完成后，首先是自检，这时发现的缺陷不计算；然后是项目组内的评审，这时发现的缺陷应计算；最后才是外部评审。应提前把相关文档和代码交给评审专家，让他们各自评审；根据项目和评审结果的情况，决定是否召开评审会议，评审会议以确认问题为主，而不是讨论解决方案。对于重要的核心的代码，要投入重点评审力量；另外，对于能力不足的成员所完成的代码，也要重点评审。每个角色也应明白各自评审重点，如QA重点放在编程规范、测试人员侧重在可测性、系统专家侧重在从整体来考虑（如对其它功能的影响、性能等）。3、问题的确认与跟踪。评审专家发现问题后，首先与该代码的完成人进行确认，如果大家达成一致认可这个问题，然后由代码完成人提出解决方案，这个解决方案要得到问题发现者的同意，然后编程人员编码实现该方案，并进行测试和验证，并将验证结果提交问题发现人，问题发现人确认无误后，该问题就可关闭。所以，评审专家发现问题后并没有结束，而是要负责跟踪该问题。总之，评审活动的组织其实比较复杂，也是项目经理项目管理能力的一个重要体现，项目经理对评审活动负有重要责任。