从最初手写 requests 脚本跑接口回归到后来为了一百多条 pytest 用例的维护焦头烂额我在自动化测试这个方向上踩过的坑两只手都数不过来。今天想认真聊一聊 DeerFlow 自动化测试方案——这是一套基于 Python 的持续集成落地思路核心是一个叫 DeerFlow 的流程编排框架。它解决的问题很直接怎么让接口测试、UI 回归、性能冒烟这些不同类型的用例从本地能跑变成提交代码就自动跑、跑完出报告、失败了能定位。如果你正在搭 CI或者被耦合严重的用例折磨到想重构测试体系这篇内容应该能给你一个可以照着抄的模板。1. 整体设计思路DeerFlow 解决的到底是什么问题1.1 从能跑到能持续跑的坎很多团队的测试自动化是从一个小脚本开始的。写完接口冒烟跑通了很高兴然后用例越来越多开始有人往里面加登录依赖、加数据库校验、加各种定制逻辑渐渐变成几百行的面条代码。这时候问题就来了本地跑得好好的一放到 CI 上就开始随机失败用例之间互相依赖改一个接口的返回值后面十几个用例全挂日志乱七八糟失败之后根本不知道是哪一步出的问题。DeerFlow 的思路和这种堆脚本的模式完全不同。它把一次测试抽象成一条有向无环的流程每条流程由若干步骤组成每个步骤可以是接口请求、页面操作、数据库校验或者通知动作。步骤之间通过上一个节点的输出做参数传递失败的时候可以配置重试也可以配置跳过后续步骤。这套抽象直接解决了三个我在实际项目里最头疼的问题用例顺序控制、失败定位、以及数据在步骤之间的流转。1.2 流程编排的核心抽象DeerFlow 里最核心的三个概念是 Flow、Step 和 Context。Flow 是一条完整的测试链路对应一个业务场景比如用户登录→下单→支付→校验订单状态。一个 Flow 执行完要么通过、要么失败失败的时候会告诉你卡在哪个 Step。Step 是 Flow 里的最小执行单位它封装了一个动作。每个 Step 可以定义自己的超时、重试次数、前置条件也可以声明它期望从上下文里拿到什么数据、最后向上下文写回什么数据。这种声明式的写法让用例的可读性比传统 fixture 嵌套高了不少。Context 是贯穿整条 Flow 的上下文对象本质就是一个线程安全的内存字典。上一个 Step 的返回值写入 Context下一个 Step 通过 key 读取这样就避免了把测试数据用全局变量到处传的写法也不需要在用例之间手工维护一堆临时变量。这个设计的好处直观来看就是用例从每个函数自己找数据变成了流程框架帮我把数据送到需要的地方。我后来在项目里让一位完全没写过自动化测试的同事照着示例写了 20 条接口用例他问我数据怎么传的次数几乎是零。这在我以前用 pytest 写 fixture 的时候是不敢想象的。1.3 为什么不用纯 pytest 或者纯脚本这里我要多说一句。不是 pytest 不好而是两者侧重点不一样。pytest 的强项是单测和参数化fixture 体系也很灵活但当一个用例的步骤链条很长、步骤之间还有数据依赖时用 pytest 写出来要么靠 fixture 层层嵌套要么靠 conftest 里的各种技巧看代码的人很容易迷路。DeerFlow 选择用流式声明来组织用例YAML 或者 Python 装饰器都行意图比一堆 fixture 拼装要清楚得多。另外有一个很现实的点CI 环境里测试要的是可观测、可重复、可定位。DeerFlow 每个 Step 执行完都会往日志和报告里写状态、耗时、请求摘要失败时直接把当前 Step 的输入输出完整输出。这个定位到步骤级的能力是堆脚本时代最缺的。我自己吃过亏以前排查一个偶发失败要在日志里翻几千行找半天才确认是登录那一步的 token 过期了。用 DeerFlow 之后报告里直接写着login 步骤失败401五分钟之内就能定位。2. 环境准备与项目初始化2.1 基础环境与安装DeerFlow 是纯 Python 项目依赖管理我推荐直接用 Poetry 或者 uv别再用 requirements.txt 手撸依赖了尤其是要部署到 CI 的时候锁定版本比什么都重要。Python 版本建议 3.10 以上实测在 3.11 上跑得最稳3.8 也能跑但有些新特性用不了。安装很简单两条命令python -m venv .venv source .venv/bin/activate pip install deerflow如果你要做 UI 测试还需要装浏览器驱动。我习惯用 Playwright 而不是 Selenium主要原因有两个一是 Playwright 的浏览器驱动是自动下载的不用像 Selenium 那样手工找版本、还要操心驱动和浏览器版本对不对得上二是它的等待策略更智能对 CI 里的时序抖动容忍度高很多同样的用例在本地能过、CI 上不一定能过的概率明显低。DeerFlow 有对应的 Playwright 插件装完插件包再执行一次同步命令就行。2.2 初始化一个 DeerFlow 项目DeerFlow 提供了项目脚手架跑一条命令就能把目录结构拉起来deerflow init my_test_project cd my_test_project生成出来的结构大概是下面这样my_test_project/ ├── flows/ # 流程文件一个业务场景一个目录 │ └── demo/ │ ├── flow.yaml # 流程定义 │ └── steps.py # 自定义步骤 ├── config/ │ ├── env.yaml # 环境配置域名、账号、超时 │ └── runner.yaml # 并发、重试、报告设置 ├── reports/ └── conftest.pyflows 目录是核心config 里的 env.yaml 建议按环境拆成 env_dev.yaml、env_test.yaml。让同一个用例集在不同环境之间切换时只改配置、不改代码。这一点我后面在 CI 接入的部分会展开讲因为环境切换在持续集成里特别容易踩坑——测试在 dev 环境跑绿了切到 test 环境就红通常都是因为域名、账号或者测试数据没隔离干净。2.3 配置 runner.yamlrunner.yaml 是执行引擎的入口配置我贴一份自己项目里常用的配置直接抄能少踩很多坑# config/runner.yaml runner: workers: 4 # 并发 worker 数 timeout: 300 # 单条 flow 超时秒 retry: enabled: true max_retries: 2 interval: 3 # 重试间隔秒 retryable_status: [500, 502, 503] # 仅这些状态码触发重试 report: format: allure output_dir: reports/ environment: test # 对应 config/env_test.yaml注意这个 retryable_status很多新手会把所有失败都交给重试兜底结果就是 400 这种断言失败也被重试两遍浪费执行时间还掩盖了真正的问题。我个人的原则是重试只针对环境抖动类问题比如 5xx、连接超时、网络闪断业务断言失败和参数错误必须直接红不要重试让开发一眼看到真实原因。3. 编写可编排的测试流核心实操3.1 用 YAML 定义一条完整链路流程文件用 YAML 声明的好处是好审阅、好改版本即使不是写代码的人也能看懂。拿最常见的登录→下单→校验库存来举例# flows/order/flow.yaml name: 订单创建全链路 description: 用户登录后创建订单并校验库存扣减 environments: [test] steps: - id: login type: http_request method: POST url: /api/v1/auth/login json: username: {env.user} password: {env.password} extract: token: $.data.token retry: 1 - id: create_order type: http_request depends_on: login method: POST url: /api/v1/orders headers: Authorization: Bearer {context.token} json: sku_id: {env.sku_id} quantity: 2 validate: - key: $.code op: eq expect: 0 - id: verify_inventory type: sql_query depends_on: create_order dsn: postgresql://${env.db_user}:${env.db_pass}${env.db_host}/shop query: | SELECT stock FROM inventory WHERE sku_id {env.sku_id} validate: - key: $[0].stock op: less_than expect: 100这里有几个关键设计想解释一下。首先是 extract 字段它从响应里提取 token 写入 Context后面 create_order 步骤里 headers 直接引用 {context.token}这就实现了步骤间的数据流转不用在代码里维护全局变量。其次是 url 里的 {env.xxx}它会在执行时从当前环境配置里替换同一个 flow 文件切个环境配置就能跑不同环境这比在测试代码里硬编码域名强得多。最后是 validate它就是断言DeerFlow 内置了 eq、neq、greater_than、less_than、contains 这些常见操作符如果不够用可以写一个自定义校验器。3.2 自定义步骤把重复逻辑收进一个类YAML 适合描述标准动作但真实项目里总有特殊逻辑比如生成加密签名、调内部接口拿一次性票据、解析自定义协议。这时候就需要写自定义步骤了。DeerFlow 的步骤类长这样# flows/order/steps.py from deerflow import Step, Context class OrderSignStep(Step): name order_sign def run(self, ctx: Context): payload ctx.get(order_payload) sign self._make_sign(payload) ctx.set(order_sign, sign) return {signed: True, sign: sign} def _make_sign(self, payload): # 这里放你自己的签名算法 return md5(f{payload}{SALT}).hexdigest()然后把 flow.yaml 里的步骤 type 换成 order_sign 就行。这里有个经验自定义步骤尽量做得无状态只依赖 Context 里的输入结果写回 Context不要在步骤内部缓存任何可变数据。原因很简单——DeerFlow 支持并行跑 flow如果步骤里藏了可变成员变量多线程一跑就会出现互相污染排查起来非常痛苦。我在一个项目里就亲眼见过两个流程同时执行同一个自定义步骤其中一个把步骤对象里的某个列表清空了另一个接下来一读数据全没了日志里根本看不出是哪里的问题。3.3 数据驱动一套流程跑多组参数自动化测试最烦的一件事就是这个用例换个参数再跑一遍。DeerFlow 直接在 flow 配置里支持参数化name: 登录用例参数化 params: - username: u1 password: p1 expected_code: 0 - username: u2 password: wrong_pwd expected_code: 10001 steps: - id: do_login type: http_request method: POST url: /api/v1/auth/login json: username: {params.username} password: {params.password} validate: - key: $.code op: eq expect: {params.expected_code}params 列表里有多少组这个 flow 就会执行多少遍每一遍的 Context 是独立的报告里也会把参数值标出来。这个特性在持续集成里价值很大因为它让一个场景覆盖多种输入变成了配置而不是代码逻辑。我自己维护一个商品下单流程就是用参数化把支付方式、优惠券、收货地址的组合全跑了一遍一共 20 多组参数flow 文件却只有一个新增组合只需要往 params 里加一行。3.4 断言的艺术别把所有校验都堆到最终结果我在实际项目里总结的一个教训是很多测试失败之后难定位是因为把所有校验都放在流程最后一步中间任何一步错了都表现为最后结果不对。DeerFlow 里每个 Step 都能配 validate我建议你把校验拆开到每一步登录成功后立刻校验 token 非空、下单成功后立刻校验订单号格式、最后再校验库存变化。这样一旦失败报告里能精确到哪个动作、哪条断言挂了开发排查的时间能从小时级降到分钟级。举个反例曾经有个同事写支付流程用例五个步骤做完只在最后一步断了一次支付状态为成功。结果某天线上接口改造第二步下单接口直接返回了 500他的用例在最后一步才红而且失败信息只有支付状态不是 SUCCESS。他排查了一个下午最后发现根本不是支付的问题而是下单接口挂了。如果他按步骤拆分断言报告里早就定位到了。4. 接入持续集成CI 平台对接实战这一节是标题里持续集成的重头戏。DeerFlow 本身只负责把测试跑起来、汇总结果真正让它发挥威力的是和 CI 平台打通代码提交触发、自动拉分支、跑对应环境的测试、出报告、通知到人。4.1 在 Jenkins 里跑 DeerFlow如果你的团队还在用 Jenkins配置思路通常是拉代码 → 装依赖 → 跑测试 → 归档报告。Jenkinsfile 用声明式写法核心阶段大概长这样pipeline { agent any stages { stage(Checkout) { steps { checkout scm } } stage(Install) { steps { sh python -m venv .venv . .venv/bin/activate pip install -e .[test] } } stage(Run DeerFlow) { steps { sh . .venv/bin/activate deerflow run --env ${ENV_NAME} --tags regression } } stage(Archive Report) { steps { allure includeTrend: true } } } }几个要点说一下。第一ENV_NAME 用环境变量注入不要写死在 Jenkinsfile 里这样一套流水线可以跑 dev、test、预发三个环境。第二每次跑都新建 venv 而不是复用旧的虽然慢一点但能避免包版本漂移——我在项目里见过最诡异的问题就是同一个用例昨天绿今天红最后查出是 CI 机器上的依赖被上一次构建偷偷升了级。第三报告归档这一步一定要用插件管理历史趋势否则你根本看不出最近两周失败率是不是在上涨。4.2 GitLab CI 的 Runner 配置GitLab CI 的配置更轻量在项目根目录写 .gitlab-ci.yml 就行。我常用的版本stages: - test deerflow-test: stage: test image: python:3.11-slim before_script: - pip install -e .[test] script: - deerflow run --env test --workers 4 artifacts: paths: - reports/ expire_in: 7 days rules: - if: $CI_PIPELINE_SOURCE merge_request_event用 merge_request_event 触发是我的习惯每次合并请求更新就跑一遍自动化回归开发在合代码之前就能看到测试结果而不是等合完之后才发现问题。直接 git push 触发的全量回归可以放在 nightly 计划里避免每次提交都跑一遍全量用例把时间拖长。这里要单独提醒一个容器环境的问题如果 UI 测试要用 Playwright镜像里必须要装浏览器依赖否则测试一跑起来就报找不到 Chromium。我踩过一次就是镜像用了纯 python:3.11-slim跑接口测试没问题一跑 UI 用例就各种报缺系统库后来换成 Playwright 官方镜像或者自己构建一个带依赖的镜像才解决。4.3 测试报告与失败通知报告我统一用 AllureDeerFlow 原生支持往 allure-results 目录写数据。Allure 的优势不用多说用例步骤、失败信息、耗时趋势都可以直接展示开发点开失败用例就能看到当时的请求和响应省去了一趟趟找测试要日志的工夫。通知这块我接的是 IM 机器人其实各家工具都是一个套路。关键不是用什么工具而是通知内容里要包含哪些信息。我的通知文案模板大概是这样的【流水线异常】订单全链路回归 环境test 失败用例创建订单并校验库存扣减 失败步骤create_order 失败原因断言 code 0 失败实际 code 10009库存不足 报告链接http://ci.internal/reports/job/123/按这个格式通知开发基本不用找测试就能定位问题。这里有个细节通知消息里要带上失败步骤和失败原因这全靠前面说的每步断言的写法才能拿到如果你把所有校验堆在最后一步通知里只能写一句订单流程执行失败等于没写。4.4 环境切换与配置管理这一节必须单独拿出来讲因为环境切换是我见过翻车最多的地方。DeerFlow 的设计思路是 flow 文件里只写相对的东西环境相关的全放 env 配置# config/env_test.yaml env: user: ci_tester password: welcome1 sku_id: SKU-10086 api_base: https://test-api.internal.com db_host: 10.0.0.8# config/env_dev.yaml env: user: dev_admin password: dev2024 sku_id: SKU-20001 api_base: https://dev-api.internal.com在 CI 里通过 deerflow run --env test 指定环境。这里最容易犯的错是测试数据不隔离测试环境写脏了商品库存另一条用例再去下单就断言失败。我后面在稳定性那节会讲数据隔离的具体做法这里先提醒一点——每个环境最好配上独立的测试账号池账号不要共用否则并行一跑A 用例把账号踢下线B 用例立刻 401。注意环境配置务必不要用生产环境的真实连接串当默认值。我见过有人把包含真实密码的 env.yaml 提交进仓库这种事故一出就是大事。宁可多配几个假的占位符也不要图省事。5. 稳定性设计并行、重试与数据隔离自动化测试接入 CI 之后最大的挑战不再是写用例而是让测试稳定地绿。我在项目里用 DeerFlow 跑回归遇到过的最经典场景本地跑全绿CI 上跑 10 次红 3 次每次红的用例还不一样。这一类问题的根源基本都出在并行调度、重试策略和数据隔离这三块。5.1 并行执行策略DeerFlow 的 runner.yaml 里 workers 控制并发数。并行跑能省时间当然是显然的但并行不是越大越好它有两个天然敌人一个是被测系统的限流一个是测试数据之间的竞争。先说限流。我曾经把 workers 调到 8结果测试环境网关直接开始返回 429一堆用例排队重试整体跑完的时间反而比 workers4 还长。后来我养成了一个习惯先做一次简单的容量摸底先用 workers2 跑一遍全量然后逐步往上加找到执行时间开始不再下降的那个点那就是当前环境的最优并发度。再一个是数据竞争。如果两个 flow 同时操作同一条测试数据比如都去改同一件商品的库存那断言结果就是看谁先到。这种问题不是重试能解决的必须从数据设计上隔离。我常用的方法是按 worker 切分数据每个并发 worker 用一个固定的前缀去生成测试数据比如 sku_id 里带上 worker 编号这样不同 worker 之间的测试数据天然不重叠。5.2 失败重试的两种姿势DeerFlow 里的重试有两种一种是执行器层面的重试也就是 runner.yaml 里配置的全局重试它主要兜底网络抖动、服务重启这类环境问题另一种是流程内的局部重试写在某个 Step 上比如获取订单状态这个轮询步骤本身就设计成最多查 5 次、每次间隔 1 秒。我的建议是能用流程内轮询解决的就不要依赖全局重试。举个例子创建订单后要等异步任务把库存扣减完你直接在 verify_inventory 这个 Step 上配 retry: 5、interval: 2 秒比让执行器把整条 flow 重跑一遍要快得多也不会把登录、创建订单这些已经成功的步骤再执行一遍避免产生重复数据。还有一点全局重试的 retryable_status 一定要收敛。我见过有人配置成所有错误都重试结果是 400 这类请求错误也被重试日志里全是重试记录既浪费时间又掩盖了真实的代码问题。重试的本质是给不确定因素一个容忍窗口不是给 bug 一个蒙混过关的机会。5.3 数据隔离方案数据隔离是我认为整个稳定性设计里最值得花时间的地方。测试数据一旦互相污染所有重试、并行策略都白搭。DeerFlow 项目里我一般会同时做两层隔离。第一层是逻辑隔离用配置开关控制前置数据准备。每个 flow 在执行前先调用一个 setup 步骤生成本次运行专属的测试数据比如创建一个名字带时间戳加随机数的测试订单跑完后再调 teardown 步骤清理数据。DeerFlow 的 Step 支持在定义时声明 setup 和 teardown这样数据生命周期就跟着 flow 走了不会残留到下一次运行。第二层是物理隔离在条件允许的情况下给自动化测试搭一个独立的测试环境数据库、缓存、消息队列都和其他环境分开。如果实在没有独立环境也要保证自动化测试账号池、测试商品池和手工测试用的数据分开绝不能在同一个账号、同一件商品上又跑自动化又做手工验收。我在一个模拟项目里就吃过这种亏手工验收把库存改成了 0自动化一跑就断言失败排查半天还以为是代码问题最后发现是数据被人工操作污染了。5.4 时间与时序的坑最后补一个很容易被忽视的稳定性问题时间与时序。CI 环境里异步任务的时序非常不稳定同一个用例在本地跑 100 毫秒就拿到结果CI 上可能要 2 秒。解决办法有两个一是所有涉及异步状态的断言都要做轮询等待而不是固定 sleep二是轮询的间隔和超时要给得足够宽。我在 DeerFlow 里写了一个 wait_until 类型的步骤专门做这种事情- id: wait_order_finish type: wait_until scheduler: 1s # 每秒轮询一次 timeout: 30s # 最多等 30 秒 request: url: /api/v1/orders/{context.order_id} condition: $.status FINISHED这种轮询直到满足条件的写法比在测试代码里到处 sleep(3) 要可靠得多而且整体耗时可控。试想一下如果你在流程里埋了三个 sleep(5)一次稳定跑下来光等待就花 15 秒而且 CI 负载高的时候 5 秒根本不够用轮询才是正道。6. 常见问题与排查实录DeerFlow 接进 CI 之后我积累了一批高频问题的排查经验整理成一张速查表按出现的频率排序现象常见原因排查/解决思路本地跑绿CI 跑红依赖版本漂移或环境变量缺失检查 CI 里是否新建 venvenv 配置是否被正确注入用例偶发失败数据污染或时序问题看失败用例是否和数据前置准备有关把 sleep 改成轮询并发跑着跑着就报 401共享账号被踢下线账号池按 worker 隔离或改用 token 池UI 用例找不到浏览器容器镜像缺系统依赖换带 Playwright 依赖的镜像或构建时安装重试之后还是不绿重试对象选择错误确认 retryable_status 只含 5xx/超时业务断言别重试报告里步骤信息缺失自定义步骤没写返回描述自定义 Step 的 run 方法要返回可读的字典报告才会展示这里我挑两个最典型的展开讲一下。6.1 重试了还是失败的排查思路有个模拟项目订单支付流程偶发失败我开了全局重试结果发现重试之后依然失败而且失败的那一次响应里写的都是订单已存在。一查才发现问题是这样第一次调用创建订单其实成功了但是响应超时DeerFlow 认为请求失败触发重试重试时同一笔订单标识又发了一次后端幂等校验拦下来返回了业务错误。这种情况全局重试不但救不回来反而会制造新的脏数据。正确的做法是给创建订单这种非幂等的操作单独处理要么自己在 Step 里做查重逻辑请求前查一下订单是否已存在要么把该 Step 的 retry 关掉靠后置的订单状态轮询去等超时的那笔订单落地。这个案例我印象很深因为它说明一个道理——重试不是万能的你要先搞清楚这个操作是不是幂等的再决定要不要重试。6.2 报告上传失败的排查有一次流水线明明全部跑绿了但 Allure 历史趋势图空了。检查后发现是产物路径写错了DeerFlow 的报告输出到 reports/而 CI 里归档配置填的却是 allure-report。还有一次更隐蔽是并行 worker 同时往同一个 allure-results 目录写文件导致冲突后来在 runner.yaml 里给每个 worker 分配了独立的 results 子目录再统一合并问题才消失。如果你也遇到报告时有时无的情况优先检查这两点路径对不对、有没有并发写冲突。6.3 维护成本控制用例越多越要管结构最后说点软经验。DeerFlow 用流程编排解决了很多问题但用例数量大了之后仍然会出现流程文件越来越多、互相引用越来越多的情况。我的做法是给 flows 目录做分层核心回归层、冒烟层、全量层用 tags 区分比如 --tags core、--tags smoke。CI 里合并请求只跑核心回归和冒烟全量层放到 nightly。这样既能保证主干质量又不至于每次提交要等 40 分钟跑全量。这算是我在几个项目里摸索出来最实用的降本手段。最后分享一点个人的体会。DeerFlow 这套自动化测试持续集成方案技术上并不复杂真正有价值的是它逼着你把测试当成一个工程问题来思考用例要有结构数据要有隔离错误要有定位报告要有趋势。我最早写自动化测试的时候总想着把用例写得聪明越复杂越有成就感现在反过来我追求的恰恰是简单、可重复、出问题三分钟能定位。如果你也正打算把自动化测试接进 CI我建议你从一条最核心的业务链路开始用 DeerFlow 把它的数据流转、断言、重试都理清楚跑通了再往周边扩散。工具本身不神奇神奇的是你开始用工程化的方式对待测试的那一刻。