测试同学怎么参与codereview

前言

Code Review，简称CR，也就是我们常说的代码评审。Code Review主要是在开发过程中，对代码进行评审。其目的是为了提高代码质量和规范性，尽早发现潜在缺陷与BUG，降低修复成本。同时也可以提高开发者自身水平。现在越来越多的公司已经把Code Review作为研发流程中的一个必备环节之一。

在大家的潜意识当中，Code Review是开发的工作，只要开发参与就行了。与测试同学无关。但是随着近些年测试左移概念的流行，Code Review可以作为测试左移的一个环节之一。测试过程中结合Code Review 可以大大的提升测试质量和效率。

为什么要参与Code Review？

1、用更低的成本发现问题

        一些比较简单的错误经常通过Code Review就能发现，比如计算错误、数值类型错误（存储时间的变量使用 string 类型是否合适）、未做异常捕获、未对边界值进行处理等等。

        Deming 先生曾提出“问题发现得越早，修复的成本越低”。有数据指明，85% 的缺陷都是在代码编码阶段引入的，然而大部分的缺陷并不是在编码的时候发现的，而是在后面的测试过程中发现的，并且越往后发现的缺陷越多。

按照STICKYMINDS网站上上的一篇名为The Shift-Left Approach to Software Testing的文章中所给出的（如上图），假如在编码阶段发现的缺陷只需要1分钟就能解决，那么单元测试阶段需要4分钟，功能测试阶段需要10分钟，系统测试阶段需要40分钟，而到了上线之后再发现可能就需要640分钟来修复，这个成本是非常高的。 

        所以如果测试同学有能力通过Code Review 就发现问题，不仅可以降低修复问题的成本，也提高整体的效率。

2、明确测试范围，进行精准测试

        通过Review代码，了解代码变更点，能够针对性地对开发代码的变更点以及变更关联点做测试，并且精准的确定回归测试范围，避免了全量回归造成的测试资源浪费，也降低了漏测的风险。

3、对上线需求代码范围进行把控

        之前在一次Code Review时，发现有一位开发把不属于本次版本上线的需求代码也合并了过来，后来经证实是误操作后，又把对应的代码进行剔除。

        那如果这部分代码未经测试就上线，极大可能会影响线上的正常功能。这种情况是大家都不愿看到的。

        有的同学会说，在发版之前开发会检查对应的代码的吧，在上线前剔除就可以了。如果是这种情况，代码剔除之后，一些解决的冲突会被复原，测试同学还要再进行一次比较全面的回归，非常浪费时间且风险极大。

4、较小需求可以在Code Review后直接上线

        经常有些需求只涉及到相关配置文件的变更，比如，有一些logo图片是上传到存储平台后，把url放在配置平台的，如果设计/产品要更换logo，直接修改相关配置后，产品/设计直接进行验收即可，不用再进行对应的测试，也大大的节约了测试时间。

5、更快速的定位问题

        熟练的同学可以结合日志和代码，快速的定位到出现bug的代码行，在提交bug 的时候把相关代码信息提交上去，开发直接修改即可，在提高效率的同时，也会让开发对我们更加的信服！

什么时候做Code Review呢？

        提测前，在开发完成coding后，把开发分支合到测试分之前进行code review，可以自己走读代码，也可以参与开发的代码评审会议，这时参与，可以对比自己对需求的理解和开发实现的有何不同，及时对齐相关信息。

        功能测试发现bug时，这时候可以通过走读代码，定位失败原因，将详细的错误代码行指出并告知开发，可以提高开发修复bug 的效率，也减少了自己给开发复现bug的时间。

        修复bug后，走读开发提交的代码记录，看是否会引入新的bug。

        上线前，查看开发merge 代码范围，检查是否只merge了当前要上线需求的代码，是否夹带了其他不需要上线需求的代码，等。

测试同学在Code Review中应该关注什么？

开发同学在review代码的时候，会检查代码的可读性和可维护性，会关注代码的设计，逻辑和业务是否正确，使用的相关设计模式等等，但是对于测试来说，我们应该着重关注一下代码逻辑，以及常见的缺陷等。

CR前：

        在CR前我们要对需求做一个全面的了解，对如何实现需求有自己的思路。对比自己的思路和开发的实现逻辑有何差异，开发的实现有什么优势？自己的思路缺点在哪里？实现有没有漏洞？这么做不仅可以加深自己对业务的理解，也能大大提高自己的代码能力和设计能力！

CR时：

        在CR过程中要关注下开发的代码实现细节， 并且对自己的测试用例查漏补缺，来完善测试场景，也可以对测试设计中冗余的 case 进⾏清理，避免重复⽆⽤的测试。

        另外，除了关注这次的改动点，还要留意是否不小心改了其它地方的代码，影响已有功能。

        其次，在review 代码的时候，我们还可以关注一下常见的缺陷，下面列举了一些：

• 函数的参数， 参数是否被函数使用或正常使用
• 数据类型 对某个值用int还是double；
• 除数为0、整数溢出、精度损失；
• 可能死循环；

• 在finally程序块中关闭或者释放资源；

• 异常处理，是否正确处理了异常，最常见的空指针异常要关注；

• 公式计算错误；

• 字符串对比不能用==，使用equals；

• 数组可能越界；

• 传递引用错误；类型转换错误；

• 条件范围选择错误；

• 边界值处理情况；

等等...

多参与Code Review，记录常见的缺陷，总结、整理出自己的心得，一定会越来越顺手的。

充分合理的利用code review，不仅可以降低发现和修改问题的成本，还可以提高测试质量和效率。同时也可以学习代码中设计精妙的地方，快速提高自身编程水平。