探索式测试，靠章程不靠运气

很多人对探索式测试的印象是「资深测试员随手点点，靠直觉找 bug」。Elisabeth Hendrickson 的《Explore It!》专门反驳这个误解：探索是有结构的自由——先定义要探索什么（章程），再限定多长时间（会话），最后系统地穷举变量（启发法）。exploratory-testing-skill 把这套结构蒸馏成 8 个 Agent 技能入口。

最能说明问题的是它的核心机制：章程 + 限时会话（SBTM）。章程三要素——目标（探索什么）、资源（用什么）、信息（回什么）——写得像作战命令；会话有时间盒，到点复盘。自由探索一旦有了章程和时间盒，就从「运气驱动」变成「覆盖率可管理」。

八个技能里最有意思的三个

测试启发法速查表。变量识别之后，对着一张速查表系统发问：零、一、多；金发姑娘（刚好合适）；干扰（并发、噪声）；相同、不同、缺失、无效……每个词都是一类 bug 的高发区。这张表的价值在于把「资深直觉」外化成了清单——新人照着问，能问到老手八成的坑。

不可重现缺陷四步调查法。「偶现」是测试员最怕的词。四步：先查日志时间线，再复现状态组合，然后压并发与干扰，最后写监测陷阱守株待兔。偶现 bug 大多数不是随机，是条件苛刻——四步法就是条件收敛术。

可测试性 = 可视性 + 控制。一个系统好不好测，取决于你能不能看见内部状态（日志、探针）、能不能强制它进入指定状态（注入、开关）。这个公式直接可以当架构评审的检查项——可测试性差是设计问题，不是测试问题。

flowchart TD
    A["《Explore It!》<br/>Hendrickson 著"] --> B["章程设计<br/>目标·资源·信息"]
    B --> C["限时会话 SBTM<br/>时间盒+复盘"]
    C --> D["启发法速查<br/>零一多·金发女孩·干扰"]
    D --> E["四步调查法<br/>日志→状态→并发→陷阱"]

结构一览

flowchart TD
    A["exploratory-testing 入口<br/>13 个能力路由"] --> B["charter-session-design<br/>章程与会话"]
    B --> C["test-heuristics / oracle / 状态模型<br/>三张方法牌"]
    C --> D["实体 CRUD / 间歇缺陷调查<br/>两类实战武器"]
    D --> E["6 张路由能力卡<br/>信任边界·噩梦头条·遗留侦察"]

边界与判断

适用：新功能的第一轮接触、需求模糊时的探索性澄清、遗留系统的侦察。不适用：回归——探索是发现未知，回归是守护已知，混着做两头都做不好。

一句提醒：技能包里保留了拆书流水线的全部审计产物（candidates/verified/coverage-audit），说明作者对「能力卡的证据链」较了真——这种可审计性本身值得拆书的做法推广。

我的判断：如果说脚本测试是明媒正娶，探索式测试就是必要的野路子——但野路子也有谱，这个技能包把「谱」做成了 Agent 能执行的东西。

下一篇拆「把 50 条测试建议压成 10 张能力卡」的清单式技能，同系列持续更新，关注不迷路。

仓库：https://github.com/Fen9pi-Max/exploratory-testing-skill（含章程模板与启发法速查表）