为什么测试同学要看代码？这是很多开发同学、甚至部分测试同学都很疑惑的一个问题。其实在测试中结合进行code review可以大大提升测试的质量和效率。具体原因如下：
一、可以用更低的成本发现问题
1. 很多时候一些简单的错误通过code review就可以发现，比如计算错误（计算一年或者三个月的公式是否正确）、数据类型（给金额的值用double类型来处理是否合适）、方法错误（应该用方法A却用了方法B）、处理遗漏（某次改动需要将某个方法的传参A（a,b,c）改成A（a,b,d），但是可能并没有改完）。
2. 了解代码逻辑，在coding阶段发现问题，可以提高发现问题的概率和降低修复问题的成本。开发的一些bug可能花几分钟看代码就能看出来，而单纯靠执行测试还不一定能发现这个错误。我们的目标不是为了执行测试而测试，而是要交付更高质量的产品，并且是在更短的时间交付质量更高的产品。
3. 设计的不合理也可以通过代码看出来，特别是对新项目。有的开发真的会认为能把功能上线就行，有问题后面再进行重构，所以前期设计时毫不注意，这是不对的。后面重构的成本意想不到，而且技术债务越堆越多，想重构都难下手，这样的项目在提测时就应该打回去。
二、让测试更加精准
测试同学在设计用例和执行测试时如果知道代码逻辑，就能更加精准地基于风险进行测试，并且能降低遗漏的风险。就举功能测试的例子来说，两个同学测试同一个功能，甲仅基于原型进行测试，乙除了原型还了解代码逻辑，你觉得哪个同学测试覆盖率会高一些。对某个入口，乙在测试中有针对性地对前提条件进行组合测试，而甲只是基于业务经验进行测试，可能测试用例中大部分都是无效的。你可能会说，如果给甲多一点时间，或者他经验更丰富一些，他能写出最完美的测试用例和做最完善的测试。是的甲确实可以，但是考虑过效率和成本问题吗？
三、避免夹带/误删而测试同学不知情
如果你没看过代码，开发提测的代码中可能夹带/误删而未通知你呢。除了新项目测试时会全面一些，迭代项目的话大家的测试点都是基于改动点和影响范围的，不可能进行全量测试，这时候开发改动了其它部分并且认为这不影响功能（比如重构），可能就没在改动点里说明，那测试同学就很容易忽略了。而如果刚好这部分功能上线后出了问题呢，难道测试同学真的不需要负责吗？
四、上线版本管理
还有一种情况，如果上线的代码不是你测试的代码呢，可能是开发同学的误操作或者在即将上线时改了东西。虽然这可能涉及到版本管理和上线规范的问题，但是测试同学通过检查发布的版本中是不是这次测试的对象，开发在上线前是不是又改了东西，就能避免这样的问题。作为测试同学，不能认为我只确保测试阶段的问题，我发测试报告之后的意外情况就概不负责了。要对全流程进行质量把控，不能把测试工作仅限于测试本身，应该多关注质量管理问题。
五、小需求通过code review可直接上线
有的小需求小改动直接通过code review可以评估能否上线或者可以直接给产品验收的，就无需再执行测试了。比如开发修改配置文件、修改参数等，对这些改动进行测试是没有太大必要的。当然前提是需要准确评估，虽然偶尔还是会出现测试同学评估可以直接上线，结果上线后出现线上问题的情况。
那么怎么做code review呢？以下列出一些方法供大家参考。
1. 对大项目来说，一般改动非常多，而且可能涉及好几个系统的改动，详细过代码不太实际，可以提测后和开发同学结对review一次代码，主要是评估是否有其他改动点，同时可以根据具体逻辑完善测试用例。然后测试阶段开发修复bug提交的代码每一次都要过一遍，主要看这次改动能否解决问题，以及改动方式和范围会不会影响其他功能。
2. 对小需求/fix来说，改动的范围不多，测试同学自己结合commit看改动点即可。
对于新接手的开发提交的代码需要更加谨慎，除了看这次的改动点，还需要留意是否不小心改了其它地方的代码。
在review时要特别注意哪些方面呢？
1. 处理逻辑 在A出现了某个异常之后没有进行步骤B。
2. 数据类型 对某个值用int/double类型是否合适。
3. 公式计算
4. 可以关注规范问题如打印日志的规范。
总而言之，code review基本是发现和修复问题成本最低的方式，测试同学进行code review可以大大提高测试质量和效率，同时还可以提高编程能力。能有权限看代码就要合理使用（可能有的公司会不给测试同学开权限）当然有权限也需要谨慎，不能做违反纪律法律和道德的事情。
|
