Exploratory Testing

探索式测试（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（产出结构）

# 探索笔记：{主题}

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

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

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

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

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

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

工作流

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

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

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

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

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

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

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

4. 收敛与落盘

• 时间盒到 / 停点条件满足 → 整理探索笔记落盘 探索笔记_{主题}.md
• 知识沉淀判定：探索中确认的业务规则、环境怪癖、flaky 噪声判据若过 qa-memory 的写入判据（换新会话重测能省一次重新发现），按其流程沉淀进项目 .qa/ 知识库
• 风险清单按 ../core/risk-model.md 预评级（Impact × Likelihood；证据不足时 status 记 risk/inference 并注明补强方向，不用 status 枚举外的标记）
• 测试想法分类：可直接转用例的 / 需先澄清的 / 需专项环境的

5. 交付与移交

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

Common Mistakes