exploratory-testing

结构化探索可以发现脚本化测试遗漏的缺陷。探索性测试同时包含学习、测试设计和执行——测试人员会根据应用实时呈现的信息灵活调整。本技能提供相关框架，让探索过程系统化、可重复并且可记录。

---

快速指南

根据具体情况，选择对应的测试章程模式和要查看的参考资料。

情况	测试章程模式	查看参考资料
新功能——了解功能，发现需求缺口	“使用不同角色／数据探索 [功能]，以发现需求缺口和意外行为”	session-templates.md 中的测试章程示例和会话流程；heuristics-and-automation.md 中的边界／“如果……会怎样”问题库
回归测试——刚有变更合入	“在 [变更] 后探索 [区域]，以发现集成点上的回归问题”	heuristics-and-automation.md 中的状态转换启发法
缺陷调查——报告描述模糊（“有时很慢”）	“根据 [报告中的条件] 探索 [区域]，以找出确切的复现步骤”	session-templates.md 中的会话流程和会话日志模板；heuristics-and-automation.md 中的错误处理启发法

下文的 按情境规划会话 列出了各行对应的完整时间分配。

---

探索问题

设计会话前，先收集背景信息。首先检查 .agents/qa-project-context.md——如果该文件存在，就以其内容为基础，并跳过其中已经回答的问题。

目标区域

• 要探索的目标是哪个功能、模块或流程？
• 这是新功能（发现模式）还是现有功能（回归模式）？
• 该区域最近一次变更是什么？
• 该区域是否有已知风险或曾出现的缺陷聚集？（风险数据参见 risk-based-testing。）

假设与疑虑

• 你认为哪些地方可能出问题？（直觉也可以作为有效的切入点。）
• 开发人员提到过哪些棘手或不确定的地方？
• 自动化测试套件有哪些未覆盖的区域？
• 用户以前是否报告过该区域的问题？

时间与范围

• 这次会话有多少可用时间？（45-90 分钟最为理想。）
• 这是广泛摸查（尽可能扩大覆盖面）还是深入探索（集中攻查某个区域）？
• 有哪些可用的环境和数据集？
• 是否需要重点关注特定的平台、浏览器或设备类型？

团队背景

• 该功能由谁构建？（与开发人员结对探索可能很有成效。）
• 是否有熟悉该领域的测试人员？
• 应向谁发送会话报告？

---

核心原则

1. 有结构的自由

探索性测试并非“随便点点看会发生什么”。它由一份测试章程引导，明确目标、资源和信息获取目的。在章程范围内，测试人员可以自由追踪线索、调查异常，并根据发现调整方向。结构让过程可重复，自由让过程有效。

2. 边做边记录

没有记录的观察就会消失。请在会话过程中做笔记，而不是事后补记。记录你做了什么、看到了什么，以及产生了哪些疑问。会话日志就是交付物——它取代测试脚本。

3. 启发法优于脚本

启发法是指导探索的思考工具，不会规定确切步骤。HICCUPS 和 FEW HICCUPS（见下文）提供了系统检查软件的视角，帮助测试人员提出更好的问题，并留意原本可能忽略的事项。

4. 限时会话

无明确时限的探索会逐渐收益递减。90 分钟后，疲劳会降低发现缺陷的效率。请将会话时长限制在 45-90 分钟，然后进行复盘。简短而专注的会话胜过漫长而松散的会话。

5. 发现 Bug 不是终点，而是起点

一次发现 Bug 的探索性测试，只完成了一半工作。另一半是：这个 Bug 是否可以通过自动化测试捕获？如果可以，就编写该测试。探索性测试为自动化流程提供输入。

---

基于会话的测试管理（SBTM）

SBTM 为探索性测试提供了管理层：测试章程明确意图，会话是工作单元，复盘则提炼经验。

权威参考资料：

• SBTM PDF（Jon Bach / James Bach，satisfice.com）— https://www.satisfice.com/download/session-based-test-management
• 认真对待测试：快速软件测试方法（Bach & Bolton，Wiley 2025）— 当前权威的 RST/SBTM 书籍。
• HTSM v6.3（Bach，最后更新于 2024 年 12 月）— 强调基于状态的测试和边界启发法。请与下文的 HICCUPS 搭配使用。

测试章程模板

测试章程是一句任务说明，遵循以下模式：

Explore [target]
  with [resources]
  to discover [information]

测试章程质量检查清单：

• 目标足够具体，能够引导探索（不要写成“探索应用”）
• 资源中列出要使用的具体工具、数据或条件
• 信息目标描述你想了解什么，而不是想证明什么
• 一次会话能够在 45-90 分钟内合理完成该章程

