接口测试接进 CI/CD 后,我们踩过的 5 个坑

Apifox CLI 接进 CI/CD 后最容易踩的 5 个坑:环境数据、用例顺序、凭证、断言、阻塞门禁,附 GitHub Actions 骨架。

用 Apifox,节省研发团队的每一分钟

接口测试接进 CI/CD 后,我们踩过的 5 个坑

免费使用 Apifox

相关推荐

最新文章

API

一体化协作平台

API 设计

API 文档

API 调试

自动化测试

API Mock

API Hub

立即体验 Apifox
目录

用 Apifox 跑的接口测试在本地好好的,一进流水线就红。

这大概是所有把 API 测试接进 CI/CD 的团队都会经历的阶段。我们一开始以为是工具问题,后来发现大部分坑都在“环境、数据、凭证、断言、门禁”这五件事上。

下面按踩坑顺序记录,附上我们后来采用的解法,以及 Apifox CLI 在流水线里的配置方式。

说明:以下为脱敏后的团队实践,流水线以 GitHub Actions 为例,其他 CI 工具思路类似。

坑 1:环境和数据不隔离

现象:同一套测试,在本地通过,在流水线失败;重跑一次又过了。

原因:流水线用的是共享测试环境,数据被其他任务改了。比如:

  • 测试账号被别的用例禁用
  • 订单状态被并发任务改掉
  • 数据库里有上次失败留下的脏数据

做法:

  • 每个流水线用独立的环境变量和测试账号。
  • 测试数据带唯一前缀,例如 ci_${run_id}_。
  • 用例自己造数据、自己清理,不依赖“环境里本来就有的数据”。
  • 对共享环境加锁,或者把写操作集中到专用环境。

坑 2:测试顺序依赖,单独跑就失败

现象:整套跑能过,单独跑某条用例就 401 或 404。

原因:用例之间偷偷共享了变量。比如“登录”用例把 token 写到全局变量,“查询”用例直接拿来用。

做法:

  • 每个测试场景自己完成登录和前置准备。
  • 变量作用域尽量小,不要全局乱写。
  • 用测试场景的“前置步骤”做依赖,而不是靠执行顺序。
  • 在 CI 里单独跑每条核心用例,验证独立性。

坑 3:凭证硬编码,日志里全是 token

现象:流水线日志里能看到完整 token;或者换环境后,token 失效导致全红。

原因:把 token 写进了 YAML、脚本或测试用例。

做法:

  • 凭证放 CI Secrets,不写进代码库。
  • 用环境变量传入,例如:
apifox run \
  --access-token "$APIFOX_ACCESS_TOKEN" \
  -t <测试场景ID> \
  -e <环境ID> \
  -r cli,junit
  • 日志里不要打印 Authorization、Cookie、完整请求体。
  • 不同环境用不同 token,不要一套 token 跑所有环境。
  • 定期轮换 token,离职/转岗及时回收。

坑 4:断言太脆,环境一变就红

现象:接口返回没问题,但断言失败。比如:

  • 断言了完整时间戳
  • 断言了自增 ID
  • 断言了数组顺序
  • 断言了完整错误文案

原因:把“稳定契约”和“不稳定实现”一起断言了。

做法:

  • 只断言契约:状态码、业务 code、关键字段存在、类型正确。
  • 时间、ID、排序用正则/范围/存在性断言。
  • 错误文案断言错误码,不要断言整句话。
  • 对第三方依赖做 mock,不要在 CI 里赌外部服务稳定。
  • 失败时保留请求/响应报文,方便定位。

坑 5:所有测试都设成阻塞门禁

现象:流水线天天红,开发开始习惯性点“忽略”;真正的问题反而没人看。

原因:把不稳定用例、外部依赖用例、长耗时用例全设成阻塞。

做法:

  • 分两层:
  • 阻塞层:核心链路、稳定、快,失败必须修。
  • 观察层:长耗时、外部依赖、实验性用例,失败只告警。
  • 阻塞层控制在 5–10 分钟内跑完。
  • 对 flaky 用例设隔离区,修好再放回阻塞层。
  • 失败信息要能直接定位到接口和断言,不要只给一个“exit code 1”。

一个可用的流水线骨架

name: api-tests

on:
  pull_request:
  push:
    branches: [main]

jobs:
  api-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install Apifox CLI
        run: npm install -g apifox-cli

      - name: Run API tests
        env:
          APIFOX_ACCESS_TOKEN: ${{ secrets.APIFOX_ACCESS_TOKEN }}
        run: |
          apifox run \
            --access-token "$APIFOX_ACCESS_TOKEN" \
            -t ${{ vars.APIFOX_SCENARIO_ID }} \
            -e ${{ vars.APIFOX_ENV_ID }} \
            -r cli,junit

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apifox-report
          path: apifox-reports/

几个细节:

  • -r cli,junit 同时输出终端结果和 JUnit 报告。
  • 报告用 if: always() 上传,失败时也能看。
  • 场景 ID、环境 ID 放仓库变量,不要写死。
  • token 放 Secrets,不要放变量。

接 CI 前的检查清单

  • 测试环境独立,数据可清理
  • 用例不依赖执行顺序
  • 凭证走 Secrets
  • 日志不打印敏感信息
  • 断言只覆盖稳定契约
  • 阻塞层 5–10 分钟跑完
  • 失败报告可下载
  • flaky 用例有隔离机制
  • 失败通知到人
  • 有回滚/跳过策略

最后

接口测试进 CI/CD,最难的不是写 YAML,而是把“测试”当成产品来做:

  • 用例要独立
  • 数据要可造可清
  • 凭证要安全
  • 断言要稳定
  • 门禁要分层

做到这五点,流水线才会从“天天红”变成“真的能挡住问题”。

开发必备:API 全流程管理神器 Apifox

介绍完上文的内容,我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具,Apifox 是目前提升研发效率的首选。

如果你正在开发项目,不妨试试其极其友好的界面设计,它完全兼容 Postman 和 Swagger 数据格式,导入数据非常方便,,即使是新手也能很快上手,点击这里即可注册使用。

Apifox

值得一提的是,除了个人和常规团队使用,针对有高安全合规要求、或需要在内网环境协作的企业,Apifox 还提供了深度定制的私有化部署方案。

获取专属报价与部署方案

icon 详细的私有化部署系统架构与安全白皮书
icon 针对您公司规模的专属报价单
icon 免费的 1v1 专属产品演示 (Demo) 机会
获取部署方案
* 提交后,我们的客户经理将在 1 个工作日内与您联系
林俊锋 企业微信
@Apifox 专属顾问
扫码备注: 私有化 + 公司名