自动化测试的编写方式正在发生变化。以前，测试人员需要熟悉 JavaScript、Cypress 命令、DOM 结构和元素定位，才能独立编写一条端到端测试。现在，借助 AI，测试人员可以直接描述业务流程，生成可执行的测试命令，还能利用 AI 辅助补充断言和应对部分页面变化。
Cypress 已经把这些能力带进实际测试流程：Cypress Studio 可以录制真实的页面操作，Studio AI 能根据页面变化推荐断言，cy.prompt() 可以将自然语言步骤转换为 Cypress 命令，并支持针对部分 UI 变化进行自愈处理。
但测试开发人员很快会遇到一个更实际的问题：AI 生成的脚本能跑通，是否就意味着测试有效？页面改版后，AI 自动找到的元素一定正确吗？
这些问题决定了 AI 自动化测试究竟停留在演示阶段，还是能够进入企业的日常回归体系。
目录
Cypress AI 的三种测试编写方式
用自然语言生成一条完整的 E2E 测试
AI 生成断言，怎样判断测试是否有效
页面改版后，自动化脚本如何维护
从单条测试到企业级自动化测试流程
Cypress AI 的使用边界与落地建议
一、Cypress AI 的三种测试编写方式
Cypress 的 AI 测试能力主要解决三个问题：如何快速编写测试、如何补充断言，以及如何减少部分脚本维护工作。
能力
主要用途
适合场景
Cypress Studio
录制真实操作，生成测试代码
快速搭建业务流程
Studio AI
根据页面变化推荐断言
检查页面状态与断言缺口
cy.prompt()
将自然语言转换为可执行的 Cypress 命令
快速编写测试、应对部分页面改动
Cypress Studio 从真实的浏览器操作出发，测试人员点击按钮、填写表单、切换页面，工具会把这些操作转换成 Cypress 测试代码。
Studio AI 在此基础上观察操作前后的 DOM 变化，推荐元素可见性、文本内容、表单值和页面地址等断言。测试人员可以查看生成的代码，运行验证后再决定是否保留。
cy.prompt() 则提供了另一种入口。测试人员不必先写出每一步的定位器，可以直接描述测试意图，由 AI 识别页面元素并生成对应命令。
三种能力可以组合使用。例如，先通过 Studio 录制业务流程，再利用 Studio AI 补充断言；也可以直接用 cy.prompt() 描述一条新用例，随后检查和固化生成的代码。
二、用自然语言生成一条完整的 E2E 测试
假设现在需要测试一个后台管理系统的登录功能。
需求包括：用户输入正确的账号和密码，点击登录后进入工作台，并看到欢迎信息。
传统方式需要测试人员自己编写元素定位、输入操作和断言。使用 cy.prompt()，可以先把业务流程描述出来：
describe('登录流程', () => {
it('有效账号登录后进入工作台', () => {
cy.prompt(
[
'visit /login',
'type {
{email}} in the email field',
'type {
{password}} in the password field',
'click the login button',
'verify the URL includes "/dashboard"',
'verify the welcome heading is visible'
],
{
placeholders: {
email: 'qa@example.test',
password: Cypress.env('E2E_PASSWORD')
}
}
);
});
});
示例假设项目已经配置好 baseUrl、Cypress Cloud 连接和测试账号。实际项目中的页面路径、元素名称和环境变量需要按现有系统调整。
这里有三个值得关注的细节。
第一，自然语言描述的是业务意图。
测试人员不必在每一步都提前写出 CSS 选择器。AI 会根据页面结构识别元素，再生成相应的 Cypress 命令。
第二，预期结果必须明确。
“点击登录按钮”只描述了操作；“验证地址进入工作台，并确认欢迎标题可见”才描述了操作完成后应该出现的结果。
第三，敏感数据要单独处理。
placeholders 用于传递动态值或敏感输入，这些值会从发送给 AI 的请求内容中排除，并支持缓存处理。密码应从环境变量或安全的凭据管理系统中读取，不能把生产账号密码直接写进提示词或代码仓库。
自然语言提示词怎样写更准确？
测试人员给 AI 的描述越模糊，生成的测试就越容易出现歧义。
模糊描述
更适合自动化执行的描述
测试登录
使用有效账号登录，验证进入工作台
点击提交
点击名称为“提交订单”的按钮
检查页面
验证页面地址包含 /dashboard，并确认欢迎标题可见
测试失败场景
使用错误密码登录，验证错误提示出现，并确认仍停留在登录页
对于正式项目，建议把自然语言测试步骤写成“操作对象 + 执行动作 + 预期结果”的形式。
Cypress 官方目前说明，cy.prompt() 针对英文提示进行了优化，其他语言的支持效果不能保证。因此，实际使用时可以优先采用简洁、明确的英文步骤。
三、AI 生成断言，怎样判断测试是否有效
测试开发中有一个很容易被忽略的问题：脚本执行成功，不等于业务验证成功。
假设订单系统的提交按钮可以正常点击，但后端实际上没有创建订单。如果测试只检查按钮能够点击，测试报告仍可能显示通过。
Studio AI 能根据页面交互前后的 DOM 变化推荐断言，例如元素是否出现、文本是否变化、输入框的值是否正确，以及页面地址是否发生变化。
但它并不了解系统完整的业务规则，也不能仅凭页面变化判断后端数据一定正确。
以订单提交为例，可以把测试拆成三个层次：
操作验证： 确认用户能够选择商品、填写信息并提交订单。
页面结果验证： 确认出现订单提交成功提示，订单状态展示正确。
业务结果验证： 检查订单接口响应、订单编号及必要的后端数据，确认业务操作确实生效。
例如，下面的代码通过网络请求和页面状态共同验证订单提交结果：
cy.intercept('POST', '/api/orders').as('createOrder');
cy.get('[data-cy=submit-order]').click();
cy.wait('@createOrder')
.its('response.statusCode')
.should('eq', 201);
cy.get('[data-cy=order-status]')
.should('contain.text', '已提交');
这是一个示意示例，接口地址、状态码和页面元素需要按实际项目调整。
其中，cy.intercept() 负责监听订单创建请求，cy.wait() 等待请求完成并检查响应，最后再确认页面状态。
AI 可以帮助补全断言，但测试人员必须定义业务正确性的标准。 对登录、订单、支付、权限管理等核心功能，建议将页面断言与接口结果、业务数据验证结合起来，避免只检查页面表象。
四、页面改版后，自动化脚本如何维护
自动化测试最耗费精力的工作之一，就是维护不断变化的元素定位。
例如，原来的登录按钮使用 .login-btn，前端改版后换成了 .submit-btn。依赖旧选择器的脚本可能因此失败。
cy.prompt() 支持两种不同的使用方式。
使用方式
工作机制
更适合的场景
生成后固化
生成 Cypress 代码，审核后提交到代码仓库，后续按固定代码执行
核心业务回归、需要严格审查的流程
运行时自愈
保留自然语言步骤，遇到部分页面变化时重新识别元素并生成命令
页面结构经常调整、定位维护成本较高的场景
Cypress 官方支持查看 cy.prompt() 生成的具体命令，并将代码导出到项目中。运行时自愈也能帮助处理部分选择器变化，但不保证所有变化都能自动修复。
这里还涉及一个重要的工程问题：AI 找到了一个元素，不代表它找对了业务对象。
例如，页面上同时出现两个“删除”按钮。如果 AI 识别错了目标元素，测试可能继续执行，却操作了错误的数据。
所以，固定代码与动态自愈应该根据业务风险选择，而不是所有测试统一采用同一种方案。
对于稳定的核心业务流程，建议优先使用具有明确业务含义的选择器：
cy.get('[data-cy=login-button]').click();
cy.get('[data-cy=welcome]')
.should('be.visible');
对于变化频繁的页面，可以让 AI 辅助识别元素，但必须检查目标是否唯一、操作对象是否正确，以及执行结果是否符合预期。
五、从单条测试到企业级自动化测试流程
如果团队只让 AI 生成几条测试脚本，带来的收益通常有限。更有价值的做法，是把 AI 放进完整的测试开发流程。
图片
在这套流程里，AI 可以参与多个环节：
测试编写： 根据明确的业务步骤生成操作命令。
断言补充： 根据页面变化推荐可见性、文本和状态断言。
脚本维护： 帮助处理部分元素定位变化。
失败分析： 结合测试日志和实际页面状态定位问题。
持续回归： 将审核通过的脚本纳入 CI/CD，持续检查业务功能。
Cypress 还提供面向 AI 编码助手的 Cypress AI Skills，以及通过 cypress tap 让 AI 助手读取运行中的 Cypress 会话信息等能力。AI 可以据此获取更具体的测试上下文，参与编写、执行和调试测试，而不只是生成一段看起来合理的代码。
不过，自动化测试失败不能全部归因于脚本问题。定位失败可能来自页面改动，也可能是服务异常、数据问题或真实业务缺陷。团队应保留失败证据，并在修复后重新执行验证，不能让 AI 为了提高通过率而直接放宽断言。
六、Cypress AI 的使用边界与落地建议
在将这些能力引入现有项目之前，还需要确认几个现实条件。
版本与运行环境
Cypress Studio 本身支持录制操作和手动添加断言；Studio AI 的智能断言推荐要求 Cypress 15.11.0 或更高版本，并需要互联网连接、源映射配置和关联的 Cypress Cloud 项目。cy.prompt() 同样需要连接 Cypress Cloud，当前主要支持 Chrome、Edge 等 Chromium 系列浏览器。并非所有操作都能交给自然语言命令
cy.prompt() 并没有覆盖 Cypress 的全部 API。例如，API 请求、清理 Cookie 或会话、滚动到指定元素等操作存在支持限制，Canvas 和 iframe 场景也不在当前支持范围内。复杂测试仍然需要结合常规 Cypress 代码、网络拦截和测试数据管理来完成。关注执行稳定性与数据安全
自然语言步骤在运行时需要经过 AI 处理，因此团队应评估额外的执行开销、调用限额和 CI 稳定性。核心业务用例可以优先采用生成后固化的代码。
账号、密码、客户数据和生产环境信息也必须按照企业安全要求管理。应使用专用测试账号、环境变量和受控测试数据，避免把真实敏感信息写进提示词。
- 先做小范围试点，再评估投入产出
建议从登录、搜索、表单提交等流程相对清晰的场景开始，重点记录以下指标：
新增一条自动化用例需要多少时间。
页面改版后，脚本维护次数是否减少。
AI 推荐的断言中，有多少经过审核后可以保留。
自动化测试误通过、误失败的情况是否发生变化。
接入 CI/CD 后，执行时间和回归稳定性是否符合要求。
这些数据比单纯统计 AI 生成了多少行代码更有参考价值。
结语
Cypress + AI 正在改变端到端自动化测试的编写和维护方式。Cypress Studio 让录制操作更方便，Studio AI 可以辅助补充断言，cy.prompt() 则让自然语言成为生成和维护测试脚本的一种入口。
对于测试开发工程师来说，代码编写成本降低之后，测试设计、业务规则分析、断言有效性、失败诊断和工程化治理仍然不可缺少。
一条自动化测试的价值，不在于 AI 写了多少代码，而在于它能否稳定、准确地发现真实的业务问题。
未来团队引入 AI 测试工具时，建议同时建立代码审核、测试数据管理、失败归因和回归质量评估机制。只有把这些环节串起来，AI 才能从脚本生成助手，逐步成为测试工程体系中的有效工具。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
