为什么测试同学要看代码？这是很多开发同学、甚至部分测试同学都很疑惑的一个问题。在测试中结合进行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)，我们将立即处理
