自动化测试开发实战教程

很多人学自动化测试卡在同一个地方：脚本能跑通一条，跑到一百条就开始随机失败、跑得慢、改一次全崩。问题往往不在语法，而在结构、隔离、并发和日志这些工程细节没定下来。这篇按从零到实战的顺序，把该搭的东西、该定的规矩和排查顺序一条条列出来，你可以照着走一遍，也可以拿去对照自己现有的用例集找缺口。

很多人学自动化测试卡在同一个地方：脚本能跑通一条，跑到一百条就开始随机失败、跑得慢、改一次全崩。多半不是语法问题，而是结构、隔离、并发和日志这些工程细节没提前定下来。这篇按从零到实战的顺序，把该搭的东西、该定的规矩和排查顺序一条条列出来，你可以照着走一遍，也可以拿去对照自己现有的用例集找缺口。

读的时候建议手边放着现在那份用例集，每看完一节就回头检查一件事：我这块有没有明确规则。没有规则的地方，就是将来会随机失败的地方。真要对比不同框架或执行方案的资料，可以到站内工具目录里按需查，不要凭印象选型。

先定范围和技术栈，别一上来就写用例

第一步是划线，不是写代码。把要覆盖的范围写成一页纸：做哪一层、覆盖哪些核心流程、哪些明确不做。这份范围说明后面会反复用到，加需求时先看它，能挡掉不少「顺手也测一下」的临时要求。

• 先分清做的是接口层、UI 层还是单元层：优先从接口层切入，稳定性高、维护成本低，UI 层留到接口层跑稳之后再补；
• 选语言和框架只看两个指标：团队现有技术栈能不能复用、报告和重跑机制是不是自带，别为了新框架把学习成本叠在业务成本上；
• 目录结构一开始就分三层——用例、业务封装、基础工具，后面加用例才不会互相污染；
• 判断标准：如果新加一条用例要动三个以上文件，说明抽象层次还没定好，别急着铺量。

用例与测试数据怎么组织才不互相踩

用例集乱，八成乱在数据上。两条用例共用一个账号、一个订单，只要并发或顺序变了就互相踩。规矩要在写第一批用例时就立起来，后面再补，改动量会翻倍。

1. 前置与清理自带每条用例自己准备数据、自己收尾，禁止依赖上一条留下的状态。验证方式：单独跑这一条也能过。
2. 数据从工厂或固定集生成不写死真实账号和环境地址，环境差异走配置项注入。验证方式：换一套配置能整体跑通。
3. 断言只断业务结果不断日志文案和字段顺序，这类断言最容易在无关改动后失败。验证方式：改无关文案，用例不应红。
4. 命名统一按「模块-场景-预期」命名，失败时从报告标题就能判断要不要人工看。

并发跑批、超时与随机失败的处理顺序

并发不是目的，是缩短回归时间的手段。顺序上一定是先单线程跑稳再加并发，否则你分不清失败是并发引入的，还是本来就有的问题。并发度从很小起步，慢慢往上加，重点看失败率随并发变化的拐点在哪。

超时、重试、退避这三件事写进公共调用层，别在每条用例里各写一份。重试只对幂等操作开放，非幂等的写入操作重试会制造脏数据，这类接口宁可失败也不要自动重试。

• 遇到随机失败按这个顺序查：数据是否共享 → 是否受执行顺序影响 → 被测服务自身是否限流 → 网络与超时设置；
• 必须串行的用例显式打标记隔离，而不是靠调低整体并发来兜；
• 同一用例连续多次失败但单独跑能过，基本锁定在共享状态，先查数据而不是先查框架；
• 限流导致的失败在报告里要和真实缺陷区分开，否则天天狼来了，没人再看报告。

日志、报告与可回放：出错时能自己定位

自动化跑起来之后，最耗时的不再是写用例，而是排查失败。日志和报告的目标只有一个：让看报告的人不用问写用例的人，就能自己判断这是真问题还是环境抖动。

关键字段

每次调用记请求标识、耗时、状态、失败原因摘要，四个就够用，多了没人看。

脱敏

敏感字段落盘前先处理，日志本身也是数据泄漏面。

可回放

报告里保留失败时的原始请求与响应，别人能自己复现。

结果快照

跑完归档一份，用来对比两次运行的差异，区分新增失败和老问题。

趋势比单次结果重要：连续几次都偶尔失败的用例，当成待修问题排队，别忽略。

接进流水线与回归节奏怎么排

流水线里的用例集要分两套：提交触发的冒烟集，和夜间跑的全量集。分开维护的核心目的是保证开发者反馈够快，全量集再全，如果每次提交都要等很久，最后只会被人绕过去。

把自动化和人工探索测试的分工写清楚：自动化管回归和边界，新功能的首轮验证仍然靠人。接流水线前先确认执行环境、网络出口和凭据管理方式，本地能跑不等于 CI 里能跑，这一步不确认，上流水线第一天就会卡住。

• 定期清理长期失败和被跳过的用例，用例集不是越大越好；
• 跑得慢和噪音大会让人直接不看报告，这比用例少更糟；
• 凭据统一走流水线密钥管理，不要散落在代码或配置文件里；
• 各执行环境的资源开销和限制差异，可以到站内工具目录按需核对，别用本地经验硬套。