dsh-qa-skills/skills/exploratory-testing/SKILL.md

DeepSeek Harness (dsh) plugin: 10 testing skills (requirement analysis, test strategy, case writing/review, E2E/API automation, exploratory, regression, bug analysis) + shared core knowledge base — a full QA pipeline as agent skills.

---
name: exploratory-testing
slug: exploratory-testing
displayName: 探索式测试
version: 0.6.0
description: 需求不完整、系统陌生、文档不足时，发起以理解系统/发现风险为目的的独立探索式测试会话时使用——charter 驱动（目标 → 探索 → 记录），产出探索笔记（系统理解/风险清单/测试想法）作为需求建模输入或独立交付。不用于：为写自动化踩点的小规模探索（automated-e2e-testing 工作流零）、按既有用例执行（执行类 skill）。
---

# 探索式测试（exploratory-testing）

需求不完整、系统陌生、文档不足时的**独立**探索式测试会话：charter 驱动，边探索边设计，产出系统理解与风险清单，而不是执行既有用例。

- **输入**：被测系统入口（环境 + 账号）、探索主题或 charter、（可选）已有需求材料
- **输出（落盘）**：`{项目}/探索笔记_{主题}.md`（charter、系统理解、风险清单、测试想法、发现的 Bug）——旁路场景下作为 `requirement-analysis` 的输入
- **适用**：新系统、老系统、文档缺失、黑盒测试、Agent 自主测试

## When to Use

- 新接手/陌生的系统，文档缺失或不可信，先探索再建模
- 需求不完整，需要用探索补齐系统理解与风险清单
- 黑盒环境（只有入口和账号）下的自主测试

## When NOT to Use

- 为写自动化**踩点**（理解页面结构、提取选择器、落 Page Object）→ `automated-e2e-testing` 工作流零（业务熟悉）
- 按既有用例执行 → `automated-e2e-testing`（UI）/ `api-testing`（接口）
- 已确认 Bug 的根因分析 → `bug-analysis`
- 端到端流水线 → `qa`（本 skill 是其旁路阶段 0）

## 探索笔记 Schema（产出结构）

```markdown
# 探索笔记：{主题}

## Charter（本轮探索的使命）
- 目标：{回答什么问题 / 覆盖什么区域}
- 范围：{系统/模块/流程}
- 时长/停点：{时间盒或停止条件}

## 系统理解（探索中修正）
- 入口与导航路径 / 角色与权限 / 核心流程 / 数据流向 / 状态与流转

## 风险清单（每条带证据标注，此时加载 `../core/evidence.md`）
- R?：{风险描述}｜evidence: {E0–E4 + 来源}｜confidence: {high/medium/low}
  （R? 为会话内临时编号；移交 `test-strategy` 时并入其 Risk Map 统一重编为 R1…，探索笔记原文编号不保留）

## 测试想法（后续转化为正式用例的候选）
- 想法 → 建议归属：{test-case-writing 直接产出 / 需先澄清的问题}

## 发现的 Bug（现象 + 复现步骤 + 证据；未定性，标 Hypothesis）

## 未解之谜（需要用户/开发澄清的问题）
```

## 工作流

### 1. 制定 Charter（先定使命，再动手）

- Charter 三要素：**目标**（回答什么问题，如"优惠券领取的前置约束有哪些"）、**范围**（哪个系统/流程）、**停点**（时间盒或"风险清单满 10 条"）
- 主题未知时与用户对齐一句："这轮探索想弄清楚什么？"
- 无环境/账号 → 先索取（入口地址、每角色账号、数据说明），**不开无凭据的探索**

### 2. 系统摸底（建初始地图）

- 登录 → 枚举入口与导航路径 → 记录角色可见的功能面
- 走一遍可发现的主流程，记录：页面/接口、数据对象、状态与流转
- 使用 `automated-e2e-testing` 的工具能力（浏览器自动化、截图、API 监听）采集证据时，以本 skill 的笔记结构为产出——工具归 e2e，**会话与产出归本 skill**；宿主/环境无浏览器自动化能力时降级为**人工探索**（测试工程师按手动步骤操作 + 人工截图/抄录响应），笔记结构与证据标注不变，仅证据采集效率下降

### 3. 探索循环（边设计边执行边记录）

按 charter 目标循环：**假设 → 触发 → 观察 → 记录**：

| 探索启发式 | 问的问题 |
|-----------|---------|
| 输入极值 | 空值/超大/特殊字符/负数，系统怎么拦 |
| 状态穿越 | 跳步操作（未达前置直接触发后续）、逆向操作、重复操作 |
| 并发与竞态 | 两个会话同时操作同一对象 |
| 数据生命周期 | 创建→修改→删除→再查，残留吗；级联对象怎么办 |
| 权限边界 | 换角色/退出登录后重放同一操作（含直接调接口） |
| 错误恢复 | 失败后重试、断网重连、超时后的状态 |
| 平台与环境 | 换浏览器/分辨率/弱网/系统配置开关，行为还一致吗 |
| 时间与时钟 | 零点/跨天边界、过期与定时任务触发时机，状态与文案对吗 |

- 每个观察记 evidence 等级（E3 运行证据优先——截图/响应原文）；推测记 Inference/Hypothesis，不伪装成事实
- **发现异常先定性再记录**："这是预期行为还是 Bug？"不确定 → 记入未解之谜问用户，不自判（提问格式与裁决落盘统一按 `../core/clarify-pattern.md`，场景用「Bug 定性」）

### 4. 收敛与落盘

- 时间盒到 / 停点条件满足 → 整理探索笔记落盘 `探索笔记_{主题}.md`
- 风险清单按 `../core/risk-model.md` 预评级（Impact × Likelihood，可标"待证据补强"）
- 测试想法分类：可直接转用例的 / 需先澄清的 / 需专项环境的

### 5. 交付与移交

- 旁路场景（qa 流水线 / 需求建模前）：笔记路径交给 `requirement-analysis` 作为建模输入
- 独立场景：向用户交付笔记 + 一句话结论（系统理解程度 / 最高风险 / 建议下一步）
- Bug 移交：已确认 → `bug-analysis`；测试想法转正式用例 → `test-case-writing`

## Common Mistakes

| 错误 | 后果 | 正确做法 |
|------|------|---------|
| 无 charter 闲逛 | 探索散漫、产出碎片化 | 先定目标/范围/停点 |
| 把探索当踩点（只收集选择器） | 与 e2e 工作流零职责混淆 | 产出是系统理解+风险清单，不是 Page Object |
| 观察不记证据 | 笔记不可复核，风险清单失效 | 每条观察带 evidence 等级与来源 |
| 异常自判为 Bug | 误报（可能就是预期设计） | 未定性记 Hypothesis，问用户 |
| 探索发现全部当场写正式用例 | 会话失焦、时间盒失控 | 记测试想法，会话后统一转 |
| 笔记留在会话里不落盘 | 下游无法消费、断点丢失 | 落盘 `探索笔记_{主题}.md` |