为什么做软件测试要进行Code Review？

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

　　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、快速定位问题

　　有时候结合报错日志以及代码，我们是可以直接定位到出现问题的代码行，发现其中出现问题的地方和导致问题出现的情况，然后告诉开发同学修改即可。因为我们找开发同学解释出现问题的过程步骤、结果的时候，即使将缺陷详细地提交到了缺陷管理平台，他可能还是会看不懂然后再问你，这么一来一回解决问题的效率就非常低了。但是如果你将报错情况和相关代码一起附上去，就可以加快开发同学解决问题的效率了。

　　以上内容为大家介绍了为什么做软件测试要进行Code Review，本文由多测师亲自撰写，希望对大家有所帮助。了解更多软件测试相关知识：https://www.duoceshi.com/xwzx-hydt/