不知道大家有没有一个感受，刚开始使用自动化测试工具时，感觉非常方便，但用久了会发现一个问题，录了 50 条用例，跑了一个月之后还能稳定通过的，可能不到 30 条。

是工具不好吗？不一定。更多时候，是录制时的方法不对。

今天，我们来聊聊一条好的测试用例应该长什么样，并以零代码自动化测试平台回演 CueCast 为例，手把手带你创建一个可以长期使用的测试用例。

什么样的用例才算好用例

真正能进入回归流程的自动化测试用例，至少要满足三个条件。

第一，跑得稳。同样的环境和数据，跑十次能过九次以上。不因为页面加载快慢、网络抖动、元素渲染顺序就随机失败。

第二，错得明。失败了能一眼看出哪一步出问题、为什么出问题。不用打开截图逐帧对比，不用去看代码才能推理出问题原因。

第三，改得动。页面按钮换了位置、交互流程有小改动时，用例应该可以局部修复，而不是整条报废重录。

下面，我们以“新增用户”测试流程为例，看看在实操过程中，录制测试用例要注意些什么。

1. 录制前：花一分钟省一小时

做 Web 自动化测试时，很多人打开页面就开始点，但你最好先花一分钟做两件事。

第一，手动走一遍路径。 确认页面路径通顺，确认你需要的测试数据已经准备好了。

第二，从干净状态开始。 清缓存、退出登录、关闭多余浏览器标签页。

还有一个小细节，想清楚起始 URL 应该设在哪。录登录流程就从登录页开始，录登录后的功能就直接从功能页开始。不要每条用例都从打开首页导航过去。

2. 录制时，少即是多

准备好之后，就可以开始录制这条用例了。这条路径本身不复杂：

打开用户管理页面
点击“新增用户”
填写用户名
填写邮箱
点击“确认创建”

但录制时很容易被忽略一个问题：操作页面时，常常有一些多余动作，比如多滚动几下、重复点击。这些动作录制进用例中，可能会变成后续回放失败的原因。

录制时，可以记住几个原则。

第一，等页面响应后再操作。比如点击“新增用户”之后，先等弹窗真正出现，再填写用户名。

第二，不要把废动作录进来，比如无意义的 hover、多余滚动、重复点击。

第三，输入框先清空再填写，避免默认值或上一次输入内容影响回放。

3. 加上动态值和等待，让它可以反复跑

这条用例里，第一个容易踩坑的地方是用户名。

假设录制时填写的是 test-user，第一次回放可能可以成功创建。但第二次回放时，系统很可能会提示“用户名已存在”。

这主要是因为用例设计时没有考虑重复执行。很多后台系统都不允许创建同名数据，用户名、项目名称、审批单编号等，这些字段通常都要求唯一。

这种情况下，可以使用动态值。

比如用户名可以配置成 user-{timestamp}。这样每次回放都会生成一个新的用户名和邮箱，既能避免重复，也方便后续在列表里识别测试数据。

常见的动态值包括：

• 前缀 + 时间戳：固定前缀加上时间戳，可读且唯一
• 时间戳：填入当前时间
• 随机字符串：纯随机字母数字，适合对可读性没要求的场景
• 随机数字：纯数字，适合编号、手机号后缀

处理完动态值之后，用例就变成：

打开用户管理页面 
点击“新增用户” 
填写用户名：user-{timestamp} 
填写邮箱
点击“确认创建” 
等待 1000ms（列表刷新）

这里的“等待列表刷新”也很重要。点击提交之后，页面不会在同一瞬间完成所有事情。它可能会先调用接口，然后弹出“创建成功”的提示，接着关闭新增弹窗，再刷新用户列表，最后才显示新用户。所以这里可以加一个短暂等待 1000ms。

4. 断言验证业务结果

录制结束并不代表用例创建完成，因为它只完成了操作。我们还需要加上断言。

断言通常放在关键路径的末尾，比如创建后、提交后、删除后、状态变更后，用于判断结果。

这里先解释一下断言常见的三种目标和四种匹配方式：

断言目标：

目标	占日常使用	适用场景
整页文本 + 包含	80%	最常见的验证方式，判断某段文案是否出现在页面上
指定元素	15%	需要精确校验某个字段、单元格或区域的值
错误提示	5%	负向校验，验证错误密码等场景的错误提示文案

