需要结构化探索性测试时：用 SBTM 章程…

当你要对新功能、回归区域或模糊缺陷报告进行人工探索性测试，并希望过程可重复、可记录、可转化为自动化回归时使用。

适用场景

解决思路

1. 先收集上下文：检查 .agents/qa-project-context.md，若存在则以其为基础，跳过已回答的问题；确认目标区域、假设与怀疑点、时间与范围、团队上下文。
2. 为每个目标区域写一句章程，格式为：Explore [target] with [resources] to discover [information]；确保目标足够具体、资源明确、信息目标描述想学什么而非想证明什么、45-90 分钟内可完成。
3. 按情境选择章程模式与时间分配：新功能用“Explore [feature] with various roles/data to discover requirement gaps and unexpected behaviors”，15 分钟定向 + 40 分钟启发式 + 20 分钟边界/错误 + 15 分钟记录；回归用“Explore [area] after [change] to discover regressions at integration points”，10 分钟看 diff + 20 分钟变更区 + 20 分钟集成点 + 15 分钟冒烟 + 15 分钟记录；缺陷调查用“Explore [area] with [reported conditions] to discover exact reproduction steps”，10 分钟读报告 + 15 分钟复现 + 20 分钟最小化 + 15 分钟相关区域 + 15 分钟记录。
4. 执行会话流程：前 15 分钟定向与概览，约 40 分钟探索，最后收尾并做结构化 debrief；即使独自测试也要 debrief。
5. 用 HICCUPS 作为七类 oracle 引导探索：History（与过去行为对比）、Image（品牌与质量观感）、Comparable（竞品/行业做法）、Claims（规格/营销/提示文本承诺）、User expectations（真实用户是否困惑或沮丧）、Product（与产品其他部分一致性）、Standards（WCAG、RFC、GDPR 等标准）。
6. 用 FEW HICCUPS 扩展三个视角：Familiarity（首次用户能否无需帮助理解）、Explainability（能否向他人解释该行为，解释不了可能是缺陷）、World（不同 locale、时区、网络条件、屏幕尺寸下是否可用）。
7. 需要具体测试想法时查阅 references/heuristics-and-automation.md 中的启发式库：边界启发式（数值、字符串、时间、集合的 zero/one/many、max±1、Unicode、DST、分页边界）、状态转换启发式（跳步、后退、中断、重复、并发转换、错误后状态）、错误处理启发式（断网、畸形响应、限流、会话过期、非法上传）、“What if”场景（后退按钮、重复标签页、广告拦截器、粘贴格式、无障碍功能、陌生 locale、恶意用户）。
8. 实时记录会话日志：使用 references/session-templates.md 中的表格格式，给每条观察打时间戳并标记 BUG、QUESTION、IDEA、RISK 或 NOTE，便于 debrief 时排序而不必重读全文。
9. 按决策框架判断探索还是自动化：需求演进中的新功能、模糊缺陷报告、质量普查、复杂状态组合、主观质量（UX/直观性/视觉打磨）、找缺陷而非确认行为时选择探索；行为稳定明确、需每次提交/PR 运行、有清晰通过/失败标准、数据组合繁琐、需大规模跨浏览器/设备覆盖、探索发现缺陷后想防回归时选择自动化。
10. 把每个可复现的探索缺陷转化为自动化回归测试，使未来会话聚焦新区域；参考 references/heuristics-and-automation.md 中的转化步骤与 Playwright 回归示例（BUG-456 email validation）。
11. 当探索性冒烟章程稳定后分两步毕业：先把章程作为自然语言目标交给 agentic-browser-testing 运行以确认流程稳定，再在获得可维护 selector 后升级为 playwright-automation 脚本测试。
12. 把 LLM 作为会话伙伴而非替代：会话前粘贴章程让它生成 10 个启发式可能遗漏的边界情况，只挑 3 个实际尝试；会话中遇到意外行为时让它查规格/API/标准，但必须对照其引用来源验证；让它审查你写的缺陷报告清晰度，而非替你写报告；debrief 时让它根据笔记建议下一个章程。
13. 警惕生产力悖论：若 debrief 笔记开始像 LLM 写的，说明 LLM 在主导，停止并运行下一次无辅助会话；绝不把选择探索什么、判断是否为缺陷、撰写测试故事委托给 LLM。
14. 按验证清单证明产出真实可问责：每个会话都有比“the app”更具体的章程行；会话日志有时间和标签；每个 filed bug 能追溯到章程并在干净环境复现；转化后的回归测试先在缺陷构建上运行失败（如 npx playwright test path/to/spec 应失败）再在修复后通过；debrief 诚实标注每个章程区域为 covered、partial 或 unexplored。
15. 满足完成标准：每个目标区域都有章程；所有计划会话已执行并按 debrief 模板 debrief；每个缺陷记录来源章程与复现步骤；会话日志存在且观察带时间戳与 BUG/QUESTION/IDEA/RISK/NOTE 标签；findings summary 包含会话总数、按严重度 filed 的缺陷数、识别的测试想法、已安排或明确推迟的后续会话。
16. 避免反模式：不做无章程探索；不跑超过 90 分钟的会话；不依赖记忆事后补笔记；不只探索 happy path；不让同一缺陷每版手动重找而不写自动化；不把探索性测试视为“非真正测试”。

适用边界 · 注意事项

• 不要用于让 AI 浏览器代理从自然语言目标自主探索应用——应使用 agentic-browser-testing。
• 不要用于测试产品自身的 AI/LLM 功能——应使用 ai-system-testing。
• 不要用于行为稳定、有清晰通过/失败标准且需每次提交运行的场景——这类应自动化而非人工探索。