掌握自动化测试用例编写的7个秘诀：从新手到专家的进阶之路

自动化测试用例编写最容易陷入一个误区：脚本能够执行通过，并不代表测试真正有效。我在参与多个 Web、接口和企业级业务系统测试时反复看到同一种情况，团队花了几周时间搭建自动化脚本，回归执行次数很多，但一旦页面改版、测试数据变化或接口响应变慢，失败数量就快速上升，最后测试人员不得不人工重跑。真正拉开新手与专家差距的，不是会不会调用某个框架，而是能否把业务风险设计成稳定、可重复、可验证、可维护的测试用例。

一、先讲核心结论：好用例不是“能跑”，而是“长期提供可信信号”

1. 自动化测试用例的价值，取决于四个结果

一个自动化用例至少要同时满足四个条件：能够稳定执行，能够准确判断结果，失败后能够定位原因，并且在需求变化后能够以合理成本维护。缺少其中任何一项，自动化都可能从质量保障工具变成噪声制造工具。

例如，登录成功用例只检查“首页元素是否出现”，看起来简单可靠，但它可能没有验证用户是否真的获得正确权限，也没有确认会话是否建立，更没有判断页面展示的数据是否属于当前账号。这样的脚本即使连续通过一百次，也只能证明页面大概率打开了。

我对自动化用例的判断标准是：它每次执行产生的结果，是否足以支持团队做出“发布、阻断或继续排查”的决定。如果失败后大家第一反应是“先重跑几次看看”，说明这个用例的诊断能力还不够。

2. 七个秘诀其实是一条完整链路

本文的七个秘诀并不是互相独立的技巧，而是一条从决策到治理的链路：先判断场景值不值得自动化，再从业务风险拆解场景，然后设计数据、步骤和断言，最后处理定位、依赖、诊断和维护。

1. 先判断场景是否值得自动化；
2. 从业务风险而不是页面按钮开始拆解；
3. 把前置条件、数据、操作和预期结果分开；
4. 选择稳定的定位方式和等待策略；
5. 让断言验证业务结果；
6. 控制用例之间的依赖，保证独立执行；
7. 建立可维护、可诊断的用例体系。

如果顺序反过来，直接从“选择框架、录制操作、生成代码”开始，通常会得到一批表面覆盖率很高、实际维护成本也很高的脚本。

二、背景和真实场景：为什么很多自动化项目最后变成“重跑项目”

1. 一个电商下单用例的两种写法

我经常用电商下单流程来判断团队的自动化设计成熟度。初级用例通常是：登录系统，打开商品页，点击购买，提交订单，检查页面出现“下单成功”。它的优点是编写快、演示直观，缺点是几乎没有验证价格、库存、优惠、订单状态和数据落库。

成熟一些的用例会先准备库存明确的商品和独立账号，再校验商品价格、购买数量、优惠计算、订单状态、库存扣减和支付待处理状态。执行结束后还要清理订单或标记测试数据，并保留订单编号和接口响应，方便失败时定位。

这两种用例都可能在本地运行通过，但它们提供的质量信号完全不同。前者只能说明页面流程没有明显阻断，后者才有机会发现金额计算错误、库存扣减异常和订单状态不一致。

2. 自动化失败不一定是产品缺陷

在实际排查中，我会先把失败分成三类：产品缺陷、脚本缺陷和环境或数据故障。很多团队把三类失败都统计为“自动化不稳定”，然后盲目增加重试次数，结果只是把问题推迟了。

产品缺陷通常表现为稳定复现、接口和页面结果同时异常，或者在相同条件下人工与自动化都能观察到错误。脚本缺陷往往与错误定位、等待时机、断言对象或数据清理有关。环境故障则可能来自服务超时、依赖系统不可用、数据库连接异常或测试数据被其他任务修改。

重试机制只能处理短暂性故障，不能用来掩盖断言错误、数据污染和定位器脆弱。如果一条用例第一次失败、第二次通过的比例持续升高，团队应该先分析失败分类，而不是把重试次数从一次改成三次。

三、七个秘诀之一：先判断场景是否值得自动化

1. 用收益和维护成本做判断

