做显示调校时，很多人盯着色准、伽马曲线、白点坐标猛调，却很少有人问一句：调校脚本和自动校准工具本身的代码靠不靠谱？这时候，测试覆盖率就成了藏在幕后的‘隐形质检员’。
行覆盖率：最基础也最容易骗人
它统计的是源代码中被执行过的语句行数占比。比如一段校准逻辑里有10行代码，测试运行时只走到了第1、3、5、7、9行，那行覆盖率就是50%。看似简单，但有个坑：哪怕只是给每个if分支都加个空print，也能把数字拉高——可这根本没验证逻辑对不对。
分支覆盖率：盯住判断逻辑的真假路径
比行覆盖进了一步，它关注的是所有if、else、case等分支是否都被执行过。举个例子：
if (displayMode == "HDR") {
applyToneMapping();
} else {
applyGammaCurve();
}要达到100%分支覆盖率，就得分别用HDR模式和SDR模式跑一遍测试。很多显示设备在不同模式下响应差异极大，漏掉任一分支，校准结果就可能偏得离谱。
条件覆盖率：拆解复合判断里的每个子表达式
当if里出现多个条件时，比如：
if (isOLED && brightness > 80 && ambientLight < 50)条件覆盖率要求每个布尔子表达式（isOLED、brightness>80、ambientLight<50）都分别取过true和false。这对显示驱动层尤其关键——OLED屏的亮度补偿算法一旦在低环境光+高亮度组合下没测到，就可能出现局部过曝却无报警。
路径覆盖率：穷尽所有执行路线（理论上难实现）
它要求覆盖程序中所有可能的执行路径。上面那个三条件if，就有2³=8条路径。实际项目中几乎不会追求100%，但核心校准流程（如色彩空间转换矩阵计算）至少要覆盖主路径+边界异常路径，比如输入RGB值超出[0,255]范围时是否触发安全钳位。
函数/方法覆盖率：看有没有‘漏网之鱼’
检查所有声明的函数是否都被调用过。显示调校工具里常有专门处理广色域映射、色深抖动、动态对比度抑制的独立模块，如果某个旧版ICC解析函数没被新流程调用，而你又没发现，导出的配置文件就可能在某些显示器上直接失效。
这些指标不是数字游戏。当你在调试一台新面板时反复出现白场发青、暗部细节丢失的问题，回头看看测试覆盖率报告，往往能快速定位是哪个校准环节的边界逻辑没覆盖到——比起盲目换参数，这更省时间。