很多人第一次搭自动化测试框架，卡的不是不会写断言，而是一上来就选型、装依赖、抄模板，结果跑到十几个用例就开始乱：环境切不过来、失败原因看不出来、加一条用例要改五处代码。这篇按「先能跑、再能扩、最后能进流水线」的顺序拆，给你每一步该做什么、做到什么程度算过关，以及什么时候这套做法不适用。
很多人第一次搭自动化测试框架，卡住的不是断言怎么写，而是一上来就选型、装依赖、抄模板。结果跑到十几个用例就开始乱：环境切不过来、失败原因看不出来、加一条用例要改五处代码。问题不在工具，在于顺序搞反了——先想框架长什么样，再想怎么跑通第一条用例。
这篇按「先能跑、再能扩、最后能进流水线」的顺序拆。每一步给你该做什么、做到什么程度算过关，以及什么时候这套做法不适用。你不需要一次搭完，能按顺序往下走就行。
先定边界：框架要覆盖哪几层测试
动手前先想清楚框架要管哪一层。测试大致分三块：接口层最稳、UI 层最脆、单元层归开发。新人团队优先从接口层起步，理由是接口变更少、断言好写、跑得快，出问题也容易定位是数据错还是逻辑错。UI 层不是不能做，而是它维护成本高，得先有接口层兜底再上。
- 接口层
- 直接调后端接口做校验，输入输出都是结构化数据，最适合新人起步和做回归
- UI 层
- 驱动真实界面点击输入，最接近用户但最容易受改版影响，维护成本明显高于接口层
- 单元层
- 在函数级别验证逻辑，通常由开发在代码仓库里维护，测试框架不必重复覆盖
判断要不要做 UI 自动化，标准就一条：核心流程必须验证真实交互时才上。业务原型期、界面一天改三遍的项目，先做 UI 自动化等于给自己挖坑。另外先把「测什么」写成一页清单，标明哪些是回归必跑、哪些只是偶尔验证，这份清单直接决定后面目录怎么分、标签怎么打。
目录骨架：一份能长期用的分层结构
目录按职责分，别按页面分。公共封装、用例层、测试数据、环境配置、执行入口各占一个目录，避免用例文件里混进连接逻辑和 SQL。这样做的直接好处是：改被测地址只动配置，改接口字段只动封装，用例本身几乎不用碰。
| 目录 | 放什么 | 改动频率 |
|---|---|---|
| 公共封装 | 请求发送、断言工具、日志 | 低，接口稳定后基本不动 |
| 用例层 | 按业务模块分的用例文件 | 中，需求变就加用例 |
| 测试数据 | 输入参数、预期结果、账号池 | 中，数据变了改这里 |
| 环境配置 | 被测地址、超时、并发数 | 低，但各环境必须分开 |
| 执行入口 | 命令行脚本、标签筛选 | 低，一次配好长期用 |
配置一定要外置。被测地址、账号、超时、并发数放到环境配置文件里，用例只引用配置名，不写死值。具体参数该取多少，到 /tools/speed-test 量一遍你自己的延迟基线再定，别照抄别人的默认值。断言和定位也要分开：预期结果放用例里，元素或字段的定位规则放封装层，改版时只改一处。
- 留一个跑冒烟集的入口，命令行一条命令跑通最小那组用例，这是后面接 CI 的前置条件
- 用例文件里不出现具体的连接字符串和账号，全部通过配置读取
- 每个目录有个 README，说明改什么该动哪里，新人接手不用问人
- 配置分环境存放，本地和流水线用不同文件，靠参数切换而不是改代码
用例与数据：写起来顺手、扩起来不痛
一条用例只验证一个判断点。失败时不用翻代码就知道哪断了。把准备数据、执行、校验分成三个函数段落，方便单独复用和调试。很多新人喜欢把一整条业务流程塞进一个用例，结果跑挂了不知道是登录失败还是下单失败，排查时间比写用例还长。
- 准备数据在用例开头单独建测试所需的账号和数据，跑完清理。验证方式：重复跑两次结果一致。
- 执行操作调用封装好的请求或操作，只做调用，不做断言。验证方式：执行完能拿到完整的响应对象。
- 校验结果在最后集中写断言，预期结果不写死在封装里。验证方式：故意改错一个预期值，用例应该报错。
数据驱动要克制。只有当同一套步骤能用不同输入重复跑时才抽数据文件，硬凑数据驱动会让调试变难——出错了不知道是第几组数据挂的。给用例打标签也很关键：冒烟、回归、慢用例分开标记，跑的时候按标签筛，而不是每次全量。失败可复现是底线，每条用例失败时能输出请求、响应和当时的配置快照，不然排查只能靠猜。
| 做法 | 什么情况适合 | 什么情况不适合 |
|---|---|---|
| 数据驱动抽文件 | 同一套步骤跑多组输入，如边界值批量验证 | 只有一两条用例，抽文件反而增加跳转 |
| 打标签筛选 | 用例数过了几十条，需要分批次跑 | 用例很少，直接全量跑更省事 |
| 失败快照 | 接口和断言都可能出错的场景 | 纯本地计算、无外部依赖的用例 |
跑起来之后：并发、重试与报告
并发度先保守，从单线程跑通再逐步加。用例之间有共享状态时必须串行，比如共用同一个账号下单，两个线程同时跑必然冲突。并发上不去往往不是机器不够，而是用例互相污染，先去查数据隔离再说。重试只用在环境抖动上，不用在断言失败上——区分「调用异常」和「结果不符」，前者可重试，后者重试只会掩盖问题。
- 报告给人看不是给机器看：失败列表按用例归属分组，附日志片段和截图
- 让不写代码的人也能判断是不是真 bug，否则报告只有开发者看得懂
- 接流水线时先只跑冒烟集，稳定一段时间再放回归集
- 每次发版前跑什么、谁来处理红灯，提前写进流程文档，别等红灯亮了才讨论
- 红灯处理要有时间上限，超时未处理自动降级为已知问题，避免拖住发版
并行度、重试次数、超时上限这些值没有放之四海皆准的答案，跟你的环境和业务规模强相关。建议到 /rankings 看同类项目的运行数据，或者到 /price-watch 对照当时的资源成本，再定你团队的参数。别直接抄别人的配置，环境不一样结论就不一样。
整套顺序说到底就三句话：先让一条用例能跑通，再让加用例只改一处，最后让它能自动跑起来。中间任何一步卡住，都别急着往下走，回头把上一步的目录或配置理顺，比硬撑着加用例划算得多。
下一步把你现在项目的接口文档和手工用例清单对照一下，看看哪些用例适合先自动化。框架选型和运行参数可以到站内工具目录对比着看，别只凭感觉定。→常见问题
新人第一套框架该从接口测试还是 UI 测试入手？
优先接口层。接口用例写得快、跑得稳、定位问题直接，新人能在短周期内拿到正反馈。UI 自动化适合放到第二个阶段，等你已经有一套能跑的持续集成流程、界面也相对稳定了再补。如果项目本身还在频繁改原型，UI 自动化维护成本会明显高于收益，不如先手工跑核心路径。
框架跑一段时间越来越慢，该从哪查？
先看用例数量涨了还是单条变慢。单条变慢通常是等待策略写成了固定等待、或者共享资源排队；整体变慢多半是并发配置和用例隔离的问题。做法是把慢用例打上标签单独跑一遍，对比去掉它们后的总耗时，差值集中在哪几条就改哪几条，不要一上来就调并发数。
要不要一开始就上现成的测试平台？
先用代码加命令行跑通最小闭环，再考虑平台。平台能解决用例管理和报告展示，但解决不了用例本身写得脆的问题，早早引入反而多学一套操作。等你手上稳定跑着几十条用例、多人需要看结果时，再把执行挂到平台上更划算。选型时可以对照站内的工具清单看当时的对比。
