反思自动化：AI 时代的非传统测试策略
重新评估自动化成本
重新评估“自动化”
在软件工程领域，“自动化”几乎是一个神圣的词汇。它意味着效率、可靠性和可扩展性。然而，PSPDFKit 的创始人 Peter Steinberger 提出了一个颠覆性的观点：在 AI 驱动的开发初期，过度依赖传统的端到端（E2E）自动化工具（如 Playwright 或 Selenium）实际上会拖慢你的步伐。
这听起来有违直觉。自动化测试不是应该节省时间吗？是的，但在 AI 开发的独特背景下，答案并非如此简单。我们需要打破“自动化即高效”的迷思，从一个全新的角度——“上下文经济学”——来审视我们的测试策略。
自动化测试的隐性成本
传统自动化工具的成本不仅仅是编写和维护脚本的时间。在与 AI 协作时，它们会带来两种主要的“隐性税”：破坏心流和挤占上下文。
首先是心流成本。开发者的“心流”是一种高度专注、高效的工作状态。快速的反馈周期是维持心流的关键。当你修改一行代码，你希望立刻知道结果。单元测试通常能在几秒内完成，反馈几乎是即时的。
然而，Playwright 这类 E2E 工具需要启动一个完整的浏览器实例，模拟用户交互，等待页面加载。一次完整的测试运行可能需要 30 秒甚至数分钟。这种漫长的等待会无情地打断开发者的心流。你可能会分心去看手机、回复邮件，当测试最终完成时，你需要花费额外的精力才能重新回到之前的思维轨道。这种上下文切换的累积成本是巨大的。
更关键的是上下文成本。在 AI 辅助开发中，上下文窗口是我们最宝贵的资源。它决定了 AI 能“记住”多少信息，从而影响其生成代码的质量和相关性。一个典型的 Playwright 脚本不仅包含测试逻辑，还必须引用庞大的 DOM（文档对象模型）结构来定位元素。
// 一个简单的 Playwright 脚本
import { test, expect } from '@playwright/test';
test('has title', async ({ page }) => {
await page.goto('https://playwright.dev/');
// 为了让 AI 理解这个测试，它需要知道页面的 DOM 结构
// 比如 'h1'、'text=Playwright' 等选择器
await expect(page).toHaveTitle(/Playwright/);
});
test('get started link', async ({ page }) => {
await page.goto('https://playwright.dev/');
// 这个测试依赖于一个带有 'Get started' 文本的 <a> 标签
// DOM 结构一旦变化，测试就会失败
await page.getByRole('link', { name: 'Get started' }).click();
await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
});
当你把这样的脚本和相关的 HTML 结构一起放入 AI 的上下文窗口时，它们会迅速消耗掉宝贵的空间。这就像试图在一个小背包里塞进一本厚重的电话簿。结果就是，留给核心业务逻辑、函数定义和问题描述的空间变少了。当上下文被无关的 DOM 细节和脆弱的测试代码填满时，AI 就更容易产生“幻觉”——生成不相关或错误的代码，因为它丢失了最重要的信息。
AI 开发中的过早优化
在传统软件开发中，我们通常在功能稳定后编写 E2E 测试。但在 AI 驱动的开发流程中，尤其是在早期探索阶段，产品的功能和界面变化极快。你今天依赖的 DOM 结构，明天可能就被 AI 生成的另一个版本完全替代了。
在这种情况下，为不稳定的界面编写脆弱的 E2E 自动化脚本，是一种典型的“过早优化”。你花费了大量时间去编写和维护这些脚本，而它们在下一次迭代中就可能完全失效。这不仅浪费了开发时间，还给 AI 的上下文增加了不必要的噪声。
这个流程对比清晰地展示了问题所在。传统开发的稳定需求为 E2E 测试提供了坚实的基础。而 AI 开发的本质是探索和迭代，界面和功能随时可能发生根本性变化。在这种动态环境中，依赖具体 DOM 结构的测试脚本变得异常脆弱。
因此，在 AI 开发的早期，我们应该优先考虑那些不依赖于 UI 实现细节的测试，比如业务逻辑的单元测试。当产品形态逐渐稳定下来后，再有选择地引入 E2E 测试，才是明智之举。
现在，让我们通过几个问题来巩固今天学到的知识。
根据文章，在 AI 驱动开发的初期阶段，为什么过度依赖传统的端到端（E2E）自动化测试会适得其反？
文章中提到的“上下文经济学”指的是什么？
总而言之，选择测试工具和策略时，不能一概而论。在 AI 驱动开发的浪潮中，我们需要重新评估每一个决策的成本，尤其是在宝贵的上下文窗口和开发者的心流方面。放弃在早期阶段进行全面的 E2E 自动化，不是倒退，而是一种更适应新范式的智慧。