测试同学为什么要做code review

由于刚入职不久,需要熟悉业务但是有没有专门的同事进行业务交接,所以想要看下开发代码。提高测试效率。

Code Review是一种通过复查代码提高代码质量的过程,在XP方法中占有极为重要的地位,也已经成为软件工程中一个不可缺少的环节。其目的在于找到开发时被忽视的 Bug,以此极大地提高代码质量也可以帮助开发者们更加熟悉项目。

你是否经常觉得测试时间太短,执行用例时间不够?
你是否感觉已经做了充分的测试分析,漏测率还是很高?
提的bug要反复沟通开发同学才理解?
怎么办呢,增加测试时间?不可能,测试时间越长,在后期我们能通过测试发现bug的数量是缓慢上升的,从业务要求和公司利益出发,都不会通过增加无限的测试时间来解决问题。我们要考虑投入产出比,只有提高测试质量和效率,才能从根本上解决这个问题。
因此,在测试时间不是十分充足的情况下,我们要合理利用好有限的资源,可以从代码入手。
1、可以用更低的成本发现问题
很多时候一些简单的错误通过code review就可以发现,比如计算错误(计算一年或者三个月的公式是否正确)、数据类型(给金额的值用double类型来处理是否合适)、方法错误(应该用方法A却用了方法B),处理遗漏(某次改动需要将某个方法的传参A(a,b,c)改成A(a,b,d),但是可能并没有改完)。
了解代码逻辑,在coding阶段发现问题,可以提高发现问题的概率和降低修复问题的成本。开发的一些bug可能花几分钟看代码就能看出来,而单纯靠执行测试还不一定能发现这个错误。我们的目标不是为了执行测试而测试,而是要交付更高质量的产品,并且是在更短的时间交付质量更高的产品。
设计的不合理也可以通过代码看出来,特别是对新项目。有的开发真的会认为能把功能上线就行,有问题后面再进行重构,所以前期设计时毫不注意,这是不对的。后面重构的成本意想不到,而且技术债务越堆越多,想重构都难下手,这样的项目在提测时就应该打回去。
2、让测试更加精准
测试同学在设计用例和执行测试时如果知道代码逻辑,就能更加精准地基于风险进行测试,并且能降低遗漏的风险。就举功能测试的例子来说,两个同学测试同一个功能,甲仅基于原型进行测试,乙除了原型还了解代码逻辑,你觉得哪个同学测试覆盖率会高一些。对某个入口,乙在测试中有针对性地对前提条件进行组合测试,而甲只是基于业务经验进行测试,可能测试用例中大部分都是无效的。你可能会说,如果给甲多一点时间,或者他经验更丰富一些,他能写出最完美的测试用例和做最完善的测试。是的甲确实可以,但是你有考虑过效率和成本问题吗。
3、避免夹带/误删而测试同学不知情
如果你没看过代码,开发提测的代码中可能夹带/误删而未通知你呢。除了新项目测试时会全面一些,迭代项目的话大家的测试点都是基于改动点和影响范围的,不可能进行全量测试,这时候开发改动了其它部分并且认为这不影响功能(比如重构),可能就没在改动点里说明,那测试同学就很容易忽略了。而如果刚好这部分功能上线后出了问题呢,难道测试同学真的不需要负责吗。
4、上线版本管理
还有一种情况,如果上线的代码不是你测试的代码呢,可能是开发同学的误操作或者在即将上线时改了东西。虽然这可能涉及到版本管理和上线规范的问题,但是测试同学通过检查发布的版本中是不是这次测试的对象,开发在上线前是不是又改了东西,就能避免这样的问题。作为测试同学,不能认为我只确保测试阶段的问题,我发测试报告之后的意外情况就概不负责了。要对全流程进行质量把控,不能把测试工作仅限于测试本身,应该多关注质量管理问题。
5、小需求通过code review可直接上线
有的小需求小改动直接通过code review可以评估能否上线或者可以直接给产品验收的,就无需再执行测试了。比如开发修改配置文件、修改参数等,对这些改动进行测试是没有太大必要的。当然前提是需要准确评估,虽然偶尔还是会出现测试同学评估可以直接上线,结果上线后出现线上问题的情况。
6、快速定位问题
有时候结合报错日志以及代码,我们是可以直接定位到出现问题的代码行,发现其中出现问题的地方和导致问题出现的情况,然后告诉开发同学修改即可。因为我们找开发同学解释出现问题的过程步骤、结果的时候,即使将缺陷详细地提交到了缺陷管理平台,他可能还是会看不懂然后再问你,这么一来一回解决问题的效率就非常低了。但是如果你将报错情况和相关代码一起附上去,就可以加快开发同学解决问题的效率了。

怎么做

1、对大项目来说,一般改动非常多,而且可能涉及好几个系统的改动,详细过代码不太实际,可以提测后和开发同学结对review一次代码,主要是评估是否有其他改动点,同时可以根据具体逻辑完善测试用例。然后测试阶段开发修复bug提交的代码每一次都要过一遍,主要看这次改动能否解决问题,以及改动方式和范围会不会影响其他功能。
2、对小需求/fix来说,改动的范围不多,测试同学自己结合commit看改动点即可。可通过代码审查直接上线,或者快速确认测试点快速测试。
对于新接手的开发提交的代码需要更加谨慎,除了看这次的改动点,还需要留意是否不小心改了其它地方的代码。
那么在review时要关注哪些方面呢?
1、处理逻辑 在A出现了某个异常之后没有进行步骤B。
2、数据类型 对某个值用int/double类型是否合适。
3、公式计算
4、可以关注规范问题 如打印日志的规范。
总而言之,code review基本是发现和修复问题成本最低的方式,测试同学进行code review可以大大提高测试质量和效率,同时还可以提高编程能力。能有权限看代码就要合理使用(可能有的公司会不给测试同学开权限)当然有权限也需要谨慎,不能做违反纪律法律和道德的事情。

 

你可能感兴趣的:(工作日常遇到的问题)