메뉴
"自动化测试执行专家 - 读取YAML测试用例，通过Chrome DevTools MCP执行E2E测试，生成专业HTML报告。当用户需要执行测试、运行测试、回放测试时调用此技能。支持中文触发：执行测试、运行测试、回放测试、跑一下这个yaml、重放刚才的测试、开始自动化、执行测试用例、运行yaml文件、单步调试、带截图执行、生成测试报告、批量执行测试、并行测试、E2E执行、浏览器自动化执行。"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
"PDD框架下的业务分析Skill，运用专业方法论进行需求分析和业务建模。当用户输入/analyze、/audit、/doc等命令，或需要对业务流程、管理制度、Excel表单进行专业分析时触发。支持中文触发：业务分析、需求分析、需求建模、5W1H分析、MECE、流程分析。"
"PDD熵减智能体，持续监控和偿还技术债务，防止系统腐化。当用户需要代码清理、文档更新、技术债务管理、架构对齐、熵减、垃圾回收、清理技术债务时自动触发。即使用户只说'熵减'、'清理技术债务'或'垃圾回收'，也应触发此Skill。支持中文触发：熵减、技术债务、代码清理、文档更新、架构对齐、垃圾回收。"
根据开发规格实现功能点代码的核心Skill。当用户想要开始编码实现、根据规格文档生成代码、实现功能点时调用此Skill。此Skill会自动调用pdd-template-engine生成基础代码框架，然后由software-engineer补充业务逻辑。即使只有规格文档没有明确说'实现'，只要涉及代码生成、功能开发，都应触发此Skill。支持中文触发：实现功能点、编码实现、开始编码、功能开发、代码实现、PDD实现。
PRD驱动开发的主入口Skill，协调整个开发流程。当用户想要基于PRD文档进行功能开发、从需求文档生成代码、执行PDD方法论流程、开发业务模块、实现完整功能、'搞个功能'、'资产转让'、'国有产权转让'、'帮我搞个资产转让的功能'时必须调用此Skill。即使用户没有明确说'使用PDD'，只要涉及PRD文档、需求文档、功能点开发、规格文档、模块开发、根据文档开发、业务功能实现、'开发ZCCZ'、'我想开发'、'搞个功能'等场景，都应触发此Skill。此Skill会自动协调pdd-ba、pdd-extract-features、pdd-generate-spec、pdd-implement-feature等子Skill完成从需求分析到代码交付的完整流程。注意：单一接口设计、调试问题、文档查询等场景不应触发此Skill。支持中文触发：PRD驱动开发、PDD开发、功能开发、启动PDD。
"交通事故责任评估与判定专业技能。当用户需要交通事故责任分析、事故现场照片评估、交通法规咨询、事故责任划分、法律依据查询时触发此技能。适用于车辆碰撞事故、行人事故、非机动车事故等各类道路交通事故的责任认定场景。无论用户使用'交通事故'、'车祸'、'责任判定'、'交通法规'、'事故定责'等何种表述，只要涉及交通事故评估或责任认定，均应调用此技能。支持中文触发：交通事故、车祸、责任判定、交通法规、事故定责、责任划分、事故评估、追尾、碰撞、违章、赔偿。"
自动化重构专家技能，将收集到的质量改进任务转化为具体的代码操作。当用户需要代码重构、消除重复、简化复杂度时自动触发。即使用户只说'重构代码'、'消除重复'或'简化代码'，也应触发此Skill。支持中文触发：重构代码、消除重复、简化复杂度、自动重构、代码重构、PDD重构。
| name | testcase-agent |
| description | "自动化测试执行专家 - 读取YAML测试用例，通过Chrome DevTools MCP执行E2E测试，生成专业HTML报告。当用户需要执行测试、运行测试、回放测试时调用此技能。支持中文触发：执行测试、运行测试、回放测试、跑一下这个yaml、重放刚才的测试、开始自动化、执行测试用例、运行yaml文件、单步调试、带截图执行、生成测试报告、批量执行测试、并行测试、E2E执行、浏览器自动化执行。" |
版本: 1.0.1 分类: Expert Skill 作者: PDD Team 最后更新: 2026-05-08 文档结构: 主文件 (本文件) + references/ (详细参考)
Testcase Agent 是一个基于 Chrome DevTools MCP 的 E2E 测试自动化执行引擎。它读取由 Testcase Modeler 生成的 YAML 测试用例，通过 CDP 协议直接操控浏览器，完成测试执行、断言验证、错误自愈和报告生成的全流程。
Testcase Modeler (建模) Testcase Agent (执行)
┌─────────────────────┐ ┌─────────────────────┐
│ 用户自然语言描述 │ ───YAML──▶ │ 读取 YAML 用例 │
│ ↓ │ │ ↓ │
│ 智能意图提取 │ │ context_check 状态感知 │
│ ↓ │ │ ↓ │
│ 生成标准 YAML 用例 │ │ 逐条执行 steps │
│ ↓ │ │ ↓ │
│ 安全处理 + 断言注入 │ │ 每步: 截图 + 验证 │
└─────────────────────┘ │ ↓ │
│ 自愈/重试 │
│ ↓ │
│ 生成 HTML 报告 │
└─────────────────────┘
⚡ 主动触发原则：当用户提到以下任何关键词或场景时，即使没有明确说"执行测试"，也应主动使用本技能运行测试并生成报告。
当用户提供以下内容时，立即触发：
pdd test replay ./tests/login/portal-login.yamltest_id:, steps:, action: 的文本⚠️ 必须严格遵守以下 5 条规则，确保测试执行的可靠性和可追溯性。
💡 完整实现细节请参阅 references/iron-rules-detail.md
核心：在执行任何 steps 之前，必须先检查当前浏览器是否已登录。
执行逻辑：
context_check 配置home_indicator 特征文本检测）强制要求：
📖 详细说明 → 铁律1完整实现
核心：每完成一个 step，必须立即进行三项操作：截图保存、记录响应数据、评估断言结果。
三项强制操作：
step_{N}_{action}_{timestamp}.png示例输出：
{
"step": 3,
"action": "fill",
"target": "用户名输入框",
"duration_ms": 245,
"screenshot": "step_3_fill_20260508_143052.png",
"assertion_result": { "type": "field_filled", "passed": true }
}
📖 详细说明 → 铁律2完整实现
核心：凡是涉及提交/保存/删除等改变数据的操作，必须通过网络工具监控 API 调用。
触发场景：
| 操作类型 | 必须校验 |
|---|---|
| 表单提交 | POST /api/save |
| 删除操作 | DELETE /api/{id} |
| 文件上传 | POST /api/upload |
| 导出下载 | GET /api/export |
假阳性识别：UI 显示"成功"但 API 未调用或失败 → 标记为 FAILED
# 示例：提交按钮的双重断言
assertions:
- type: toast_visible # UI层
expected: "保存成功"
- type: network_called # 网络层（强制！）
url_pattern: "/api/apply*"
method: POST
response_code: 200
📖 详细说明 → 铁律3完整实现
核心：当按照 target 描述找不到元素时，禁止直接报错终止。必须启动 4 级降级自愈程序。
4 级降级策略：
Level 1: UID 缓存查找 (<1ms, 命中率~95%复用时)
↓ 失败
Level 2: 精确语义匹配 (~50ms, 命中率~80%)
↓ 失败
Level 3: 模糊匹配 (~100ms, 命中率~65%)
↓ 失败
Level 4: AI 辅助 (~500ms-2s, 命中率~55%, 兜底)
整体自愈成功率目标 > 65%
自愈成功示例：
目标: "资产评估核准"
→ Level 2 未找到精确匹配
→ Level 3 发现 <span>资产评估核准管理</span> (相似度87%)
✓ 使用模糊匹配结果，更新缓存
📖 完整实现 → references/self-healing-strategy.md （独立文档，约500行）
核心：执行完毕后，必须生成完整的 HTML 测试报告。
报告必须包含：
输出位置：test-results/reports/{test_id}_report_{timestamp}.html
📖 详细说明 → 铁律5完整实现
1️⃣ 初始化阶段 (Initialization)
├── 加载 YAML 用例文件
├── 解析并验证 YAML 结构
├── 加载 config/test-actions.yaml 动作配置
├── 加载 config/cdp-test-config.yaml 全局配置
├── 初始化环境变量（从 env_mapping）
└── 创建输出目录结构
2️⃣ 状态检测阶段 (Context Check) 【铁律 1】
├── 获取当前浏览器状态
├── 检测登录状态
├── 如未登录 → 执行登录流程
└── 如已登录 → 记录状态，准备执行
3️⃣ 步骤执行阶段 (Step Execution)
│ FOR EACH step IN yaml.steps:
│ ├── 3.1 动作解析与参数验证
│ ├── 3.2 元素定位 【铁律 4】(4级降级)
│ ├── 3.3 执行动作 (MCP工具调用)
│ ├── 3.4 截图与记录 【铁律 2】(强制)
│ ├── 3.5 断言验证 (UI + 网络【铁律 3】)
│ └── 3.6 结果汇总 (PASS/FAIL/SKIP/ERROR)
└── END FOR
4️⃣ 清理阶段 (Teardown)
├── 执行 YAML 的 teardown 部分
├── 最终截图
└── 收集网络日志和控制台日志
5️⃣ 报告生成阶段 (Reporting) 【铁律 5】
├── 汇总所有步骤结果
├── 生成统计信息和图表
├── 组装 HTML 报告
└── 输出到 test-results/reports/
# 基础执行
pdd test replay tests/login/portal-login.yaml
# 调试模式（单步执行）
pdd test replay tests/login/portal-login.yaml --debug
# 指定环境变量
pdd test replay tests/login/portal-login.yaml \
--env TEST_USER=admin \
--env TEST_PASS=password123
# 执行目录下所有用例
pdd test replay ./tests/asset-eval/
# 并行执行（最多3个标签页）
pdd test replay tests/*.yaml --parallel --max-tabs=3
# 只执行失败的用例
pdd test replay ./tests/ --rerun-failed
当用户说：
"执行这个 login-flow.yaml"
Agent 应该：
本技能采用三层文档结构，详细信息存储在 references/ 目录中：
| 文档 | 内容 | 行数 | 适用场景 |
|---|---|---|---|
| iron-rules-detail.md | 5条铁律的完整实现细节、代码示例、验收清单 | ~600行 | 深入理解执行规则、自定义行为 |
| self-healing-strategy.md | 4级降级策略详解、UID缓存机制、成功/失败案例 | ~500行 | 排查元素定位问题、优化自愈率 |
| error-handling.md | 错误分类体系、重试策略配置、处理流程图 | ~450行 | 配置错误处理、分析失败原因 |
| cli-reference.md | 所有CLI命令、选项、参数、CI/CD集成示例 | ~550行 | 命令行使用、自动化脚本编写 |
日常使用（只需主文件）：
需要深入时（阅读references/）：
Q1: 如何在对话中使用本技能？ A: 当你提供 YAML 文件路径、粘贴 YAML 内容，或说"执行/运行/回放测试"时自动触发。
Q2: 执行失败时如何排查？
A: 查看 HTML 报告中的失败步骤详情，包含诊断信息和修复建议。也可使用 --debug 模式单步执行。
Q3: 如何提高自愈成功率？ A: 确保 YAML 中的 target 描述准确且稳定。定期更新 UID 缓存。参见 self-healing-strategy.md 的优化建议。
Q4: 支持哪些浏览器？ A: 通过 Chrome DevTools MCP，支持 Chromium 内核的所有浏览器（Chrome、Edge、Brave 等）。需确保浏览器开启了远程调试端口。
Q5: 如何集成到 CI/CD？ A: 使用 CLI 命令配合 JUnit XML 输出格式。详见 cli-reference.md 的 Jenkins/GitHub Actions 示例。
版本历史
- v1.0.0 (2026-05-08): 初始版本，包含完整的774行SKILL.md
- v1.0.1 (2026-05-08): 重构为三层结构，主文件精简至<300行，详细内容移至references/
维护者: PDD Team
许可证: MIT