请参阅 references/session-templates.md，其中有五个完整的测试章程示例（结账、个人资料、搜索、数据导出、多用户协作）。

会话设置、流程与复盘

完整的会话生命周期——会话前的设置步骤、环境准备清单、逐分钟的会话流程、“发现有趣内容时”的循环，以及结构化的复盘模板——均位于 references/session-templates.md 中。请在会话开始时打开该文件，并保持打开状态。

无需打开参考资料即可记住的关键时间安排：前 15 分钟用于熟悉情况和概览，约 40 分钟用于探索，最后用于收尾和复盘。务必进行复盘，即使是独自测试也不例外。

---

Bug 发现启发法

启发法是引导探索的思维模型。它们并非需要逐项完成的检查清单，而是观察问题的视角。

HICCUPS

这是一个记忆口诀，包含七种用于发现 Bug 的判定依据。判定依据是帮助识别问题的原则。

字母	判定依据	检查内容	示例问题
H	历史	当前行为是否与过去的行为一致？	上一个版本中功能正常吗？行为是否发生了细微变化？
I	外观	是否符合产品的品牌形象和质量标准？	看起来精致吗？与应用的其他部分风格一致吗？
C	可比产品	类似产品如何处理此问题？	竞争对手在这里怎么做？行业标准是什么？
C	声明	是否符合承诺？	是否符合规格说明？营销页面？工具提示文本？
U	用户预期	真实用户会觉得困惑或沮丧吗？	我母亲能理解吗？高级用户会觉得烦吗？
P	产品	是否与同一产品的其他部分保持一致？	此错误消息的风格是否与其他错误消息一致？
S	标准	是否符合适用标准？	无障碍方面的 WCAG、协议方面的 RFC、数据处理方面的 GDPR？

FEW HICCUPS（扩展版）

在基础 HICCUPS 模型上增加三个观察视角：

字母	判定依据	检查内容
F	熟悉度	首次使用的用户无需帮助就能理解吗？
E	可解释性	你能向别人解释这种行为吗？如果不能，它可能是一个 Bug。
W	现实环境	在真实环境中能正常工作吗？（不同地区、时区、网络条件、屏幕尺寸）

启发式测试思路库

边界、状态转换、错误处理和“如果……会怎样”探索的详细测试思路列表位于 references/heuristics-and-automation.md。需要具体提示时，可以查阅这些列表：

• 边界启发式 — 数值、字符串、时间和集合边界（零/一个/多个、最大值±1、Unicode、DST、分页大小边界）。
• 状态转换启发式 — 跳过步骤、返回上一步、中断、重复、并发转换、错误后的状态。
• 错误处理启发式 — 网络中断、格式错误的响应、速率限制、会话过期、无效上传。
• “如果……会怎样”场景 — 后退按钮、重复标签页、广告拦截器、粘贴的格式、无障碍功能、不熟悉的区域设置、恶意用户。

---

笔记模板

使用会话日志实时记录观察结果。会话日志表格格式和观察标签（BUG、QUESTION、IDEA、RISK、NOTE）位于 references/session-templates.md。为每条观察一致地添加标签，这样复盘时无需重读整份日志即可整理发现。

---

何时探索，何时自动化

并非所有测试都应该采用探索式测试，也并非所有测试都应该自动化。请使用此决策框架：

适合探索的情况：

• 功能是新的，需求仍在不断变化
• 你正在调查模糊的错误报告（“有时会很慢”）
• 你想评估某个区域的整体质量（质量调查）
• 该区域较复杂，包含许多难以编写脚本的状态组合
• 你需要评估主观品质（UX、直观性、视觉精致度）
• 你的目标是发现错误，而非确认行为

适合自动化的情况：

• 行为稳定且定义明确
• 测试需要在每次提交/PR 时运行（回归测试）
• 场景有明确的通过/失败标准
• 测试涉及的数据显示组合繁多，手动探索很繁琐
• 你需要大规模覆盖多种浏览器或设备
• 你通过探索发现了错误，并希望防止回归

从探索到自动化的流程

通过探索发现的每个可复现错误都应转化为自动化回归测试，这样后续会话就能专注于新区域，而不是重新检查旧错误。完整流程图、转换步骤以及一个完整的 Playwright 回归示例（BUG-456 邮件验证），请参见 references/heuristics-and-automation.md。