匹配方式：

• 包含：最常用，只要页面文本包含期望值即通过，容错最好
• 等于：精确匹配，适合字段值校验
• 不包含：验证某段文案确实没出现
• 正则匹配：需要模式匹配但不在意具体值

比如在这条新增用户用例里，只看到“创建成功”还不够，还需要加两层断言：

断言：整页文本包含“创建成功”
断言：整页文本包含“user-”

第一层断言验证提交动作得到了系统反馈，第二层断言验证业务结果真的成立。

这样一来，它就可以验证完整的业务结果：用户提交成功，并且新用户确实出现在列表中。

现在，一条完整的测试用例就变成了：

Step 1  navigate → 打开用户管理页面
Step 2  click    → 点击「新增用户」按钮
Step 3  input    → 填写用户名（动态值：前缀 + 时间戳，如 user-）
Step 4  input    → 填写邮箱
Step 5  click    → 点击「确认创建」
Step 6  wait     → 等待 1000ms（列表刷新）
Step 7  assert   → 文本断言：整页文本 + 包含，「创建成功」
Step 8  assert   → 文本断言：整页文本 + 包含，用户名前缀「user-」

5. 当用例变复杂，智能步骤可以补上短板

如果“新增用户”只是填写用户名和邮箱，普通录制通常就够了。

但真实后台系统里，新增用户可能还需要选择部门、分配角色、选择权限组，甚至要在一个树形组织架构里找到某个节点。

这些场景的共同点是，页面元素不一定固定，比如角色列表的顺序可能会变。如果用例只是记录“点击第三行第二个按钮”，后面数据顺序一变，就很容易失败。

这时更适合用智能步骤来描述业务目标。

智能步骤是指用自然语言描述要完成的界面操作，它非常适合以下场景：

• 多层下拉联动，第二层的选项取决于第一层的选择
• 树形控件或菜单里的特定节点
• 需要验证随机数据下的连锁反应

写智能步骤要注意，描述目标，不是描述动作。

❌ 不好的写法：点击第三行第二个图标

✅ 好的写法：点击角色名称为“管理员”的这一行中的选择按钮

关键是说清楚在哪一行、在哪一列、操作什么。

6. 失败后能定位，才适合进入回归

自动化测试用例失败时，很多人的第一反应是重新录一条。但这不一定是最高效的方式，有时候只需要局部修改。

还是以这条新增用户用例为例。如果失败在点击“新增用户”这一步，可能是按钮定位变了，也可能是页面还没加载完成。如果失败在填写用户名这一步，可能是弹窗还没渲染出来，也可能是输入框结构变化了。

一般失败报告会告诉你：第几步失败、失败原因、失败时的页面截图。

拿到这些信息之后，按这个顺序排查：

1. 看截图：页面还没加载完？进了错误页面？还是出现了意料之外的弹窗？
2. 调定位：如果页面没问题但找不到元素，调整这一步的 CSS 选择器或 XPath
3. 加等待：如果页面渲染慢，给这一步加一个执行前等待
4. 重录局部：如果页面改版、结构大变，这一段直接重新录制

到这里，这条“新增用户并验证”的用例已经不只是一次操作记录了。它有清晰的主路径，有动态用户名和邮箱，有提交后的适度等待，有“创建成功”和列表结果的双重断言。失败后，也可以按步骤定位和局部修复。

下一步，它就可以进入团队的回归流程。比如在发版前执行一次，核心功能改动后执行一次，失败后通过通知同步给相关同学，后续页面小改时继续在原用例上维护。

从一次录制，到长期回归

回到最开始的这条新增用户用例。它看起来只是一个很普通的后台操作流程，但完整走下来，已经包含了一条好用例最重要的几个要素：路径清晰，步骤干净，数据能重复执行，关键结果有断言，复杂交互能处理，失败之后能定位，页面变化后能维护。

当一条条核心路径都能这样沉淀下来，自动化测试才会真正进入团队的日常回归流程。

---

回演 CueCast 是一款 AI 驱动的零代码 Web 自动化测试工具。在浏览器上点选操作即可录制用例，支持 CDP 真实回放、智能步骤、文本/JSON 断言、执行计划和 Webhook 通知。

官网：www.icuecast.com