自动化不是把所有手工用例都翻译成代码。一个场景是否值得自动化，至少要同时看执行频率、规则稳定性、人工重复成本、结果是否可判定以及维护难度。

高频回归、规则清晰、结果稳定、人工操作重复且容易出错的场景，通常适合优先自动化。核心交易流程、权限校验、接口契约、关键状态流转和高频数据校验，往往比一次性活动页面更值得投入。

相反，探索性测试、视觉体验判断、需求仍在快速变化的页面，以及需要复杂人工观察的场景，不一定应该立即自动化。它们可以先通过手工测试沉淀规则，等业务行为稳定后再选择适合的自动化层级。

2. 用简单评分避免“凭感觉上自动化”

我通常会给候选场景做一个五项评分，每项 1，5 分。执行频率、业务稳定性、人工成本和结果可判定性分数越高，自动化优先级越高；维护成本分数则需要反向考虑。

可以采用下面的计算方式：自动化优先级 = 执行频率 + 人工成本 + 结果可判定性 + 业务风险 – 维护成本。这个公式不是精确的财务模型，但能迫使团队把“为什么自动化”讲清楚。

例如，一个每天执行三次的库存扣减接口，规则稳定、结果明确、人工重复成本高，即使编写需要两天，也有较高优先级。一个只在年终活动使用一次、页面还会随营销方案变化的弹窗流程，即使录制只需要半小时，也未必值得进入核心回归集。

四、七个秘诀之二和之三：从业务风险拆解，并把用例结构写完整

1. 不要从“页面上有什么按钮”开始

新手写用例时，常见思路是按照页面顺序罗列元素：输入账号、输入密码、点击登录、检查首页。这种方式容易遗漏真正的业务风险，因为页面只是系统的表现层。

我更推荐先问四个问题：用户最不能做错什么？系统最容易在哪个状态下出错？哪些数据必须保持一致？不同角色看到的结果是否不同？这些问题会把测试思路从页面操作引向业务规则。

以登录为例，至少应该考虑账号不存在、密码错误、账号锁定、密码过期、验证码错误、权限不足、重复提交、会话失效和退出后回退等场景。它们不一定全部通过 UI 自动化实现，有些更适合接口层或服务层验证。

2. 用“正常、异常、边界、权限”四类场景建矩阵

场景矩阵的价值在于避免只覆盖一条绿色路径。正常场景验证主流程，异常场景验证系统如何拒绝错误输入，边界场景验证临界值，权限场景验证不同角色看到和能操作的范围。

写完矩阵后，我会再检查每一行是否都能回答“输入是什么、动作是什么、预期结果是什么、失败证据在哪里”。如果只能写出操作，却说不清预期结果，这条用例还没有达到自动化条件。

3. 前置条件、数据、操作和预期结果必须分离

很多脚本难以维护，是因为所有内容都混在测试方法里。用户创建、商品准备、页面操作、业务断言和数据清理被写成一长段代码，任何一个需求变化都会影响整条链路。

更稳妥的结构是把用例拆成四块：前置条件负责建立状态，测试数据负责描述输入，操作步骤负责触发行为，预期结果负责判断业务是否正确。清理动作则作为独立的收尾阶段管理。

测试目标：验证库存不足时系统不会创建有效订单
前置条件：

创建库存为 2 的测试商品
创建具备购买权限的独立测试账号
确认商品处于可售状态
测试数据：

购买数量：3

商品库存：2

测试账号：每次执行动态生成

操作步骤：

提交购买数量为 3 的下单请求
查询订单创建结果
查询商品库存状态
预期结果：

系统拒绝下单并返回库存不足
不生成可支付订单
商品库存仍为 2
失败时记录请求编号和响应内容
清理动作：

1. 删除本次执行创建的测试数据
2. 回收测试账号和临时资源

上面的结构看似比“点击下单并检查成功”复杂，但它能够复现、能够诊断，也能在接口层直接执行。用例写得更细，不是为了增加文档篇幅，而是为了减少执行结果的歧义。

五、七个秘诀之四和之五：稳定定位、合理等待与有效断言

1. 定位器要面向测试稳定性设计

