CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
软件测试入门/课时/CI 中的测试
RawBlame
课时目录12 节

软件测试入门

  1. 01测试金字塔
  2. 02JUnit 5 基础
  3. 03Mockito 与 Mock
  4. 04Spring Boot 测试
  5. 05MockMvc 接口测试
  6. 06集成测试
  7. 07TDD 与可维护性
  8. 08前端单元测试
  9. 09E2E 与 Playwright
  10. 10覆盖率与质量门禁
  11. 11CI 中的测试
  12. 12综合练习

CI 中的测试

GitHub Actions mvn test、并行策略。

30 分钟

CI 中的测试

这一课你将能做到

  1. 读懂并标注本站 .github/workflows/ci.yml 里 backend / platform 两个 job 的测试命令与顺序
  2. 说清 mvn test 与 mvn verify 的差异,并让本地习惯与 CI 严格对齐
  3. 解释并行 job、concurrency 取消旧 run、失败阻断合并的工程含义,并画出走测试分轨的草图

为什么要学

个人笔记本上的绿测挡不住两件事:「我忘了跑」和「我机器有特殊配置」。持续集成(CI) 在每次 push / PR 时用干净环境自动跑测试——失败即红,阻止未验证代码进入主线。人话:CI 是团队共享的红绿灯,它比同事更不讲面子,也比你本地环境更干净。

CodeForge 的 ci.yml 是现成范本:backend 跑 mvn -B verify,platform 跑 npm test + npm run build。学完本课,你应能在 PR 页 30 秒内定位红灯来源,并知道「为什么我的测试要这么挂」。写测试的手法在前 10 课;本课讲测试如何成为工程纪律。

没有 CI 时,测试停留在「有纪律的人偶尔跑」;有 CI 后,测试成为默认路径。金字塔策略也在这里落地:CI 里快测必跑,慢测按频率分轨,避免红绿灯变成永远排队的黄灯。

先建立图像

push / PR
    │
    ├─► job backend:  setup-java → mvn -B verify
    └─► job platform: npm ci → npm test → npm run build
              ▲
      两者并行;总时长 ≈ max(两者),不是相加

concurrency:同一分支新 push 取消旧 run(省分钟)
命令含义
mvn test跑 Surefire 快测(*Test)
mvn verifytest + 打包 / JaCoCo report / Failsafe IT 等后续阶段
npm test前端单元 / 组件测
npm run build编译打包,放测试后以免白跑

任一 job 失败,PR 不应合并。Checks 是「合并前的最后读者」。

跟着做

步骤 1:打开并标注 ci.yml

一份与 CodeForge 结构一致的带注释样例(细节以仓库真实文件为准):

name: ci
on:
  push:
    branches: [main]
  pull_request:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true    # 连续 push 只跑最新

jobs:
  backend:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "17"       # 与生产一致
          cache: maven             # 依赖缓存,省下载分钟
      - name: 测试与打包
        run: mvn -B verify
        working-directory: backend
      - name: 上传测试报告
        if: always()               # 红了也要能看报告
        uses: actions/upload-artifact@v4
        with:
          name: surefire-reports
          path: backend/target/surefire-reports/

  platform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: npm
          cache-dependency-path: platform/package-lock.json
      - run: npm ci                # 锁文件为准,比 npm install 可复现
        working-directory: platform
      - run: npm test
        working-directory: platform
      - run: npm run build         # 测试绿了才值得打包
        working-directory: platform

在笔记里标出:两个 job 的 working-directory、JDK/Node 版本、缓存配置、实际测试命令。

步骤 2:本地对齐 backend

cd backend
mvn test          # 日常快反馈
mvn -B verify     # 提交前对齐 CI(含 JaCoCo report / IT)

记下两者耗时差。-B 是 batch 模式,日志干净适合机器读。若 verify 比你预期的慢,看是哪个插件阶段(打包 / IT / 报告)——这是第 6、10 课分轨知识的用武之地。

步骤 3:本地对齐 platform

cd platform
npm ci
npm test
npm run build

顺序与 workflow 一致。npm ci 严格按 package-lock.json 安装——「我这能过」与 CI 的差异多半藏在依赖版本里。

步骤 4:理解并行与 concurrency

时间轴 ─────────────────────────────────►
backend  ████████████
platform ████████████████
总等待 ≈ 较长的那条,而不是相加

cancel-in-progress 的含义:同一 PR 连续 push 三个 commit,前两个 run 被取消,只跑最新的。人话:最新提交说了算,旧结果没有意义,排队分钟全是浪费。

步骤 5:读一次红灯的正确姿势

当 Checks 变红:

  1. 点开失败的 job(backend 还是 platform?失败归属先分家)
  2. 展开失败的 step(mvn -B verify 还是 npm test?)
  3. 搜索第一个 FAILURE / AssertionError / FAIL
  4. 记下:类名、方法名、期望 vs 实际
  5. 本地复现:mvn test -Dtest=那个类#那个方法

