SonarQube 质量指标是什么
SonarQube 把问题归入可靠性、安全性、可维护性三个维度，严重级别从 Blocker 到 Info。它配套质量门与「新代码」口径：门禁通常只对新增代码设阈值，存量问题看趋势。界面上的 A 到 E 评级是问题密度（技术债比率、覆盖率、重复率等）换算出的档位，说明的是相对状况，不是绝对质量结论。
基本信息
| 维度 | Reliability / Security / Maintainability |
|---|---|
| 严重级别 | Blocker / Critical / Major / Minor / Info |
| 评级 | A 到 E，由问题密度换算 |
| 新代码口径 | New Code，例如近 30 天或上一版本 |
| 门禁 | Quality Gate，通过或失败两种结果 |
典型使用场景
- 版本发布前确认质量门是否通过
- 周会只看新代码的新增问题数，而不是总问题数
- 多项目横向对比时，注意技术栈与代码量差异带来的影响
- 把安全热点审查纳入发布前检查清单
- 用评级变化判断长期趋势，而不是单次快照
质量门示例
质量门示例
Quality Gate（新代码口径）:
- 覆盖率 >= 80%
- 重复率 <= 3%
- 新增 Blocker / Critical = 0
- 安全热点审查完成 100%维度与典型判据
| 维度 | 关注点 | 典型判据 |
|---|---|---|
| Reliability | 缺陷与异常处理 | 新增 Blocker 与 Critical 数量 |
| Security | 漏洞与安全热点 | 安全热点审查完成率 |
| Maintainability | 坏味道与复杂结构 | 技术债比率、重复率 |
| Coverage | 测试覆盖情况 | 新代码覆盖率 |
看指标的顺序
- 先看门禁状态：通过还是失败，失败原因落在哪个维度
- 再看新代码指标：新增问题数与新代码覆盖率
- 随后看整体趋势：评级与技术债比率的变化方向
- 横向对比同类项目前，先确认语言、代码量与团队规模是否可比
门禁的重点放在新代码上：存量负债一次性清零不现实，把阈值压在本次改动上，指标才会持续改善而不是越滚越大。
直接套用默认质量门：项目历史负债与团队节奏各不相同，阈值需要结合实际情况校准，否则门禁要么形同虚设、要么长期失败被人无视。