找回密码
 我要加入

QQ登录

只需一步,快速开始

新理念测试 首页 测试文章 测试文化 查看内容

工作之道3:让Code Review常态化

herosrx 2015-8-3 09:10

在百度,阿里等很多大型互联网公司,测试人员都会参与到code review中,我们团队也在去年开始开展起code review,为什么我们要这么做,首先老生常谈一下代码评审的诸多优点: 1. 通过大家一起改进代码的质量,可以在 ...

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

鲜花
鲜花
握手
握手
雷人
雷人
路过
路过
鸡蛋
鸡蛋
分享至 : QQ空间
收藏
来自: OKTest

相关阅读