📚 课程目录第4章静态分析工具链选型与部署

4. 静态分析工具链选型与部署

航空软件静态分析不是“装一个工具跑一遍”就结束的工作。它需要把工具能力、鉴定证据、构建流程和许可资源放在同一张工程图上考虑。Polyspace、Coverity、LDRA Testbed、Helix QAC 这几类工具在航空项目中都常见，但它们的强项并不相同：有的偏重抽象解释与运行时错误证明，有的偏重缺陷模式匹配与大规模代码库扫描，有的偏重编码规则符合性检查，有的则把规则检查、覆盖率与需求追溯放在同一套工具链里。选型时如果只看“能不能查 MISRA”，很容易在项目后期发现证据链不完整或 CI 集成成本过高。

先看能力对比。Polyspace 的核心是抽象解释，它不依赖测试用例，而是对变量取值范围、指针指向、数组边界做静态推演，因此适合证明“不会发生除零、越界、溢出”这类运行时错误。Coverity 以数据流和缺陷模式见长，适合在大型 C/C++ 代码库中快速定位空指针解引用、资源泄漏、未初始化变量等缺陷，扫描速度快，适合增量集成。LDRA Testbed 和 Helix QAC 更贴近 DO-178C 的编码标准符合性检查，规则库覆盖 MISRA C/C++、CERT 等，能输出规则违例、代码度量和追溯矩阵。实际项目中，常见组合是“Helix QAC 或 LDRA 做规则门禁，Polyspace 做运行时错误证明，Coverity 做缺陷扫描”，三者互补而不是互相替代。

工具鉴定是航空项目区别于普通软件项目的关键环节。DO-178C 把工具分为两类：如果工具的输出被直接用于替代或减少某种验证活动，且该工具可能引入错误而不被后续检查发现，就属于“鉴定工具”，需要提供工具鉴定证据。例如，用 Polyspace 证明“无运行时错误”来替代部分动态测试，就必须做工具鉴定；而如果只是用 Helix QAC 辅助人工审查 MISRA 违例，最终仍由人工确认，则通常按“非鉴定工具”处理，但需保留工具配置和规则集版本。鉴定证据一般包括工具操作需求、工具鉴定计划、工具鉴定说明和工具鉴定总结，核心是证明工具在特定配置下不会引入未被检测的错误。

在 CI/CD 中集成时，关键不是把工具命令塞进流水线，而是让分析结果可判定、可追溯。以 GitLab CI 为例，可以在构建阶段生成编译数据库，再并行触发多个分析作业：

stages:
  - build
  - static_analysis
  - quality_gate

build:
  stage: build
  script:
    - cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -B build
    - cp build/compile_commands.json .
  artifacts:
    paths:
      - compile_commands.json

qac_analysis:
  stage: static_analysis
  script:
    - qacli analyze -P . -j compile_commands.json --ruleset MISRA_C_2012
    - qacli report -P . --format html --output qac_report.html
  artifacts:
    paths:
      - qac_report.html

polyspace_analysis:
  stage: static_analysis
  script:
    - polyspace-bug-finder -compile-commands compile_commands.json -results-dir ps_results
  artifacts:
    paths:
      - ps_results/

quality_gate:
  stage: quality_gate
  script:
    - python3 check_violations.py --qac qac_report.html --threshold 0

这段配置里，compile_commands.json 是多个工具共享的输入，避免每个工具各自解析构建系统。check_violations.py 是自定义门禁脚本，读取 QAC 报告中的违例数量，若超过阈值则返回非零退出码，流水线自动阻断合并。阈值设定要结合项目阶段：新项目初期可允许少量低风险违例，但必须记录偏差和整改计划；安全关键模块应设为 0 容忍。Polyspace 的结果通常以 .ps_results 目录形式归档，便于后续审查时回溯到具体版本。

许可管理常被低估。Polyspace 和 Coverity 多采用浮动许可，CI 中并发触发多个分析作业时，如果许可数不足，作业会排队甚至失败。建议在流水线中设置分析作业的并发上限，或把全量分析放在夜间定时任务，增量分析放在合并请求阶段。Helix QAC 的许可通常按分析节点或用户数计费，LDRA 则可能按模块或项目授权。无论哪种模式，都应在工具鉴定计划中记录许可类型、版本号和到期时间，避免因许可变更导致分析结果不可复现。

选型时建议先做一次“能力矩阵验证”：用同一份含已知缺陷的示例代码分别跑四个工具，记录每个工具发现的缺陷类型、误报率、扫描耗时和报告格式。这份记录既是选型依据，也是后续工具鉴定的输入材料。

最后要强调的是，工具链部署不是一次性任务。规则集版本、工具版本、编译器版本和许可配置都会影响分析结果。建议把工具版本和规则集写入配置管理，每次升级都重新执行一次基线分析，对比违例数量变化，确认没有引入新的误报或漏报。只有把工具、流程、证据和资源放在同一套受控配置下，静态分析才能真正支撑航空软件的适航符合性。