门禁核心指标：四个你必须盯死的数字

做智能座舱质量门禁，说白了就是跟四个数字打交道。代码静态扫描通过率、编译告警清零率、单元测试覆盖率、功能测试通过率——这四个指标，我习惯叫它们「四根柱子」。任何一根倒了，发布风险就会直线上升。

你可能会问：为什么偏偏是这四个？我在项目中遇到过太多次了，团队辛辛苦苦赶完功能，结果一跑静态扫描，几千个高危漏洞。或者编译全是警告没人管，上线后偶发崩溃。嗯，这些坑我都踩过。所以今天咱们把这四个指标掰开揉碎讲清楚。

2.1 代码静态扫描通过率

静态扫描，说白了就是让工具替你读代码。它不运行程序，只靠规则引擎检查语法、逻辑、安全漏洞。我见过很多开发觉得这步多余，觉得「我写的代码我自己清楚」。但说实话，人眼总有盲区。

举个例子。我曾经在一个项目中，静态扫描工具报了一个「空指针解引用」的警告。开发看了三遍说没问题，结果我让他把那个分支的输入参数打印出来——好家伙，确实可能传 null。这种问题，靠人审很难发现。

静态扫描通过率怎么算？很简单：

通过率 = (1 - 阻断性问题数 / 总问题数) × 100%

但这里有个关键点——不是所有问题都一视同仁。我建议把问题分三级：

级别	定义	门禁要求
阻断性	空指针、内存泄漏、安全漏洞	必须清零
严重	资源未释放、未初始化变量	通过率 ≥ 95%
建议性	命名不规范、注释缺失	通过率 ≥ 80%

2.2 编译告警清零率

编译告警，很多人觉得「能编译过就行，警告无所谓」。但你想过没有——编译器不会无缘无故给你警告。每一个警告背后，都藏着潜在风险。

我记得有一次，座舱的导航模块在特定场景下会闪退。查了两天，最后发现是一个未初始化的变量。编译时其实报了 warning，但团队觉得「不影响运行」就没管。结果呢？线上事故。

编译告警清零率，我要求必须是 100%。没有商量余地。为什么？因为告警是编译器在替你操心，你不领情，它就不管了。

常见的告警类型包括：

• 未使用变量——可能是逻辑遗漏
• 类型不匹配——隐式转换可能丢精度
• 未初始化变量——运行时行为不确定
• 废弃API调用——后续版本可能移除

2.3 单元测试覆盖率

单元测试覆盖率，这个指标争议最大。有人说「覆盖率不重要，测试质量才重要」。我同意一半。覆盖率确实不是万能的，但没有覆盖率是万万不能的。

我个人习惯看两个维度：

• 行覆盖率：代码中多少行被执行过
• 分支覆盖率：条件判断的真假分支是否都覆盖到

座舱软件里，我建议行覆盖率 ≥ 80%，分支覆盖率 ≥ 70%。为什么不是 100%？因为有些异常分支很难构造，强行覆盖反而会写出「为了测试而测试」的代码。

但这里有个坑——覆盖率数字好看，不代表测试有效。我遇到过项目覆盖率 90%，但核心逻辑根本没测到。为什么？因为测试全写在 getter/setter 上。

2.4 功能测试通过率

功能测试通过率，这是门禁的最后一关。前面三个指标再漂亮，功能跑不通也是白搭。

功能测试通过率 = 通过的测试用例数 / 总测试用例数 × 100%。这个数字，我要求必须 ≥ 98%。而且剩下的 2% 必须有明确的「已知问题清单」和「修复计划」。

你可能会问：为什么不是 100%？因为有些场景下，非关键功能可以带已知问题发布。比如某个主题的动画效果有轻微卡顿，但不影响核心导航和语音交互。但前提是——必须经过产品经理和测试负责人双签确认。

功能测试的用例设计，我建议按优先级分：

优先级	覆盖内容	门禁要求
P0	核心功能（导航、语音、电话、安全）	100% 通过
P1	重要功能（媒体、设置、蓝牙连接）	≥ 98% 通过
P2	增强功能（主题、个性化推荐）	≥ 90% 通过

2.5 四个指标的关系

这四个指标不是孤立的。它们之间有先后顺序和依赖关系。我画了一张图，帮你理清逻辑：

从图上你能看到，这四个指标是层层递进的。静态扫描和编译告警是「代码级」检查，单元测试是「模块级」验证，功能测试是「系统级」确认。任何一个环节出问题，后面的工作都是白费。

我个人的经验是：门禁执行时，按这个顺序跑。先静态扫描，再编译，然后单元测试，最后功能测试。前面没过，后面的不用跑。这样能节省大量时间。