自动化测试入门与实战

很多人第一次做自动化测试，是从「把手工用例全录一遍」开始的，结果脚本越写越多，跑一次要等半天，失败还查不出原因，最后整条流水线没人看。这篇不讲工具语法，讲的是判断顺序：哪些用例值得自动化、脚本怎么分层、断言写在哪、失败之后按什么顺序排查。照着做完，你至少能搭出一条自己敢持续维护的测试流水线。

很多人第一次做自动化测试，是从「把手工用例全录一遍」开始的。结果脚本越写越多，跑一次要等半天，失败还查不出原因，最后整条流水线没人看。问题不在工具语法，而在判断顺序：哪些用例值得自动化、脚本怎么分层、断言写在哪、失败之后按什么顺序排查。

这篇不讲某个框架的 API，讲的是能落地的路径。照着做完，你至少能搭出一条自己敢持续维护的测试流水线。如果中途要对比不同方案的成本，可以去站内相关页面核对当时的数字，而不是凭感觉拍板。

先判断：哪些用例值得自动化，哪些别碰

自动化不是目的，是省重复劳动的手段。判断标准可以浓缩成一句话：这条用例未来还会被反复执行，且断言结果明确、不依赖人工判断、数据可控，那才值得写。反过来，手工跑一次就够的探索性用例、界面大改期间的临时验证，先别碰。

• 典型不该自动化的场景：需求还在反复改、界面元素天天动，以及需要人眼判断的视觉类用例。
• 成本账这么算：一次自动化投入要能覆盖未来重复执行的次数，否则还不如手工点。换算口径可以到 模型成本计算器（/tools/model-cost-calculator） 同类工具里找思路，把执行次数和时间成本拉到同一把尺子上。
• 不适用的边界：项目只做一次性交付、下个版本就要停掉，自动化收益基本为零，别硬上。

脚本怎么分层：别让一条用例从界面点到数据库

1. 定三层结构用例层只写业务步骤，页面或接口操作层封装具体动作，数据与配置层管账号、环境地址、测试数据。先画出来再写代码。
2. 写第一条最小可用脚本选一条最稳定的主干流程，配三个明确断言，加一条失败就截图或记录请求日志的兜底逻辑。能跑通再谈扩展。
3. 集中管理定位与字段元素定位、接口字段统一放一处。散落在各条用例里的硬编码，是后期改一次崩一片的主因。
4. 设一条止损线用例不到十条、项目体量很小时，硬套分层反而增加维护负担，先用直线写法跑起来更实际。

分层不是越细越好，而是让改动点集中。比如登录动作只在一个地方封装，哪天登录页改了，你改一处就够，不用翻二十条用例。到底改成什么样，可以去站内看当时同类项目的成本口径，再决定投入多少。

断言和测试数据：失败的原因要一眼看出来

断言决定这条用例有没有意义。写在能区分成功与失败的最小粒度上，别用「接口返回 200 就算过」这种假阳性断言。数据则要能自己造、自己清，别依赖线上环境的某条历史记录；数据互相污染是自动化用例随机失败的第一大来源。

假阳性断言

断言过宽，明明结果错了仍判定通过，掩盖真实问题。

真阳性断言

断言落在业务结果上，比如金额、状态、条数，错了必然失败。

数据自造自清

每条用例建自己的数据并清理，避免互相污染。

环境一致性

同一用例在不同环境结果不同时，先查环境差异再改脚本。

• 同一条用例多次执行结果不同时，先怀疑数据状态和环境差异，再怀疑脚本逻辑。
• 排查顺序：环境是否一致 → 数据是否干净 → 断言是否过宽 → 最后才看脚本本身。
• 断言失败信息里写清期望值与实际值，别只留一句「断言失败」。
• 接入大模型做断言辅助时，要接受输出不稳定的现实，判断标准可先到 模型底层概念随手对照（/ai-dict/category/tech） 把相关术语对一遍，再设计校验方式。

跑起来之后：流水线、失败处理和长期维护

先在本地稳定跑通，再挂到流水线。触发时机一般选提交后或每日定时；跑得太慢的用例拆开单独跑，别阻塞主干流程。失败处理要分类：真 bug、环境抖动、用例本身脆弱，三类对应三种动作，全部当 bug 报会很快消耗掉团队的信任。

1. 本地跑通再上线连续几天本地全部通过，再接入流水线。别拿没跑通的东西污染主干。
2. 选触发时机提交后触发快速集，每日定时跑全量集，慢用例单独排队。
3. 失败先分类按上表三类打标，每周复盘一次，看哪类最多。
4. 定期清理长期不跑的僵尸用例、改名没同步的标记、失败率高的脆弱用例，都要定期处理。

维护清单里最容易忽略的是失败率记录。哪条用例经常红、是环境问题还是脚本问题，记下来比修一次强。需要横向对比不同方案的稳定性时，去站内相关页面核对当时的数字，别用印象做判断。