在 UI 自动化中，最常见的不稳定来源不是框架本身，而是定位方式。动态生成的元素编号、过深的层级选择器、依赖可变文案的定位方式，都会让页面的小改动演变成大量脚本失败。

优先级较高的定位方式通常包括专门的测试属性、稳定的业务标识、可靠的语义定位和明确的组件边界。定位器应该表达“我要找哪个业务元素”，而不是表达“我要找页面上第几个按钮”。

如果产品团队愿意配合，最好在需求或开发规范中预留稳定的测试属性。这样做的成本通常低于测试人员在上线后反复修复脆弱定位器，也能减少测试代码对页面样式和布局的耦合。

2. 等待页面状态，不要等待一个固定秒数

固定休眠是新手最容易使用、也是最容易滥用的方式。设置 3 秒等待，可能在本地环境勉强通过；换成网络更慢的环境，3 秒不够；换成响应更快的环境，又会白白增加执行时间。

更合理的做法是等待可观察状态，例如元素可交互、接口响应完成、订单状态变为目标值、加载遮罩消失或特定业务数据出现。等待条件应该与业务状态相关，而不是与某台机器的平均响应速度绑定。

需要注意的是，等待时间过长也不是稳定性的答案。过长的超时会让真正的故障被延迟暴露，导致整个回归任务变慢。建议为不同类型操作设置不同的超时策略，并在失败日志中记录实际等待过程。

3. 断言必须验证“结果发生了什么”

断言可以分成三层。第一层是界面反馈，例如错误提示、按钮状态和页面跳转；第二层是接口结果，例如状态码、响应字段和业务编码；第三层是数据或状态结果，例如订单记录、库存变化、权限生效和消息投递。

关键业务流程最好不要只依赖第一层断言。页面上出现“提交成功”并不代表后端写入成功，也不代表异步任务最终完成。对于订单、支付、权限和库存等场景，至少需要结合接口或数据层进行二次确认。

六、七个秘诀之六：控制依赖，让每条用例能够独立执行

1. 用例串联会放大失败影响

如果第二条用例必须依赖第一条用例创建的用户，第三条用例又依赖第二条用例修改后的状态，那么第一条失败后，后续失败就很难判断到底是哪一个业务行为出了问题。

独立执行并不意味着每条用例都要从零开始通过 UI 完整操作。恰恰相反，成熟的自动化体系会使用接口、Fixture、初始化脚本或数据工厂准备状态，把 UI 留给真正需要验证的交互。

例如验证订单取消，不必每次都从注册、登录、选品、下单开始。可以通过可靠的数据准备接口直接创建“待支付订单”，然后通过页面或接口验证取消行为。这样既缩短执行时间，也减少无关步骤对结果的干扰。

2. 共享数据是并行执行的隐形风险

单线程执行时，共享账号和固定商品可能暂时看不出问题；一旦进入并行回归，两个任务同时修改同一订单、同一库存或同一用户状态，失败就会变得随机。

解决方式包括使用唯一业务编号、动态生成账号、按任务分配资源、建立租户级隔离、设置数据回收机制，以及为并行任务增加执行上下文。数据隔离不只是数据库问题，也包括缓存、消息、文件和第三方依赖。

如果测试环境暂时不具备完整隔离能力，应明确哪些用例可以并行，哪些用例必须串行，并把这个约束写入执行策略，而不是交给执行人员凭经验判断。

3. 清理动作要和准备动作一样可靠

很多自动化失败并不是因为准备数据失败，而是因为上一次执行留下了脏数据。下一次任务读取到旧订单、旧权限或旧库存后，断言自然会出现偏差。

我建议每条涉及状态变化的用例都记录自己创建或修改的资源，并在结束阶段执行清理。即使测试中途失败，也要通过统一的收尾机制尽力回收数据。对于无法删除的业务记录，可以使用明确的测试标记、过期策略或独立租户隔离。

七、七个秘诀之七：建立可维护、可诊断的用例体系

1. 用分层设计控制修改范围

我通常把自动化代码分成测试场景层、业务操作层、页面或接口封装层、测试数据层和基础设施层。测试场景层描述“验证什么”，业务操作层描述“如何完成一个业务动作”，底层封装负责与页面元素、接口协议或数据库交互。

