简历上写着「会用 Jenkins 跑自动化」，面试官只问了一句：「你们那条流水线，从开发提交代码到测试报告出来，中间经过哪几层？每层在干什么？」

你脑子里浮现的是那个熟悉的页面：点一下「立即构建」，左边开始滚日志，几分钟后跳出一个绿色对勾，或者一片刺眼的红。可这句问话要怎么回答？你张了张嘴，发现自己描述不出任何东西——因为你一直是在别人搭好的平台上点按钮，从来没人跟你讲过按钮后面那副骨架长什么样。

这不是知识量的问题，是视角的问题。企业级测试平台看起来庞杂：Jenkins、GitLab CI、GitHub Actions、自研调度台、容器集群、报告中心、通知机器人……但从一个新人的视角拆开，一条流水线其实只有五层。看懂这五层，你就能把「我会点按钮」升级成「我知道这套东西是怎么被组织起来的」，而这恰恰是面试里区分新人与入行半年的人的那道线。

一、先给结论：五层，以及每层在解决什么问题
一条测试 CI 流水线，本质是把「代码变了」这件事，自动翻译成「这次变更的质量结论」，并且让结论能被看见、被拦住、被追溯。这中间固定要经过五件事：

触发层解决「什么时候跑」。开发 push 代码、提合并请求、定时到点、有人手工点一下，这些事件通过 webhook 或调度器进入平台。没有这一层，测试永远是「想起来才跑一次」。

准备层解决「在什么环境里跑」。拉代码、装依赖、起数据库和容器、准备配置、造测试数据。这一层最脏最累，也最容易出问题：本地能跑、CI 上跑不起来，九成原因都在这里。

执行层解决「跑什么、按什么顺序跑」。单元测试先跑，接口测试跟上，UI 测试压轴；能并行的并行，不能并行的排队。顺序本身就是策略——先跑便宜且快的，把明显的问题挡在前面。

结果层解决「跑完留下了什么」。测试报告、失败用例的日志与截图、覆盖率数据、耗时统计。这一层决定了你能不能复盘，也决定了别人愿不愿意相信你的绿灯。

门禁与反馈层解决「结论有没有用」。报告不达标就卡住合并，失败了通知到具体的人，问题单自动归档到缺陷系统。这一层是流水线从「跑一遍」变成「有约束力」的关键。

二、五层对照：新人该把力气花在哪
把五层摊开对照着看，你会发现它们的「新人优先级」并不一样——面试最容易被追问的那层，往往不是你以为最重要的那层。

层次
它在解决什么
新人优先级
面试高频问法
触发层
什么事件让流水线跑起来，push、合并请求、定时还是手工
中：知道有哪几种触发方式即可
「你们流水线是每次提交都跑，还是合并前才跑？为什么？」
准备层
代码、依赖、环境、容器、测试数据是否就绪
最高：新人踩坑最多、也最能讲出细节
「CI 上跑失败但本地是好的，你怎么排查？」
执行层
跑哪些测试、分几层跑、怎么并行与重试
高：要能讲清分层顺序的道理
「为什么单元测试跑完才跑接口，接口跑完才跑 UI？」
结果层
报告、日志、截图、覆盖率怎么收集与保留
最高：绿灯红灯都得有依据
「你们怎么定义一次流水线的通过标准？」
门禁与反馈层
卡不卡合并、通知谁、失败怎么归档
中：知道存在与价值，能说出一次真实经历更好
「测试挂了，开发还是会合并，你们怎么办？」
这张表最值得记住的一点是：新人容易把注意力全放在执行层，因为那是唯一「看得见在动」的一层；但面试官的问题几乎都落在准备层和结果层，因为那两层才暴露你是不是真的维护过一条流水线。能把「依赖装不上怎么定位」「报告没生成怎么补」讲清楚的新人，比能把测试框架 API 背一遍的新人值钱得多。

三、为什么顺序是先窄后宽：执行层的分层逻辑
执行层里那个「单元 → 接口 → UI」的顺序，不是习惯，是成本计算。

单元测试跑得快、定位准，失败基本就是那个函数的问题；接口测试慢一些，失败可能是服务、可能是数据、可能是配置；UI 测试最慢最脆，一次失败你可能得看截图、看网络包、看渲染时机才能判断到底是不是真缺陷。所以流水线的通行做法是：便宜的先跑，贵的后跑，前面挂了后面直接不跑或者标记跳过。这样一次失败的平均定位时间最短，机器时间也省得最多。

并行也是同一个道理。同一个仓库里三个互不依赖的模块，可以开三个 job 同时跑；但涉及同一份测试数据的用例必须串行，否则互相踩脏数据，红灯就变得没有意义。新人最容易犯的错是「一上来全并行」，跑得是快了，可失败原因从「代码有问题」变成了「数据被别人改了」，排查成本反而更高。

四、动手练：用 GitHub Actions 搭一条最小可跑流水线
看懂不算懂，跑通才算。下面这份 workflow 是最小但完整的三层实现（准备 → 执行 → 结果），你把它放进自己任意一个小项目的 .github/workflows/ 目录，push 上去就能在 Actions 页面看到它跑起来。项目里需要有一个 requirements.txt，写上 pytest 和 pytest-html 两行即可；测试文件放在 tests/ 目录下，哪怕只有一个 test_demo.py 里写一条 assert 1 + 1 == 2，也足够让整条流水线跑通。

