原创内容，未获授权禁止转载、转发、抄袭。

最近看了些讲 Vibe Testing 的文章。

里面有个观点我比较认同：传统自动化更擅长验证“结果对不对”，但很多真实问题出在“体验顺不顺”。

比如：

接口返回 200，但页面提示很奇怪
订单创建成功，但用户不知道下一步该干什么
表单校验没问题，但错误提示出现得太晚
流程能走通，但中间状态让人不放心

这些问题不一定会让自动化用例失败，但用户就是会觉得“不舒服”。

这就是 Vibe Testing 想解决的空间。

Vibe Testing 不是玄学

我不太喜欢把 Vibe Testing 翻译成“感觉测试”，因为听起来太虚。

更准确一点，我倾向于把它理解为：

用 AI 从用户视角评估产品流程体验，并把主观体验问题转成可复现证据的一种测试实践。

注意这里有几个关键词：

• 用户视角：不是只看 DOM、接口、状态码
• 体验质量：流程是否顺、反馈是否清楚、状态是否可信
• 可复现证据：不能只说“感觉不好”，要给步骤、截图、原因、建议

所以 Vibe Testing 不应该是：

AI 觉得这个页面体验不好

而应该是：

在第 3 步提交失败后，页面只提示“操作失败”，没有说明失败原因，也没有保留用户已填写内容。
这会导致用户无法恢复操作。建议展示具体错误，并保留表单输入。

这样才有测试价值。

它和传统测试有什么区别

传统自动化更像精确断言：

expect(response.status()).toBe(200);
expect(page.getByText('提交成功')).toBeVisible();

Vibe Testing 更像体验评审：

用户是否能理解当前状态？
失败后是否知道怎么恢复？
等待过程是否有反馈？
按钮文案是否符合用户预期？
流程中是否出现让人困惑的跳转？

可以简单这样区分：

类型	关注点	适合验证
单元测试	函数逻辑	算法、规则、边界
接口测试	数据契约	状态码、字段、幂等、权限
UI 自动化	流程是否走通	登录、下单、支付、查询
Vibe Testing	用户体验是否合理	提示、反馈、状态、恢复路径

它不是替代关系。更准确地说，传统测试解决“结果是否正确”，Vibe Testing 补充“过程是否顺畅”。

哪些场景适合做 Vibe Testing

我会优先把它用在这几类场景。

1. 新用户首次使用流程

比如注册、登录、创建项目、首次下单。

这类流程最怕“功能都对，但用户不知道下一步做什么”。

2. 多步骤业务流程

比如：

填写信息 -> 选择商品 -> 使用优惠券 -> 提交订单 -> 支付 -> 查看结果

传统测试能验证每一步是否成功，Vibe Testing 更适合评估中间状态是否清楚。

3. 错误和异常场景

很多系统的正常流程做得不错，异常体验很差。

比如：

库存不足
优惠券不可用
支付失败
权限不足
接口超时

这些场景非常适合让 AI 从用户视角评估：

提示是否说清楚
用户是否能继续操作
是否保留已填写内容
是否提供重试入口

4. AI 生成页面或 Vibe Coding 产物

AI 生成的页面经常能“看起来可用”，但细节不稳定：

按钮文案前后不一致
成功状态没有闭环
错误提示很生硬
空状态没有引导
加载态缺失

这类问题靠人工扫一遍很累，用 Vibe Testing 做第一轮体验巡检比较合适。

一套可落地的 Vibe Testing 流程

我建议不要上来就说：

帮我测一下这个页面体验好不好

这个提示词太空，AI 很容易泛泛而谈。

更好的流程是四步。

1. 定义用户角色
2. 定义业务目标
3. 定义体验评价维度
4. 要求输出证据和改进建议

可以直接用这个提示词：

你是资深测试工程师和用户体验评审。

请从“新用户首次使用”的视角，评估下面这个流程的体验质量：
注册账号 -> 登录 -> 创建项目 -> 提交保存。

请按以下维度检查：
1. 流程是否顺畅，有没有突兀跳转
2. 每一步用户是否知道当前状态
3. 错误提示是否具体，能否指导用户修复
4. 加载、成功、失败状态是否清晰
5. 表单输入是否被保留，失败后能否恢复
6. 文案是否一致，按钮含义是否明确

输出格式：
- 问题标题
- 复现步骤
- 观察到的现象
- 为什么影响体验
- 严重程度：高 / 中 / 低
- 建议改法

不要只给主观评价，必须给出具体证据。

关键是最后一句：不要只给主观评价，必须给具体证据。

没有证据的 Vibe Testing，就是聊天。

体验评分表可以这样设计

为了避免 AI 一会儿说好、一会儿说不好，最好给它一个评分表。

比如：

维度	评分标准
流程连续性	用户能否自然完成目标，中间是否中断
状态清晰度	加载、成功、失败、空状态是否明确
错误可恢复	出错后是否知道原因，能否继续操作
文案一致性	按钮、提示、标题是否前后一致
信息可信度	金额、状态、权限、结果是否让人放心
操作成本	是否有重复输入、无意义跳转、多余确认

让 AI 按 1~5 分评估，再要求它给证据：

请按 1~5 分评分。
每个低于 4 分的维度，必须给出页面证据和修改建议。

这样输出会稳定很多。

一个简单例子：优惠券下单流程

假设要评估优惠券下单流程。

传统自动化可能这样写：