这种分层的直接收益是需求变化时修改范围更小。比如登录页面增加了验证码，可能只需要调整登录能力和测试数据准备，不必逐条修改所有依赖登录的业务用例。

但封装也不能过度。一个只被调用一次、且没有稳定业务含义的操作，强行抽象成公共方法，反而会让代码阅读变得困难。我的原则是：重复出现且语义稳定的行为才值得封装。

2. 统一命名、标签和执行层级

自动化用例数量增加后，团队最先遇到的不是代码问题，而是“到底该跑哪些用例”。建议至少按业务模块、风险等级、执行耗时和回归层级设置标签。

• 冒烟层：验证系统是否具备继续测试的基本条件；
• 核心回归层：覆盖高风险、高频业务流程；
• 完整回归层：覆盖更广的边界、权限和异常场景；
• 专项验证层：针对性能、兼容性、数据一致性或外部依赖。

标签还应和发布流程结合。例如每次提交只运行快速冒烟集，每日构建运行核心回归集，版本发布前再运行完整回归集。这样可以在反馈速度和覆盖范围之间取得平衡。

3. 失败时留下足够的证据

一条失败信息如果只有“期望值 A，实际值 B”，排查人员仍然需要重新构造上下文。高质量报告至少应该包含用例名称、执行环境、测试数据标识、关键请求、响应内容、页面截图、页面源码、日志和前后状态。

对于异步业务，还应记录轮询次数、最后一次响应、状态变化时间和超时阈值。对于权限问题，要记录角色、租户、账号类型和接口返回的授权信息。证据越接近失败现场，排查越不依赖人工重现。

4. 定期删除低价值用例

自动化用例库不能只增不减。重复用例、长期失败用例、已经废弃的业务流程和无法稳定执行的脚本，都会拖慢回归并降低团队信任。

我会定期查看四类数据：执行频率、通过率、失败分类和维护耗时。连续多个周期没有执行过的用例，需要确认是否仍有业务价值；失败率长期偏高且无法稳定定位的用例，应暂停进入核心门禁，先修复或降级为专项任务。

八、不同情况下的实施策略：从新手练习到企业级落地

1. 新手：先练一条完整、可复现的业务链路

刚开始学习时，不建议一上来就搭建复杂框架。可以选择登录、搜索、下单或文件导出中的一条稳定链路，完整经历需求理解、数据准备、操作执行、断言、失败截图和清理。

新手阶段最重要的不是写出很多代码，而是建立正确的用例意识。每写一条脚本，都要补充三个问题：它验证了什么风险？如果失败，我能知道哪里错了吗？换一份数据后还能重复执行吗？

2. 有基础的测试人员：从单条脚本转向场景矩阵

当你能够稳定编写主流程后，下一步不是继续堆代码，而是扩大场景设计能力。围绕一个业务功能补齐异常、边界、权限、重复提交、超时和数据一致性，并判断哪些场景适合 UI、接口或更底层的自动化。

此阶段建议建立统一的用例模板和数据准备方式。模板不应只是文档格式，还要能够映射到代码结构，让前置条件、数据、操作和断言在实现层保持一致。

3. 测试开发工程师：建设公共能力而非重复造轮子

当自动化规模扩大后，个人技巧会逐渐失效，团队需要统一的页面对象、接口客户端、数据工厂、环境配置、报告和失败分类机制。公共能力的目标不是让代码看起来更复杂，而是让业务用例更短、更接近测试意图。

如果团队使用某项目管理平台管理需求、缺陷和测试任务，可以将自动化用例与需求、版本和缺陷建立关联，形成从需求风险到执行结果的追踪链路。对于中大型企业，尤其是 100 人以上组织，还需要提前评估权限、审计、私有化部署、数据合规和现有工具迁移成本。若已有 Jira 流程，也应先盘点字段、状态和历史数据，再决定是否进行平滑迁移，不能只比较界面功能。

4. 测试负责人：用质量信号而不是脚本数量衡量成果

管理层最容易看到的是用例数量和自动化覆盖率，但这两个指标都不能直接代表质量。更有价值的指标包括核心风险覆盖率、稳定通过率、误报率、平均排查耗时、失败分类率、维护人时和缺陷提前发现比例。

