AI 修复 Cypress 测试，先划清修改权限

Cypress 测试自动修好了，购买流程却可能已经测错：原来的下单按钮消失，AI 改点另一个「Continue」，只因两个流程最终都显示「Thank you」，测试便恢复绿色。选择器找到了，业务保障却丢了。

作者是 Cypress Ambassador，这篇文章补充了其 CypressConf 2026 分享。核心主张很明确：让 AI 修测试之前，先规定它能改什么，并验证修完的测试仍能抓住原来的缺陷。这套审查思路，比单纯追求通过率更值得带回团队。

AI 可以分析失败，但修改必须有边界

作者主张把自动分析和自动修改分开。AI 可以帮助定位失败原因，但不能因为目标是「修好测试」，就顺手删断言、跳过用例，或者把点击条件放宽到随便命中一个按钮。

文章提到要区分三类变化，但提供的原文没有完整列出分类，不能替作者补齐。它给出的明确做法，是把允许修改的范围写成可审查的策略。

这段配置把文件范围、允许操作和业务后置条件放在了一起：

const repairPolicy = {
  editableFiles: ['cypress/e2e/checkout.cy.ts'],
  allowed: ['selector-replacement', 'wait-for-observable-event'],
  forbidden: [
    'assertion-removal',
    'fixed-delay',
    'force-click',
    'skip-test',
  ],
  requiredPostconditions: [
    'POST /api/orders returns 201',
    'confirmation route reached',
    'persisted order status is confirmed',
  ],
  humanApproval: true,
}

要看清 humanApproval: true 和 requiredPostconditions：即使只改指定文件，也要保住下单成功的业务结果，并经过人工审批。

这只是应用层策略示例，不是 Cypress 内置的配置格式。 把它复制进项目，不会自动获得限制能力；团队还需要让修复流程执行这些约束。

选择器可以换，购买行为不能换

问题不在于能否找到按钮，而在于如何证明点击后发生的仍然是购买。

作者建议用语义锚点保护测试意图。这里的锚点，就是不完全依赖页面标签结构、又能识别目标行为的证据，例如按钮的可访问角色与名称、API 操作和请求内容、持久化服务端状态，以及不应出现的副作用。

下面的测试同时检查下单请求和确认页路径，避免只凭成功文案判断：

cy.intercept('POST', '/api/orders').as('createOrder')

cy.findByRole('button', { name: 'Place order' }).click()

cy.wait('@createOrder').then(({ request, response }) => {
  expect(request.body.items).to.have.length.greaterThan(0)
  expect(response?.statusCode).to.eq(201)
})

cy.location('pathname').should('match', /\/orders\/[^/]+\/confirmation$/)

关键是 cy.wait('@createOrder') 后的请求、响应断言，以及最后的路径断言。换成「Request a quote」后，单有「Thank you」已经不足以通过。

不过，这段代码没有检查策略中要求的持久化订单状态。真实项目若把「订单状态为 confirmed」列为必要条件，还要补上对应验证，不能把示例当成完整实现。

锚点也不是越多越好。作者建议选择能唯一确定业务行为的最小组合，避免一次修复引入过多维护负担。

通过重跑之后，还要证明它会失败

修复中出现 cy.wait(5000)、cy.get('button').first().click({ force: true }) 或 it.skip(...)，都应重点审查。删除断言、扩大选择器范围、增加超时，以及把业务断言换成可见性检查，也属于警示信号。

这些变化可能让测试更容易通过，却没有解释原来的失败。

作者要求修复附带可观察证据：旧选择器为何失效、新选择器是什么、具体改了哪些内容、保留了哪些业务条件。但摘要只是辅助，源码 diff 和实际重跑才是审查依据。

还要记录环境指纹：Cypress、Node、浏览器、应用 commit、viewport，以及 CI 镜像或 Docker digest。先在原来固定的环境复现，才能避免把浏览器或镜像变化造成的失败误判为选择器问题。

修复后通过，只能证明当前路径可通过；负向对照才能检查测试是否仍有检错能力。

作者给出的做法是，用 cy.intercept('POST', '/api/orders', ...) 把创建订单响应设为 statusCode: 409，响应体设为 { code: 'ORDER_NOT_CREATED' }。此时购买测试必须失败；如果仍然绿色，就说明它没守住原来的要求。重新生成操作步骤后，尤其应该做这项检查。

工作流也影响审查方式。原文称 cy.prompt() 支持生成后导出、提交代码，也支持运行时持续自愈。前者在合并前就有 diff，更容易接入常规审查；后者需要记录运行时证据，并收紧修改权限。

原文标注 cy.prompt() 为 Generally Available，Studio AI recommendations 为 Beta，但没有提供具体版本号。发布成熟度也不能代替业务意图验证。支付、权限、账号删除、隐私控制及受监管流程，作者都建议通常采用明确审查过的补丁。

我的判断

我赞同把「测试恢复通过」和「测试继续有效」分开判断。尤其是购买流程，API 请求与确认页路径能提供比成功文案更明确的证据。

但这些锚点需要团队提前定义。若现有测试本来只有浅层断言，限制 AI 只改选择器，也不能自动补足业务保障。负向对照同样只覆盖选定的缺陷：订单创建失败能被发现，不代表订单内容错误或其他副作用也都能被发现。

作者没有给出修复成功率、误修率，也没有与人工维护选择器、统一测试属性等做法进行对照。这是一套风险控制经验，不能据此认定持续自愈比传统维护更省成本。

文章对修改范围的提醒也很实用。如果补丁同时改应用源码、fixtures 和断言，应先确认产品行为，再更新测试，避免产品错误和弱化后的断言互相抵消。

能拿来做什么

• 给关键 Cypress 用例写明允许修改的文件、操作和必要业务结果，再把这些约束交给 AI；先明确什么才算修好。
• 检查现有前端测试是否只断言成功文案或元素可见，对购买等关键流程补上能区分相邻业务路径的请求与结果验证。
• 将环境指纹、源码 diff、重跑结果和一次相关负向对照纳入修复审查，重点检查测试在订单创建失败时能否报错。
• 使用 cy.prompt() 时，优先让关键流程生成可提交的补丁；持续运行时适配只在边界明确、风险较低的展示变化中谨慎采用。