文件：.github/workflows/test.yml

作用：一条最小但完整的三层流水线（准备 → 执行 → 结果）

使用：把本文件放进仓库的 .github/workflows/ 目录，push 到 main 分支即自动触发

name:pytest-minimal-pipeline

on:
push:
branches:[main]
pull_request:
branches:[main]
workflow_dispatch: # 保留一个手工触发入口，方便随时点一下验证

jobs:
test:
runs-on:ubuntu-latest
steps:

  # ===== 准备层：把代码、运行时、依赖、数据都弄就绪 =====
  -name:checkout拉取代码
    uses:actions/checkout@v4

  -name:setup-python装运行时（带pip缓存）
    uses:actions/setup-python@v5
    with:
      python-version:"3.11"
      cache:pip            # 命中缓存时依赖安装能快很多

  -name:安装依赖
    run:|
      python -m pip install --upgrade pip
      pip install -r requirements.txt

  -name:准备测试数据（起一个干净的SQLite库文件）
    run:|
      mkdir -p reports
      python -c "import sqlite3; c=sqlite3.connect('test_data.db'); c.execute('CREATE TABLE users(id INTEGER PRIMARY KEY, name TEXT)'); c.execute(\"INSERT INTO users(name) VALUES('tester01')\"); c.commit(); print('test data ready')"

  # ===== 执行层：跑用例并生成两种报告 =====
  -name:执行pytest
    run:|
      pytest tests/ -v \
        --junitxml=reports/report.xml \
        --html=reports/report.html --self-contained-html
    continue-on-error:true   # 用例失败不要中断流水线，先把报告收上来

  # ===== 结果层：无论成功失败都归档报告 =====
  -name:上传测试报告artifact
    if:always()
    uses:actions/upload-artifact@v4
    with:
      name:pytest-report
      path:reports/
      retention-days:7

五、这段 YAML 为什么这么写，我踩过哪些坑
先说三个关键设计。第一，执行那一步加了 continue-on-error: true：pytest 有用例失败时会返回非零退出码，GitHub Actions 默认会立刻中断整个 job，后面的上传步骤就不跑了——你会得到一个「失败了但什么报告都没有」的结果，这是最难排查的一种失败。让它继续跑，报告才能落地。第二，上传那一步写了 if: always()，双保险，确保无论前面成败都归档。第三，用了 workflow_dispatch，因为新人调试流水线时最需要的是「不改代码也能再跑一次」，否则每验证一个小改动都得造一次无意义的 commit。

再说三个我真实踩过的坑。一是路径坑：--junitxml=reports/report.xml 里的 reports/ 目录必须先存在，pytest 不会替你建目录，第一次跑就报了一个和测试完全无关的文件写入错误，日志里翻半天才看到根因，所以上面专门有一步 mkdir -p reports。二是依赖坑：本地 Python 3.13、CI 上 3.11，某个库的新语法直接报错，从此我把 python-version 写成和团队一致的固定值，绝不用 latest。三是数据坑：一开始我把测试数据写在用例里现造，多条用例共用一个库文件，并行跑的时候互相删对方的行，红灯一片却查不出代码问题；后来固定成「准备层统一造数据、每条用例只读不写自己那份」，流水线才稳定下来。这三个坑分别对应准备层和结果层，也正是面试官最爱追问的地方——你把它们讲出来，比你背十个框架名词都有说服力。

六、把这条流水线讲成一段面试回答
练完之后，你可以把五层压成一段一分钟能说清的话：「我们那条流水线是合并请求触发的，准备层用容器把依赖和测试数据库拉起来，执行层按单元、接口、UI 三层跑，前两层并行、UI 串行，结果层出 junit 报告加失败截图，覆盖率低于阈值会卡住合并，失败会直接通知到提交人。」

这段话之所以有分量，不是因为词多，而是因为它同时证明了三件事：你知道流水线是被什么事件驱动的，你知道每层的产出是什么，你知道这套东西对团队有约束力。面试官接下来大概率会追问某一层，比如「覆盖率阈值怎么定的」「失败通知发给谁」——这时候你已经从被考的人，变成了在讨论的人。

跑通之后别停。你可以按同一条思路把它慢慢长成完整的五层：给执行层加一个覆盖率参数，让结果层多产出一份覆盖率数据；再加一个判断步骤，覆盖率低于自己定的线就让 job 失败，这就是最小版的门禁；最后接一个通知，失败了往自己的群里发一条消息。每加一层，你对这一层的理解就实一分，面试里也多一段「我自己动手做过」的经历可讲。

看懂平台的骨架，比记住平台上有哪些按钮重要得多。

新人最该补的不是「会用哪个工具」，而是能不能把一条流水线拆成触发、准备、执行、结果、门禁五层，并说清每层在替团队解决什么问题。

你第一次在 CI 上跑出红灯时，是先看报告，还是先改代码重跑一遍？评论区聊聊。