白盒测试最直观的白盒例子，是测试给一段代码“照X光”。
假设你写了个函数，白盒判断一个年份是测试不是闰年：

def is_leap(year): if year % 400 == 0: return True if year % 100 == 0: return False if year % 4 == 0: return True return False

黑盒测试只关心输入输出——你扔进2024，返回True；扔进1900，白盒返回False。测试但白盒测试会盯着代码本身，白盒问一句：“这四行判断，测试每一行都被跑过了吗？白盒”

我见过太多测试新手栽在这上面。他们拿着等价类划分表，测试测了2000年、白盒2100年、测试2023年，白盒觉得万无一失。测试结果某天用户输入了个负数年份，白盒程序直接崩溃——因为代码里压根没写对负数的处理，而白盒测试的“语句覆盖”指标会立刻暴露这个漏洞：最后一行return False对负数也生效，但前面三个if分支里的year % 400计算，对负数取模的结果跟预期完全不同。

白盒测试最狠的地方在于它逼你面对逻辑死角。
拿上面闰年函数举例，你按“判定覆盖”设计用例：
- 用例A：year=2000（走通第一个if，返回True）
- 用例B：year=1900（跳过第一个if，进入第二个if，返回False）
- 用例C：year=2024（跳过前两个if，进入第三个if，返回True）
- 用例D：year=2023（跳过所有if，直接return False）

这四组数据看着齐全，但你要是用“条件覆盖”再审视一遍，会发现问题——year % 400 == 0这个条件，在用例A里为真，但你没测过它为假的情况。万一哪天有人把% 400错写成% 4，你的判定覆盖用例全通过，但条件覆盖用例立刻炸出bug。

真事。我去年接手一个支付模块，同事写了段折扣计算代码：

if user.level == 'gold' or user.age > 60: discount = 0.8 else: discount = 1.0

他自豪地说“测试覆盖率100%”。我看了眼他的测试报告——只测了gold用户和普通用户。但那个or右边的条件，user.age > 60从来没被单独验证过。后来上线第三天，一个62岁的老客户投诉说没享受到折扣。查下来，代码逻辑没错，但测试用例根本没覆盖“非gold但年龄超过60”的路径。白盒测试要是做了“分支条件组合覆盖”，这种坑早填上了。

还有个容易被忽略的细节：白盒测试对循环结构的处理。
你写了个遍历购物车的循环，统计总价。测试时只跑了一遍空购物车和一件商品的情况，觉得够了。但白盒测试会要求你测“循环体执行0次、1次、多次”三种场景。为什么？因为很多隐蔽bug藏在循环边界——比如循环里有个if index == len(items) - 1的特殊处理，你只测一件商品时，这个条件永远为真，压根没验证过它为假时的分支。

我习惯把白盒测试想成“代码的体检报告”。黑盒测试告诉你“这人看着没病”，白盒测试则盯着每一根血管看有没有血栓。但别神话它——路径覆盖再全，也测不出需求理解错误。你按错误需求写的代码，白盒测试只会帮你验证“错误得多么完美”。

工具方面，我用过JaCoCo、Istanbul这些覆盖率工具，但别被百分比忽悠。80%的语句覆盖可能比95%的判定覆盖更有价值，关键看你测的是哪条路。真正的高手会先看代码里哪些分支最容易藏雷——比如异常处理块、嵌套if、递归出口——然后手工设计用例去炸它们，而不是傻乎乎追求100%行覆盖。

最后说个反常识的观察：白盒测试写多了，你会发现自己写代码时更小心。因为你知道每个条件都会被拆开审视，那些“顺手写个else兜底”的坏习惯，会逼你思考else里到底该干嘛。这大概就是测试反哺开发的微妙之处。