如果自动化数量增加一倍，但失败后仍需要人工重跑，核心业务风险没有覆盖，或者维护耗时超过节省的人工回归时间，那么这项建设就需要调整方向。

九、AI 工具如何辅助编写，但不能替代测试设计

1. 适合交给 AI 的工作

AI 很适合处理结构化、重复性较高的任务。例如根据一段需求补充正常和异常场景，根据已有代码生成测试骨架，将重复的定位器或接口调用重构成公共方法，或者帮助检查测试数据是否覆盖边界值。

我会把 AI 当成“场景扩展器”和“代码助手”，而不是测试结论的生产者。它可以提醒我考虑密码过期、重复提交、权限变化等情况，但是否属于当前系统规则，仍需要由熟悉业务的人确认。

2. 不应直接相信生成的脚本

AI 生成的自动化代码常见问题包括使用不存在的接口、虚构元素属性、选择不适合当前框架的等待方法、把页面提示当成最终结果，以及忽略数据清理和权限上下文。

尤其在企业系统中，真实业务数据可能包含客户信息、订单信息、内部接口和权限配置。提交给外部工具前必须进行脱敏，并确认组织的数据安全政策。为了节省几分钟编码时间，把生产数据和敏感配置直接复制到公共服务中，是不值得的风险。

3. 推荐一套可审查的使用流程

1. 先由测试人员写清业务目标、风险和验收条件；
2. 让 AI 补充场景、边界和可能遗漏的异常；
3. 人工筛选与当前产品规则相关的建议；
4. 让 AI 生成用例结构或代码骨架；
5. 在脱敏环境中执行并检查定位、等待和断言；
6. 补充日志、数据清理和失败证据；
7. 通过代码评审后，再纳入持续集成。

AI 能够缩短“从想法到初稿”的时间，但不能缩短“确认测试正确”的责任。最终测试结论必须建立在真实执行、明确断言和可复核证据之上。

十、不同情况下的取舍：UI、接口、数据层和平台化如何选择

1. 什么时候优先使用 UI 自动化

当目标是验证真实用户操作、页面交互、关键表单行为、权限展示和前端状态变化时，UI 自动化更有价值。它能够发现元素不可见、按钮不可用、页面跳转错误和前端数据展示异常。

但 UI 自动化通常执行更慢，也更容易受到浏览器、网络、页面结构和异步渲染影响。因此不应把所有业务规则都放在 UI 层验证。

2. 什么时候优先使用接口自动化

当目标是验证业务规则、接口契约、状态流转、异常参数和数据一致性时，接口自动化通常更快、更稳定，也更适合生成和清理测试数据。

接口自动化不能完全替代 UI 验证。接口返回正确，不代表前端正确展示，也不代表用户角色能够看到或操作对应功能。更合理的做法是让接口层承担大部分业务规则验证，让 UI 层保留关键用户路径。

3. 什么时候需要数据层或服务层验证

涉及库存、金额、权限、账务、消息投递和异步任务时，单独看页面和接口可能仍然不够。此时可以通过受控的数据查询、事件消费结果或服务状态确认业务是否完成。

数据层验证必须谨慎处理权限和环境差异，不建议让测试用例随意依赖生产结构或绕过业务接口修改数据。数据准备可以更直接，但结果验证仍要遵守可审计和最小权限原则。

4. 什么时候值得建设统一测试平台

当团队存在多个产品线、多个测试框架、复杂权限和持续集成任务时，统一平台可以帮助管理用例、执行计划、环境、报告和需求关联。但平台化不是解决所有脚本问题的捷径，如果底层用例本身没有稳定数据和明确断言，平台只会更快地执行不可靠脚本。

对于中大型企业，平台选型应同时比较部署方式、权限模型、审计要求、接口开放能力、历史数据迁移、团队学习成本和供应商服务能力。支持私有化部署、具备 Jira 平滑迁移能力的某项目管理平台，在国产化和数据合规要求较高的场景中可能更适合，但仍需通过试点验证实际迁移效果。

十一、发布自动化用例前的检查清单

