高阶版前端工程自动化测试用例提示词

角色定义与任务定位

请以“资深前端测试架构师”的角色进行思考与创作。你的核心目标是：为复杂的前端应用或核心模块，系统化地设计与生成高质量、可维护、高覆盖率的自动化测试用例集。你的产出不是零散的测试代码片段，而是具备良好工程结构、清晰测试逻辑和明确断言策略的完整测试方案。

适用场景

• 为新增的核心业务组件（如数据可视化图表、复杂表单、状态管理模块）设计端到端（E2E）或集成测试套件。
• 对现有大型前端应用进行测试覆盖率补全，针对关键用户路径（Critical User Journey）编写自动化测试。
• 在技术方案评审后，为即将开发的功能模块预先输出测试用例，驱动测试左移（Shift-Left Testing）。
• 构建或重构项目的自动化测试框架时，定义标准化、可复用的测试用例结构与编写模式。

核心提示词

以下提示词组合可直接用于引导AI生成或作为您构思的骨架：

• 为【一个用户管理模块的“角色权限配置”功能】编写一组完整的集成测试用例。要求覆盖：1) 页面加载与初始状态断言；2) 权限树形结构的渲染与勾选交互；3) 模拟API成功/失败场景下的提交行为与UI反馈；4) 表单验证逻辑。使用 Jest + React Testing Library 语法。
• 生成针对【一个基于ECharts的实时数据仪表盘】的端到端（Cypress）测试场景。重点测试：数据流更新时图表的重绘正确性、图例交互（显示/隐藏数据系列）、工具栏缩放功能，以及无数据时的占位符显示。
• 设计【一个购物车商品增减与优惠券计算】组件的单元测试集。明确每个测试用例的：描述（it块）、前置条件（渲染组件与初始状态）、交互动作（模拟用户事件）、预期结果（对DOM状态、计算金额、组件内部状态的断言）。

风格方向

• 工程化风格：用例组织遵循“描述清晰、结构分层、准备/执行/断言（AAA）模式分明”的原则。测试代码本身应像生产代码一样可读、可维护。
• 防御性风格：不仅测试“快乐路径”（Happy Path），更要重点覆盖边界条件、异常输入、网络错误、异步超时等场景，确保前端应用的鲁棒性。
• 业务导向风格：测试描述使用业务语言（如“当用户尝试提交空表单时，应显示红色错误提示”），而非技术实现语言，便于产品、测试与开发三方沟通。

构图建议（测试用例结构）

• 顶层套件（Describe）：以被测功能或模块命名，界定测试范围。
• 逻辑分组（Describe/Nested Describe）：按用户操作流程、状态分支或子功能进行分组，形成清晰的测试叙事线。
• 用例骨架（It/Test）：每个独立测试用例遵循“Given-When-Then”或“Arrange-Act-Assert”结构，确保逻辑单一、意图明确。
• 数据驱动：将测试数据（尤其是边界值、异常值）提取为常量或工厂函数，与测试逻辑分离，便于维护与扩展。

细节强化

• 模拟（Mock）与桩（Stub）的精准使用：明确指定需要模拟的API端点、返回数据格式（成功/失败）、以及模拟的触发条件。例如：“模拟`POST /api/submit`在500ms后返回`{code: 500}`”。
• 异步操作等待：明确指定等待条件，如等待元素出现、等待网络请求完成、等待状态更新，避免使用固定的`sleep`时间。
• 可访问性（A11y）测试集成
  • 在用例中融入对关键DOM元素角色（role）、标签（aria-label）的断言，确保UI变化对辅助技术友好。
  • 为复杂的键盘导航操作流编写专门的测试用例。

  使用建议

  • 变量替换：使用【】标注的核心提示词部分，请替换为您具体的业务模块或技术栈（如Vue3 + Vitest， Angular + Protractor）。
  • 分层应用：将本方案生成的用例作为“需求规格”，再结合具体的测试框架API和项目目录规范，转化为可执行的测试文件。
  • 持续迭代：将生成的测试用例纳入版本控制系统，并与CI/CD流水线集成。当功能变更时，同步更新对应的测试用例，使其成为活的文档。
  • 组合使用：可将“核心提示词”中的不同示例组合或拆解，针对大型功能生成一个完整的测试计划，或针对微小交互生成一个独立的测试单元。