白盒测试的白盒核心，是测试测试拿代码当犯罪现场来查。你手里有源码，用例就像拿到了嫌疑人的白盒日记——每个if分支是犹豫的瞬间，每个循环是测试测试重复的谎言，每个边界条件则是用例藏不住的马脚。但问题在于，白盒日记写得太厚了，测试测试没人能逐字读完。用例

我见过最典型的白盒白盒测试用例，长这样：被测函数接收一个整数，测试测试如果大于0返回"正"，用例小于0返回"负"，白盒等于0返回"零"。测试测试新手会写三个用例：1、用例-1、0。覆盖了三个分支，看起来完美。可代码里还有一行被忽略的细节——如果入参是字符串"5"呢？类型转换失败会抛异常。这行代码不在任何分支里，但它真实存在。所以真正的白盒用例得加上：传字符串、传null、传浮点数5.0。这些用例不是为了测逻辑，是为了测那些"你以为不会发生"的事。

有个老前辈教过我一个土办法：把代码打印出来，拿荧光笔涂。每走通一条路径，就涂掉对应的行。等你把所有路径都走完，纸上还有没涂色的地方——那些就是漏网之鱼。这个办法效率不高，但胜在直观。后来我改用工具做覆盖率统计，发现工具报告"100%行覆盖"时，我依然心里发虚。因为行覆盖只看每行代码是否执行过，不关心你执行时用的什么数据。你拿x=1走一遍if(x>0)和拿x=2走一遍，行覆盖都算通过，但边界值x=0呢？没人测。

所以白盒测试用例的设计，本质是在跟代码的"侥幸心理"对抗。代码里每个分支条件都像一道门，你推开了其中几扇，但没推开的那几扇后面，可能藏着段错误或者死循环。我习惯在每个条件判断处停下来问自己：这个判断的等号边界，真的需要严格相等吗？如果改成大于等于会怎样？这种问法很烦人，但确实能逼出问题。

有一次我测一个排序函数，代码写得规规矩矩，冒泡排序，两层循环，交换标志位。行覆盖100%，分支覆盖也100%。可我用了一个包含重复元素的数组，结果函数直接死循环了——因为交换标志位只在元素严格大于时才置位，重复元素导致标志位永远为真。这个bug藏在两层循环的交叉点，任何单路径用例都测不出来。后来我在用例里加了一条：用相同元素填满整个数组。这才把问题暴露出来。

白盒测试最反直觉的地方在于，它要求你既当侦探又当罪犯。你得先假设代码有罪，然后设计出能证明它有罪的场景。而代码最常犯的罪，不是逻辑错误，而是对输入的过度自信。每当你看到参数类型是int，就默认它一定是整数；看到数组长度大于0，就默认它非空——这些默认，就是白盒测试要打破的。写用例时，把每个参数都当成可能传错的、每个边界都当成可能越界的、每个循环都当成可能不终止的。这种偏执狂式的写法，反而能写出最扎实的测试。

最后说个实用技巧：别只盯着代码结构看。把函数调用图打印出来，找到那些被多个地方调用的公共函数。这些函数是白盒测试的重灾区——因为每个调用方对它的假设都不同，而你只能为它写一套用例。这时候就得看调用方的实际传参范围，挑出最极端的组合去测。这活儿不浪漫，但干久了你会发现，代码里最深的坑，往往不在最复杂的算法里，而在那些人人都觉得"简单到不用测"的工具函数里。