Agentic Testing: Where Agents Fit in the E2E Testing Stack智能体测试：智能体在端到端（E2E）测试架构中的定位

Abstract摘要

Agent-driven end-to-end (E2E) tests add a new exploratory layer to testing, but should they replace traditional deterministic tests? We ran more than 200 agentic E2E workflows using the Playwright MCP, Playwright CLI, and agent-generated Playwright tests in test workspaces using non-production data to find out how agentic testing could fit into both our and your testing stacks.基于智能体的端到端（E2E）测试为测试领域增添了新的探索维度，但它们应该取代传统的确定性测试吗？为了探究智能体测试如何融入我们以及你们的测试架构，我们使用非生产环境数据，通过 Playwright MCP、Playwright CLI 以及智能体生成的 Playwright 测试，执行了超过 200 个智能体 E2E 工作流。

1. From Journeys to Goals1. 从“旅程”到“目标”

Traditional end-to-end tests validate a specific journey through the UI.传统的端到端测试用于验证用户在 UI 界面中的特定操作旅程。

click → click → type → assert点击 → 点击 → 输入 → 断言

Agent-driven tests instead validate whether a goal can be achieved, often expressed as an instruction (e.g. “send a thread message”):而基于智能体的测试则验证目标是否达成，通常以指令形式表达（例如：“发送一条线程消息”）：

goal → agent adapts → verify result目标 → 智能体自适应 → 验证结果

This difference can be summarized simply:这种差异可以简单概括为：

Tests enforce journeys. Agents verify goals.测试强制执行旅程。智能体验证目标。

Across our agentic test runs, the overall workflow remained consistent (e.g. login → search → result → clear), but the exact sequence of actions varied. In practice, agents took different paths to reach the same outcome:在我们进行的智能体测试运行中，整体工作流保持一致（例如：登录 → 搜索 → 结果 → 清除），但具体的动作序列各不相同。实际上，智能体采用了不同的路径来实现相同的结果：

• Different input methods (clicking a search suggestion vs pressing Enter)不同的输入方法（点击搜索建议 vs 按下回车键）
• Different navigation patterns (reopening search vs reusing existing state)不同的导航模式（重新打开搜索 vs 复用现有状态）
• Additional or skipped steps (extra clicks, snapshots, or intermediate actions)额外或跳过的步骤（额外的点击、快照或中间操作）

Agents can still validate intermediate steps when needed, but this flexibility comes with tradeoffs in reliability, cost, and execution time, which we explore in the next sections.智能体在需要时仍能验证中间步骤，但这种灵活性在可靠性、成本和执行时间方面需要做出权衡，我们将在后续章节中探讨这些问题。

The Problem问题所在

Agent-driven E2E testing looks promising, but it raises a real question: can something that costs $15–30 per run and takes over 10 minutes actually fit into modern testing workflows?基于智能体的 E2E 测试前景广阔，但也引发了一个现实问题：如果每次运行成本高达 15–30 美元且耗时超过 10 分钟，它真的能融入现代测试工作流吗？

At first glance, the answer seems like no. But in 200+ runs, we found they are fundamentally different from traditional tests. They can be highly reliable and have a clear place in the testing stack.乍一看，答案似乎是否定的。但在 200 多次运行后，我们发现它们与传统测试有着本质区别。它们可以非常可靠，并在测试架构中占据明确的一席之地。

This is largely due to recent advances in large language models, which enable agents to write code, debug failures, and interact directly with user interfaces. These capabilities introduce a new execution model for testing, but where they fit in existing E2E workflows is not always clear.这在很大程度上归功于大语言模型的最新进展，使智能体能够编写代码、调试故障并直接与用户界面交互。这些能力引入了一种新的测试执行模型，但它们在现有 E2E 工作流中的定位并不总是显而易见。

2. Our Experiment2. 我们的实验

To understand how agent-driven tests can fit into E2E workflows, we ran 200+ automated executions across multiple configurations to measure reliability, execution speed, and cost.为了了解智能体驱动的测试如何融入 E2E 工作流，我们在多种配置下进行了 200 多次自动化执行，以衡量其可靠性、执行速度和成本。

Execution models执行模型

We evaluated three different approaches:我们评估了三种不同的方法：

