GTest 代码覆盖率达标标准（行业通用+落地参考）
结合嵌入式、服务端、移动端、车载 等主流场景，分通用底线、合格标准、优秀标准 ，同时区分行/函数/分支三类指标。
一、核心指标定义（简要）
- 函数覆盖率：被调用测试的函数 / 总函数数
- 行覆盖率：被执行到的代码行 / 有效代码行（空行/注释不计）
- 分支覆盖率 ：
if/else/switch/for/while等所有真假分支都被走到的比例
二、行业通用达标阈值（最常用）
1. 基础底线（项目准入/门禁红线，必须强制）
适用于所有正式交付代码（业务代码、核心逻辑）
- 函数覆盖率：≥90%
- 行覆盖率：≥80%
- 分支覆盖率：≥70%
低于此线：视为测试不充分，门禁拦截、禁止合入主干。
2. 合格标准（常规产品/迭代版本，推荐目标）
绝大多数互联网、后端、客户端、普通嵌入式项目
- 函数覆盖率：95%+
- 行覆盖率：85% ~ 90%
- 分支覆盖率：75% ~ 80%
3. 优秀标准（核心模块/基础库/安全类/车载/工控/金融等高可靠场景）
核心逻辑、底层SDK、安全模块、车规、医疗、金融、操作系统组件
- 函数覆盖率：98% ~ 100%
- 行覆盖率：90% ~ 95%
- 分支覆盖率：85% ~ 90%
4. 极致要求（安全关键代码、航空/军工/高等级车规 ASIL-D）
- 函数/行覆盖率：100%
- 分支覆盖率：≥90%，关键分支 100%
三、不同代码类型 差异化要求（实战落地）
1. 核心业务/底层库/公共组件（严格要求）
执行合格~优秀标准，不允许大面积低覆盖。
2. 入口层、胶水代码、简单封装、配置类代码
这类代码逻辑简单、分支少：
- 行/函数尽量 95%+
- 分支一般轻松 85%+
3. 异常分支、错误处理、边界条件（难点）
很多项目卡在这里：
- 正常分支：要求 100%
- 极端异常（内存失败、网络断连、硬件报错）：可放宽 60%~70% ，但必须人工评审，不能直接放任。
4. 测试代码、工具脚本、废弃代码
不计入主覆盖率统计，单独排除，不参与门禁考核。
四、实战补充规则（避坑）
-
不要盲目追求 100% 覆盖率
强行冲100%会写出大量无意义用例，维护成本暴增。行业共识：90%行覆盖、85%分支覆盖已是高质量。
-
分支覆盖率 > 行覆盖率 更重要
多行代码顺序执行，行覆盖很容易达标；分支漏测才是bug重灾区，门禁优先卡分支。
-
允许白名单豁免
硬编码、平台兼容宏、永远走不到的兜底
default、终止类代码（exit/abort），可单独配置豁免，不计入统计。 -
门禁配置建议（CI/CD 直接抄）
- 红线（阻断提交）：行<80% 或 分支<70%
- 告警（提醒优化）：行<85% 或 分支<75%
总结速查表
| 等级 | 函数覆盖率 | 行覆盖率 | 分支覆盖率 | 适用场景 |
|---|---|---|---|---|
| 底线(门禁) | ≥90% | ≥80% | ≥70% | 所有正式代码最低要求 |
| 合格(推荐) | ≥95% | 85%~90% | 75%~80% | 常规业务、客户端、后端 |
| 优秀(核心) | 98%~100% | 90%~95% | 85%~90% | 底层库、核心模块、车载/金融 |
| 极致(高安全) | 100% | 100% | ≥90% | 车规ASIL、工控、安全关键代码 |