探索式测试
探索式测试是在观察系统行为的过程中，持续调整问题、输入和下一步操作的测试方式。它适合发现预先用例没有考虑到的交互：一次上传取消后出现了短暂缩略图，就可以继续追查刷新、重试和其他页面是否仍能看到那条记录。
探索的价值来自反馈后的判断。没有目标地点击既难以说明覆盖了什么，也难以复现发现的问题；有效的探索需要明确范围、保留过程，并把重要发现变成后续可重复的检查。
1. 面试核心
先记住这几条，再读正文- 探索过程中学习、设计、执行和判断相互反馈，下一步由观察到的行为决定，而不只是照着固定步骤执行。卡 · 观察与调整
- 测试章程写清探索对象、关注风险、资源与时间范围，让一次会话有可解释的目标。卡 · 目标与测试章程
- 发现异常后，保留触发条件和证据，再逐步缩小复现路径。不能靠重新操作时的记忆重建问题。卡 · 记录与复现
- 探索会话的产物包括发现、覆盖线索和未解问题。没有发现缺陷，不等于该区域已经没有风险。卡 · 会话结果与后续检查
2. 目标与测试章程
测试章程是一次探索会话的简短任务说明。它给出方向，但不预先锁死每一步操作。
下面是一份示例章程：
| 项目 | 约定 |
|---|---|
| 对象 | 测试环境中的图片上传与取消流程 |
| 目标 | 查找取消、失败和重试后的残留记录或重复显示 |
| 资源 | 两个测试账号、小型合法图片、请求日志、可控制的网络响应 |
| 范围 | 单文件流程，观察当前页面、刷新后列表与服务端记录 |
| 时间 | 30 分钟；发现数据污染时先保留证据并恢复环境 |
| 输出 | 实际操作路径、可复现异常、已覆盖线索与未完成问题 |
时间只是安排会话的工具，不是证明覆盖充分的阈值。单文件没有发现问题，也不能把结论外推到批量上传、并发上传或所有设备。
规则仍来自 测试分析。如果“点击取消后已上传部分该怎样处理”没有定义，就先记录需求疑问；不要仅凭个人偏好宣布产品存在缺陷。
3. 观察与调整
探索步骤应由一个具体问题推动。以下是一条假设的推导过程，用于说明思路，并非真实产品的测试结论：
- 上传开始后取消，观察进度是否结束、按钮是否恢复。
- 短暂出现缩略图，于是怀疑前后端对取消结果的理解不同。
- 刷新页面，再查询该请求对应记录，区分只是界面残留还是已保存数据。
- 用同一文件重试，核对是否产生两条记录。
- 改为服务端已保存但响应未到达时取消，比较两个时刻的结果。
每一步都在缩小问题范围。这里仍然用了状态与时序分析；探索式测试并不排斥边界、等价类等系统方法，而是根据新观察灵活选择。
工具也可以参与探索。脚本生成输入、查询状态、收集日志，浏览器工具控制网络响应，人再判断下一步。不能把探索式测试简单等同于只能手工操作。
4. 记录与复现
记录应让别人能够重新建立条件，而不只是一句“上传好像不稳定”。可以按时间顺序保留：
| 记录内容 | 作用 |
|---|---|
| 构建版本、配置与账号角色 | 重建环境边界 |
| 初始状态和使用的数据 | 解释为何这次能触发 |
| 操作顺序、关键时刻与请求标识 | 关联界面和服务端事件 |
| 预期、实际与截图或日志 | 证明差异，区分事实和推测 |
| 复现次数与尝试总数 | 描述观察频度，不伪装成总体概率 |
| 已排除条件与待验证假设 | 避免重复尝试和过早归因 |
偶发问题不应该因暂时不能复现就直接关闭。先保留原始证据，再控制网络、时钟或数据等条件，一次改变一个因素，寻找足够小但仍能触发的路径。若始终没有确认原因，就明确写“观察到一次，尚未稳定复现”，而不是把推测写成根因。
缺陷表达和处置见 缺陷管理。提交后还要决定哪些知识值得保留：稳定复现输入可成为回归测试，新的需求疑问进入规则澄清，难以自动判断的交互可以留下探索提示。
5. 会话结果与后续检查
会话结束时，说明实际走过哪些路径、发现了什么、哪些问题尚未解决。用“检查了取消发生在请求前和保存后两种时机”比“取消功能通过”更准确。
把探索发现转为回归时，应保留最小触发条件和独立判定依据。只录制整段操作而不理解触发点，可能留下很长、很脆弱的脚本；反过来，删掉关键等待或状态准备，又可能失去复现能力。
探索与预先设计的测试可以配合：固定规则用稳定用例持续核验，探索会话继续寻找未建模的行为和交互。随着新发现加入回归，下一次探索可以改变重点，不必重复相同操作来积累次数。
6 · 面试题卡片
本页题目与参考回答
6.1 探索式测试与随机点击有什么区别？
考察重点：目标、观察反馈和测试判断。
相关内容：观察与调整。
参考回答
探索式测试围绕目标，根据观察形成下一步假设和操作，并保留可追溯记录。 例如取消上传出现残留缩略图后，继续检查刷新、服务端记录和重试，以区分不同原因。
随机点击可能碰到异常，但缺少目标和记录时，难以解释覆盖范围或复现。探索也可以使用自动化工具，不受限于纯手工操作。
6.2 一次上传流程探索会话应准备哪些内容？
考察重点：测试章程、资源与可观察证据。
参考回答
先写明对象、关注风险、范围和时间安排，再准备可重建的数据及观察手段。 例如关注取消后的残留记录，就需要测试账号、文件、请求标识和查询最终状态的方式。
会话中记录实际路径、环境和差异，结束后说明发现与未完成问题。时间到了只能表示会话结束，不代表所有上传风险已验证。
6.3 探索中发现偶发问题，怎样转为可重复的回归检查？
考察重点：证据保留、条件控制与最小复现。
参考回答
先保存原始环境、数据、时序与失败证据，再控制变量缩小触发条件。 通过受控网络、时钟或状态准备提高可重复性，分清观察事实和根因假设。
稳定复现后，把必要条件和正确结果写进测试。尚未稳定复现时保留证据和限制，不能靠无限重试或录制大段步骤假装已经建立可靠回归。
6.4 探索半小时没有发现缺陷，可以怎样报告结果？
考察重点：观察范围与质量结论的边界。
相关内容：会话结果与后续检查。
参考回答
报告本次环境、实际路径和没有观察到异常的范围，同时列出未探索部分。 例如只验证单文件的两种取消时机，就不能概括为所有上传操作没有问题。
未发现缺陷是一项观察结果，不是不存在缺陷的证明。后续是否继续探索，应结合风险和现有证据决定。
7. 参考资料
来源：Coding 101 原文 · 免费阅读，引用请保留出处。内容使用说明