E
E2E测试执行引擎
作者：鹿Sir开发工具v1
基于项目测试用例执行E2E测试，通过浏览器自动化验证远程环境功能，记录Bug到Markdown，支持断点续测，生成测试报告。
下载量
248
点赞
62
价格
免费
技能文档
---
name: e2e-test-runner
title: E2E测试执行引擎
category: 开发工具
description: 基于项目测试用例执行E2E测试，通过浏览器自动化验证远程环境功能，记录Bug到Markdown，支持断点续测，生成测试报告。
---
# QA E2E Runner（E2E 测试执行技能）
## Overview
本技能用于对远程测试环境执行端到端（E2E）测试。AI 从 `test-project/ai-version/` 读取测试用例，通过 Browser Agent 操控浏览器逐步验证功能，将发现的 Bug 记录到 Markdown 文件，支持中断后断点续测，并在测试完成后生成 Markdown 格式的测试报告。
**关键特性：**
- 自动读取配置：如果当前项目存在 `test-config.md`，自动读取作为默认配置；不存在则询问用户
- 断点续测：通过进度文件追踪执行状态，中断后可从上次位置继续
- Bug 追踪：以 Markdown 格式记录所有发现的 Bug，字段完整、便于跟踪
- 测试报告：自动生成包含统计、模块分析、风险建议的 Markdown 报告
---
## 路径配置
本技能中所有路径均相对于**仓库根目录** `c:\TestTools\code\busyming-mcp-service` 描述。如果项目结构不同，仅需在本章节调整对应路径，其他章节引用将自动沿用。
| 路径 | 用途 |
|------|------|
| `test-project/ai-version/` | 测试用例源文件（AI 执行依据，只读） |
| `test-project/bug-reports/` | Bug Markdown 报告目录，按 `YYYYMMDD` 日期分子文件夹 |
| `test-project/test-reports/` | Markdown 格式测试报告 |
| `test-project/test-progress.json` | 断点续测进度文件 |
| `test-config.md`（项目根目录下） | 测试环境默认配置文件（可选） |
---
## 使用方式（How to Use）
通过以下方式调用本技能：
```
/qa-e2e-runner
```
或附带参数：
```
/qa-e2e-runner --resume # 从上次中断处继续执行
/qa-e2e-runner --module 001 # 仅执行指定模块
/qa-e2e-runner --module 001,003 # 仅执行多个指定模块
/qa-e2e-runner --quick # 冒烟模式：仅执行 P0 优先级用例
/qa-e2e-runner --priority P0,P1 # 指定优先级范围
/qa-e2e-runner --quick --module 001 # 组合使用
```
---
## 执行粒度与自动串行策略
### 核心原则
Browser Agent 存在上下文窗口限制，全量测试必须拆分为小批次串行执行，由 Leader 自动调度，**全程无需用户干预**。
### 规则
#### RULE-EXEC-001：单批次用例上限
- 每个 Browser Agent 单次执行**不超过 15 个用例**
- 如果单模块用例数 ≤ 15：一个 Agent 执行完整模块
- 如果单模块用例数 > 15：按优先级拆分为多批次（P0 优先），每批 ≤ 15 个
#### RULE-EXEC-002：自动串行调度
- Leader 按模块编号顺序（001 → 012）逐个调度 Browser Agent
- 当前模块所有批次执行完毕后，自动启动下一模块
- 无需用户确认或手动触发
#### RULE-EXEC-003：弹窗自动处理
- Browser Agent 遇到 confirm/alert/prompt 弹窗时，必须立即使用 handle_dialog 工具处理
- **禁止**等待用户手动干预
- **注意：handle_dialog 仅对浏览器原生弹窗（alert/confirm/prompt）有效**，对于 IDE 级弹窗或自定义组件弹窗无效，此类情况参见 RULE-EXEC-007B
- 其他业务弹窗：根据上下文选择合适操作
#### RULE-EXEC-004：进度持久化
- 每完成一个模块，立即更新 test-progress.json 中该模块状态
- 记录格式：`{ "module": "001", "status": "completed", "passed": X, "failed": X, "skipped": X }`
- 支持中断恢复：重新启动时从 test-progress.json 中读取已完成模块，跳过已完成的
#### RULE-EXEC-005：单 Agent 职责边界
- 每个 Browser Agent 只负责执行用例 + 记录结果
- 禁止在 Agent 内生成最终测试报告（由 Leader 汇总）
- Agent 输出格式固定为结构化表格（用例ID/名称/状态/备注）
#### RULE-EXEC-006：失败不阻断
- 单个用例失败不阻断后续用例执行
- 单个模块全部失败不阻断下一模块调度
- 连续 5 个用例中失败 ≥ 3 个时：自动重新登录后继续
#### RULE-EXEC-007：页面导航优先于URL猜测
- Browser Agent 进入新模块时，**必须优先通过导航菜单或页面内链接**进入目标页面
- **禁止**直接猜测URL路径访问（SPA应用的路由可能是hash路由如 `#/audit`，直接访问会404）
- 导航策略优先级：
1. 点击顶部导航栏菜单项（如"审计"）
2. 点击页面内的跳转链接（如"前往密钥管理"）
3. 从测试用例文件中读取明确的页面路径
4. 最后才尝试直接URL访问
- 如果通过URL直接访问返回404，**不可**立即判定为"模块未部署"，必须回到首页通过导航菜单重试
#### RULE-EXEC-007B：强制重登保护
- 当以下任一情况发生时，必须**自动重新登录并清除浏览器缓存**：
1. 页面显示"会话已过期"提示
2. 页面被自动重定向到登录页（URL 变为 login 或出现登录表单）
3. 页面显示"请重新登录"或"登录已失效"等文案
4. 登录态丢失（用户头像消失、权限菜单缺失）
- **禁止依赖 handle_dialog 处理登出弹窗**（该弹窗可能是 IDE 级弹窗，无法被浏览器捕获）
- 重新登录后必须清除所有缓存（localStorage/sessionStorage 中的非认证数据 + HTTP 缓存），确保后续测试不受脏数据影响
#### RULE-EXEC-008：禁止执行会触发登出的测试操作
- Browser Agent **绝对禁止**执行以下操作：
1. 清除/修改 localStorage/sessionStorage 中的认证token
2. 调用登出API或点击登出按钮
3. 任何会导致当前登录态失效的操作
- 原因：这些操作会触发系统级登出确认弹窗（非浏览器原生dialog），Browser Agent无法处理该弹窗，会导致浏览器完全卡死，阻断所有后续测试
- 涉及的用例类型（如"清除Token后跳转登录页"、"Token篡改后跳转"等）必须标记为 skip（skip_reason: `cannot_simulate`），归入「需人工验证清单」
- 如果测试用例描述中包含"清除token"、"token失效"、"登出"、"退出登录"等关键词，直接跳过，不得尝试执行
> **执行约束**：本章所有涉及"清除Token"、"篡改Token"、"触发登出"的测试操作，受 RULE-EXEC-008 约束——Browser Agent 禁止执行此类操作。相关用例统一标记为 `skip`（skip_reason: `cannot_simulate`），归入「需人工验证清单」。本章规则仅用于定义测试覆盖维度和用例生成，不影响自动化执行决策。
#### RULE-EXEC-009：未开发模块排除规则
- 以下情况的模块视为**未开发模块**，不纳入测试范围：
1. 导航栏无入口 **且**
2. 其他已开发页面中无任何跳转链接指向该模块 **且**
3. 直接访问对应路由hash后，页面未加载该模块内容（仍显示首页或空白）
- 以上三条必须**同时满足**才能判定为未开发
- 判定时机：每次全量测试开始前，先执行"模块可达性扫描"——逐个检查测试用例文件对应的模块页面是否可达
- 可达性验证方式（任一方式可达即判定为已开发）：
1. 顶部导航栏有入口
2. 其他已开发页面中有链接/按钮可跳转到该模块
3. 直接访问路由hash后页面正常加载了模块内容（非首页、非空白、非404）
- 未开发模块不执行用例、不计入统计、不记录Bug
- 测试报告中单独列出"未纳入测试的模块"及判定依据
#### RULE-EXEC-010：字段准确性校验禁止使用造数据替代真实链路
- 涉及**字段准确性校验**的测试用例（如审计日志的caller、callTime等），**必须基于真实业务操作产生的数据**进行验证
- **禁止**通过SQL插入或API直接写入"已知正确值"来替代真实链路验证
- 正确做法：先执行真实业务操作（如用API Key调用MCP工具）→ 等待数据生成 → 再验证各字段是否正确记录
- SQL造数据仅允许用于：分页测试、排序测试、大数据量压力测试等不涉及字段来源准确性的场景
- （同时覆盖漏测防护场景：造数据掩盖真实Bug）
#### RULE-EXEC-011：浏览器原生导航行为验证
- 每个页面的测试用例中，必须包含对**浏览器返回按钮**行为的验证：
1. 从页面A导航到页面B后，点击浏览器返回按钮，必须回到页面A
2. SPA应用中，路由切换必须正确管理 history 栈，不得出现返回到非预期页面的情况
- 验证场景优先级：
- **P1**：详情页返回列表页（如MCP详情页→MCP列表页）
- **P2**：跨模块导航返回（如从审计页点击链接进入MCP详情页→返回审计页）
- 执行方式：在进入目标页面后，调用浏览器返回操作（`history.back()`或点击返回按钮），验证URL和页面内容是否为预期的上一页
#### RULE-LEAK-003 & 005：E2E测试漏测防护规则（强制）
> 注：RULE-LEAK-001已融入RULE-EXEC-010，RULE-LEAK-002已融入Skip判定规则，RULE-LEAK-004已融入测试执行完整性保障章节。
基于v0.14全量测试漏测复盘，以下漏测根因必须在测试执行中主动防御：
| 编号 | 漏测类型 | 防护规则 | 违反后果 |
|------|---------|---------|----------|
| RULE-LEAK-003 | Failed未诊断根因 | 用例Failed后，不能仅描述表象（如"数据为空"），**必须追加根因诊断**（如"认证失败导致接口返回空"） | 报告中Failed用例必须附带根因分析 |
| RULE-LEAK-005 | 判定逻辑过松 | 验证字段值时，不能仅判断"非空"或"有区分"，**必须验证具体内容是否符合业务预期**（如caller应为中文姓名，而非仅"不同账号caller不同"） | 判定条件必须具体到业务语义层面 |
**Skip合法性判定标准：**
- ✅ 合法Skip：功能确认未开发/未上线（产品确认），且用例文档中标注"待实现"
- ✅ 合法Skip：测试环境临时不可用（需标注恢复后重测计划）
- ❌ 非法Skip：页面报错、接口返回异常、功能无响应 → 这些是Bug，不是Skip
- ❌ 非法Skip：前置数据不存在但应该存在 → 数据缺失本身可能是Bug
**强制约束：** 非法Skip必须同时在buglist中记录对应Bug，禁止仅标记Skip而不追踪问题。Skip原因为功能缺陷却未记Bug = 漏测。
**【强制要求-RULE-LEAK-003】** Failed用例的Bug记录中，根因(Root Cause)分析必填，不允许仅描述表象现象（如"数据为空""页面报错"）。必须诊断为什么出现该现象（如"Key认证失败导致接口返回空"）。
**Failed根因诊断模板：**
```
用例ID: TC-E2E-XXX
表象: [描述观察到的现象]
根因: [分析为什么出现该现象]
影响范围: [该根因还可能影响哪些其他用例]
关联Bug: BUG-V14-XXX（新建/已存在）
```
### 调度流程图
```
Leader 读取模块列表 → 按编号排序
↓
对每个模块:
├─ 检查 test-progress.json，已完成则跳过
├─ 计算用例数，> 15 则拆分批次
├─ 派发 Browser Agent（含用例清单 + 环境配置）
├─ Agent 完成 → Leader 收集结果
├─ 更新 test-progress.json
└─ 自动进入下一模块
↓
全部模块完成 → Leader 汇总生成最终报告
```
---
## 执行流程
AI 被调用后必须严格按以下步骤执行：
### 阶段一：环境准备
1. **读取默认配置（可选）**
检查当前项目是否存在 `test-config.md` 文件：
- 存在 → 自动读取，获取默认环境配置（测试地址、账号密码、浏览器等）
- 不存在 → 跳过此步，直接在下一步询问用户提供所有必要信息
2. **确认或覆盖**
将读取到的配置（或空白模板）展示给用户，询问：
- "检测到以下默认配置，是否直接使用？如需修改请告知。"（有配置文件时）
- "未检测到配置文件，请提供以下测试环境信息："（无配置文件时）
- 用户确认则直接使用，用户提供新值则覆盖对应字段
- **本次测试范围**（见下方说明）
- **截图保存目录**（默认 `test-project/bug-reports/YYYYMMDD/`，以测试执行日期命名，用户可自定义路径）
- 其他备注（如特定测试数据、已知问题等）
**测试范围确认（重要）：**
由于项目可能只开发了部分模块，必须在开始前确认本次测试范围：
- 列出 `test-project/ai-version/` 下所有可用模块（编号 + 名称），供用户勾选
- 如果用户通过 `--module` 参数已指定，展示确认即可
- 如果用户未指定，询问："是否执行全部模块测试？还是只测试部分已开发模块？"
- 用户可输入模块编号（如 `001,002,003`）来选择范围
- 将最终确认的测试范围记录到进度文件的 `scope` 字段中
3. **检查依赖**
Bug 以 Markdown 格式记录，直接使用文件写入工具（Write/SearchReplace）操作，无需额外 Python 依赖。
4. **初始化目录**
确保以下目录存在，不存在则创建：
```
test-project/bug-reports/
test-project/bug-reports/YYYYMMDD/
test-project/test-reports/
```
其中 `YYYYMMDD` 为本次测试执行日期，同一天多次测试共享同一日期文件夹。
5. **检查断点续测**
读取 `test-project/test-progress.json`：
- 若文件存在且用户确认继续 → 进入断点续测模式，从上次未完成的用例继续
- 若文件不存在或用户选择重新开始 → 创建新的进度文件
### 阶段二：加载测试用例
6. **扫描用例文件（按测试范围过滤）**
根据阶段一确认的测试范围，按文件名排序读取对应的 `.md` 文件（排除 `README.md`）：
- 全量测试：读取 `test-project/ai-version/` 下所有 `.md` 文件
- 部分模块：仅读取用户选定模块对应的文件（如选择 `001,003` 则只读取 `001-xxx.md` 和 `003-xxx.md`）
7. **解析并过滤 E2E 用例**
从每个 Markdown 文件中提取测试用例时，必须遵守以下过滤规则：
- **只解析 E2E 区域**：优先查找标题含"E2E 测试"的章节（如 `## 九、E2E 测试`），仅在该章节内提取用例
- **只执行用例 ID 以 `TC-E2E-`、`TC-E2E-SUP-`、`TC-E2E-ISO-` 或 `TC-E2E-TEXT-` 开头的测试用例**
- **忽略其他类型**：`TC-API-*`、`TC-SVC-*`、`TC-CARD-*` 等不在本 Skill 执行范围内，仅作上下文参考
- 如果 Markdown 文件中没有 E2E 章节，跳过该文件
提取到的每个用例至少包含：用例ID、用例名称、前置条件、操作步骤、预期结果、优先级。
**统计说明**：`total_cases` 仅统计本次测试范围内的 E2E 用例数，而非全部模块的总用例数。
### TC-E2E-TEXT-* 文案质量检查执行规则
执行 `TC-E2E-TEXT-*` 前缀用例时：
1. 抓取页面所有可见文本（标题、按钮、提示语、表格列头、卡片内容、弹窗文案）
2. 按 global.md 第十三章的 5 个维度逐一检查：错别字、逻辑通顺、中英文混排、文案一致性、空文案/占位符
3. 发现问题记录为 Bug，**按指派判定规则确定指派对象**（见阶段四 Bug指派判定）
4. 优先级：空文案/占位符为 P0，错别字/逻辑不通为 P1，混排/一致性为 P2
5. 文案问题如spec未明确要求，优先级降为 P3，指派产品经理
### 阶段二-B：加载历史Bug回归清单
7.5 **扫描上次未修复Bug**
在正式执行测试用例前，自动扫描历史 Bug 记录用于回归验证：
1. 扫描 `test-project/bug-reports/` 目录下所有日期子目录（格式 YYYYMMDD）
2. 找到最近一次（非本次）的 `buglist-*.md` 文件
3. 解析该文件，提取所有状态为 `Open` 的 Bug 记录
4. 生成回归验证清单，包含每个 Open Bug 的：Bug ID、所属模块、操作步骤、预期结果
**输出示例：**
```
检测到上次 buglist（20260701）中有 X 个 Open Bug 需要回归验证：
- BUG-001 (P1): 卡片列表页缺少工具数量显示
- BUG-004 (P1): 404页面不显示导航栏
将在测试执行过程中同步验证这些 Bug 是否已修复。
```
如果没有找到历史 buglist 或所有 Bug 均为 Fixed/Closed，跳过此步骤。
### 阶段二-C：数据准确性用例的测试数据准备
对于标记为"数据准确性校验"类的E2E用例（如审计中心字段校验），执行前需先造数据：
1. **识别造数据需求**：当用例前置条件中包含"需先通过MCP工具调用产生已知审计数据"或类似描述时，触发数据准备流程
2. **执行MCP工具调用**：通过CallMcpTool调用审计中心已接入的MCP服务（当前已接入：product-inventory-api-to-mcp、py-meeting-server-to-mcp、py-server-to-mcp、py-yuque-server-to-mcp），记录调用时间、服务名、工具名等关键信息作为后续校验基准
3. **等待数据同步**：调用后等待约5-10秒，确保审计系统记录到位
4. **进入UI验证**：携带已知的调用信息进入审计中心页面，逐字段比对
注意：如果审计中心未接入某些MCP服务（如CV类服务），应在测试报告中标注"无法验证"并记录原因，而非跳过。
### 阶段二-D：多账号隔离性用例准备（TC-E2E-ISO-*）
1. **前置检测**：识别待执行用例中是否包含 `TC-E2E-ISO-*` 前缀
2. **账号准备**：若当前仅配置了一个测试账号，暂停执行并询问用户：
> 检测到本次测试包含多账号隔离性验证用例（TC-E2E-ISO-*），当前仅有1个测试账号。
> 请提供第2个测试账号（账号+密码），或指定跳过这些用例。
3. **账号标识**：在测试报告中标注每个 ISO 用例使用的账号（如"账号A: xxx / 账号B: yyy"）
4. **禁止静默跳过**：不得因缺少第二账号而静默跳过 ISO 用例，必须在报告中明确标注"因缺少第二账号而跳过"
### 阶段二-E：前置条件自动验证
每个模块正式执行前，先运行"前置条件预检"，确保测试环境就绪：
**预检项：**
1. **页面可访问性**：通过 Browser Agent 访问目标页面，确认非 404/500
2. **核心数据存在性**：检查页面关键列表/卡片区域是否有数据展示
3. **登录态有效性**：确认当前会话未过期
**预检失败处理：**
- **页面不可达** → 标记该模块所有用例为 skip（skip_reason: `environment_unavailable`），跳过该模块
- **数据为空但应有数据** → 尝试通过阶段二-C的造数据流程补充；造数失败则标记 skip（skip_reason: `data_unavailable`）
- **登录态失效** → 自动重新登录，成功后继续预检
**预检结果记录：**
预检结果记录到进度文件的 `module_prechecks` 字段，格式如下：
```json
"module_prechecks": {
"001-mcp-list-page": {
"page_accessible": true,
"data_available": true,
"session_valid": true,
"result": "pass"
}
}
```
预检通过后才进入阶段三正式执行。
### 阶段三：执行测试
8. **逐模块逐用例执行（按文件顺序，一个模块全部完成后再执行下一个）**
**模块切换隔离（模块间边界处理）：**
当一个模块全部用例执行完毕、开始下一模块前，执行以下清理操作：
1. 清除浏览器 localStorage/sessionStorage 中的非认证数据（搜索历史、筛选条件、用户偏好设置）
2. 保留 auth token / user info / session 等认证相关数据
3. 将页面滚动位置重置到顶部
4. 若当前页面有搜索框或筛选条件处于激活状态，清空输入或重置为默认值
5. 导航到下一模块的目标页面，等待页面就绪（网络空闲或关键元素可见）
6. 清理失败时记录警告日志但不中断测试执行
对每个测试用例，按以下流程操作：
**a. 更新进度**
将当前用例状态标记为 `in_progress`，写入 `test-progress.json`。
**b. 浏览器操作（通过 Browser Agent）**
调用 Browser Agent 执行实际操作：
- 导航到目标页面
- 执行前置条件（如登录、数据准备）
- 按操作步骤逐步执行
- 验证实际结果是否与预期结果一致
- 按[截图策略](#截图策略)保存必要截图
#### Browser Agent 操作规范
**登录复用：**
- 测试开始时先执行一次完整登录流程
- **登录成功后，立即清除浏览器缓存**（清除 localStorage/sessionStorage 中的非认证数据、清除 HTTP 缓存），确保后续页面加载的数据均为服务端最新响应，避免因缓存导致统计数据不准确
- 后续用例复用已登录状态（同一浏览器上下文）
- 若发现登录态失效（如被踢出），自动重新登录后继续
**等待策略：**
- 页面导航后：等待网络空闲（无 pending 请求）或等待关键元素可见，取先到者
- 交互操作后：等待目标状态变化（如弹窗出现、列表刷新），超时 30 秒
- 避免使用固定 sleep
**搜索/筛选类用例执行规则：**
- 执行搜索功能测试时，禁止直接使用测试用例中写死的关键词
- 必须先读取当前页面实际展示的数据（列表项名称、描述、标签等）
- 从页面真实数据中提取一个关键词作为搜索输入
- 再验证搜索结果是否正确过滤/匹配
- 原则：测试数据来自页面本身，不依赖预设环境数据
**搜索/问答结果准确性验证规则（强制）：**
对于AI问答、搜索发现等智能推荐类功能，测试不能仅验证"有结果返回"，必须验证结果的**内容准确性**：
| 验证维度 | 具体要求 | 示例 |
|---------|---------|------|
| 正向匹配 | 搜索存在的内容，结果中必须包含对应项 | 搜"货架检测"→ 推荐卡片含 goods-shelf-cv-mcp-real |
| 负向验证 | 搜索不存在的内容，不应返回无关推荐 | 搜"天气预报"→ 无推荐卡片或明确提示无结果 |
| 相关性 | 推荐结果与查询意图语义相关 | chip"哪些能力可以上传图片"→ 推荐支持图片的MCP |
| 完整性 | 符合条件的结果不遗漏（可抽样验证） | 搜"检测"→ 至少返回2个检测类MCP |
**关键原则：**
- "有结果"≠"结果正确"，必须验证返回内容与查询意图的匹配度
- 对于AI生成的文字回答，验证其中是否提及了与查询相关的能力描述
- 对于推荐卡片，验证卡片标题/描述是否与搜索关键词语义相关
**c. 元素定位容错机制（选择器优先级，保持不变）**
当 Browser Agent 找不到页面元素时，按以下顺序重试：
1. **优先使用 text 属性定位**（如按钮文字、链接文字、标签文字）
2. 尝试 `aria-label` 属性
3. 尝试 `data-testid` 或 `data-test` 属性
4. 使用 XPath 相对路径定位
5. 以上方法均失败时，**必须截图当前页面**，记录为 Bug 并标记为 failed，**禁止跳过该用例**
**d. 判定结果**
- **通过（passed）**：实际结果与预期结果一致
- **失败（failed）**：实际结果与预期结果不一致 → 记录 Bug（见阶段四）
- **间歇性失败（flaky）**：同一用例在不同执行中结果不一致（一次通过、一次失败）→ 仍然记录为 Bug，优先级至少 P2，备注中标注"间歇性/偶现"及复现率观察
- **跳过（skipped）**：当用例无法执行时标记为 skipped，必须同时记录跳过原因分类：
| 原因类型 | skip_reason 值 | 适用场景 | 示例 |
|---------|---------------|---------|------|
| 环境不可用 | `environment_unavailable` | 服务未部署/页面不可达/API超时 | MCP服务连接超时、页面返回500 |
| 数据缺失 | `data_unavailable` | 前置数据构造失败/无可用测试账号 | API造数失败、缺少第二测试账号 |
| 依赖阻塞 | `blocked_by:{case_id或bug_id}` | 前置用例失败导致当前用例无法执行 | 列表页点击跳转失败→详情页用例被阻塞 |
| 版本未开发 | `version_not_developed` | 该功能明确标注为下个版本开发 | 规划中的新功能 |
| 无法模拟 | `cannot_simulate` | 测试环境真正无法模拟的条件 | 无法模拟断网、无法触发硬件故障 |
> **禁止误判为 skipped 的情况**：当页面应展示数据但实际为空时（如工具列表显示0个、列表页无卡片等），必须先确认该服务/数据是否实际存在。如果服务实际有数据但页面未展示，这是 **Bug** 而非跳过。"数据为空"不等于"前置条件不满足"。
> **重要原则**：不得以“环境问题”为由跳过或忽略失败用例。任何失败结果都必须记录为 Bug。如果怀疑是环境因素（如 session 过期、网络抖动），应在 Bug 备注中说明可能原因，但不能因此不记录。间歇性问题本身就是需要排查的质量风险。
> **深度验证原则**：对于"复制到剪贴板"、"下载文件"、"导出数据"等操作类功能，仅验证操作成功提示（如 toast）不充分，必须同时验证操作产物的内容正确性（如剪贴板实际值、文件实际内容）。只验证"操作成功"而不验证"结果正确"属于无效测试。
> **【业务语义验证原则-RULE-LEAK-005】** 对字段值的验证必须深入业务语义层面：
> - 不能仅判断"非空"或"有区分"，必须验证值是否符合业务预期
> - 示例：caller字段不能仅判断"账号A的caller≠账号B的caller"，必须验证"caller是否为用户中文姓名而非技术标识符test_xxx"
**f-2. Bug 回归验证（穿插执行）**
在执行常规测试用例的过程中，当进入某个模块时，同步验证该模块下的历史 Open Bug：
- 按 Bug 记录的操作步骤进行复现尝试
- **已修复**：直接更新原 buglist 文件中该 Bug 的状态：
- `当前状态` 列从 `Open` 改为 `Fixed`
- `备注` 列追加回归验证信息（如"MMDD回归验证通过，{具体验证说明}"）
- **未修复**：在本次新 buglist 中新增一条记录：
- Bug ID 使用本次 buglist 的自增编号
- 备注标注"与{原日期} BUG-XXX 相同，仍未修复"
- 优先级、模块、操作步骤等与原 Bug 保持一致
- **无法验证**（如该模块不在本次测试范围）：保持原状态不变，不做修改
**e. 记录结果**
将用例结果写入 `test-progress.json`：
```json
"modules": {
"001-mcp-list-page": {
"status": "in_progress",
"cases": {
"TC-E2E-001": "passed",
"TC-E2E-002": "failed"
}
}
}
```
同时更新 `completed_cases`、`passed`、`failed`、`skipped` 计数。
**f. 模块完成标记**
当一个模块所有用例执行完毕，将该模块 `status` 更新为 `completed`。
## 阶段四：Bug 记录
9. **发现 Bug 时立即记录**
每发现一个 Bug，立即追加到 Markdown 格式的 Bug 列表文件中。
**Bug指派判定（强制步骤，每条Bug必须执行）：**
记录Bug前，必须对照以下规则确定「指派对象」字段：
- **spec明确要求但未实现** → 查看spec中的具体描述：
- 后端API/数据/接口问题 → 指派**后端**
- 前端UI/交互/布局问题 → 指派**前端**
- **spec未提及的问题**（如中英文空格规范、文案一致性等通用规范） → 指派**产品**，优先级降为P3，备注标注"需求建议"
- **demo有但实际缺失** → 指派**前端**
- **AI回答内容问题**（推荐不精准、暴露内部信息、兜底回复不合规、回答语义错误） → 指派**算法**
> 禁止不经判定直接硬编码指派对象。每条Bug的指派必须有明确依据。
**Bug 文件路径：**
```
test-project/bug-reports/YYYYMMDD/buglist-YYYYMMDD_HHmmss.md
```
**写入方式：**
直接使用文件写入工具（Write/SearchReplace）向 Bug 列表文件追加记录，无需额外脚本。
**Markdown Bug 记录格式：**
每个 Bug 作为一行追加到表格中：
```markdown
| BUG-XXX | 模块名 | TC-E2E-XXX | P0/P1/P2 | Bug标题 | 前置步骤 | 操作步骤 | 预期结果 | 实际结果 | 截图路径 | 环境信息 | Open | 指派对象 | 备注 | 2026-XX-XX HH:MM:SS |
```
**首次创建文件时，写入表头：**
```markdown
# Bug List
| Bug ID | 所属模块 | 测试用例ID | 优先级 | 标题 | 前置步骤 | 操作步骤 | 预期结果 | 实际结果 | 截图路径 | 环境信息 | 当前状态 | 指派对象 | 备注 | 发现时间 |
|--------|---------|-----------|--------|------|---------|---------|---------|---------|---------|---------|---------|----------|------|---------|
```
### 阶段五：生成报告
10. **生成测试报告**
所有用例执行完毕（或用户主动终止）后，读取 `test-progress.json` 和 Bug Markdown 文件，生成 Markdown 测试报告。
**报告存放路径：**
```
test-project/test-reports/test-report-YYYYMMDD-HHmmss.md
```
### 人工验证清单输出
测试报告生成后，必须额外输出一份「需人工验证清单」，列出所有 Browser Agent 无法自动执行的用例，供测试人员手动验证。
**纳入清单的条件：**
- skip_reason 为 `cannot_simulate` 的用例（如扫码登录、断网模拟、硬件触发等）
- 需要真实物理设备配合的用例（如企微扫码、短信验证码）
- 需要精确时机观察的用例（如骨架屏加载态、动画过渡效果）
**清单格式（附在测试报告末尾或单独输出给用户）：**
```markdown
## 需人工验证清单
> 以下用例因技术限制无法通过 Browser Agent 自动执行，需测试人员手动验证。
| 序号 | 用例ID | 所属模块 | 用例名称 | 无法自动化原因 | 验证要点 |
|------|--------|---------|---------|--------------|---------|
| 1 | TC-E2E-228 | 012-api-key-management | 企微扫码登录 | 需真实手机扫码 | 扫码后正确跳转到密钥管理页面 |
| ... | ... | ... | ... | ... | ... |
```
**规则要求：**
- 测试结束后必须输出此清单，不可遗漏
- 每个用例必须注明"无法自动化原因"和"验证要点"（简要说明人工验证时关注什么）
- 清单中的用例不计入自动化通过率，但必须在测试报告的"跳过原因分布"中体现
11. **收尾工作**
- 将最终结果汇总输出给用户
- 更新 `test-progress.json` 的 `last_updated` 时间
- 若全部通过，提示用户；若有失败，列出关键 Bug
---
## 截图策略
- **仅 Bug 截图**：只有发现 Bug 时才截图作为证据，通过的用例和普通测试过程一律不截图
- **失败用例**：必须截图（截取失败时刻的页面状态）
- **通过用例**：禁止截图
- 截图命名：`{test_case_id}-{timestamp}.png`（而非 `bug_id`，因为截图时可能还未分配 bug_id）
- 截图默认存放在 `test-project/bug-reports/YYYYMMDD/` 目录，与当天的 buglist 文件同级
- **清理规则**：项目中仅保留 buglist 文件引用的截图，其余图片应删除
---
## Bug 记录规范
### 文件信息
- **存放路径**：`test-project/bug-reports/YYYYMMDD/`，按测试执行日期分文件夹
- **文件名格式**：`buglist-YYYYMMDD_HHmmss.md`（以测试会话开始时间命名）
- **文件格式**：Markdown 表格
### 字段定义
| 序号 | 字段名 | 说明 | 示例 |
|------|--------|------|------|
| 1 | Bug ID | 自增编号 | BUG-001 |
| 2 | 所属模块 | 对应测试用例的模块名 | MCP列表页 |
| 3 | 测试用例ID | 关联的测试用例编号 | TC-E2E-001 |
| 4 | 优先级 | P0/P1/P2 | P0 |
| 5 | 标题 | Bug 简要描述 | 列表页分页功能失效 |
| 6 | 前置步骤 | 触发 Bug 前需完成的操作 | 登录系统→进入MCP列表页 |
| 7 | 操作步骤 | 触发 Bug 的具体操作 | 点击第2页分页按钮 |
| 8 | 预期结果 | 正常应该出现的行为 | 显示第2页数据列表 |
| 9 | 实际结果 | 实际出现的异常行为 | 页面无响应，仍显示第1页 |
| 10 | 截图路径 | Bug 截图的相对路径（相对 buglist 文件） | ./TC-E2E-001-20260626.png |
| 11 | 环境信息 | 测试URL、浏览器等 | URL: https://test.xx.com, Chromium |
| 12 | 当前状态 | Open/Fixed/Verified/Closed/Won't Fix | Open |
| 13 | 指派对象 | 根据Bug指派分类规则自动判定（产品经理/后端工程师/前端工程师/算法） | 后端工程师 |
| 14 | 备注 | 补充信息（间歇性Bug标注复现率和原因） | 间歇性，复现率约50%，疑似session过期 |
| 15 | 发现时间 | 发现 Bug 的时间戳 | 2026-06-26 09:30:15 |
### Bug 指派分类规则
记录 Bug 时，根据以下规则自动判定指派对象：
| 问题类型 | 判定依据 | 指派对象 |
|----------|----------|----------|
| 需求缺失/健壮性 | spec/tasks 中未提及，属于边界情况、异常处理、容错设计 | 产品经理 |
| 实现缺陷 | spec 明确要求但未实现，或 demo 有而实际缺失；后端 API 数据错误、接口逻辑、鉴权后端实现 | 后端工程师 |
| UI/前端问题 | 布局、样式、控件行为与 demo 不符；页面路由、前端逻辑、交互行为、渲染问题 | 前端工程师 |
| AI回答内容问题 | 推荐不精准、暴露内部信息、兜底回复不合规、回答语义错误 | 算法 |
判定优先级：先判断是否为需求缺失（spec 有无提及），再区分前后端职责。
### 优先级定义
- **P0**：阻塞性问题，核心功能完全不可用（如白屏、崩溃、无法登录）
- **P1**：重要功能异常或数据错误（如列表数据不显示、操作无响应）
- **P2**：次要问题（如样式错位、文案错误、非核心交互异常）
---
## 断点续测机制
### 进度文件
- **路径**：`test-project/test-progress.json`
- **作用**：记录当前测试会话的完整执行状态，支持中断恢复
### 进度文件结构
```json
{
"session_id": "uuid-v4",
"started_at": "2026-06-26T09:00:00+08:00",
"last_updated": "2026-06-26T10:30:00+08:00",
"test_url": "https://test.example.com",
"username": "testuser",
"credentials": {
"username": "testuser",
"password_hint": "***（不存储明文密码）"
},
"browser": "Chromium",
"screenshot_dir": "test-project/bug-reports/YYYYMMDD/",
"scope": {
"type": "partial",
"selected_modules": ["001-mcp-list-page", "002-mcp-detail-page"],
"all_available_modules": ["001-mcp-list-page", "002-mcp-detail-page", "003-global-navigation"]
},
"total_cases": 100,
"completed_cases": 50,
"passed": 45,
"failed": 5,
"skipped": 0,
"modules": {
"001-mcp-list-page": {
"status": "completed",
"module_name": "MCP列表页",
"cases": {
"TC-E2E-001": "passed",
"TC-E2E-002": "failed",
"TC-E2E-003": "passed"
}
},
"002-mcp-detail-page": {
"status": "in_progress",
"module_name": "MCP详情页",
"cases": {
"TC-E2E-001": "passed"
}
}
},
"bug_report_file": "test-project/bug-reports/20260626/buglist-20260626_090000.md"
}
```
### 命令参数行为约定
#### `--resume` 规则
| 场景 | 行为 |
|------|------|
| 带 `--resume` + 进度文件存在 | 直接进入续测流程 |
| 带 `--resume` + 进度文件不存在 | 提示"未找到历史进度，将从头开始"，需用户确认 |
| 未带 `--resume` + 进度文件存在 | 询问用户"检测到上次进度，是否续测？" |
| 未带 `--resume` + 进度文件不存在 | 正常从头开始 |
#### `--module` 规则
- 值为模块编号前缀，如 `--module 001` 对应 `001-mcp-list-page.md`
- 支持多模块：`--module 001,003`
- 与进度文件结合时：仅对指定模块中未完成的用例继续执行
- 不带进度文件时：只执行指定模块的全部 E2E 用例
### 续测流程
1. 检测到 `test-progress.json` 存在时，读取文件内容
2. 向用户展示上次执行进度摘要：
- 已完成 / 总计用例数
- 各模块完成状态
- 通过/失败/跳过统计
3. 询问用户：
- **继续执行**：从上次中断的用例继续
- **重新开始**：归档旧进度文件，创建新会话
- **指定模块**：仅执行特定模块
4. 若选择继续，且进度文件中已记录 `test_url`、`username`、`screenshot_dir`、`browser` 等环境信息，询问用户是否沿用，**默认沿用**
5. 跳过已完成模块和已完成的用例，从中断点继续执行
### 安全注意
- **密码不存储在进度文件中**，续测时需重新输入
- `password_hint` 仅记录"已提供"标记，不记录实际值
---
## 测试执行完整性保障
为防止测试过程中漏跑用例，本技能强制执行以下完整性规则。所有全量测试、部分模块测试以及断点续测场景均须遵守。
### 1. 用例清单强制加载
全量测试开始前，必须先读取本次测试范围内的所有测试用例文件，解析出完整的 E2E 用例 ID 清单：
- 读取 `test-project/ai-version/*.md`（排除 `README.md`）
- 仅保留用例 ID 以 `TC-E2E-`、`TC-E2E-SUP-`、`TC-E2E-ISO-` 或 `TC-E2E-TEXT-` 开头的用例
解析完成后，生成一份执行 checklist，包含每个用例的 **用例ID、所属模块、用例标题、计划状态**。执行过程中逐条标记，确保没有遗漏。
### 2. 执行状态强制记录
每个测试用例执行完毕后，必须立即在进度文件和 checklist 中记录最终状态，状态只允许以下三种：
| 状态 | 图标 | 含义 | 处理要求 |
|------|------|------|----------|
| 通过 | ✅ Pass | 实际结果与预期结果一致 | 更新进度文件，无需截图 |
| 失败 | ❌ Fail | 实际结果与预期结果不一致 | 必须记录为 Bug，并截图 |
| 跳过 | ⏭️ Skip | 当前条件下无法执行 | 必须注明跳过原因，并在备注中说明 |
**禁止**仅记录发现的 Bug 而忽略通过的用例。即使某个模块全部通过，也必须在 checklist 中明确列出每个用例的 Pass 状态。
### 3. 执行覆盖率检查
所有用例执行完毕后，必须进行覆盖率核对：
- 核对公式：`已执行用例数 = 本次测试范围内总用例数 - 明确标注"该版本未开发"的用例数`
- 如果存在未执行的用例（非"该版本未开发"），必须在测试报告和最终输出中明确列出，并说明未执行原因
- **全量测试要求覆盖率为 100%**（排除已明确标注"该版本未开发"的用例）
若覆盖率未达到 100%，禁止标记测试会话完成，必须继续执行或经用户确认后将未执行用例标记为 Skip 并注明原因。
**漏跑用例处理规范：** 全量测试结束后，必须核对用例文件中的TC-ID清单与实际执行清单。若发现存在完全漏跑的用例（不在已执行清单中，也未标记为Skip），必须立即补充执行或标注原因。全量测试≠部分执行，每个TC-ID必须有明确状态。
### 4. 测试报告附加「用例执行清单」
生成的测试报告（或 buglist 文件末尾）必须附加「用例执行清单」章节，列出本次测试范围内每个用例的最终状态。表格格式如下：
```markdown
## 用例执行清单
| 用例ID | 所属模块 | 标题 | 执行状态 | 跳过原因 | 备注 |
|--------|---------|------|---------|---------|------|
| TC-E2E-001 | 001-mcp-list | xxx | ✅ Pass | | |
| TC-E2E-002 | 001-mcp-list | xxx | ❌ Fail | | 见BUG-001 |
| TC-E2E-SUP-001 | 001-mcp-list | xxx | ❌ Fail | | 见BUG-002 |
| TC-E2E-006 | 004-homepage | xxx | ⏭️ Skip | version_not_developed | 该版本未开发 |
```
- 用例按模块和用例ID排序
- 备注列用于关联 Bug ID、说明跳过原因或补充信息
- 通过用例不得留空执行状态
### 5. 断点续测兼容
测试执行完整性保障机制与现有 `test-progress.json` 断点续测机制完全兼容：
- 续测时，只执行进度文件中状态为 `pending`、`in_progress` 或未记录的用例
- 已完成用例（`passed`/`failed`/`skipped`）不再重复执行
- 无论是否经过续测，最终生成的测试报告必须包含**所有用例**的完整状态（已执行 + 未执行但已标注原因）
- 若续测过程中新增或删除了测试用例文件，需在开始续测前重新核对 checklist 并向用户确认
---
## 快速路径执行规则（--quick / --priority 模式）
当用户使用 `--quick` 或 `--priority` 参数时，按以下规则过滤用例：
### 过滤逻辑
| 参数 | 过滤规则 | 说明 |
|------|---------|------|
| `--quick` | 仅执行优先级为 P0 的 `TC-E2E-*` 用例 | 跳过 TC-E2E-SUP-*、TC-E2E-ISO-*、TC-E2E-TEXT-* |
| `--priority P0,P1` | 执行指定优先级范围内的所有前缀用例 | 可指定任意优先级组合 |
| `--quick --module 001` | 指定模块的 P0 用例 | 参数可组合使用 |
### 被过滤用例的处理
- 被过滤掉的用例在报告中标记为 skip（skip_reason: `filtered_by_priority`）
- 被过滤用例**不计入通过率分母**（可执行用例数中排除）
- 进度文件中记录过滤参数：`"filter": {"mode": "quick", "priority": ["P0"], "total_matched": N}`
### 报告特殊标注
- 快速路径模式下报告标题增加"★ 冒烟测试"标识
- 报告开头明确标注"本次仅执行 P0 优先级，共 X/Y 个用例（Y为全量用例数）"
- 若 P0 通过率 < 95%，在报告概要中以醒目方式警告："⚠️ 核心用例通过率不足95%，建议排查后再进行全量测试"
---
## 测试报告格式
### 文件信息
- **存放路径**：`test-project/test-reports/`
- **文件名格式**：`test-report-YYYYMMDD-HHmmss.md`
### 截图可访问性要求
生成测试报告时，必须确保报告中引用的所有截图文件可访问：
- 报告生成前，检查每个截图路径对应的文件是否存在
- 若截图路径为绝对路径或跨目录引用，**必须将截图文件复制到报告同目录下的 `screenshots/` 子目录**，并更新报告中的路径为相对路径
- 若截图文件缺失，在报告中标注为"[截图缺失]"而不是引用无效路径
### 报告模板
```markdown
# E2E 测试报告
## 1. 测试概要
| 项目 | 信息 |
|------|------|
| 项目名称 | Busyming MCP Service |
| 测试环境 | {test_url} |
| 执行人 | AI Agent |
| 开始时间 | {started_at} |
| 结束时间 | {ended_at} |
| 测试时长 | {duration} |
| 浏览器 | {browser} |
| **测试范围** | **{scope_description}** |
> **测试范围说明**：{scope_detail}
>
> - 全量测试时显示："全量测试（覆盖全部 N 个模块）"
> - 部分模块时显示："部分模块测试（N/M 个模块）"，并列出具体模块名称
> - 如有未测试模块，在此注明："未纳入本次测试的模块：XXX、YYY（尚未开发/不在本次范围内）"
## 2. 测试结果统计
| 指标 | 数值 | 说明 |
|------|------|------|
| 总用例数 | {total} | 本次测试范围内的所有用例 |
| 可执行用例数 | {executable} | 排除"版本未开发"和"无法模拟"后的用例数 |
| 通过 | {passed} | |
| 失败 | {failed} | |
| 跳过 | {skipped} | |
| **可执行通过率** | **{passed}/{executable} = {rate}%** | 质量评估核心指标 |
### 跳过原因分布
| 原因 | 数量 | 占比 | 说明 |
|------|------|------|------|
| 环境不可用 | {n} | {p}% | 服务/页面不可达 |
| 数据缺失 | {n} | {p}% | 前置数据无法构造 |
| 依赖阻塞 | {n} | {p}% | 前置用例失败 |
| 版本未开发 | {n} | {p}% | 功能尚未开发 |
| 无法模拟 | {n} | {p}% | 环境限制 |
| 优先级过滤 | {n} | {p}% | 仅 --quick/--priority 模式 |
## 3. 测试范围与模块统计
### 3.1 本次测试范围
- **测试类型**：{全量测试 / 部分模块测试}
- **已测试模块**：{tested_modules_list}
- **未测试模块**：{untested_modules_list}（原因：{尚未开发 / 不在本次范围}）
### 3.2 按模块统计（仅含已测试模块）
| 模块 | 总数 | 通过 | 失败 | 跳过 | 通过率 | 状态 |
|------|------|------|------|------|--------|------|
| MCP列表页 | 15 | 13 | 2 | 0 | 86.7% | completed |
| MCP详情页 | 12 | 12 | 0 | 0 | 100% | completed |
| ... | ... | ... | ... | ... | ... | ... |
## 4. 失败用例清单
### 4.1 {模块名} - {用例ID}: {用例名称}
- **优先级**：{priority}
- **操作步骤**：{steps}
- **预期结果**：{expected}
- **实际结果**：{actual}
- **Bug ID**：{bug_id}
- **截图**：{screenshot_path}
## 5. Bug 汇总
| Bug ID | 模块 | 优先级 | 标题 | 状态 |
|--------|------|--------|------|------|
| BUG-001 | MCP列表页 | P0 | 列表页分页功能失效 | Open |
| ... | ... | ... | ... | ... |
**Bug 统计：**
- P0: {p0_count} 个
- P1: {p1_count} 个
- P2: {p2_count} 个
- 总计: {total_bug_count} 个
## 5.5 Bug 修复验证（回归结果）
> 对上次 buglist 中 Open 状态的 Bug 进行回归验证的结果汇总。
| 原Bug ID | 原日期 | 模块 | 标题 | 回归结果 | 说明 |
|----------|--------|------|------|---------|------|
| BUG-XXX | 20260701 | {module} | {title} | ✅ Fixed / ❌ 未修复 / ⏭️ 未验证 | {detail} |
**回归统计：**
- 上次Open Bug总数：X 个
- 已修复：X 个
- 未修复：X 个（已记入本次buglist）
- 未验证：X 个（不在本次测试范围）
## 6. 风险与建议
### 高风险项
- {risk_description}
### 改进建议
- {suggestion}
### 后续行动
- {action_item}
## 7. 用例执行清单
> 要求见「测试执行完整性保障」章节。此处按模块列出本次测试范围内每个用例的最终状态。
| 用例ID | 所属模块 | 标题 | 执行状态 | 跳过原因 | 备注 |
|--------|---------|------|---------|---------|------|
| {case_id} | {module_id} | {case_title} | {status} | {skip_reason} | {note} |
| ... | ... | ... | ... | ... | ... |
```
---
## 异常处理策略
| 异常场景 | 处理方式 |
|---------|---------|
| 登录失败（凭证错误/500） | 中止测试，提示用户检查凭证和环境 |
| 页面 404 | 记录为 P1 Bug，标记用例 failed，继续下一用例 |
| 页面 500 | 记录为 P0 Bug，标记用例 failed，继续下一用例 |
| 页面加载超时(30s) | 重试一次，仍失败则记录 P1 Bug 并标记 failed |
| 元素定位全部失败 | 截图 + 记录 P1 Bug + 标记 failed（现有逻辑保留） |
| Bug 文件写入失败 | 将 Bug 信息输出到控制台日志作为备份，标记用例 failed，继续执行 |
| 浏览器崩溃/无响应 | 重启浏览器，重新登录，从当前用例重试一次 |
| 连续失败检测（滑动窗口） | 最近5个用例中失败≥3个时：自动尝试重新登录（清除非认证缓存→重新登录→继续执行），记录为"自动重登"事件。若重登后下一用例仍失败，暂停执行并询问用户：① 继续执行 ② 跳过当前模块 ③ 中止测试。单次测试中自动重登超过3次时强制暂停，提示"环境可能存在系统性问题"。注：skip 状态的用例不计入失败窗口。 |
---
## 依赖与环境要求
### 工具依赖
| 工具 | 用途 |
|------|------|
| Browser Agent | 执行浏览器自动化操作（页面导航、元素交互、截图） |
### 目录结构
执行本技能后，`test-project/` 目录下会产生以下文件：
```
test-project/
├── ai-version/ # 测试用例源文件（只读）
├── bug-reports/
│ └── YYYYMMDD/ # 按测试执行日期分文件夹
│ ├── buglist-*.md # Markdown Bug 报告
│ └── *.png # Bug 截图（与 buglist 同级）
├── test-reports/
│ └── test-report-*.md # Markdown 测试报告
└── test-progress.json # 测试进度追踪文件
```
---
## 注意事项
1. **配置读取为可选**：如果当前项目存在 `test-config.md`，自动读取作为默认配置展示给用户确认；不存在则直接询问用户提供所有必要信息
2. **每发现一个 Bug 立即写入 Markdown 文件**，避免批量记录导致遗漏
3. **进度文件在每完成一个用例后立即更新**，确保中断后可精确恢复
4. **失败用例必须截图**，截图命名使用 `{test_case_id}-{timestamp}.png`
5. **Browser Agent 操作时如遇页面加载超时（默认 30 秒）**，重试一次后标记为失败并记录
6. **数据操作边界**：
- 允许通过专用接口或 MCP 工具在测试环境中**造测试数据**，用于数据准确性校验（遵守 global.md 第十二章规则）
- 禁止直接修改或删除已有业务数据，禁止对生产环境执行写操作
- 所有造数操作必须发生在测试环境，并在用例中明确记录造数步骤和预期字段值
7. **临时脚本/文件清理**：执行过程中若生成了临时脚本或临时文件（如 `.tmp-*.json`、`.py` 辅助脚本等），任务完成后必须立即删除，不得留在项目目录中
8. **Bug 回归验证规则**：每次测试执行时自动回归上一次 buglist 中的 Open Bug；已修复的直接在原文件更新状态（Open→Fixed）；未修复的记录到本次新 buglist 中，保持问题可追溯支持平台：Qoder · QoderWork · Claude · Codex 等 AI 编程助手