当探索式 冒烟测试 任务说明趋于稳定（“快乐路径仍然可以正常运行”）时，应分两步而非一步将其升级：首先，将任务说明交给 agentic-browser-testing，以自然语言目标运行的方式确认流程稳定，而无需编写脚本；然后，等稳定流程有了受维护的选择器后，再将其升级为脚本化的 playwright-automation 测试。

---

按上下文制定会话计划

上下文	重点	任务说明模式	时间分配
新功能	学习、需求缺口、UX	“使用不同角色/数据探索[功能]，以发现需求缺口和意外行为”	15 分钟熟悉 + 40 分钟启发式探索 + 20 分钟边界/错误 + 15 分钟记录
回归测试	变更及其副作用	“在[变更]后探索[区域]，以发现集成点上的回归问题”	10 分钟查看差异 + 20 分钟检查变更区域 + 20 分钟检查集成 + 15 分钟冒烟测试 + 15 分钟记录
错误调查	复现和缩小范围	“根据[报告的条件]探索[区域]，以确定确切的复现步骤”	10 分钟阅读报告 + 15 分钟复现 + 20 分钟缩小范围 + 15 分钟检查相关区域 + 15 分钟记录

---

辅助探索（LLM 是伙伴，而非替代者）

你可以让 LLM 担任顾问和创意生成器，开展测试会话，同时保留自己的批判性思考主导权。这与 Bach 和 Bolton 在 Taking Testing Seriously（Wiley，2025）中提出的测试与检查之分十分契合：LLM 可以协助进行检查（这是否符合已知参考？），但测试——也就是由人判断要探索什么、什么算问题——仍由你负责。运用得当，LLM 能拓展你的测试任务覆盖范围；运用不当，它就会用听起来信心十足的幻觉取代你的判断。

如何在测试会话中使用 LLM：

• 会话开始前用作创意生成器。 粘贴测试任务，要求它提出 10 个启发式方法可能遗漏的边缘案例。挑选 3 个实际尝试，其余的舍弃——大多数建议都很泛泛或是凭空捏造的。
• 会话中途用作“这是否正确？”的顾问。 发现意外行为时，让 Agent 查阅规范 / API / 标准。务必根据它引用的来源核实答案，绝不要直接相信。
• 用作发现结果的事实核查员，而非缺陷报告撰写者。 缺陷由你撰写；LLM 负责检查表达是否清晰。反过来——由 LLM 撰写、你来审核——会产出套模板的报告，丢失人类注意到的具体细节。
• 复盘时提供覆盖缺口建议。“根据这些笔记，我接下来应该执行什么测试任务？”

生产力悖论警示： AI 工具可能让测试人员的产出看起来更快，同时悄然削弱创造价值所需的批判性思考。（Michael Bolton 曾在 DevelopSense 的演讲和文章中阐述这一观点；请将其视为工作原则，而非有引文支持的研究结论。）如果你的复盘笔记开始听起来像是 LLM 写的，那说明现在是 LLM 在主导——停下来，下一场测试会话不要借助它。

绝不要把以下事项委托给 LLM：

• 选择探索什么。测试任务必须源于你对风险和利益相关方关注点的理解。
• 判断某件事是否是缺陷。“模型说看起来没问题”不算复盘。
• 撰写测试叙述。具体、结合情境的细节正是探索式测试的要点——泛泛的 LLM 文本恰恰与之相反。

有关测试 AI 功能本身（而非仅用 AI 来测试）的内容，请参阅 ai-system-testing。

---

现代团队中的测试人员角色

可用于人员配置和自我定位讨论的实用术语。这些是业界常见的典型角色，并非正式分类：

• 嵌入式测试人员——完全融入交付团队的测试人员，从头到尾参与开发讨论，而不是充当独立的把关者。这是跨职能团队中最常见的模式。
• 专家型测试人员——在某个领域（安全、无障碍、性能）具备深厚技能，并为各团队提供支持。
• 教练型测试人员——教授专业技能（启发式方法、测试任务编写、探索式思维）的资深测试人员，受众包括开发人员和初级测试人员；他们很少亲自从头到尾进行测试。

如果你的组织正转向采用嵌入式测试人员，探索式测试就是最值得展示的技能之一——开发人员很难在没有指导的情况下掌握它，而测试思维也最能通过这项技能体现出来。

有关测试与检查之分以及 AI 的作用，请参阅“What Is Testing? A Conversation with Bach and Bolton”（DevelopSense，2026 年 2 月）：https://developsense.com/blog/2026/02/what-is-testing-a-conversation-with-james-bach-and-michael-bolton

---

反模式

无测试任务的探索

