前言

在当前的软件研发流程中，端到端（E2E）测试是确保应用整体功能稳定运行的关键一环。然而，E2E 测试的开发与维护往往伴随着不小的挑战和成本投入。本文旨在分享我们团队在实践中如何运用 Cursor 这一集成环境，结合其定制化的规则引擎，来改进 E2E 代码的评审机制，并探索如何借助其智能化能力辅助测试脚本的生成，以期提升测试工作的整体效率与质量。同样的，你也可以在其他的软件比如 copilot 等的 AI 编程软件中使用。

E2E 代码评审

保证 E2E 测试代码的健壮性、可读性及一致性，对于维护一个健康的测试套件至关重要。为此，一套有效的代码评审机制不可或缺。我们发现在 Cursor 中引入的 E2E 代码评审功能，能够很好的帮助我们完成代码审查。它通过预定义的 code review 规则文件，为开发者提供了一种自动化的、基于统一标准的审视方式，有助于在开发早期就识别并修正代码中的潜在问题。

核心操作流程解析：

明确评审的代码范围：

在 Cursor 环境中，开发者首先需要指定待评审的目标代码。通过 "Add context" -> "Git" 的操作路径，可以便捷地选择：本地 Commit：这种方式较为推荐，尤其适用于开发者在本地完成阶段性编码后，期望快速获得反馈的场景。它能针对当前的工作状态进行细致检查。

加载核心评审规则：

选定代码后，选择对应的规则文件，文件内部详细定义了针对 E2E 测试代码的各项检查标准与团队认同的最佳实践，该文件在附录中有详细的介绍。

激活智能评审代理：

准备就绪后，通过一个简单的指令即可启动评审过程。开发者通常需要在相关的代码注释或特定输入区域添加一个触发指令（例如，我们内部实践中使用的 'E2ECR'）。我们像 AI Agent 发送` 帮我完成代码审查`的命令 Agent 便会依据已加载的规则，对选定代码进行扫描和深度分析。

基于反馈进行代码优化：

评审代理完成分析后，会输出一系列具体的、有针对性的修改建议。开发者需要仔细研读这些建议，理解其提出的缘由，并据此对 E2E 测试代码进行必要的调整与优化，从而达到提升代码质量的目的。

E2E 测试脚本生成

面对从零开始编写 E2E 测试脚本的耗时任务，我们尝试 E2E 测试脚本生成功能，探索一种更为高效的、由 AI 驱动的解决方案。该功能通过生成测试代码的规则，结合 MCP 工具的模板化能力以及大型语言模型（LLM）的代码理解和生成能力，旨在显著缩短测试脚本的初始开发周期。

核心操作流程解析：

配置生成测试的 MCP 工具：

此为我们内部用于优化模板生成的工具，若无此类工具，可理解为一种快速生成标准化模板的机制）。

指定生成规则与 AI 引擎 (LLM)：

与代码审查的流程相似，通过 "Add context" -> "Cursor Rules" 加载 生成代码的规则文件。此规则文件将指导后续的脚本生成逻辑。同时，需要为本次生成任务选择一个合适的大型语言模型（例如，我们实践中尝试过的 claude-3.7-sonnet）。LLM 的选择对生成代码的质量和自然度有直接影响。

下达生成指令，启动构建引擎：

配置完成后，在 Cursor 的交互界面中输入生成指令。该指令通常包含一个关键的测试用例 ID，生成模版的工具将依据此 ID 从测试管理系统中获取该用例的详细描述信息，这些信息是后续所有生成工作的原始输入。

系统内部的自动化构建逻辑概览：

用例信息提取：接收到指令后，系统首先会根据提供的 ID 与测试管理系统交互，准确抓取对应测试用例的标题、步骤描述等关键信息。

模板动态生成：基于获取到的用例信息和预定义的脚本结构，系统会动态生成一个初步的测试脚本模板，搭建起基础框架。

代码智能化填充与增强：随后，系统会利用其代码理解能力，在现有代码库中搜索与当前测试用例步骤描述在功能或语义上相似的、可复用的代码片段，并将这些片段智能地整合到模板中，以充实脚本内容。

初步质量检查与输出：在代码组装完成后，系统还会进行一轮初步检查，识别并尝试修复一些常见的语法错误或潜在逻辑问题，力求输出一份结构合理、可读性较高的初始代码。

人工介入：评审、调试与最终完善：

不可或缺的关键环节：尽管自动化生成技术发展迅速，但其生成的脚本仍应被视为初稿。开发者必须投入时间和专业判断，对其进行细致审查，修正任何可能存在的偏差、遗漏或逻辑不当之处。

严格遵循测试规范：在调试过程中，务必确保最终的测试脚本严格遵守团队内部的自动化测试（AT）编码规范和最佳实践。同时，按照内部要求，确保测试用例在本地环境中能够稳定、可靠地成功执行至少 3 次，以此验证其有效性，之后方可将代码提交入库。

生成规则的持续优化：

如果生成的脚本在准确性或实用性方面未能完全达到预期，我们鼓励团队深入分析原因，并积极调整 规则文件。通过这种持续的反馈与优化循环，脚本生成的效果将会越来越贴合实际需求。

实践带来的收益与未来可探索的方向

在团队中引入基于 Cursor 的 E2ECR 和 E2EGS 流程后，我们观察到了一些积极的变化，同时也引发了对未来进一步优化的思考。

主要收益

代码质量得到保障：通过 E2ECR 的自动化规则检查，有助于统一编码风格，减少低级错误，从而确保 E2E 测试代码的规范性和可维护性。

测试开发效率有所提升：E2EGS 在一定程度上缩短了从零开始编写测试脚本的时间，尤其对于结构相似或包含大量重复逻辑的测试用例，效果更为明显。这使得开发者能将更多精力投入到核心业务逻辑的测试设计上。