1. 场景是否值得自动化

• 该场景是否高频执行，或者对应高风险业务？
• 业务规则是否已经足够稳定？
• 结果是否能够通过明确数据或状态判断？
• 维护成本是否低于长期人工重复成本？

2. 用例结构是否完整

• 前置条件是否可以自动准备并重复执行？
• 测试数据是否独立、可追踪、可清理？
• 操作步骤是否与验证目标一一对应？
• 预期结果是否具体到状态、金额、权限或数据？

3. 脚本是否足够稳定

• 定位器是否使用稳定的测试属性或业务标识？
• 是否使用状态等待而不是无依据的固定休眠？
• 是否避免依赖其他用例的执行顺序？
• 并行运行时是否会发生账号、订单、库存或文件冲突？

4. 失败后是否容易诊断

• 是否保存日志、截图、页面源码和接口请求响应？
• 是否记录测试账号、订单号、数据编号和环境信息？
• 是否能够区分产品缺陷、脚本缺陷和环境数据故障？
• 是否设置了合理重试，而不是用重试掩盖真实问题？

5. 是否纳入长期治理

• 用例是否有明确负责人、标签和回归层级？
• 是否统计稳定通过率、失败分类率和维护耗时？
• 是否定期删除重复、失效和低价值用例？
• 是否将关键结果与需求、版本和缺陷建立关联？

十二、从新手到专家：真正的进阶路线

1. 新手阶段：先学会把需求写成可验证结果

新手的第一项能力不是熟练使用框架，而是读懂需求中的用户、输入、状态和结果。你应该能够把“用户可以正常下单”改写成“库存充足且具备购买权限的用户提交订单后，系统创建待支付订单，金额等于商品金额减去有效优惠，并正确扣减可售库存”。

表达越具体，后续越容易选择测试数据、设计断言和判断失败原因。代码只是这个过程的最后一环。

2. 熟练阶段：从主流程扩展到风险矩阵

熟练阶段要学会识别异常、边界、权限、重复操作和依赖失败。你需要知道哪些场景应该自动化，哪些场景保留手工探索，哪些场景适合接口验证，哪些场景必须结合数据状态确认。

这个阶段的标志不是脚本数量，而是面对一个新功能时，能够快速给出场景矩阵和自动化分层方案。

3. 高级阶段：把个人经验变成团队能力

高级测试人员需要建设数据工厂、公共封装、报告体系、失败分类和持续集成策略，让其他成员能够按照统一方式编写和维护用例。

如果只有少数人知道数据怎么准备、环境怎么恢复、失败怎么排查，那么自动化仍然依赖个人英雄主义，无法稳定扩展。

4. 专家阶段：用质量信号影响发布决策

专家不仅关注某条用例是否通过，还会观察自动化结果是否可信：核心风险覆盖了多少，误报率是否上升，失败是否集中在某个环境，维护投入是否超过收益，哪些用例应该退出核心回归集。

专家的终点不是拥有最多脚本，而是能让团队相信自动化结果，并据此做出更快、更稳妥的工程决策。

十三、总结：不要追求“自动化一切”，要追求“验证最重要的风险”

掌握自动化测试用例编写的七个秘诀，真正要改变的是思考顺序。不要先问“这个页面怎么定位”“这段代码怎么生成”，而要先问“系统最可能在哪里出错”“这个风险如何稳定复现”“什么结果能够证明系统真的正确”。

从场景选择开始，经过业务风险拆解、数据设计、稳定定位、有效断言、依赖隔离和持续治理，自动化用例才会从一次性脚本变成长期可用的质量资产。

如果你准备立刻实践，可以选择一个登录、下单、权限变更或数据导出场景，按本文顺序完成一次改造：先写风险矩阵，再拆前置条件和测试数据，补充业务断言，最后加入失败证据和清理机制。不要同时改造几十条用例，先把一条用例做成真正稳定、可诊断、可复用的样板。

完成第一条样板后，再把同样的方法推广到同一模块的其他场景。这样建立起来的自动化体系，虽然起步看起来比录制脚本慢，但它更容易通过持续集成验证，更容易被团队复用，也更有可能在长期回归中真正节省时间。