代码评审，揭示黑盒背后的真相

一、引言

黑盒测试犹如案发现场，只能根据表象推断事件经过。
代码评审即深入调查，挖掘蛛丝马迹的线索，揭示背后的真相。
“They think I am hiding in the shadows, but I am the shadows.”

二、黑盒测试与白盒测试的区别

黑盒测试存在一些局限性：

• 可能无法发现与系统实现相关的问题
• 可能无法覆盖所有的测试场景
• 测试效率较低，比如准备物料、模拟场景
• 强依赖需求文档，如果文档不全，测试会漏

对于测试人员来说，可以在代码评审阶段，通过白盒测试改进测试的质量和效率。

三、代码评审的定义和意义

代码评审，Code Review（CR），是一种通过检查代码来提高代码质量的过程。
对于测试人员来说，参与代码评审，可以尽量提前发现问题，减少修复代价，提高效能。

四、代码评审的形式

「多人讨论」
组织会议，研发牵头讲解代码，架构和测试参与，讨论交流。这是最普遍的一种形式。
「Code Diff」
查看Code Diff，可以借助Gitlab或IDEA，比较分支差异或版本差异。

对比时机：

• 提测前和测试中，自行走查代码
• 发现缺陷，定位代码原因
• 修复缺陷后，评估影响范围
• 上线前，是否夹带代码

「精准测试」
评估测试用例的代码覆盖率，查漏补缺，Jacoco的on-the-fly模式支持动态收集代码覆盖率数据。

五、代码评审的方法

面向业务，面向业务，面向业务。重要的事情说三遍。
刚开始做代码评审，很容易把注意力集中在找代码规范问题上面，比如命名不规范、注释不清楚、代码实现冗长等。这些问题不是测试人员关注的重点，需要由研发团队或代码扫描工具来解决。
在做Code Diff时，也没必要把每个文件、每行代码的意思搞懂，比如研发对代码结构做了调整，在diff时要梳理清楚的话，ROI会非常低，因为既消耗时间，又发现不了问题。

「那该怎么做代码评审呢？」 关注业务：

1. 跟需求文档比较，哪些需求是遗漏的，哪些代码是补充的，哪些代码是夹带的
2. 关注核心业务代码逻辑，使用条件覆盖、路径覆盖等方法设计测试用例
3. 优化测试用例，针对代码实现考虑异常、边界、幂等、并发等场景

代码评审要求测试人员具备代码能力，理解编程语言，掌握软件设计，熟悉代码结构和架构，多与开发同学交流，共同优化代码质量。