• Agent + Playwright MCP
  The agent interacts with the browser through the Playwright MCP, using predefined browser actions (clicking elements, typing input, reading DOM state, etc…) with persistent context (DOM snapshots and logs)智能体 + Playwright MCP 智能体通过 Playwright MCP 与浏览器交互，使用预定义的浏览器操作（点击元素、输入内容、读取 DOM 状态等），并保持持久化上下文（DOM 快照和日志）。
• Agent + Playwright CLI
  The agent interacts with the browser by running Playwright CLI commands via the shell, executing one step at a time and deciding the next action based on the updated UI state智能体 + Playwright CLI 智能体通过 Shell 运行 Playwright CLI 命令与浏览器交互，每次执行一个步骤，并根据更新后的 UI 状态决定下一步操作。
• Generated Playwright Tests
  An AI agent generates deterministic Playwright test code from a natural language description, executes it as a standard E2E test, and iteratively refines it until it passes生成的 Playwright 测试 AI 智能体根据自然语言描述生成确定性的 Playwright 测试代码，将其作为标准 E2E 测试执行，并进行迭代优化，直到测试通过。

Experiment Setup实验设置

• Agent model (Playwright MCP / CLI): Claude Sonnet 4.5智能体模型（Playwright MCP / CLI）：Claude Sonnet 4.5
• Model used for generated Playwright tests: Claude Opus 4.6用于生成 Playwright 测试的模型：Claude Opus 4.6
• Execution: non-interactive Claude Code (claude -p)执行环境：非交互式 Claude Code (claude -p)
• Browser tooling:
  • Playwright MCPPlaywright MCP
  • Playwright CLIPlaywright CLI
• Environment setup: 
  • Slack Dev API MCPSlack Dev API MCP
  • All experiments were conducted in test workspaces using non-production data所有实验均在测试工作区中使用非生产环境数据进行。

Test flows测试流程

We used two flows to cover different levels of complexity. These flows were kept consistent across all experiments to allow for direct comparison.我们使用了两个流程来覆盖不同复杂程度的场景。这些流程在所有实验中保持一致，以便进行直接比较。

• Thread Reply (simple)
  A shorter workflow (~15–20 steps) involving creating a channel, sending a message, replying in a thread, and verifying thread state线程回复（简单）：一个较短的工作流（约 15–20 个步骤），包括创建频道、发送消息、在线程中回复并验证线程状态。
• Search Discovery (medium complexity)
  A longer workflow (~25–30 steps) involving entering search queries, navigating results, moving between views (search, channels, threads), and verifying expected outcomes搜索发现（中等复杂度）：一个较长的工作流（约 25–30 个步骤），包括输入搜索查询、导航结果、在视图之间切换（搜索、频道、线程）并验证预期结果。

Input formats输入格式

For agent-driven approaches, we evaluated two input types:对于智能体驱动的方法，我们评估了两种输入类型：

• Natural language (NL)
  Detailed, human-readable instructions describing the workflow and expected outcomes (e.g. “reply in a thread, and verify it appears in All Threads”), often written as step-by-step lists自然语言 (NL)：详细且易于阅读的人类语言说明，描述工作流和预期结果（例如“在线程中回复，并验证它出现在‘所有线程’中”），通常以分步列表的形式编写。
• Structured YAML
  The same workflow expressed in a structured format, with explicit steps, actions, targets, and expected outcomes结构化 YAML：以结构化格式表达的相同工作流，包含明确的步骤、操作、目标和预期结果。

The difference is not the level of detail, but how that detail is represented: natural language requires the agent to interpret and map instructions to actions, while YAML defines that mapping more explicitly.区别不在于细节程度，而在于细节的表达方式：自然语言要求智能体解释并将指令映射到操作，而 YAML 则更明确地定义了这种映射。

Each configuration was run 20 times. The experiment matrix below shows the full setup:每种配置运行 20 次。下方的实验矩阵展示了完整的设置：

Experiment Matrix实验矩阵

Exp	Execution Model	Input Type	Tools	Thread Reply	Search Discovery
1	Agent (Playwright MCP)	NL	MCP	20	20
2	Agent (Playwright MCP)	YAML	MCP	20	20
3	Agent (Playwright CLI)	NL	CLI	20	20
4	Agent (Playwright CLI)	YAML	CLI	20	20
5	Agent (Generated Tests)	NL	Code	20	20

3. What We Observed3. 我们的观察结果

Summary of Results结果摘要

