在百度，阿里等很多大型互联网公司，测试人员都会参与到code review中，我们团队也在去年开始开展起code review，为什么我们要这么做，首先老生常谈一下代码评审的诸多优点：
　　1. 通过大家一起改进代码的质量，可以在前期发现很多缺陷；
　　2. 彼此分享传递知识，让更多的人尤其是不太熟悉该业务的人也可以轻松的维护代码，甚至可以做好人员的back up，否则人少活儿多的团队，因为某个人的离开导致业务发展受到影响得不偿失；
　　3. 促进团队沟通，彼此取长补短；
　　4. 同时常态化的code review可以很好的提高团队凝聚力，在工作中彼此帮助，相互学习，团队中每个人会自动进化成长。
　　以上这些优点基本上都是说的开发团队成员间的code review，而对于测试人员来说，参与到code review中的好处又有哪些呢：
　　1. 可以更深入地理解开发实现，易于测试覆盖到一些非需求性的点；
　　2. 方便评估影响范围，有效提高测试效率，不会因为一个小改动而动全身，大范围的回归测试，实际上只是因为改了一行代码，只不过在多次被调用而已；
　　3. 对于一些不易于测试的代码可以很方便的静态检查，甚至可以直接编码进行调试验证，可以省去让开发人员额外编码满足易测试性要求的成本；
　　4. 增加了一种更加“程序猿化”的沟通方式，再也不会被开发人员瞧不起咱们不懂代码了，提出bug的时候直接甩出来哪个地方的问题，真是爽哉！
　　当然，一旦测试人员介入到code review的时候，特别是对于测试新人容易出现一种情况，大家都习惯于在IDE中反复敲击F3来跟代码，从一个入口方法一直这样一步步往下，心里还一边恍然大悟一样，soga，原来是这样实现的，如果你不保持自我的清醒意识，仿佛着了魔一样沉溺于code的海洋。打住！你要跳出来，以一个需求方甚至是终端用户的角色来看待代码都做了什么，毕竟我们要来审视开发人员的劳动成果是否满足需求，而不是以他们为标准来熟悉业务，这完全应该是两码事，不能跟着代码走！正确的做法是，在充分理解了需求，对需求每一点理解的都非常透彻的前提下，review代码是否按此实现了，如果没有尽早提出来，让开发修改，所以我觉得测试人员在进行code review的第一大任务应该是review业务逻辑是否被正确实现，然后才是去理解开发人员的实现方式以及找出代码中的其他问题。
　　在我们所做的review中，会关注以下内容：
　　1）需求里要求的业务处理逻辑是否有遗漏，是否有实现错误等；
　　2）判断的条件是否缺失， 判断的条件是否符合需求，特别是在对边界处理上，本应该大于等于的是否写成了大于，等等；
　　3）错误处理，是否正确处理了错误，错误是否应当被拦截，拦截后是如何处理的，需要打日志的时候是否打了，遇到非常重要的操作时如果失败的话是否添加了报警（包含但不限于邮件，短信等）；
　　4）是否对入参进行了校验，校验是否涵盖全了；
　　5）SQL语句是否正确，比如创建和更新，应该分别是insert和update的语句实现的，不能搞错，还有很多页面显示的数据都是通过select查询语句实现的，如果where条件不正确一眼能看出来；
　　6）数组越界，以及空指针异常等；
　　7）同样，还可以检查出代码的结构是否合理，是否有冗余，比如经常有开发同学把同样一段代码在if和else两个分支里都实现了，是否可以直接拿到判断之外；
　　8）对于能力更强的测试同学，同样还可以找出设计模式上的问题，以及可能存在的安全及性能的风险。
　　目前我们的review工作基本集中在前7条，我相信在大家逐步熟练和进步了之后，会慢慢的发现一些代码架构，性能等深层次的缺陷的。
　　通过实施code review，测试同学更加熟悉开发实现，对自己所测试的系统的质量保障更加有底气，一个新需求到手，马上都能想到开发人员要改动哪里，现在我们的测试人员已经基本养成了及时svn up代码，打开IDE或者通过svn diff查看改动的代码内容，虽然在此之前我曾强制要求大家使用一个code review的工具来开展，但是强制所带来的效果，远没有让大家感受到其好处来的更佳，慢慢地，code review成了常态化。