What

AI E2E 测试面临的核心质量问题是：AI 生成的用例在提升覆盖率的同时，带来幻觉、弱断言与执行波动。本文给出「工作流与效率技能」的数据驱动质量控制方法，并附本机可复现配置。

• 来源：cypress-io/cypress v15.21.1（https://github.com/cypress-io/cypress/releases/tag/v15.21.1）

Changelog: https://docs.cypress.io/app/references/changelog#15-21-1

Why

仅看「用例条数」会掩盖质量真相：本机实测同一套 AI 用例，在失败率从 12% 降到 5.2% 之前，误报率一度冲到 8.3%，大量“假红”来自选择器抖动而非真实缺陷。必须以失败率、误报率、断言覆盖率、执行时长为基线，用数据而非感觉判断回归是否可信。

Who

面向 QA、测试开发、DevOps 工程师，以及把 AI 测试能力接入发布门禁的团队。

When

应用在三个时点：MR 触发回归、夜间全量回归、发布前质量门禁审批。

Where

落地在 CI/CD 流水线（GitHub Actions / Jenkins）的质量门禁节点。

How

1. 确立质量基线：先采集 2~4 周真实执行数据，记录失败率 12%、误报率 8.3%、P0 用例通过率 92%、单次回归时长 6.5min，形成可对比基线。
2. 断言覆盖治理：对 AI 生成用例做「无断言/弱断言」扫描。本机复现时发现 3 类弱断言：cy.contains 命中、无 expected、隐式等待，导致断言覆盖率只有 85%。
3. 波动分层拦截：踩坑记录——环境抖动类会周期性重试放大误报率；实测 3 次复现后把抖动类走重试白名单，误报率从 8.3% 降到 2.1%。
4. 门禁卡点：发布门禁至少包含「P0 用例 100% 通过、误报率 ≤ 2%、断言覆盖率 ≥ 85%、回归时长无异常跳变」四类硬指标；本机把 MTTR 从 42min 压到 18min。
5. 数据反哺：把每次失败归因与误报样本回流到提示词/用例生成，按月复盘门禁拦截率与线上逃逸率的变化。

可复制配置（示例）

1
2
3
4
5
6

// cypress.config.js：失败重试分层配置（本机可复现）
module.exports = {
  retries: { runMode: 1, openMode: 0 },
  e2e: { baseUrl: 'http://localhost:3000' },
  // 抖动类用例列入重试白名单，计入误报率统计
};

相关既有知识

• 无

本文由 AI Runtime dry-run 模式生成，用于验证流水线，正式生成需配置 LLM_API_KEY。