Before diving into individual metrics, here’s a quick look at how the different approaches performed overall across both natural language and YAML-based executions.在深入探讨各项指标之前，以下是不同方法在自然语言和 YAML 执行中的整体表现概览。

Approach	Failure rate  (thread reply)	Failure rate  (search discovery)	Avg runtime
Agent (Playwright MCP)	0%	~12%	~5–8 min
Agent (Playwright CLI)	~12%	~20%	~9–11 min
Generated Playwright Tests	~8%	~48%	~3 min

The following sections break down these results by individual metrics.接下来的章节将按各项指标详细拆解这些结果。

Reliability可靠性

One of the clearest patterns we saw was how reliability changed as flows became more complex. 我们观察到的最明显的模式之一是可靠性如何随着流程复杂度的增加而变化。

Across the agentic Playwright flows, the Playwright MCP was the more reliable configuration, consistently achieving near‑zero failure rates on simple scenarios and remaining within 0–12% on more complex flows. In contrast, the Playwright CLI showed higher failure rates (roughly 12–20%), with many failures caused by execution issues such as authentication handling, navigation timing, and session instability rather than model reasoning.在智能体 Playwright 流程中，Playwright MCP 是更可靠的配置，在简单场景中始终实现近乎零的失败率，在更复杂的流程中失败率保持在 0–12%。相比之下，Playwright CLI 的失败率较高（约 12–20%），许多失败是由身份验证处理、导航计时和会话不稳定等执行问题引起的，而非模型推理问题。

Generated Playwright tests performed reasonably well on simple flows (~8% failure rate), but degraded significantly on more complex workflows (~48%). These tests were not entirely wrong, as they typically progressed through 70-80% of the flow before breaking on a final interaction or assertion. Failures were primarily caused by variability in UI state and abstraction mismatches. These tests were generated from loosely specified natural language flows and reused existing page object abstractions, which sometimes interfered with precise element targeting in more complex scenarios.生成的 Playwright 测试在简单流程中表现尚可（约 8% 的失败率），但在更复杂的工作流中表现显著下降（约 48%）。这些测试并非完全错误，它们通常能完成 70-80% 的流程，但在最后的交互或断言时中断。失败主要由 UI 状态的变异和抽象不匹配引起。这些测试由松散指定的自然语言流程生成，并复用了现有的页面对象抽象，这有时会干扰复杂场景中精确的元素定位。

Overall, the reliability gap widened with increasing complexity, suggesting that the agent-native execution models like MCP provide more stable behavior as flows get harder. One likely reason is how each model handles state. MCP keeps a live, stable view of the app, while CLI rebuilds state from snapshots at each step. As flows get longer, small inconsistencies in how the UI is interpreted or timed can accumulate and lead to failures. Another likely factor is in-session context. In MCP-based runs, the agent appears to reuse successful interactions from earlier steps in the same flow, while CLI can feel more like starting from scratch at each step. We didn’t explicitly measure this, but it may also contribute to the gap.总体而言，可靠性差距随着复杂度的增加而扩大，这表明像 MCP 这样的智能体原生执行模型在流程变难时能提供更稳定的行为。一个可能的原因是模型处理状态的方式：MCP 保持了对应用程序实时、稳定的视图，而 CLI 在每一步都从快照中重建状态。随着流程变长，UI 解析或计时上的微小不一致会累积并导致失败。另一个可能因素是会话内上下文。在基于 MCP 的运行中，智能体似乎复用了同一流程中早期步骤的成功交互，而 CLI 在每一步都感觉像是从零开始。我们没有明确测量这一点，但这可能也是导致差距的原因之一。

Speed速度

When it came to speed, generated tests were consistently the fastest.在速度方面，生成的测试始终是最快的。

Approach	Average Duration
Generated Playwright Tests	~3 minutes
Agent (Playwright MCP)	~5–8 minutes
Agent (Playwright CLI)	~9–11 minutes

For generated tests, the runtime includes both test generation and execution. Each test was generated once and executed five times, and the numbers above reflect the average duration per run. In practice, the raw execution was much faster: ~32 seconds for thread reply and ~45 seconds for search discovery. In CI environments where tests run repeatedly, the one-time generation cost becomes negligible, allowing deterministic tests to scale more efficiently.对于生成的测试，运行时包括测试生成和执行。每个测试生成一次并执行五次，上述数据反映了每次运行的平均持续时间。实际上，原始执行速度要快得多：线程回复约为 32 秒，搜索发现约为 45 秒。在需要重复运行测试的 CI 环境中，一次性的生成成本变得可以忽略不计，从而使确定性测试能够更高效地扩展。