不设测试任务就开始探索。“我就随便试试看能发现什么”会导致结果不一致、无法复现，也无法进行有意义的复盘。务必编写测试任务，哪怕只有一句话。

测试会话过长

连续进行 3 小时的探索式测试。超过 90 分钟后，发现缺陷的效率会急剧下降。疲劳会导致测试人员漏掉问题，不再跟进线索。应将长时间的测试工作拆分为多个 60-90 分钟的会话，并在会话之间休息。

会话期间不做记录

依靠记忆还原发生过的事情。会话结束时，一半的观察结果已经忘记，剩下的也变得模糊不清。请使用上面的模板实时记录。

只探索顺利路径

仅通过探索性测试验证功能是否正常。这与自动化测试已有的覆盖重复了。探索性测试的优势在于发现那些没人想到要编写脚本的路径中的问题。使用启发式方法，深入那些令人不安的领域。

不转化为自动化测试

每次发布都手动发现同一个 Bug，因为没人为它编写自动化测试。通过探索发现的每个可复现 Bug 都应成为自动化回归测试。探索到自动化的流程必须保持运转。

认为探索“不算真正的测试”

认为探索性测试不如脚本化测试严谨。SBTM 通过测试章程、会话日志和复盘，产出有记录、可追责的测试。其文档形式与测试脚本不同，但严谨程度相同。

---

验证

证明会话产出了真实、可追责的产物，而不只是让人觉得“测过了”——先做最小的检查：

• 每份章程都是真正的章程： 每次会话都有一行书面内容，格式为 Explore [target] with [resources] to discover [information]，其中目标比“应用”更具体。没有章程行的会话属于无章程探索，而非 SBTM。
• 会话日志包含时间戳和标签： 打开日志，确认观察结果带有时间列和标签（BUG、QUESTION、IDEA、RISK、NOTE）。没有时间记录、没有标签的一大段文字无法用于复盘。
• 每个已提交的 Bug 都可追溯至章程且可复现： 对每个 Bug ID，在干净的环境中按照复现步骤操作，并确认问题仍然存在。无法复现的 Bug 是一条记录，而不是已提交的缺陷。
• 转化后的回归测试确实经历了先失败、再通过： 对于任何从探索发现转为自动化测试的问题，先在存在 Bug 的构建版本上运行新测试（npx playwright test path/to/spec 应该失败），再在修复后的版本上运行（应该通过）。从未观察到失败的回归测试，不能证明它能防止该 Bug 再次出现。
• 如实说明覆盖情况： 复盘中应将每个章程领域标记为已覆盖、部分覆盖或未探索。若标注“100% 覆盖”，下方却列出了未探索的领域，这正是需要发现的漏洞。

完成标准

• 为每个目标领域编写会话章程，每份章程都遵循“Explore [target] with [resources] to discover [information]”格式
• 执行所有计划中的会话，并使用复盘模板完成复盘；将每个章程领域标记为已覆盖、部分覆盖或未探索
• 记录会话中发现的每个 Bug，并注明其源自哪份章程及复现步骤
• 保存会话日志，其中包含带时间戳的观察结果，并标记为 BUG、QUESTION、IDEA、RISK 或 NOTE
• 编写发现摘要，记录会话总数、已提交的 Bug（按严重程度分类）、发现的测试创意，以及已安排或明确延期的后续会话

参考文件（位于 references/ 中）

• session-templates.md — 章程示例、环境准备清单、会话流程时间安排、复盘模板，以及记录笔记的会话日志格式。
• heuristics-and-automation.md — 边界／状态／错误／“如果……会怎样”启发式测试创意库、探索到自动化的流程图，以及一个完整的 Playwright 回归示例。

相关技能

• agentic-browser-testing -- 自动化版：浏览器 Agent 会根据自然语言目标探索应用，无需脚本。用于无人值守的探索性冒烟测试；而 exploratory-testing 用于由人主导、以测试章程为依据的 SBTM 测试和缺陷搜寻。
• playwright-automation -- 将经过验证的探索结果转化为可维护、确定性的回归测试。
• test-planning -- Sprint 测试计划会为探索性测试安排时间，并引用测试章程。
• risk-based-testing -- 风险评估可确定哪些领域值得重点探索。
• test-reliability -- 探索过程中发现的不稳定或不可靠领域，可用于改进测试可靠性。
• qa-metrics -- 将探索性测试次数、缺陷发现率和测试章程覆盖率作为 QA 指标进行跟踪。
• qa-project-context -- 项目上下文文件会指出已知风险领域和以往的缺陷聚集情况，为编写测试章程提供参考。