09 CI/CD、质量平台与精准测试

测开进阶的分水岭，通常在脚本之外：能不能把质量能力沉淀进团队流程。

为什么重要

会写自动化脚本的人很多，能让自动化「在团队里持续产生价值」的人少。区别就在于工程化：脚本接进流水线，失败有人看、问题能定位、报告能聚合、数据能驱动决策。这一章就是从 L2 到 L3 的跨越（能力分层见第 01 章）。

知识清单

CI/CD 集成【必须掌握】

把质量检查接进代码流水线，是第一步：

• 流水线分层：
  • 提交级：lint、单元测试、静态安全扫描（快，分钟级）。
  • 合并级：接口自动化冒烟集、契约检查。
  • 每日级：全量接口回归 + UI 冒烟 + 报告归档。
  • 发布级：部署后冒烟（发布完自动验证核心链路）。
• 失败处理机制：失败通知（IM 机器人）、失败归因入口（日志、截图、请求响应链接）、负责人机制。
• 工具：GitHub Actions / GitLab CI / Jenkins 至少深入一个，理解触发器、并行矩阵、缓存、产物上传（报告）、密钥管理。

测试平台【必须掌握（思路 + 至少做过简化版）】

一个简单的平台也可以很有价值，核心模块：

• 用例管理：维护接口、场景、优先级、标签、执行状态（很多团队用 TestRail / PingCode / 禅道，理解其数据模型即可）。
• 自动化调度：按项目、分支、环境、标签触发测试（Jenkins Job / 定时任务 / API 触发）。
• 报告聚合：展示通过率、失败原因分类、历史趋势——「昨天 92%、今天 87%，掉了 5 个点，全是支付模块」这种趋势信息是平台的灵魂。
• 测试数据管理：准备账号、订单、库存、审批流等数据（造数平台概念）。
• 缺陷联动：失败用例自动关联缺陷单或通知负责人。

不必一上来就写平台。先用「pytest + Allure + Jenkins Job + 企业微信/钉钉机器人通知」拼出一条简化链路，平台化是这条链路的自然演进。

覆盖率【必须掌握】

• Java 用 JaCoCo，Python 用 Coverage.py。
• 能统计：自动化用例覆盖了哪些代码行、分支和方法。
• 能解读：行覆盖率 60% 意味着什么、不意味着什么（覆盖了 ≠ 验证了）。
• 落地：把覆盖率接入 CI，生成增量覆盖率（新代码覆盖率），推动「新代码必须有自动化覆盖」的团队规范。

精准测试【必须掌握（概念）/ 了解即可（实现）】

覆盖率告诉你「测到了哪里」，精准测试回答「这次改动该跑哪些用例」：

• 思路：结合代码变更范围（diff）、调用链分析、历史失败记录，筛选出最可能发现问题的用例子集，代替全量回归。
• 入门实现：变更文件 → 关联模块标签 → 跑该模块用例（用第 07 章的用例标签思路就能做简化版）。
• 精准测试对校招生不是硬要求，但它很适合作为进阶项目。相比「我写了一个接口自动化框架」，能说清「我根据代码覆盖率和变更文件筛选回归用例」，技术含量高不少。

质量度量【必须掌握（指标设计）】

能设计一套团队质量指标并解释其局限：

• 过程指标：自动化覆盖率、用例执行率、缺陷收敛趋势。
• 结果指标：线上缺陷密度、漏测率（线上 bug 中测试阶段应发现的比例）、平均故障恢复时间（MTTR）。
• 效率指标：回归时长、发布频次、人均维护用例数。
• 警惕古德哈特定律：单一指标一旦成为 KPI 就会被优化变形（用例数冲量、断言注水）。度量要成组、要看趋势、要服务于改进而不是考核。

测试左移右移落地【必须掌握】

衔接第 05 章的概念，落到具体动作：

• 左移动作：需求评审 checklist（可测性、日志、开关）、冒烟前置到联调、契约测试（Pact 概念级了解）。
• 右移动作：核心接口线上拨测（定时从外部调真实接口验证可用性）、错误率告警关联自动化用例、线上问题回流成自动化用例（「每个线上 bug 至少沉淀一条自动化用例」是很多团队的铁律）。

学习建议与常见误区

• 从把一个项目接进 CI 开始，不要从「设计测试平台架构图」开始。平台是流程跑通后的沉淀，不是起点。
• 建一条自己的「质量流水线」：GitHub Actions 里跑 lint → 单测 → 接口冒烟，失败发通知，报告上传归档。这条链路做完，你对 CI/CD 的理解就超过大多数人了。
• 误区一：自动化率越高越好。 80% 自动化率但全是弱断言，不如 40% 覆盖核心链路的强断言。汇报「自动化率」的同时必须汇报「自动化发现问题的数量」。
• 误区二：平台做成玩具。 花三个月写了个漂亮的 Web 界面，但没人用。平台价值 = 用它的人 × 它省的时间，先服务自己，再服务团队。
• 误区三：覆盖率数字崇拜。 为了覆盖率写一堆无断言的「触碰式用例」。覆盖率是参考坐标，不是目标本身。
• 误区四：报告只给自己看。 报告的价值在于驱动别人行动（开发看失败原因、Leader 看趋势）。设计报告时先想「谁看、看完做什么」。

自查清单

1. 提交级、合并级、每日级、发布级流水线各跑什么？为什么这么分层？
2. 自动化失败通知里应该包含哪些信息，才能让人不用问你就开始排查？
3. 覆盖率 70% 能说明什么、不能说明什么？
4. 增量覆盖率是什么？怎么用它推动团队规范？
5. 精准测试的核心思路？用「模块标签 + 变更文件」设计一个简化方案。
6. 设计 3 个结果类质量指标，并各说一个它们可能的失真方式。
7. 「每个线上 bug 至少沉淀一条自动化用例」为什么是高性价比实践？
8. 你的测试报告有历史趋势吗？没有的话，加趋势需要哪些数据？

推荐资源

• GitHub Actions 官方文档：流水线入门首选。
• Jenkins 官方文档：企业存量最多的 CI 工具。
• JaCoCo 官方文档：Java 覆盖率标准工具。
• Coverage.py 文档：Python 覆盖率标准工具。
• Allure TestOps / 开源 Trace：报告与用例管理的产品形态参考。
• 搜「字节跳动 / 美团 精准测试」技术博客：中文圈精准测试实践讲得最透的一批文章。
• AI 测试开发导航 · 精选课程：CI/CD 与质量平台建设实战教程。