2、测试基础理论回顾：白盒测试、黑盒测试、灰盒测试、静态分析与动态测试

各位同学好，我是老张。今天咱们聊聊测试的基础理论。说实话，这些概念很多工程师面试时都能背出来，但真正用对地方的人不多。我见过不少项目，测试报告写得花团锦簇，结果产品一上线就出问题——说白了，就是没搞懂这些测试方法到底该用在哪儿。

2.1 白盒测试：把代码翻个底朝天

白盒测试，也叫结构测试。你想想看，就像把一台发动机拆开，看里面的齿轮怎么咬合、油路怎么走。测试人员得盯着代码本身，检查每一条路径、每一个分支。

核心关注点：

• 语句覆盖：每行代码都跑过一遍了吗？
• 分支覆盖：if-else 的两个方向都测了吗？
• 条件覆盖：每个布尔表达式的真/假都覆盖了吗？
• 路径覆盖：所有可能的执行路径都走通了？

举个例子，我当年做汽车BMS（电池管理系统）时，有一段过流保护逻辑：

if (current > OVERCURRENT_THRESHOLD) {
    if (duration > 100) {
        fault_flag = 1;
        shutdown_relay();
    } else {
        fault_flag = 0;
    }
} else {
    fault_flag = 0;
}

嗯，这里要注意。如果只测了电流超标且持续时间长的情况，那 else 分支里的 fault_flag = 0 可能永远没机会执行。我在项目中遇到过，某次测试报告显示覆盖率达到95%，结果漏掉的就是这个 else 分支——后来现场出了故障，标志位没清掉，系统一直报错。

2.2 黑盒测试：只管输入输出，不看内部

黑盒测试正好相反。你把它当成一个黑箱子，只管塞输入、看输出对不对。内部代码怎么写、用了什么算法，一概不管。

常用方法：

• 等价类划分：把输入分成几个等价类，每个类里选一个代表测就行。比如温度传感器范围是 -40°C 到 125°C，那 -40、0、125 各测一次，没必要每个温度都测。
• 边界值分析：bug 最喜欢藏在边界上。比如阈值是 100，那 99、100、101 必须测。我吃过这个亏——某次通信协议里，数据长度字段是 0-255，我测了 0、128、255，结果没测 256（溢出），上线后直接数组越界。
• 因果图法：多个输入条件组合时，画个因果图，找出哪些组合会导致特定输出。

2.3 灰盒测试：介于两者之间

灰盒测试，说白了就是「我知道一点内部结构，但我不全看」。比如我知道某个模块用了状态机，但我不知道状态转移的具体代码怎么写。那我测的时候，就针对状态机的几个关键状态设计用例。

为什么会需要灰盒测试？因为纯黑盒可能漏掉内部逻辑的缺陷，纯白盒又太耗时。灰盒是个折中方案。

典型场景：

• 测试通信协议栈：我知道协议分几层，但每层的具体实现我不关心
• 测试驱动函数：我知道它调用了底层硬件接口，但我只验证接口参数对不对
• 测试中间件：我知道它用了消息队列，但我只测消息的收发是否正确

2.4 静态分析与动态测试

这两个概念经常被混淆。我简单说清楚：

维度	静态分析	动态测试
执行代码？	不执行，只看代码文本	必须运行代码
发现什么？	语法错误、编码规范、潜在缺陷	运行时错误、逻辑错误、性能问题
工具举例	PC-Lint、Coverity、SonarQube	VectorCAST、CppUnit、LDRA
什么时候做？	编码阶段，甚至写一行就能分析	编译完成后，运行阶段

静态分析，说白了就是让工具帮你读代码。我习惯在每次提交代码前跑一遍静态分析。记得有一次，静态分析工具报了一个「未初始化变量」的警告，我一看，确实有个局部变量没赋初值就直接用了。这种 bug 动态测试很难发现，因为有时候它碰巧是0，有时候是随机值——嗯，这就是典型的「幽灵 bug」。

动态测试，就是让代码真正跑起来。你给它输入，看它输出，监控它的行为。动态测试能发现静态分析发现不了的问题，比如死锁、内存泄漏、时序问题。

2.5 小结：怎么选？

说了这么多，你可能会问：那我到底该用哪种？

我的建议很简单：

• 安全关键模块（比如刹车控制、医疗设备）：白盒+静态分析，必须的
• 业务逻辑模块（比如数据处理、协议解析）：灰盒+动态测试，效率高
• 系统级验证（比如整机功能测试）：黑盒为主，辅以动态测试
• 代码质量管控：静态分析，天天跑

记住，没有银弹。每种方法都有它的适用场景。我见过有人死磕白盒覆盖率达到100%，结果项目延期三个月；也见过有人只用黑盒，结果线上出了严重的内存泄漏。灵活运用，才是正道。

下一章，咱们聊聊单元测试的具体实践——怎么写一个真正有用的测试用例。