ECC e2e-runner 深度解析Kiro 平台端到端测试 Agent 的工具链、工作流与 Flaky 测试治理【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC在 Everything Claude CodeECC仓库中.kiro/agents/e2e-runner.md定义了 Kiro 平台上的端到端E2E测试专家 Agent——e2e-runner。本文以该 Agent 定义为核心系统讲解其六大职责、以 Agent Browser 为主 / Playwright 为回退的双工具链、Plan → Create → Execute 三段式工作流、定位器与等待策略等关键原则、Flaky 测试的隔离与识别方法以及可量化的成功指标并结合仓库中配套的e2e-testing技能与安装脚本说明该 Agent 如何真正落地到你的项目中。读完本文你可以直接在 Kiro IDE/CLI 中调用该 Agent 生成、维护并执行关键用户旅程的 E2E 测试。一、e2e-runner 在 ECC 中的定位e2e-runner是 ECC 面向 Kiro 平台的 Agent 之一。在仓库根目录的 AGENTS.md 中它被列为标准 Agent 之一用途为 End-to-end Playwright testing适用场景是 Critical user flows关键用户流程在 docs/COMMAND-AGENT-MAP.md 中/e2e命令也映射到该 Agent。仓库中该 Agent 存在两种载体内容同源.kiro/agents/e2e-runner.md面向 Kiro IDE 的 Markdown 格式 AgentYAML frontmatter 中声明name: e2e-runner与allowedTools: read, write, shell即允许读写文件与执行 shell 命令——这恰好覆盖写测试文件 跑测试 上传产物的全部操作面**.kiro/agents/e2e-runner.json**面向kiro-cli的 JSON 格式 AgentallowedTools为fs_read / fs_write / shellprompt字段内嵌与 MD 版完全一致的提示词。根据.kiro/README.md的说明ECC 的.kiro/目录提供双格式Agent 以最大化兼容性Markdown 供 IDE 使用自动选择或显式调用JSON 供 CLI 使用/agent swap切换。README 对e2e-runner的一句话描述是End-to-end testing specialist. Creates and maintains E2E tests using Playwright or Cypress.适用前提e2e-runner是提示词驱动的 Agent 配置模型由 Kiro 当前选择决定README 明确说明 Agent 配置不指定模型它本身不是可执行脚本而是指导 Agent 按既定方法论执行 E2E 测试任务的角色说明书。二、六大核心职责原文档将职责固化为六条这也是该 Agent 的能力契约Test Journey Creation旅程测试创建——为用户流程auth、核心功能、支付、CRUD 等编写测试优先使用 Agent Browser回退到 PlaywrightTest Maintenance测试维护——UI 变更后同步更新测试防止选择器漂移导致的静默失效Flaky Test Management不稳定测试治理——识别不稳定测试并将其隔离quarantine避免污染 CI 信号Artifact Management产物管理——捕获截图、视频、trace为失败定位提供证据链CI/CD Integration流水线集成——确保测试在 CI 中可靠执行Test Reporting测试报告——生成 HTML 报告与 JUnit XML供人类和流水线消费。这六条职责与后文的工作流、原则、Flaky 处理章节是一一对应的闭环创建 → 维护 → 隔离 → 产物 → CI → 报告。三、首选工具Agent Browser文档明确指出Prefer Agent Browser over raw Playwright——理由是它具备语义选择器、AI 优化、自动等待能力且底层就是构建在 Playwright 之上。这意味着用 Agent Browser 驱动探索式交互时行为与 Playwright 测试生态兼容而选择器维护成本更低。文档给出的完整操作序列如下可直接复制执行# Setup npm install -g agent-browser agent-browser install # Core workflow agent-browser open https://example.com # 打开页面 agent-browser snapshot -i # 获取带引用 [refe1] 的元素快照 agent-browser click e1 # 按引用点击 agent-browser fill e2 text # 按引用填充输入框 agent-browser wait visible e5 # 等待元素可见 agent-browser screenshot result.png # 截图其核心机制是引用refsnapshot -i先对页面做结构化快照为每个可交互元素分配e1、e2之类的短引用后续操作直接按引用寻址。这规避了传统 CSS/XPath 选择器在 DOM 重构后大面积失效的问题与后文语义定位器优先的原则一脉相承。四、回退方案Playwright 直驱当 Agent Browser 不可用例如 CI 环境未预装、或需要写长期维护的回归套件时Agent 回退到直接使用 Playwright。文档列出的命令面覆盖了日常执行、调试与报告的完整链路命令作用npx playwright test运行全部 E2E 测试npx playwright test tests/auth.spec.ts只运行指定文件npx playwright test --headed有头模式肉眼观察浏览器行为npx playwright test --debug以 inspector 调试逐步执行npx playwright test --trace on全程记录 trace用于失败回溯npx playwright show-report本地查看 HTML 报告其中--debug与--trace on组合是定位偶发失败的标准手段inspector 允许单步执行到失败动作前trace 则记录完整的 DOM 快照、网络请求与操作时间线。五、三段式工作流Plan → Create → Execute5.1 Plan规划识别关键用户旅程auth认证、核心功能、支付、CRUD为每条旅程定义三类场景happy path主路径、edge cases边界、error cases异常按风险分级排优先级HIGH资金相关、认证、MEDIUM搜索、导航、LOWUI 细节打磨。风险分级的意义在于资源分配CI 预算有限时HIGH 级旅程必须有完整覆盖与更高重试容忍度LOW 级则可以从简。5.2 Create编写采用Page Object ModelPOM模式组织页面层定位器优先级data-testid属性选择器 CSS 选择器 XPath在关键步骤加断言fail fast在关键点截图取证使用正确的等待策略严禁waitForTimeout。配套仓库中的skills/e2e-testing/SKILL.md给出了该原则的可复制实现。POM 示例中ItemsPage类把选择器封装在构造器里search()方法演示了条件等待的完整写法——先fill输入再用waitForResponse等待/api/search请求返回最后waitForLoadState(networkidle)async search(query: string) { await this.searchInput.fill(query) await this.page.waitForResponse(resp resp.url().includes(/api/search)) await this.page.waitForLoadState(networkidle) }对应的测试结构用beforeEach统一导航两个用例分别覆盖搜索命中与无结果两条路径并在命中用例末尾page.screenshot({ path: artifacts/search-results.png })留存证据——这正是原文档关键步骤加断言、关键点截图两条原则的组合示范。5.3 Execute执行本地连续运行3–5 次用重复性暴露 flakiness将不稳定的测试用test.fixme()或test.skip()隔离将产物报告、截图、trace、视频上传 CI保证失败可回溯。六、关键原则稳定性从写法开始原文档的 Key Principles 是该 Agent 的方法论内核六条原则可归纳为三个永远不要语义定位器优先[data-testid...] CSS XPath。data-testid是与展示样式解耦的稳定契约UI 重排不会导致测试失效。等条件不等时间waitForResponse()waitForTimeout()。固定时长等待在慢环境下必挂、在快环境下白等是 flaky 的第一大来源。用自动等待的定位器page.locator().click()内建 actionability 等待可见、稳定、可交互裸page.click(selector)不做等待。测试彼此隔离每个测试独立、无共享状态——这是 CI 并行执行fullyParallel: true的前提。快速失败每个关键步骤都用expect()断言避免错误在长链路末端才暴露。重试时留 trace配置trace: on-first-retry只在失败重试时记录 trace兼顾磁盘开销与可调试性。skills/e2e-testing/SKILL.md中Common Causes Fixes一节用 Bad/Good 对照进一步落实了这些原则例如竞态条件场景// Bad: assumes element is ready await page.click([data-testidbutton]) // Good: auto-wait locator await page.locator([data-testidbutton]).click()动画时序场景则推荐先waitFor({ state: visible })waitForLoadState(networkidle)再 click的三步组合。七、Flaky 测试治理隔离、识别、归因7.1 隔离Quarantine原文档给出的隔离范式是给测试加test.fixme()并附上 issue 号让它在报告中以已知失败呈现而非新失败从而不干扰对真实回归的判断// Quarantine test(flaky: market search, async ({ page }) { test.fixme(true, Flaky - Issue #123) })e2e-testing技能还补充了条件隔离——只在 CI 中跳过本地仍能跑保留人工验证通道test(conditional skip, async ({ page }) { test.skip(process.env.CI, Flaky in CI - Issue #123) })7.2 识别Identify文档与技能给出的识别手段是重复执行放大偶发率npx playwright test --repeat-each10 # 每个用例重复 10 遍 npx playwright test tests/search.spec.ts --repeat-each10 npx playwright test tests/search.spec.ts --retries37.3 归因Diagnose文档总结的三大常见根因与对策根因对策竞态条件元素未就绪改用自动等待的locator()链式操作网络时序数据未返回waitForResponse()等待具体接口动画时序点击落在动画中途等待networkidle/ 元素稳定后再操作八、配套能力e2e-testing 技能提供的工程化模板原文档在结尾声明详细的 Playwright 模式、POM 示例、配置模板、CI/CD 流程与产物管理策略见e2e-testing技能。仓库中该技能同时存在于.kiro/skills/e2e-testing/SKILL.mdKiro 安装后位于.kiro/skills/与skills/e2e-testing/SKILL.mdECC 主技能库内容一致。它把 Agent 的职责清单补全为可直接落地的工程产物以下要点值得逐条对照配置。8.1 测试目录组织按旅程域分目录测试文件与 fixtures 分离tests/ ├── e2e/ │ ├── auth/ # login.spec.ts / logout.spec.ts / register.spec.ts │ ├── features/ # browse.spec.ts / search.spec.ts / create.spec.ts │ └── api/ # endpoints.spec.ts ├── fixtures/ # auth.ts / data.ts └── playwright.config.ts8.2 生产级 Playwright 配置模板技能给出了一份带完整注释语义的playwright.config.ts逐项对应 Agent 的职责要求import { defineConfig, devices } from playwright/test export default defineConfig({ testDir: ./tests/e2e, fullyParallel: true, // 测试隔离原则的直接落地 forbidOnly: !!process.env.CI, // CI 中禁止 .only 残留 retries: process.env.CI ? 2 : 0, // CI 允许 2 次重试 workers: process.env.CI ? 1 : undefined, // CI 串行降低相互干扰 reporter: [ [html, { outputFolder: playwright-report }], // 人类消费 [junit, { outputFile: playwright-results.xml }], // 流水线消费 [json, { outputFile: playwright-results.json }] // 二次处理 ], use: { baseURL: process.env.BASE_URL || http://localhost:3000, trace: on-first-retry, // 对应原则 6 screenshot: only-on-failure, // 产物按需生成 video: retain-on-failure, // 视频只保留失败片段 actionTimeout: 10000, navigationTimeout: 30000, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] } }, { name: firefox, use: { ...devices[Desktop Firefox] } }, { name: webkit, use: { ...devices[Desktop Safari] } }, { name: mobile-chrome, use: { ...devices[Pixel 5] } }, ], webServer: { // 自动拉起被测应用 command: npm run dev, url: http://localhost:3000, reuseExistingServer: !process.env.CI, timeout: 120000, }, })几个值得注意的设计取舍workers在 CI 中取 1是用吞吐换确定性与Flaky rate 5%指标配套三 reporter 并存分别服务人类、CI 平台与后处理脚本正好满足 Agent 第六项职责生成 HTML 报告和 JUnit XML。8.3 CI/CD 集成与产物上传技能给出的流水线示例覆盖 Node 20 环境准备、浏览器依赖安装、环境变量注入与产物上传# .github/workflows/e2e.yml示例 name: E2E Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test env: BASE_URL: ${{ vars.STAGING_URL }} - uses: actions/upload-artifactv4 if: always() # 失败也要上传报告 with: name: playwright-report path: playwright-report/ retention-days: 30if: always()是细节上的关键点测试失败时playwright-report/仍然存在且是排障的唯一入口若不加该条件失败现场的 HTML 报告会丢失。8.4 产物三件套与报告模板截图整页fullPage: true、元素级locator().screenshot()均可Trace配置级trace: on-first-retry是默认方案深度调试时可显式startTracing/stopTracing视频video: retain-on-failurevideosPath只保留失败录像。技能还附了一份测试报告模板Date/Duration/Status/Summary/Failed Tests/Artifacts 五段结构要求对每个失败用例给出文件行号、错误信息、截图路径与Recommended Fix——这为 Agent 的Test Reporting职责提供了统一格式。8.5 两类高价值场景模板金融/关键流程对真实资金操作加test.skip(process.env.NODE_ENV production, ...)先断言预览金额再确认最后用带resp.status() 200条件的waitForResponse等待/api/trade返回超时显式设为 30s钱包/Web3用context.addInitScript注入 mock 的window.ethereumprovider使连接流程可在无真实钱包的 CI 中确定性地执行。九、成功指标量化验收线原文档给出了该 Agent 工作质量的五条可度量标准可作为 CI 看板与复盘的基线指标目标值关键旅程通过率100%整体通过率 95%Flaky 率 5%测试总时长 10 分钟产物已上传且可访问关键旅程 100% 整体 95%的分层指标设计值得借鉴允许长尾用例有可控失败率但资金、认证类旅程不允许任何漏网。十、安装与调用10.1 安装到 Kiro 项目.kiro/目录自带安装脚本.kiro/install.sh采用非破坏性拷贝不覆盖已有文件支持三种目标cd .kiro ./install.sh /path/to/your/project # 安装到指定项目 ./install.sh # 安装到当前目录 ./install.sh ~ # 全局安装到 ~/.kiro/所有 Kiro 项目生效脚本会创建agents / skills / steering / hooks / scripts / settings六个子目录并逐类拷贝e2e-runner.json与e2e-runner.md都会进入目标项目的.kiro/agents/e2e-testing技能进入.kiro/skills/二者即构成 Agent 技能的完整能力面。10.2 调用方式根据.kiro/README.mdIDE在 Kiro 会话中通过/显式调用如/e2e-runner或由 IDE 按任务自动选择CLIkiro-cli --agent e2e-runner直接以该 Agent 启动会话或在会话中/agent swap e2e-runner切换。另外仓库保留了legacy-command-shims/commands/e2e.md作为/e2e的兼容入口它只是委托层声明维护中的工作流在skills/e2e-testing/SKILL.md行为约定为——为请求的用户流程生成/更新 Playwright 覆盖、只运行相关测试除非用户明确要求全量、捕获常规产物并汇报失败与 flaky 风险。/e2e与e2e-runner之间的映射亦见 docs/COMMAND-AGENT-MAP.md。10.3 在 ECC 多平台体系中的位置ECC 同时为 Claude Code 等平台维护了同名的agents/e2e-runner.md其工具面为Read, Write, Edit, Bash, Grep, Glob并额外包含一段Prompt Defense Baseline防提示注入基线安全条款正文方法论与 Kiro 版完全一致。可以推断ECC 通过同一提示词、多平台封装的方式把 e2e-runner 的测试方法论复用到 Claude Code、Kiro 等多个宿主而各平台的差异仅体现在工具白名单与安全前缀上。十一、小结.kiro/agents/e2e-runner.md定义的e2e-runner不是一个孤立的脚本而是一套可执行的方法论契约以六大职责划定边界以 Agent Browser / Playwright 双工具链保证可用性以 Plan → Create → Execute 三段流程规范过程以语义定位器、条件等待、自动等待、测试隔离、快速失败、重试留 trace六原则约束代码风格以隔离-识别-归因三步治理 flaky最后用五条量化指标验收。仓库中的e2e-testing技能skills/e2e-testing/SKILL.md、.kiro/skills/e2e-testing/SKILL.md则把这套方法论落成了 POM 模板、生产级配置、CI 流水线与报告格式。两者配合覆盖了 E2E 测试从编写到流水线交付的完整生命周期——正如文档结尾的提醒E2E 测试是生产环境前最后一道防线它捕获的是单元测试永远看不到的集成问题。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC e2e-runner 深度解析：Kiro 平台端到端测试 Agent 的工具链、工作流与 Flaky 测试治理
ECC e2e-runner 深度解析Kiro 平台端到端测试 Agent 的工具链、工作流与 Flaky 测试治理【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC在 Everything Claude CodeECC仓库中.kiro/agents/e2e-runner.md定义了 Kiro 平台上的端到端E2E测试专家 Agent——e2e-runner。本文以该 Agent 定义为核心系统讲解其六大职责、以 Agent Browser 为主 / Playwright 为回退的双工具链、Plan → Create → Execute 三段式工作流、定位器与等待策略等关键原则、Flaky 测试的隔离与识别方法以及可量化的成功指标并结合仓库中配套的e2e-testing技能与安装脚本说明该 Agent 如何真正落地到你的项目中。读完本文你可以直接在 Kiro IDE/CLI 中调用该 Agent 生成、维护并执行关键用户旅程的 E2E 测试。一、e2e-runner 在 ECC 中的定位e2e-runner是 ECC 面向 Kiro 平台的 Agent 之一。在仓库根目录的 AGENTS.md 中它被列为标准 Agent 之一用途为 End-to-end Playwright testing适用场景是 Critical user flows关键用户流程在 docs/COMMAND-AGENT-MAP.md 中/e2e命令也映射到该 Agent。仓库中该 Agent 存在两种载体内容同源.kiro/agents/e2e-runner.md面向 Kiro IDE 的 Markdown 格式 AgentYAML frontmatter 中声明name: e2e-runner与allowedTools: read, write, shell即允许读写文件与执行 shell 命令——这恰好覆盖写测试文件 跑测试 上传产物的全部操作面**.kiro/agents/e2e-runner.json**面向kiro-cli的 JSON 格式 AgentallowedTools为fs_read / fs_write / shellprompt字段内嵌与 MD 版完全一致的提示词。根据.kiro/README.md的说明ECC 的.kiro/目录提供双格式Agent 以最大化兼容性Markdown 供 IDE 使用自动选择或显式调用JSON 供 CLI 使用/agent swap切换。README 对e2e-runner的一句话描述是End-to-end testing specialist. Creates and maintains E2E tests using Playwright or Cypress.适用前提e2e-runner是提示词驱动的 Agent 配置模型由 Kiro 当前选择决定README 明确说明 Agent 配置不指定模型它本身不是可执行脚本而是指导 Agent 按既定方法论执行 E2E 测试任务的角色说明书。二、六大核心职责原文档将职责固化为六条这也是该 Agent 的能力契约Test Journey Creation旅程测试创建——为用户流程auth、核心功能、支付、CRUD 等编写测试优先使用 Agent Browser回退到 PlaywrightTest Maintenance测试维护——UI 变更后同步更新测试防止选择器漂移导致的静默失效Flaky Test Management不稳定测试治理——识别不稳定测试并将其隔离quarantine避免污染 CI 信号Artifact Management产物管理——捕获截图、视频、trace为失败定位提供证据链CI/CD Integration流水线集成——确保测试在 CI 中可靠执行Test Reporting测试报告——生成 HTML 报告与 JUnit XML供人类和流水线消费。这六条职责与后文的工作流、原则、Flaky 处理章节是一一对应的闭环创建 → 维护 → 隔离 → 产物 → CI → 报告。三、首选工具Agent Browser文档明确指出Prefer Agent Browser over raw Playwright——理由是它具备语义选择器、AI 优化、自动等待能力且底层就是构建在 Playwright 之上。这意味着用 Agent Browser 驱动探索式交互时行为与 Playwright 测试生态兼容而选择器维护成本更低。文档给出的完整操作序列如下可直接复制执行# Setup npm install -g agent-browser agent-browser install # Core workflow agent-browser open https://example.com # 打开页面 agent-browser snapshot -i # 获取带引用 [refe1] 的元素快照 agent-browser click e1 # 按引用点击 agent-browser fill e2 text # 按引用填充输入框 agent-browser wait visible e5 # 等待元素可见 agent-browser screenshot result.png # 截图其核心机制是引用refsnapshot -i先对页面做结构化快照为每个可交互元素分配e1、e2之类的短引用后续操作直接按引用寻址。这规避了传统 CSS/XPath 选择器在 DOM 重构后大面积失效的问题与后文语义定位器优先的原则一脉相承。四、回退方案Playwright 直驱当 Agent Browser 不可用例如 CI 环境未预装、或需要写长期维护的回归套件时Agent 回退到直接使用 Playwright。文档列出的命令面覆盖了日常执行、调试与报告的完整链路命令作用npx playwright test运行全部 E2E 测试npx playwright test tests/auth.spec.ts只运行指定文件npx playwright test --headed有头模式肉眼观察浏览器行为npx playwright test --debug以 inspector 调试逐步执行npx playwright test --trace on全程记录 trace用于失败回溯npx playwright show-report本地查看 HTML 报告其中--debug与--trace on组合是定位偶发失败的标准手段inspector 允许单步执行到失败动作前trace 则记录完整的 DOM 快照、网络请求与操作时间线。五、三段式工作流Plan → Create → Execute5.1 Plan规划识别关键用户旅程auth认证、核心功能、支付、CRUD为每条旅程定义三类场景happy path主路径、edge cases边界、error cases异常按风险分级排优先级HIGH资金相关、认证、MEDIUM搜索、导航、LOWUI 细节打磨。风险分级的意义在于资源分配CI 预算有限时HIGH 级旅程必须有完整覆盖与更高重试容忍度LOW 级则可以从简。5.2 Create编写采用Page Object ModelPOM模式组织页面层定位器优先级data-testid属性选择器 CSS 选择器 XPath在关键步骤加断言fail fast在关键点截图取证使用正确的等待策略严禁waitForTimeout。配套仓库中的skills/e2e-testing/SKILL.md给出了该原则的可复制实现。POM 示例中ItemsPage类把选择器封装在构造器里search()方法演示了条件等待的完整写法——先fill输入再用waitForResponse等待/api/search请求返回最后waitForLoadState(networkidle)async search(query: string) { await this.searchInput.fill(query) await this.page.waitForResponse(resp resp.url().includes(/api/search)) await this.page.waitForLoadState(networkidle) }对应的测试结构用beforeEach统一导航两个用例分别覆盖搜索命中与无结果两条路径并在命中用例末尾page.screenshot({ path: artifacts/search-results.png })留存证据——这正是原文档关键步骤加断言、关键点截图两条原则的组合示范。5.3 Execute执行本地连续运行3–5 次用重复性暴露 flakiness将不稳定的测试用test.fixme()或test.skip()隔离将产物报告、截图、trace、视频上传 CI保证失败可回溯。六、关键原则稳定性从写法开始原文档的 Key Principles 是该 Agent 的方法论内核六条原则可归纳为三个永远不要语义定位器优先[data-testid...] CSS XPath。data-testid是与展示样式解耦的稳定契约UI 重排不会导致测试失效。等条件不等时间waitForResponse()waitForTimeout()。固定时长等待在慢环境下必挂、在快环境下白等是 flaky 的第一大来源。用自动等待的定位器page.locator().click()内建 actionability 等待可见、稳定、可交互裸page.click(selector)不做等待。测试彼此隔离每个测试独立、无共享状态——这是 CI 并行执行fullyParallel: true的前提。快速失败每个关键步骤都用expect()断言避免错误在长链路末端才暴露。重试时留 trace配置trace: on-first-retry只在失败重试时记录 trace兼顾磁盘开销与可调试性。skills/e2e-testing/SKILL.md中Common Causes Fixes一节用 Bad/Good 对照进一步落实了这些原则例如竞态条件场景// Bad: assumes element is ready await page.click([data-testidbutton]) // Good: auto-wait locator await page.locator([data-testidbutton]).click()动画时序场景则推荐先waitFor({ state: visible })waitForLoadState(networkidle)再 click的三步组合。七、Flaky 测试治理隔离、识别、归因7.1 隔离Quarantine原文档给出的隔离范式是给测试加test.fixme()并附上 issue 号让它在报告中以已知失败呈现而非新失败从而不干扰对真实回归的判断// Quarantine test(flaky: market search, async ({ page }) { test.fixme(true, Flaky - Issue #123) })e2e-testing技能还补充了条件隔离——只在 CI 中跳过本地仍能跑保留人工验证通道test(conditional skip, async ({ page }) { test.skip(process.env.CI, Flaky in CI - Issue #123) })7.2 识别Identify文档与技能给出的识别手段是重复执行放大偶发率npx playwright test --repeat-each10 # 每个用例重复 10 遍 npx playwright test tests/search.spec.ts --repeat-each10 npx playwright test tests/search.spec.ts --retries37.3 归因Diagnose文档总结的三大常见根因与对策根因对策竞态条件元素未就绪改用自动等待的locator()链式操作网络时序数据未返回waitForResponse()等待具体接口动画时序点击落在动画中途等待networkidle/ 元素稳定后再操作八、配套能力e2e-testing 技能提供的工程化模板原文档在结尾声明详细的 Playwright 模式、POM 示例、配置模板、CI/CD 流程与产物管理策略见e2e-testing技能。仓库中该技能同时存在于.kiro/skills/e2e-testing/SKILL.mdKiro 安装后位于.kiro/skills/与skills/e2e-testing/SKILL.mdECC 主技能库内容一致。它把 Agent 的职责清单补全为可直接落地的工程产物以下要点值得逐条对照配置。8.1 测试目录组织按旅程域分目录测试文件与 fixtures 分离tests/ ├── e2e/ │ ├── auth/ # login.spec.ts / logout.spec.ts / register.spec.ts │ ├── features/ # browse.spec.ts / search.spec.ts / create.spec.ts │ └── api/ # endpoints.spec.ts ├── fixtures/ # auth.ts / data.ts └── playwright.config.ts8.2 生产级 Playwright 配置模板技能给出了一份带完整注释语义的playwright.config.ts逐项对应 Agent 的职责要求import { defineConfig, devices } from playwright/test export default defineConfig({ testDir: ./tests/e2e, fullyParallel: true, // 测试隔离原则的直接落地 forbidOnly: !!process.env.CI, // CI 中禁止 .only 残留 retries: process.env.CI ? 2 : 0, // CI 允许 2 次重试 workers: process.env.CI ? 1 : undefined, // CI 串行降低相互干扰 reporter: [ [html, { outputFolder: playwright-report }], // 人类消费 [junit, { outputFile: playwright-results.xml }], // 流水线消费 [json, { outputFile: playwright-results.json }] // 二次处理 ], use: { baseURL: process.env.BASE_URL || http://localhost:3000, trace: on-first-retry, // 对应原则 6 screenshot: only-on-failure, // 产物按需生成 video: retain-on-failure, // 视频只保留失败片段 actionTimeout: 10000, navigationTimeout: 30000, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] } }, { name: firefox, use: { ...devices[Desktop Firefox] } }, { name: webkit, use: { ...devices[Desktop Safari] } }, { name: mobile-chrome, use: { ...devices[Pixel 5] } }, ], webServer: { // 自动拉起被测应用 command: npm run dev, url: http://localhost:3000, reuseExistingServer: !process.env.CI, timeout: 120000, }, })几个值得注意的设计取舍workers在 CI 中取 1是用吞吐换确定性与Flaky rate 5%指标配套三 reporter 并存分别服务人类、CI 平台与后处理脚本正好满足 Agent 第六项职责生成 HTML 报告和 JUnit XML。8.3 CI/CD 集成与产物上传技能给出的流水线示例覆盖 Node 20 环境准备、浏览器依赖安装、环境变量注入与产物上传# .github/workflows/e2e.yml示例 name: E2E Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test env: BASE_URL: ${{ vars.STAGING_URL }} - uses: actions/upload-artifactv4 if: always() # 失败也要上传报告 with: name: playwright-report path: playwright-report/ retention-days: 30if: always()是细节上的关键点测试失败时playwright-report/仍然存在且是排障的唯一入口若不加该条件失败现场的 HTML 报告会丢失。8.4 产物三件套与报告模板截图整页fullPage: true、元素级locator().screenshot()均可Trace配置级trace: on-first-retry是默认方案深度调试时可显式startTracing/stopTracing视频video: retain-on-failurevideosPath只保留失败录像。技能还附了一份测试报告模板Date/Duration/Status/Summary/Failed Tests/Artifacts 五段结构要求对每个失败用例给出文件行号、错误信息、截图路径与Recommended Fix——这为 Agent 的Test Reporting职责提供了统一格式。8.5 两类高价值场景模板金融/关键流程对真实资金操作加test.skip(process.env.NODE_ENV production, ...)先断言预览金额再确认最后用带resp.status() 200条件的waitForResponse等待/api/trade返回超时显式设为 30s钱包/Web3用context.addInitScript注入 mock 的window.ethereumprovider使连接流程可在无真实钱包的 CI 中确定性地执行。九、成功指标量化验收线原文档给出了该 Agent 工作质量的五条可度量标准可作为 CI 看板与复盘的基线指标目标值关键旅程通过率100%整体通过率 95%Flaky 率 5%测试总时长 10 分钟产物已上传且可访问关键旅程 100% 整体 95%的分层指标设计值得借鉴允许长尾用例有可控失败率但资金、认证类旅程不允许任何漏网。十、安装与调用10.1 安装到 Kiro 项目.kiro/目录自带安装脚本.kiro/install.sh采用非破坏性拷贝不覆盖已有文件支持三种目标cd .kiro ./install.sh /path/to/your/project # 安装到指定项目 ./install.sh # 安装到当前目录 ./install.sh ~ # 全局安装到 ~/.kiro/所有 Kiro 项目生效脚本会创建agents / skills / steering / hooks / scripts / settings六个子目录并逐类拷贝e2e-runner.json与e2e-runner.md都会进入目标项目的.kiro/agents/e2e-testing技能进入.kiro/skills/二者即构成 Agent 技能的完整能力面。10.2 调用方式根据.kiro/README.mdIDE在 Kiro 会话中通过/显式调用如/e2e-runner或由 IDE 按任务自动选择CLIkiro-cli --agent e2e-runner直接以该 Agent 启动会话或在会话中/agent swap e2e-runner切换。另外仓库保留了legacy-command-shims/commands/e2e.md作为/e2e的兼容入口它只是委托层声明维护中的工作流在skills/e2e-testing/SKILL.md行为约定为——为请求的用户流程生成/更新 Playwright 覆盖、只运行相关测试除非用户明确要求全量、捕获常规产物并汇报失败与 flaky 风险。/e2e与e2e-runner之间的映射亦见 docs/COMMAND-AGENT-MAP.md。10.3 在 ECC 多平台体系中的位置ECC 同时为 Claude Code 等平台维护了同名的agents/e2e-runner.md其工具面为Read, Write, Edit, Bash, Grep, Glob并额外包含一段Prompt Defense Baseline防提示注入基线安全条款正文方法论与 Kiro 版完全一致。可以推断ECC 通过同一提示词、多平台封装的方式把 e2e-runner 的测试方法论复用到 Claude Code、Kiro 等多个宿主而各平台的差异仅体现在工具白名单与安全前缀上。十一、小结.kiro/agents/e2e-runner.md定义的e2e-runner不是一个孤立的脚本而是一套可执行的方法论契约以六大职责划定边界以 Agent Browser / Playwright 双工具链保证可用性以 Plan → Create → Execute 三段流程规范过程以语义定位器、条件等待、自动等待、测试隔离、快速失败、重试留 trace六原则约束代码风格以隔离-识别-归因三步治理 flaky最后用五条量化指标验收。仓库中的e2e-testing技能skills/e2e-testing/SKILL.md、.kiro/skills/e2e-testing/SKILL.md则把这套方法论落成了 POM 模板、生产级配置、CI 流水线与报告格式。两者配合覆盖了 E2E 测试从编写到流水线交付的完整生命周期——正如文档结尾的提醒E2E 测试是生产环境前最后一道防线它捕获的是单元测试永远看不到的集成问题。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考