探索性测试：同时设计并执行测试
探索性测试：同时设计并执行测试
探索性测试是一种将学习、测试设计和测试执行融为一体的测试方法。它强调测试人员对软件的深度理解、即时的策略调整，而不是僵化地遵循预定义脚本。本教程将帮助你从零起步，掌握这项敏捷且高效的测试技能。
什么是探索性测试？
探索性测试是一种同时进行测试设计、测试执行和结果解释的测试方法。测试人员在学习被测系统的过程中，根据不断发现的线索来动态调整测试方向。它并不是“随意的测试”，而是一种有纪律、有结构的认知活动。
关键特征
- 学习与测试并行：你一边了解系统，一边设计新的测试。
- 测试人员即核心：依赖测试人员的经验、好奇心和批判性思维。
- 结构化自由：在明确章程（Charter）的引导下，测试过程享有适度的自由度。
- 强调适应：根据上一个测试结果，迅速调整下一个测试的输入或场景。
脚本测试 vs 探索性测试
| 维度 | 脚本测试（Scripted Testing） | 探索性测试（Exploratory Testing） |
|---|---|---|
| 设计时机 | 执行前完成所有测试用例设计 | 设计与执行交织进行 |
| 灵活性 | 低，必须严格遵循脚本 | 高，可随时调整策略 |
| 依赖性 | 依赖详细文档和测试脚本 | 依赖测试人员的思维和经验 |
| 适用阶段 | 适合验收、回归等结构化测试 | 适合不确定性高、快速迭代的环境 |
| 可重复性 | 高，易于自动化 | 较低，但可通过会话记录提高可重复性 |
| 发现缺陷类型 | 预期内的缺陷、用例覆盖内的缺陷 | 深层次逻辑缺陷、边缘场景、可用性问题 |
两者不是对立关系，而是互补关系。优秀的测试团队往往将两者结合，用探索性测试快速摸清软件脉络，再用脚本测试进行回归验证。
探索性测试的核心原则
1. 测试章程驱动
每次探索性测试会话都应有一个明确的 章程（Charter），它界定了本次测试的范围、目标和时间。例如：“在30分钟内，重点测试支付模块的积分抵扣功能，关注精度和并发冲突。”
2. 测试与学习同步
测试过程中，你不断构建系统的心智模型。每执行一步，你都会获得新信息，并用它来决定下一步操作，形成一个 “观察-假设-验证” 的快速循环。
3. 时间盒控制
每个探索性会话通常限制在 60～120 分钟 的“时间盒”内。这能保持高度集中，防止测试陷入混乱，也便于管理进度。
4. 及时记录与反馈
使用会话记录模板，实时记录测试路径、发现的问题、风险点和想法。好的记录是可追溯性和团队协作的基础。
如何执行一次有效的探索性测试？
步骤一：定义测试章程
章程是一个简洁的指导声明，应包含：
- 目标对象：要测试的功能、模块或用户场景。
- 测试策略：比如重点输入边界值、检查流程中断、或模拟低网络环境。
- 时间限制：明确本次测试的时长。
- 期望产出：如缺陷报告、风险列表、测试笔记。
示例章程：
“针对新上线的‘任务看板’拖拽排序功能，在60分钟内模拟三个用户同时拖拽同一任务，观察数据一致性和界面反馈，重点记录崩溃和排序错乱现象。”
步骤二：建立初始心智模型
在动手测试前，花5分钟快速了解：
- 该功能的核心业务逻辑。
- 相关接口和数据库表结构（如有权限查看）。
- 近期的变更列表或已知风险点。
你不需要成为专家，但一个粗略的心智模型能帮你更快上手。
步骤三：执行测试与动态调整
采用“探索循环”：
- 观察：打开功能页面，记录当前状态。
- 推断：根据你对系统的理解，猜测某些操作可能导致的结果。
- 试验：执行操作，尝试触发推断的行为。
- 记录：发现异常立即截图、记下环境信息和复现步骤。
- 再观察：系统如何反应？这又给了你什么新线索？
- 转向：如果当前路径无聊，根据新线索切换到更有趣的风险区域。
常用试探技术：
- 路径变体：故意跳过步骤、连续点击返回键、多次快速操作同一按钮。
- 数据干扰：输入超长字符串、特殊字符（如
<script>）、负数、小数等。 - 环境切换：改变屏幕旋转、网络从WiFi切4G、语言切换为小语种。
- 状态破坏：操作中途强制关闭应用再打开、来电中断、内存不足模拟。
步骤四：会话记录与总结
会话结束时，立即整理笔记，填好会话报告，一般包含：
- 执行的章程描述。
- 实际测试覆盖的区域。
- 发现的缺陷（附严重度、复现步骤）。
- 风险与疑问点（即使未发现缺陷）。
- 测试思路回溯：如果再做一次，会改变什么？
- 用于后续自动化或脚本测试的建议。
适合初学者的探索性测试工具
工具并不复杂，核心在于记录和重现。
| 工具类别 | 推荐工具 | 作用 |
|---|---|---|
| 屏幕录制 | Loom、OBS Studio、系统自带 | 回放操作过程，方便复现缺陷或向团队演示测试路径。 |
| 笔记工具 | Typora、Obsidian、纯文本文件 | 结构化记录测试想法、章程和发现。 |
| 截图与标注 | Snipaste、Greenshot | 快速捕捉并标注问题点。 |
| 会话管理 | 表格模板（Excel/Notion） | 记录多个探索性会话的章程、耗时、发现数，便于回顾。 |
| 辅助测试 | Postman（API）、Charles（抓包） | 当探索前后端交互时，查看请求与响应，帮助构造异常数据。 |
常见挑战与应对策略
“我测到哪里去了？”——迷失方向
应对：严格使用章程。如果发现重要新区域，不要随意偏离，先记下笔记，等本次会话结束后，为它创建新的章程。
“感觉像无头苍蝇”——缺乏测试思路
应对：运用启发式测试策略模型，如 SFDPOT（结构、功能、数据、平台、操作、时间）。从这六个角度向系统提问：
- 结构：界面布局如何？导航结构合理吗？
- 功能：核心功能能工作吗？有哪些边缘路径？
- 数据：它处理什么数据？极限值、格式错误如何处理？
- 平台：不同操作系统、浏览器、分辨率下表现一致吗？
- 操作：用户可能犯哪些错误？撤销、重做是否有效？
- 时间：长时间运行会如何？超时机制、有效期限制是否生效？
“经理觉得太随意、不可控”
应对：用可视化的方式展示过程。将会话记录、图表和发现的缺陷数量、类型定期分享，证明探索性测试是一种可管理、可度量的方法。引入基于会话的测试管理（SBTM），用指标（如误报率、归一化缺陷发现速率）说明其有效性。
真实案例：一次注册流程的探索性测试
章程： “30分钟内，探索新版注册流程的输入验证和异常恢复，重点关注邮箱字段。”
过程回顾：
- 正常注册：成功，流程顺畅。
- 邮箱输入含连续两个@：系统崩溃，返回白屏。
- 邮箱输入超长4000字符：页面响应极慢，约8秒，且无长度提示。
- 在发送验证码的同时，疯狂点击“重发验证码”：成功收到3条验证码，且都有效，逻辑漏洞。
- 注册中途按Home键退出，半小时后从后台唤醒：发现之前的输入信息全部丢失，没有暂存机制。
产出：报告了2个崩溃缺陷、1个安全漏洞（验证码重放）、1个可用性问题，并建议将邮箱校验前移至客户端，增加草稿保存。
开始你的第一次探索性测试
- 选择一个小功能：最好是近期开发、你不太熟悉的。
- 撰写简单章程：像上面案例那样，界定范围和时间（建议30分钟）。
- 启动屏幕录制，动手测试。
- 记录所有异常和疑问。
- 整理会话报告，跟团队分享。
探索性测试不是魔法，它是一种通过实践不断打磨的思维技艺。从今天开始，尝试将一小部分测试时间留给探索性方法，你会发现软件里那些被忽略的角落正逐渐被照亮。