为什么测试仍然感觉失灵（即使有 AI 与 MCP 工具）

Source: Dev.to

🚨 真正的问题

我们改进了测试的创建方式，但没有改进它们的可理解性。

即使在有 AI 的今天：

• 工具生成脚本
• 工具执行测试
• 工具提供日志

当测试失败时，我们又回到了同样的循环：

1. 打开日志
2. 查看截图
3. 回放视频
4. 尝试复现
5. 猜测

😤 AI 没能解决的

AI 帮助我们更快地编写测试，但它没有解决**“为什么测试会失败？”**——这个问题仍然耗时最长。

⏱️ 隐形成本

一次失败的测试不仅仅是一次失败。它意味着：

• 15–30 分钟的调试时间
• 多种工具的参与
• 开发与 QA 之间的上下文切换

而且有时这根本不是实际问题（只是偶发的 flaky 行为）。

💡 实际缺失的东西

我们不需要更多的测试生成。我们需要测试智能——能够：

• 用普通英文解释失败原因
• 检测跨运行的 flaky 模式
• 将失败与代码变更关联起来
• 推荐下一步该测试什么

🔄 对测试的另一种思考方式

而不是：

Generate → Run → Debug manually

如果变成：

Generate → Run → Understand instantly

⚙️ 示例

不再是通用的“未找到元素”，而是看到：

“登录按钮因最近的 CSS 更改导致标题组件布局位移而移动”

这就是：

• ❌ 数据
• ✅ 理解

🛠️ 实际意义

如果你今天使用的是现代测试栈：

• 你已经不再为编写测试而苦恼。
• 你在为理解失败而苦恼。

大多数调试仍然在主工作流之外进行，这正是大多数团队浪费时间的地方——不是执行，而是调查。

🧠 关键洞见

测试之所以“破碎”，不是因为缺少自动化，而是缺少洞察。

🚀 未来方向

测试的下一个阶段不会是：

• 更多框架
• 更多脚本
• 更多 AI 生成的代码

而是：

• 能解释的系统
• 能从失败中学习的系统
• 能指导测试决策的系统

仍处于早期阶段——非常期待你的反馈。

💬 想听听你的想法

在你的工作流中，哪件事更耗时——编写测试还是调试测试？