CI 日志很长,但导航仪只在「第一处失败」。修那一处再重跑,比从末尾汇总倒推快得多。有意在自己分支制造一次红灯并走完这个流程(别合进 main),比读十遍文章记得牢。

步骤 6:为慢测画分轨草图

频率放什么例子
每个 PR快测*ServiceTest、Vitest、lint
主分支 / 每日中速Testcontainers IT(*IT)、全上下文测
发布前慢测Playwright 冒烟 3~5 条

今天的 ci.yml 可能还没拆这么细——草图的价值是:你以后每加一种测试,都知道该挂哪个档位,而不是一股脑塞进 PR job 拖垮所有人。

讲清楚要点

  1. 环境必须干净可复现:CI 固定 JDK/Node 版本 + 锁文件 + 依赖缓存——「我这能过」往往就差在版本号上。
  2. 分钟数是钱也是反馈:job 并行、失败早停、concurrency 取消旧 run——流水线体验本身就是产品。
  3. 本地与 CI 命令一致是纪律:提交前跑同一条 mvn -B verify / npm test,消灭幽灵红灯。
  4. 红灯必须修到绿才能合并:跳过检查需要强理由与权限约束,否则主线质量只靠自觉。
  5. 双端拆 job 而不是一个大 job:backend 红、platform 绿,一眼看清失败归属。
  6. 不是所有测试都挡每次 push:IT / E2E 分频运行,快测守门、慢测巡逻。

你可能会懵的地方

  • mvn test 绿、verify 红? verify 还跑了打包、JaCoCo check、Failsafe IT 等阶段。读失败的是哪个插件,不要只盯 Surefire 的测试结果。

  • CI 偶发怪红是缓存坏了吗? 可能但少见。先重跑一次 workflow;反复红就不是玄学,去修锁文件与版本固定,而不是无限重跑碰运气。

  • fork PR 为什么没有秘密变量? 安全限制,属预期行为。E2E 若需要密钥,用 OIDC 或标签触发的设计,别把密钥塞给任意 PR。

  • concurrency 的 group 为什么带 ref? github.workflow-ref/ref 组合让不同分支互不取消,只有同一分支的连续 push 互相替代——取消范围精确到「过时的自己」。

  • CI 会帮我发现「没写的测试」吗? 不会。CI 只强制执行已有测试;「该测什么」靠金字塔分层与覆盖率导航(第 10 课),两者配合才是完整闭环。

错法对照

错法问题正解
本地从不跑测只靠 CI反馈慢、烧分钟先本地 mvn test / npm test
本地命令与 workflow 不一致幽灵红 / 假绿对齐 verify 与 scripts
红灯强行 merge主线腐烂修到绿,例外走审批
所有慢测塞进每个 PR队列爆炸分轨:PR / 主分支 / 发布前
只读日志末尾汇总被噪声带偏先读第一个失败堆栈

卡点急救

  1. CI 上 mvn -B verify 找不到 pom:根目录没有聚合 pom 时,必须 working-directory: backend 或 --file backend/pom.xml;本地能跑是因为你 cd 过去了。
  2. 平台 job 报 node 版本不匹配:workflow 的 node-version 与本地 .nvmrc/ engines 对齐;依赖 npm ci 而非 npm install,避免锁文件漂移。
  3. 测试报告没上传:upload-artifact 少了 if: always()——失败时 job 中断,后面的 step 不执行,红跑一场却拿不到现场。

面试常问

  • 为什么 CI 里用 mvn verify 而不是只 mvn test? verify 覆盖 test 之外的生命周期阶段:打包验证、JaCoCo 报告与 check 门禁、Failsafe 跑 *IT 集成测。只跑 test 会让「门禁与慢测」形同虚设——本地 test 图快,提交前与 CI 的 verify 对齐是纪律。

  • PR 流水线太慢,你怎么优化? 四招:job 并行(总时长取 max);依赖缓存(setup-java cache: maven、setup-node cache: npm);concurrency 取消过时 run;慢测分轨(IT/E2E 挪到主分支或 nightly)。本质是把「每个 push 都全量」改成「分级验证」。

  • CI 红灯时的标准处理流程? 定位 job → 定位 step → 读第一个失败堆栈 → 本地用 -Dtest=类#方法 复现 → 修复 → 重跑确认绿。禁止两个动作:跳过检查合并、无限重跑碰运气。

自测三问

  1. 本站 backend job 为什么用 mvn -B verify 而不是只 test?
  2. backend 与 platform 并行时总时长怎么估算?串行又会怎样?
  3. cancel-in-progress 对连续 push 的同一 PR 有什么好处?

小结一句话

CI = 团队共享的 mvn verify + npm test;绿测才能安心合并,测试从个人习惯升级为工程纪律。

延伸

  • GitHub Actions · Workflows 文档
  • Maven 生命周期
  • 下一课:test-practice 综合练习——把整条 track 的手法串成一次可交付、CI 可验证的完整闭环。
加载本节练习…
← 上一课覆盖率与质量门禁下一课 →综合练习