6.3 测试自动化与静态分析：检测线与巡检仪

6.3 测试自动化与静态分析：检测线与巡检仪

流水线跑起来了，本节给它装判定器官：测试自动化是检测线——让机器在夜里把整车重跑一遍；静态分析是巡检仪——不用启动车辆，扫一眼图纸就报隐患。两者合起来，把第 3.4 节的试跑活动自动化成流水线的自动判定。本节讲什么值得自动化、覆盖率怎么读才不骗人、静态报警怎么治理不沦为噪音。

让机器上夜班

自动化测试的取舍原则只有一条：把重复执行的验证交给机器，把需要判断的留给人工。适合自动化的用例有共同特征——判定标准明确、需要反复回归、环境可复制。适合人做的同样明确：探索性测试、易用性体验、一次性的验证。云梯的自动化台账：

图 6-2：云梯检测线的站点布局

一个值得抄的单元测试写法——测试名即规格说明：

单元测试示例 · 运费分摊（伪代码风格）
  用例名：均摊三仓时各仓合计等于总额
  准备：总额 100.00 元，货量 [1, 1, 1]
  动作：调用分摊函数
  断言：三仓结果之和 === 100.00
       每仓结果保留两位小数

  用例名：货量为零的仓库不分摊也不报错
  准备：总额 90.00 元，货量 [1, 0, 2]
  动作：调用分摊函数
  断言：零货仓得 0.00，其余两仓合计 90.00

覆盖率会话（提交触发的流水线输出）：
  模块          语句覆盖率   分支覆盖率
  计费分摊        92%          85%
  规则解析        88%          71%   ← 分支覆盖偏低，提示条件组合漏测
  司机端接口      76%          60%   ← 新模块，列入下迭代补测计划
​

注意看分支覆盖率那一列：语句覆盖率八成八看着体面，分支七成一才暴露真相——某个条件组合从未被测过。覆盖率只读语句那一列，等于只数车厢不看装载。

覆盖率的正确读法

覆盖率是体检指标里的"体温"：太低说明肯定有问题，正常不代表没病。三条读数纪律：看趋势不看绝对值——从六成滑向五成五是警报，从八成爬到八成五是健康；看关键模块的下限——计费引擎这类高危模块单设底线，界面外壳可以宽；防造假——为凑覆盖率的空测试（只跑不判）一经发现按无效用例清退，因为它污染的是整个指标的可信度。

静态分析：不点火就能做的巡检

静态分析不运行代码，直接检查源码与依赖：命名与风格（交给机器后，走查会上再也没人为缩进吵架）、可疑模式（空捕获、资源未关闭、超长函数）、安全漏洞（注入风险、硬编码密钥）、依赖里的已知漏洞。它的价值在把最低级的发现从人工评审里清出去，让人只看机器看不懂的问题。

报警治理决定它的生死。三级处置法：

⚠️ 静态工具上线的正确姿势是存量冻结、增量收紧：存量报警一次性定级（修、白名单），之后新代码零容忍。反过来"先全量打开再说"，第一天几百条报警会教会所有人关掉它。

不稳定用例：检测线的幽灵报警

自动化用例有自己的病：不稳定用例（同样的代码时过时不过）是检测线的幽灵报警——它让"红灯"这个信号慢慢贬值，直到真红灯也没人抬头。云梯的治理办法是把不稳定用例当缺陷对待：发现即标记隔离区（不再参与判定，但仍定期重跑观察），三天内定位原因——时序依赖、测试数据残留、环境抖动是三大惯犯——修不好就果断删除，宁可覆盖降一格，不让报警信用破产。配套一条指标：不稳定用例占比，超过百分之二触发专项清理。检测线的公信力是稀缺资产，值得为它设立专门的保养工位。

静态规则的一次调优实录

静态分析的规则集要随团队成长持续调优，看一次云梯的真实调优：最初全量开启默认规则集，报警里四成是命名风格（已被格式化工具覆盖，纯噪音）、三成是"函数过长"（阈值设得比团队现实激进得多）。团队的反应可以预见——把工具静音。调优动作分三步：与格式化工具重叠的规则全部下线（机器不做重复功）；"函数过长"阈值从行业默认值放宽到团队现状的九成位，并约定每季度收紧一格；把最近半年缺陷榜上真实出现过的模式（空捕获、并发容器误用）提升到阻断级。调优后报警总量降了六成，阻断级报警的处理率从四成升到基本清零——规则集配得上团队现状，团队才配得上工具的报警。

自动化的投入排序：先把哪一段搬上机器

检测线的建设有先后，排序错了会做无用功。判据还是老三样——重复频率、判定明确度、故障代价。按这三样给常见验证排个序：单元测试排第一（每天几十次、判定完全明确、失败代价低但累计代价高）；核心链路的接口回归第二（每次发版必跑、金额路径的判定明确）；端到端场景第三（少而精，只守主干旅程）；性能压测第四（发版前与重大变更后）；至于界面细节的像素级校验，投入产出比常年垫底，交给人工抽查更划算。云梯按这个顺序建设检测线，每一步都立刻兑现了"人从重复中解放"的红利——自动化最怕的从来不是做得慢，是把劲用在了第十年才会复发的验证上。

两个高频疑问

问：覆盖率提不上去，是不是没救了？ 先问覆盖率该在哪些模块上高。均匀拉高覆盖率是常见的徒劳——界面外壳与生成代码堆到九成没有意义。换打法：给计费、账务这类高危模块单设底线（云梯设的是分支覆盖八成），外围模块只要求"有且核心路径有断言"。资源聚焦到刀刃上，覆盖率才变成风险语言而非绩效语言。

问：检测工具选型纠结怎么办？ 工具差异远小于团队习惯差异。选型的三条实在标准：能接进现有流水线（集成成本低于切换收益）、报警格式团队读得懂、社区活跃度保证问题有答案。用不顺手的工具跑起来的团队，好过反复选型观望的团队——工具的收益从使用第一天就开始积累，选型焦虑的利息却在天天计提。

本节要点回顾

• 自动化取舍判据：判定明确、反复执行、环境可复制的交给机器；判断力活留给人。
• 测试名即规格，断言先写边界与守恒；分支覆盖率比语句覆盖率诚实。
• 覆盖率看趋势、设模块下限、清退凑数空测试；它是体温计不是健康证。
• 静态分析把最低级发现清出人工评审；报警三级处置，存量冻结、增量收紧。
• 端到端用例控制在数十条量级，数量失控的检测线先堵死自己。

机务段三件装备到齐。最后一章看列车本身的进化——微服务、云原生与全程安保。