为什么测试同学要进行Code Review?

发表于:2022-5-31 09:50

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:circle_hyy    来源:简书

  为什么测试同学要看代码?这是很多开发同学、甚至部分测试同学都很疑惑的一个问题。在测试中结合进行Code Review可以大大提升测试的质量和效率。

  什么是Code Review
  Code Review是一种通过复查代码提高代码质量的过程,在XP方法中占有极为重要的地位,也已经成为软件工程中一个不可缺少的环节。
  其目的在于找到开发时被忽视的 Bug,以此极大地提高代码质量也可以帮助开发者们更加熟悉项目。
  Code Review要检查什么内容呢?如下图,完整性检查、一致性检查、健壮性检查等。

  这些当然不是我们检查的重点,我们主要关注业务流程(先做什么、再做什么),以及处理逻辑(判断条件、金额处理、数据操作、状态变更、特殊处理)。

  为什么
  但是,你可能还是疑惑这跟测试同学有什么关系。
  你是否经常觉得测试时间太短,执行用例时间不够?
  你是否感觉已经做了充分的测试分析,漏测率还是很高?
  提的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、快速定位问题
  有时候结合报错日志以及代码,我们是可以直接定位到出现问题的代码行,发现其中出现问题的地方和导致问题出现的情况,然后告诉开发同学修改即可。
  因为我们找开发同学解释出现问题的过程步骤、结果的时候,即使将缺陷详细地提交到了缺陷管理平台,他可能还是会看不懂然后再问你,这么一来一回解决问题的效率就非常低了。
  但是如果你将报错情况和相关代码一起附上去,就可以加快开发同学解决问题的效率了。

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

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
51Testing“十佳作者”计划,投稿不只有稿费!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海漕溪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2022
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号