探索式测试教程（软件测试人员专用）¶
!!! abstract “教程简介” 探索式测试不是”随便点点”，而是在有限时间内围绕一个明确目标，边学习、边设计、边执行、边记录风险。它特别适合新功能、需求不清晰、业务复杂和高风险模块。
前置要求¶
| 项目 | 要求 | 获取方式 |
|---|---|---|
| 软件测试理论基础 | 了解测试流程、用例设计、缺陷管理 | 软件测试理论基础教程 |
新手导读¶
很多新手以为测试只有两种：照测试用例执行，或者写自动化脚本。实际项目里，还有一类非常重要的能力：当需求不完整、场景很多、时间有限时，测试人员要主动探索风险。
第一遍先记住：
探索式测试不是替代测试用例，而是补充测试用例。它能帮助你发现“用例里没写到，但用户真的会遇到”的问题。
一、什么是探索式测试¶
探索式测试强调同时进行四件事：
| 动作 | 说明 |
|---|---|
| 学习 | 快速理解功能、业务规则和系统行为 |
| 设计 | 根据观察实时产生新的测试思路 |
| 执行 | 马上操作系统验证想法 |
| 记录 | 记录缺陷、疑问、风险和后续用例 |
例子：
这些场景可能不在原始测试用例里，但非常有价值。
二、探索式测试适合什么场景¶
| 场景 | 为什么适合 |
|---|---|
| 新功能第一次提测 | 需求和实现都还不稳定，需要快速摸清行为 |
| 需求描述不完整 | 需要通过系统行为反推规则并提出问题 |
| 业务规则复杂 | 组合场景多，固定用例容易漏 |
| 高风险模块 | 支付、订单、权限、上传、优惠等容易出严重问题 |
| UI 交互复杂 | 用户操作路径多，需要观察体验问题 |
| 上线前补充测试 | 在固定用例之外寻找遗漏风险 |
不适合只靠探索式测试的场景：
- 稳定回归测试。
- 明确的合规检查。
- 必须重复执行的核心流程。
- 需要自动化长期监控的接口。
这类场景更适合测试用例和自动化。
三、探索式测试和脚本化测试的区别¶
| 对比点 | 脚本化测试 | 探索式测试 |
|---|---|---|
| 测试目标 | 验证已知场景 | 发现未知风险 |
| 执行方式 | 按步骤执行 | 根据观察实时调整 |
| 适合阶段 | 回归、验收、稳定功能 | 新功能、复杂功能、高风险功能 |
| 产出 | 用例执行结果、缺陷 | 缺陷、风险、疑问、新用例 |
| 优势 | 可重复、可度量 | 灵活、发现能力强 |
| 风险 | 容易机械执行 | 容易变成随便点，需要目标和记录 |
成熟团队通常两者结合：
四、Charter：探索式测试任务卡¶
探索式测试最好不要空着脑袋开始。先写一个 Charter，也就是探索任务卡。
模板：
示例：购物车金额探索
探索目标：发现购物车金额计算和库存联动风险。
测试范围：加购、改数量、勾选、优惠券、删除、结算前金额。
关注风险：金额错误、库存超卖、优惠叠加错误、多端数据不同步。
测试数据：正常商品、库存为 1 商品、促销商品、可用优惠券。
时间盒：60 分钟。
记录方式：记录操作路径、异常现象、截图、接口响应。
结束标准：完成 5 类金额变化场景，输出缺陷或风险清单。
Charter 的作用是让探索式测试保持方向，不变成“随手点”。
五、Session-Based Testing：基于会话的探索¶
Session-Based Testing 是一种更可管理的探索式测试方式。每次探索都有固定时间盒和记录。
5.1 Session 基本结构¶
| 项目 | 示例 |
|---|---|
| 时长 | 45 到 90 分钟 |
| 主题 | 登录安全、订单状态、文件上传 |
| 负责人 | 测试人员 A |
| 产出 | 缺陷、疑问、风险、新增用例 |
| 复盘 | 哪些有效，哪些需要继续测 |
5.2 Session 记录模板¶
5.3 执行节奏¶
不要一边聊天一边探索。探索式测试需要注意力，最好一次只围绕一个主题。
六、探索式测试常用启发法¶
启发法不是固定答案，而是帮助你快速想测试点。
6.1 CRUD 启发¶
适合后台管理、数据维护功能。
| 操作 | 测试问题 |
|---|---|
| Create | 能否新增，必填字段如何校验 |
| Read | 能否查看，是否越权看到别人的数据 |
| Update | 能否修改，状态变化是否受限制 |
| Delete | 能否删除，删除后关联数据如何处理 |
6.2 数据启发¶
| 数据类型 | 测试问题 |
|---|---|
| 空值 | 空字符串、空数组、null |
| 边界 | 最小值、最大值、刚好等于限制 |
| 特殊字符 | 空格、中文、符号、换行、Emoji |
| 重复数据 | 重复提交、重复名称、重复订单 |
| 大数据 | 长文本、大文件、大列表 |
6.3 状态启发¶
适合订单、审批、支付、任务流。
测试问题：
- 状态能否非法跳转。
- 重复操作是否幂等。
- 页面状态和数据库状态是否一致。
- 异常中断后状态是否可恢复。
6.4 权限启发¶
| 维度 | 测试问题 |
|---|---|
| 未登录 | 是否能访问页面或接口 |
| 普通用户 | 是否只能操作自己的数据 |
| 角色差异 | 不同角色按钮和接口权限是否一致 |
| 直接请求接口 | 前端隐藏按钮后接口是否仍能调用 |
| token 替换 | 用户 A token 是否能访问用户 B 数据 |
6.5 时间启发¶
适合验证码、优惠券、订单超时、会员有效期。
- 刚开始。
- 即将过期。
- 已过期。
- 跨天。
- 跨月。
- 时区差异。
- 系统时间被调整。
七、探索式测试记录怎么写¶
探索式测试最怕“测过但没证据”。记录要简洁但可追踪。
7.1 缺陷记录¶
标题：库存为 1 的商品可提交 2 件订单
路径：商品详情 -> 加购物车 -> 修改数量 -> 提交订单
测试数据：商品 ID 10001，库存 1
实际结果：订单创建成功，库存变为 -1
期望结果：提示库存不足，不创建订单
证据：截图、接口响应、库存 SQL
风险：可能导致超卖
7.2 疑问记录¶
7.3 新增用例记录¶
八、实战案例：登录功能探索¶
Charter¶
探索路径¶
- 正常账号登录成功。
- 密码错误 1 次、4 次、5 次。
- 锁定后输入正确密码。
- 未注册手机号登录。
- 禁用账号登录。
- 登录后复制 token，请求用户信息接口。
- 退出登录后继续使用旧 token。
- 修改 token 后请求接口。
可能发现的问题¶
| 问题 | 风险 |
|---|---|
| 输错 5 次未锁定 | 暴力破解风险 |
| 账号不存在提示过于明确 | 枚举账号风险 |
| 退出登录后旧 token 仍可用 | 会话失效风险 |
| token 过期后接口返回用户数据 | 鉴权漏洞 |
九、实战案例：文件上传探索¶
Charter¶
探索路径¶
- 上传正常 JPG 和 PNG。
- 上传 0 KB 文件。
- 上传刚好 5 MB 文件。
- 上传超过 5 MB 文件。
- 上传中文文件名。
- 上传超长文件名。
- 将脚本文件改名为
.jpg上传。 - 未登录直接调用上传接口。
- 用户 A 尝试替换用户 B 头像。
重点观察¶
- 前端限制是否能被接口绕过。
- 后端是否校验真实文件类型。
- 上传失败是否泄露服务器路径。
- 文件 URL 是否可被猜测。
- 旧头像是否被清理或保留。
十、探索式测试输出物¶
一次合格的探索式测试至少应该输出：
| 输出物 | 内容 |
|---|---|
| Session 记录 | 测试目标、范围、时间、覆盖情况 |
| 缺陷清单 | 可复现的问题和证据 |
| 疑问清单 | 需要产品或开发确认的问题 |
| 风险清单 | 可能影响上线的问题 |
| 新增用例 | 从探索中沉淀出的回归用例 |
示例总结：
本次围绕购物车金额进行了 60 分钟探索，覆盖加购、改数量、勾选、优惠券和结算前金额。发现 1 个缺陷：库存为 1 时可提交 2 件订单；发现 2 个需求疑问：价格是否按实时价、优惠券是否可与满减叠加。建议修复库存问题后，将价格变化和优惠叠加补充为回归用例。
十一、新手常见错误¶
| 错误 | 问题 | 改法 |
|---|---|---|
| 随便点页面 | 没有目标，难以复盘 | 先写 Charter |
| 只记录 Bug | 漏掉需求疑问和风险 | 同时记录缺陷、疑问、风险 |
| 不保留证据 | 开发难以复现 | 截图、接口、日志、SQL 都保留 |
| 测太大范围 | 时间被摊薄 | 每个 Session 只聚焦一个主题 |
| 不沉淀用例 | 下次还会漏 | 把有效探索点转成回归用例 |
十二、练习任务¶
请选择一个功能完成 45 分钟探索：
要求输出：
- 一张 Charter。
- 至少 10 条探索路径。
- 至少 2 个疑问或风险。
- 至少 1 个缺陷示例。
- 至少 3 条新增回归用例。
完成标准：
- 不是随便点，而是围绕明确目标探索。
- 记录中能看出测试数据和操作路径。
- 每个风险都能说明影响。
- 有价值的探索点被沉淀成后续用例。
探索式测试的价值在于训练测试人员的判断力。工具能帮你执行，但发现未知风险，仍然需要人的观察、怀疑和推理。
推荐下一步¶
根据你的学习进度，选择下一步：
- 如果你想继续学测试方法：学习 敏捷测试教程，掌握敏捷环境下的测试策略
- 如果你想检验理论基础：做 软件测试理论基础测验，检验学习效果
- 如果你想进入工具阶段：学习 数据库 SQL 教程，掌握数据校验
通关检查¶
完成本阶段后，使用 第1阶段-测试入门通关 检查是否可以进入下一阶段。