论新时代软件测试人员的工作之道（三）让Code Review常态化

在百度，阿里等很多大型互联网公司，测试人员都会参与到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就成了常态化。

文章同步发布在我的个人博客:www.oktest.me上，可点击进入查看，同时收录全网海量测试相关文章，欢迎阅读。