减轻人工重复劳动：无论是代码检查中的模式识别，还是脚本编写中的样板代码填充，自动化工具的引入都减轻了开发者的部分负担。

促进团队内最佳实践的推广：将编码规范和最佳实践固化到规则文件中，有助于新成员更快地理解和遵循团队标准，并在潜移默化中提升整个团队的技术水平。

加速迭代与反馈闭环：更快的代码评审和脚本生成意味着更短的测试准备周期，这为更快的软件迭代速度和更及时的质量反馈提供了支持。

未来可改进和探索的方向

规则引擎的智能化升级：当前的 .mdc 规则文件虽然具有一定的灵活性，但未来可以探索引入更高级的逻辑判断能力，例如基于机器学习的模式识别，以适应更复杂的代码场景和评审需求。

LLM 的深度定制与优化：针对特定的业务领域或项目代码风格，对所选用的 LLM 进行微调（Fine-tuning），有望生成更贴切、更符合项目实际的代码。同时，探索更优的 LLM 选择策略和多模型协作机制也值得研究。

上下文理解能力的增强：提升系统对整个项目、甚至跨项目代码库的上下文理解能力，使其在进行代码推荐或生成时，能做出更全局、更智能的判断。

与其他生态工具的无缝集成：深化与主流 CI/CD 流水线、更丰富的测试管理平台（不仅限于获取描述，还应包括结果回传、用例同步等功能）、以及开发者常用 IDE 的集成，以期打造更流畅的一站式工作体验。

调试与可解释性支持的强化：为自动生成的代码或评审建议提供更清晰的“解释”和更便捷的调试手段，帮助开发者快速理解系统行为并定位问题。

用户体验的持续打磨：不断优化 Cursor 环境内相关功能的用户界面设计和交互流程，降低学习曲线，提升用户操作的便捷性和整体满意度。

规则反馈与进化机制的完善：虽然目前已支持手动修改规则，但可以考虑建立更系统化的规则效果反馈渠道和版本管理机制，鼓励社区或团队成员共同参与规则的迭代与进化，使其更具生命力。

结语

总而言之，借助平台提供的 E2E 代码评审和测试脚本生成能力，我们的开发团队不仅在一定程度上提升了工作效率和产出质量，更重要的是，这次实践也揭示了在软件测试领域，人与 AI 协同工作的巨大潜力与广阔前景。随着技术的不断演进，我们有理由相信，未来的 E2E 测试将朝着更智能、更高效、更便捷的方向发展。

附录：关于规则（rule）文件的简要说明

我们所提及的 .mdc 文件，可以理解为我们为 Cursor 的 AI 功能设定的“行为准则”或“知识库”。

e2e-code-review.mdc：此文件定义了代码评审的具体规范。

#角色定位：首先明确 AI 在执行评审任务时的角色身份（例如，资深测试开发工程师）及其核心目标（例如，识别不符合团队规范的代码）。

#代码规范：这是规则的核心内容，详细列出了各项检查标准，涵盖了从编程标准到测试覆盖率等多个维度，例如：

编程标准 (Coding Standards)

DRY 原则 (DRY Principle)

错误处理 (Error Handling)

功能性 (Functionality)

可读性与可维护性 (Readability and Maintainability)

性能与效率 (Performance and Efficiency)

稳定性与避免测试脆弱性 (Stability and Flakiness Prevention)

测试数据管理 (Test Data Management)

报告与调试 (Reporting and Debugging)

安全性与合规性 (Security and Compliance)

CI/CD 集成与流水线稳定性 (Integration with CI/CD and Pipeline Stability)

测试覆盖率与完整性 (Test Coverage and Completeness)

gen-e2e-script.mdc：此文件则定义了自动化测试代码生成的具体规范。

#角色定位：同样，首先为 AI 设定角色，明确其作为测试脚本生成专家的技能和目标。

##信息收集 (Information Collection)：此部分指导 AI 在生成脚本前需要从用户处获取哪些必要信息。

包括测试用例的英文标题和描述、用例 ID、测试优先级、相关的关键词（如数据集 DATA_SETS、垂直领域类型 PHONE_VERTICAL 等）、维护者信息、测试用例的文档链接等，并通常会提供一个示例以供参考。

步骤定义搜索 (Step Definition Search) 规则：引导 AI 在现有代码库中搜索与新用例步骤描述相似的、已实现的步骤代码。这样做是为了提高生成代码的准确性和复用性（这一步的规则设计通常需要结合项目现有代码的实际情况，以确保 AI 能精准地找到可参考的实现）。

##特征文件 (Feature File)：此部分规定了生成的测试脚本应遵循的格式和存储位置。

文件位置 (File Location)：明确指示所有生成的 .test.ts 文件应存放的目录（例如，you feature test path，具体路径由团队自定义）。

特征模板 (Feature Template)：提供一个标准的测试用例代码模板，AI 将依照此模板进行代码生成。模板中通常包含了用例的元数据（如名称、ID、优先级、关键词等）以及具体的测试步骤结构（例如，采用 async c => { ... } 的异步函数形式）。

##生成过程 (Generation Process)：概述了 AI 执行测试用例生成的具体步骤。

接收输入：用户提供测试用例 ID。

使用 MCP 创建用例：AI 利用如 create-e2e-template 之类的辅助工具，根据用例 ID 在本地初始化测试用例的基本结构。

检查测试用例信息：核对获取到的用例信息的准确性。

搜索步骤并更新测试脚本：在初始化的用例结构基础上，AI 会根据“步骤定义搜索”的结果，将相关的代码逻辑填充到测试脚本中。