await page.getByLabel('优惠券码').fill('TEST20');
await page.getByRole('button', { name: '应用优惠券' }).click();
await expect(page.locator('#discount')).toHaveText('20');
await expect(page.locator('#total')).toHaveText('79');

这只能说明金额算对了。

Vibe Testing 还应该问：

应用优惠券后，用户是否立刻知道优惠生效？
优惠金额和应付金额是否足够醒目？
优惠券不可用时，是否说明原因？
失败后优惠券输入框是否保留原值？
用户是否知道可以重新输入？

你会发现，这些问题不是单纯 expect 能覆盖的。

可以让 AI 输出这样的检查结果：

问题：优惠券不可用时提示不够具体

复现步骤：
1. 输入 EXPIRED20
2. 点击“应用优惠券”

观察：
页面只提示“优惠券不可用”，没有说明是已过期、已使用还是不满足门槛。

影响：
用户不知道应该换券、凑单，还是联系客服。

严重程度：中

建议：
按原因展示具体提示，例如“该优惠券已过期，请更换其他优惠券”。

如果做成评估表，可以长这样：

这就是 Vibe Testing 和普通断言的差异：普通断言告诉你金额有没有算对，Vibe Testing 更关注用户是否理解这个结果。

但它不能替代精确验证

Vibe Testing 最大的风险，是把 AI 的判断当成最终结论。

我不建议用它验证这些内容：

金额计算
支付扣款
库存扣减
权限控制
幂等逻辑
数据一致性
安全校验

这些必须靠接口测试、单元测试、数据库校验、日志和监控。

比如订单金额：

商品金额 99
优惠金额 20
应付金额 79

这不是“感觉差不多”就行，必须精确断言。

Vibe Testing 可以说：

金额展示是否清楚
优惠明细是否容易理解
用户是否知道最终支付多少钱

但它不能替你确认金额算法一定正确。

落地时最容易踩的坑

1. 提示词太虚

不要写：

帮我看看体验怎么样。

要写：

从新用户视角，按流程连续性、状态清晰度、错误可恢复性三个维度评估，并输出复现证据。

2. 没有评分标准

不同人对“体验好”的理解不一样，AI 也一样。

没有评分表，结果就会飘。

3. 不要求证据

只要结论不要证据，最后会变成一堆正确废话。

一定要让 AI 输出：

步骤
现象
影响
建议
严重程度

4. 把 Vibe Testing 当验收测试

它适合发现体验问题，不适合做最终质量门禁。

上线前的核心链路，仍然要有稳定的自动化回归和精确断言。

5. 不记录 AI 的判断过程

如果 AI 说“体验不好”，但没有截图、步骤、页面状态，开发很难修。

Vibe Testing 的输出最好能沉淀成缺陷记录，而不是一次性聊天结果。

相关工具能力怎么选

先说清楚：下面这些工具不一定都直接叫 Vibe Testing，但它们分别覆盖了自然语言测试、AI 生成测试、自愈维护、浏览器执行等相关能力。

从资料看，现在相关能力大致有几类：

类型	代表	适合场景
自然语言测试	testRigor	用英文/自然语言描述端到端流程
自愈测试	Healenium、Functionize、mabl	UI 变动后降低维护成本
AI 测试平台	Functionize、mabl 等	企业级测试生成、执行、分析
浏览器 Agent	Playwright MCP、Codex、Claude Code	探索页面、生成脚本、分析失败

如果团队已经有 Playwright 或 Selenium，不一定要马上换平台。

更现实的做法是：

先用现有自动化保证精确验证
再用 AI 做体验巡检和失败分析
最后把高价值检查点沉淀成稳定脚本

测试工程师应该怎么用它

我觉得 Vibe Testing 对测试工程师最大的价值，不是“少写代码”，而是让测试视角更靠近用户。

以前我们经常问：

这个字段对不对？
这个接口通不通？
这个按钮能不能点？

现在还应该问：

用户知不知道现在发生了什么？
失败后用户能不能恢复？
这条路径有没有让人困惑？
这个结果是否足够可信？

这其实更接近测试工作的本质。

测试不是证明系统能跑，而是发现系统在哪些地方会让用户受阻。

我的建议

如果你想试 Vibe Testing，可以从一个小流程开始。

比如：

登录
下单
优惠券
搜索
表单提交
权限不足
支付失败

不要一上来测整个系统。

每次只拿一个流程，按这套模板跑：

角色：谁在用
目标：他想完成什么
路径：他会怎么操作
维度：从哪些体验指标评估
证据：哪里让人困惑
建议：怎么改更好

最后把有价值的问题沉淀成：

缺陷单
体验检查清单
自动化断言
回归用例

这样 Vibe Testing 才不是概念，而是能进入测试流程的东西。

总结

Vibe Testing 不是让 AI 凭感觉乱评。

它真正有价值的地方，是让 AI 帮我们从用户视角补上体验验证这一层：

传统测试：这个功能对不对
Vibe Testing：这个流程顺不顺
测试工程师：判断哪些问题值得修，哪些必须精确验证

我的结论是：

能精确断言的，必须精确断言。
不能靠断言覆盖的体验问题，可以用 Vibe Testing 辅助发现。
AI 可以帮你扩大观察范围，但最终质量判断还是测试工程师的责任。

别神话它，也别忽视它。

在 AI 写代码越来越快的背景下，测试不能只跟着补脚本，更要补上体验、风险和质量判断。