Agent-driven workflows pay this cost on every run. Each step typically involves:智能体驱动的工作流在每次运行中都要承担这一成本。每个步骤通常包括：

• Observing the UI state观察 UI 状态
• Reasoning about the next action推理下一步操作
• Executing the action and validating the result执行操作并验证结果

Adaptability适应性

Another pattern we saw was how differently agents navigate the UI.我们观察到的另一个模式是智能体导航 UI 的方式差异巨大。

Only about 20% of runs followed the exact same sequence of actions. In most runs, the agent discovered different valid UI paths to reach the same goal.只有约 20% 的运行遵循了完全相同的操作序列。在大多数运行中，智能体发现了不同的有效 UI 路径来达到相同的目标。

For example, while still reaching the same final state, the agent might:例如，在达到相同最终状态的同时，智能体可能会：

• Open menus in a different order以不同的顺序打开菜单
• Select slightly different UI elements选择略有不同的 UI 元素
• Use alternate navigation flows使用替代的导航流程

To measure this, we compared action signatures across runs. An action signature is the ordered list of tool calls and UI actions performed by the agent (e.g. API calls, browser clicks, form interactions). Action signatures were normalized before comparison: parameters, wait/snapshot actions, and equivalent tool variants (e.g. fill vs type) were collapsed so that only meaningful differences in the action sequence were counted.为了衡量这一点，我们比较了不同运行中的操作签名。操作签名是智能体执行的工具调用和 UI 操作的有序列表（例如 API 调用、浏览器点击、表单交互）。在比较之前，操作签名经过了归一化处理：参数、等待/快照操作以及等效的工具变体（例如 fill vs type）被合并，以便只计算操作序列中有意义的差异。

Across runs, most action sequences differed even when the final outcome was correct. This highlights a key difference between approaches: traditional E2E tests enforce a single deterministic journey through the UI, while agents explore the interface and verify whether the goal state can still be reached.在不同运行中，即使最终结果正确，大多数操作序列也不同。这凸显了两种方法之间的关键差异：传统的 E2E 测试在 UI 中强制执行单一的确定性旅程，而智能体则探索界面并验证是否仍能达到目标状态。

Cost and Where It Comes From成本及其来源

Cost stood out in our experiments. Agent-driven runs were typically $15–30 per execution, compared to much cheaper traditional test runs.成本在我们的实验中非常突出。智能体驱动的运行每次通常花费 15–30 美元，而传统的测试运行成本要低得多。

To understand where this cost came from, we analyzed token usage across different execution models by running the same search discovery flow.为了了解成本来源，我们通过运行相同的搜索发现流程，分析了不同执行模型下的 Token 使用情况。

Approach	Tokens
MCP (Opus 4.6)	~3.8M
MCP (Sonnet 4.5)	~3.5M
MCP (Haiku 4.5)	~5.7M
CLI (Opus 4.6)	~6M
Code Gen (Opus 4.6)	~7M

The first thing that stood out was that how the agent was executed mattered more than which model powered it. Haiku did use more tokens than Sonnet or Opus in our runs, but all of the MCP-based approaches still used fewer tokens overall than the CLI and Code Gen approaches for the same flow.首先引人注目的是，智能体的执行方式比驱动它的模型本身更重要。在我们的运行中，Haiku 确实比 Sonnet 或 Opus 使用了更多的 Token，但所有基于 MCP 的方法在相同流程中使用的 Token 总量仍然少于 CLI 和代码生成方法。

To understand why, we looked at how Claude Code executes agent sessions. The underlying API is stateless and every turn re-sends the full system prompt plus the entire conversation history. This means cost is not driven by model output, which is negligible, but by how quickly context accumulates and how many turns the agent takes to complete the flow.为了了解原因，我们研究了 Claude Code 如何执行智能体会话。底层的 API 是无状态的，每一步都会重新发送完整的系统提示词加上整个对话历史。这意味着成本并非由模型输出驱动（输出量微不足道），而是由上下文积累的速度以及智能体完成流程所需的步数驱动。

Approach	Turns
MCP (Opus 4.6)	~40
MCP (Sonnet 4.5)	~40
MCP (Haiku 4.5)	~60
CLI (Opus 4.6)	~85
Code Gen (Opus 4.6)	~70

On average, CLI took 85 turns compared to MCP’s ~40-60 because each browser interaction was split across multiple commands, such as actions, waits, snapshots, reads, and element lookups. MCP combined interaction and state return into a single round trip. Each additional turn pays the full system prompt tax plus re-sends all prior conversation context.平均而言，CLI 需要 85 步，而 MCP 仅需约 40-60 步，因为每次浏览器交互都被拆分为多个命令，如操作、等待、快照、读取和元素查找。MCP 将交互和状态返回合并为单次往返。每增加一步，都要支付完整的系统提示词成本，并重新发送所有先前的对话上下文。

What fills that context? For MCP and CLI approaches, browser snapshots are the primary payload. Playwright MCP returns accessibility tree snapshots as part of its browser interaction responses, and these accumulate in the conversation window across all subsequent turns. For Code Gen, the accumulated context comes from test runner output containing full error traces, assertion failures, and DOM state on each retry cycle.是什么填满了这些上下文？对于 MCP 和 CLI 方法，浏览器快照是主要的负载。Playwright MCP 将辅助功能树快照作为其浏览器交互响应的一部分返回，这些快照在后续的所有步骤中会在对话窗口中累积。对于代码生成，累积的上下文来自测试运行器的输出，其中包含每次重试循环时的完整错误跟踪、断言失败和 DOM 状态。

In our analysis, the majority of the cost was retransmission of previously seen content. Only a small fraction of tokens represented new information per turn. The biggest factors affecting cost are turn count and context growth rate rather than model reasoning or output generation.在我们的分析中，大部分成本来自于对先前可见内容的重传。每一步中，代表新信息的 Token 仅占很小一部分。影响成本的最大因素是步数和上下文增长率，而非模型推理或输出生成。

At this stage, we focused primarily on reliability and behavior, so token usage was not optimized. Opportunities to reduce cost include prompt caching, context compaction, and reducing snapshot frequency. 在此阶段，我们主要关注可靠性和行为，因此 Token 使用未进行优化。降低成本的机会包括提示词缓存、上下文压缩和降低快照频率。

Due to the cost, agent-driven testing may currently be better suited for targeted debugging or exploratory testing than for high-frequency CI execution, although cost may improve with future models and tooling.由于成本原因，智能体驱动的测试目前可能更适合定向调试或探索性测试，而非高频的 CI 执行，尽管成本可能会随着未来模型和工具的发展而改善。

Infrastructure Matters (MCP vs CLI)基础设施至关重要（MCP vs CLI）

Another important takeaway was how much the execution environment affected reliability, not just the model itself.另一个重要的结论是，执行环境对可靠性的影响程度，不仅仅取决于模型本身。

Approach	Failure rate
Agent (Playwright MCP)	0–12%
Agent (Playwright CLI)	12–20%

Most failures in CLI-based runs came from authentication and navigation issues (sign-in errors, timeouts, and session instability), suggesting that many failures were caused by the execution layer rather than the agent’s reasoning.基于 CLI 的运行中，大多数失败来自身份验证和导航问题（登录错误、超时和会话不稳定），这表明许多失败是由执行层而非智能体的推理引起的。

The Playwright MCP provides structured browser primitives and tighter integration with the agent’s tool-calling workflow, while CLI-based execution introduces additional layers between the agent and the browser.Playwright MCP 提供了结构化的浏览器原语，并与智能体的工具调用工作流实现了更紧密的集成，而基于 CLI 的执行在智能体和浏览器之间引入了额外的层级。

Parallelization also differed. MCP runs were easy to execute concurrently, while CLI-based runs were difficult to parallelize in our setup and were mostly executed sequentially.并行化能力也有所不同。MCP 运行易于并发执行，而基于 CLI 的运行在我们的设置中难以并行化，大多是按顺序执行的。

These results suggest that reliability, speed, and cost depend not just on the model, but also on how stable and well-designed the execution environment is.这些结果表明，可靠性、速度和成本不仅取决于模型，还取决于执行环境的稳定性和设计水平。

Execution Capability Boundaries执行能力的边界

Our experiments focused on single-session UI workflows. More complex scenarios, such as cross-workspace flows or workflows that open multiple browser windows, introduce a different set of challenges where the choice of execution model may matter as much as the agent itself.我们的实验侧重于单会话 UI 工作流。更复杂的场景，例如跨工作区流程或打开多个浏览器窗口的工作流，引入了一系列不同的挑战，其中执行模型的选择可能与智能体本身同样重要。

Both MCP and CLI-based approaches could support these workflows, but with different tradeoffs. MCP may run into cost issues as observation loops grow over longer flows, while CLI-based approaches may introduce additional coordination complexity when managing multiple browser sessions, on top of the higher token usage observed in our experiments. We did not explore these scenarios here, but they are an important consideration for teams evaluating agent-driven testing.MCP 和基于 CLI 的方法都可以支持这些工作流，但各有权衡。随着观察循环在更长的流程中增长，MCP 可能会遇到成本问题；而基于 CLI 的方法在管理多个浏览器会话时，除了实验中观察到的更高 Token 使用量外，还可能引入额外的协调复杂性。我们在此未探索这些场景，但对于评估智能体驱动测试的团队来说，它们是重要的考量因素。

4. Where Agentic Testing Fits in the Testing Pyramid4. 智能体测试在测试金字塔中的定位

So where does agent-driven testing actually fit?那么，智能体驱动的测试到底处于什么位置？

Rather than replacing existing approaches, it adds a new capability on top of them.它不是取代现有方法，而是在其之上增加了一种新的能力。

Deterministic E2E Tests确定性 E2E 测试

Best suited for fast, repeatable regression checks in CI.最适合 CI 中快速、可重复的回归检查。

• Human-written or AI-generated tests人工编写或 AI 生成的测试
• Fast, repeatable, and CI-friendly快速、可重复且对 CI 友好
• Low operational cost运营成本低
• Enforce a specific journey through the UI 强制执行 UI 中的特定旅程

Agentic Testing智能体测试

Agent-driven workflows operate differently from deterministic tests. Instead of executing a predefined script, agents operate from a goal: they observe the UI, reason about the current state, and determine how to reach the desired outcome.智能体驱动的工作流与确定性测试的运作方式不同。智能体不是执行预定义的脚本，而是基于目标运作：它们观察 UI，推理当前状态，并确定如何达到预期的结果。

• Exploring complex UI behavior探索复杂的 UI 行为
• Debugging flaky workflows调试不稳定的工作流
• Reproducing production bugs重现生产环境 Bug

Testing Pyramid with Agentic Layer带有智能体层的测试金字塔

From a system perspective, agentic testing still operates at the same level as E2E tests, validating real user workflows through the UI. The difference is in how those workflows are executed. 从系统角度来看，智能体测试仍然与 E2E 测试处于同一层级，通过 UI 验证真实的用户工作流。区别在于这些工作流的执行方式。

For this reason, the most effective testing strategies of the future will combine both. Deterministic tests provide a stable foundation for CI, while agentic testing adds a distinct layer at the top of the testing pyramid for exploration, debugging, and validating complex behaviors.因此，未来最有效的测试策略将结合两者。确定性测试为 CI 提供稳定的基础，而智能体测试则在测试金字塔的顶部增加了一个独特的层级，用于探索、调试和验证复杂的行为。

5. Acknowledgements5. 致谢

Huge thanks to the DevXP AI team for building and supporting tools like Claude Code, as well as the metrics infrastructure that made these experiments possible. That foundation made it much easier to run, analyze, and iterate on hundreds of executions.非常感谢 DevXP AI 团队构建并支持了 Claude Code 等工具，以及使这些实验成为可能的指标基础设施。这些基础使得运行、分析数百次执行并进行迭代变得容易得多。

Special thanks to our managers, Dave Harrington and Vani Anantha, for supporting experiments at a scale that definitely kept the token counters busy, and briefly put us on our internal token usage leaderboard.特别感谢我们的经理 Dave Harrington 和 Vani Anantha，他们支持了这种规模的实验，这确实让 Token 计数器忙个不停，并让我们短暂地登上了内部 Token 使用排行榜。

We also want to thank the Frontend Test Frameworks team for their help throughout the process, from early ideas to validation and feedback. Special thanks to Lucy Cheng, Natalie Stormann, Roopa Thanisraj, Ilaria Varriale, and Crescencio Zul for their thoughtful input and support along the way.我们还要感谢前端测试框架团队在整个过程中的帮助，从早期想法到验证和反馈。特别感谢 Lucy Cheng、Natalie Stormann、Roopa Thanisraj、Ilaria Varriale 和 Crescencio Zul 在此过程中的深思熟虑的投入和支持。