前置知识: Python

探索性测试与基于会话的测试管理

9 min入门

charter 设计、session-based test management、探索与脚本的互补边界、探索发现固化为自动化用例的路径。

知识点地图

  • 知识类别：探索性测试（exploratory testing）——「设计与执行同时进行」的测试方法，及其管理框架 session-based test management（SBTM）。
  • 解决什么问题：脚本化测试只能验证「已想到的」，真实用户走的是没人写过的路径；但「随便点点」不可计划、不可汇报、不可复现。charter + 会话计时 + 记录让探索变得可管理。
  • 什么时候用到：新版本上线前的集中风险探测；自动化覆盖之外的黑盒盲区检查；新需求刚合入、文档与用例还没跟上的窗口期；回归死角盘点。

前置：测试类型 5.3 节首次提及探索性测试，本文展开为完整方法；发现的固化路径接从手工到自动化。

1. 心智模型：探索不是「没有用例」，而是「用例边走边写」

探索性测试的定义要点是同时学习产品、设计测试、执行测试三件事。它与「随意点一点」的区别在于前者有目标（charter）、有记录（会话表）、有产出（问题与后续测试 idea）。

探索与脚本化的互补边界：

维度脚本化测试探索性测试
回答的问题「写下来的行为还对吗」「还有什么没写下来的坏行为」
可重复性高（回归基线）低（路径即兴）
发现盲区能力弱（只覆盖已知）强（主动找未知）
对测试者要求熟悉用例熟悉产品与风险
最佳比例回归主干每次发版前的定向探测

三个场景理解什么时候用探索：

  • 场景 A（新功能首次合入）：导出功能刚开发完，用例文档还没写——探索一轮既发现问题又顺手产出用例草稿，比「等文档齐了再测」快一个周期。
  • 场景 B（回归死角怀疑）：自动化全绿但线上仍有客诉——探索集中在「自动化永远不碰的交互组合」：断网重连、双端同时编辑、超长输入。
  • 场景 C（第三方依赖变更）：支付网关升级了回调格式——探索回调的所有分支路径（成功/超时/乱序/重放），快速摸清影响面。

2. Charter：给一段探索一个目标

Charter 是一次探索会话的任务书，三句话结构：探索目标 + 资源/范围 + 附加约束。

text
Charter：探测导出功能的可靠性边界
资源：导出向导页、10MB/100MB 两种数据集、断网工具（Charles 故障注入）
约束：60 分钟；不测权限（另有专项）；重点记录「用户会丢数据」的路径
  • 好 charter 的标准是可判定是否完成：「测试导出功能」不可判定；「探测导出在异常网络与大数据集下是否丢数据」可判定。写 charter 的过程本身就是在做风险分析。
  • charter 粒度：一个会话（60-90 分钟）一个 charter。塞三个目标进一个会话，记录就分不清哪个发现属于哪个目标。
  • 附加约束里写「不测什么」与写「测什么」同样重要——它把有限时间压在风险最高的区域。

三个不同目标的 charter 示例：

  1. 崩溃路径：探索移动端弱网下的支付流程，记录所有导致白屏/闪退的操作序列；
  2. 互操作性：探索同一账号在 Web 与 App 同时操作的冲突表现；
  3. 升级路径：从 v2.3 直升 v2.6（跳过中间版本），探索配置迁移是否丢失。

3. Session-Based Test Management：让探索可汇报

SBTM（James Bach / Jonathan Bach 提出，本文按其公开框架用自己的话重写）把探索切成有时限的会话，每个会话产出结构化记录：

text
会话表
charter:    探测导出功能的可靠性边界
时间盒:     60 分钟（10:00-11:00）
测试者:     王工
任务分解:
  - 正常导出 10MB 数据（15 分钟，验证基线可用）
  - 断网 + 恢复时机的导出（25 分钟，重点）
  - 100MB 超大数据集 + 中途取消（15 分钟）
  - 汇总记录（5 分钟）
时间占比:   测试执行 75% / 环境搭建 10% / 缺陷调查与报告 15%
风险与问题:
  - P1 断网恢复后点「继续导出」产生重复文件（已提缺陷 #8821）
  - P2 100MB 导出无进度提示，用户会重复点击（观察项）
后续 charter:
  - 「探测重复文件对下游对账的影响」60 分钟
自动化候选:
  - 断网恢复重复导出 → 转回归用例（见第 5 节）
  • 时间占比汇报回答管理者最关心的问题「探索到底干出了什么」——执行/调查/搭环境的比例让探索的成本与产出可比较。
  • 后续 charter 链：一次探索的发现引出下一次探索的目标，风险探测像河流一样延伸，而不是每次都从头乱点。
  • 易错点：把会话表写成流水账（「点了这里、又点了那里」）。记录的单元是发现（问题、风险、测试 idea），不是操作步骤——操作没有复用价值，发现才有。

工程场景（上线前 60 分钟 charter 探索）：BI 平台新版本上线前，对导出功能开 60 分钟 charter（上文那张会话表就是其结构）。发现的两条崩溃路径——断网恢复重复导出、大数据集中途取消后任务状态卡死——前者当场转成回归用例，后者当天修复。这次探索的总投入不到 1 人时，挡下的是上线后必然出现的客诉。

4. 记录与去重的最小心智：测试矩阵全景

探索发现会碎、会重复、会丢。轻量做法是维护一张测试矩阵全景：维度（功能模块 x 环境组合 x 异常类型）格子里标注「已自动化 / 已手测 / 从未覆盖」。素材参考：某游戏项目 CHANGELOG 的门禁段把 import、17 个场景级 check、stats、focus、replay、nettest 等十几个测试套件与 tests/ 目录的 check 文件一一对应——它的价值不在游戏而在模式：每一类风险有一个名字、一个执行入口、一个通过判据。探索会话开始前看一眼矩阵，「从未覆盖」的格子就是本次 charter 的候选；会话结束后回填矩阵，探索产出从此可累积。

5. 把探索发现固化成自动化用例

探索发现的崩溃路径如果只修不断，三个月后会在重构里复活。固化路径四步：

  1. 判据收窄：探索发现是「断网恢复后点继续导出产生重复文件」——自动化用例要把它缩到可断言：模拟导出中断网 5 秒后恢复，点击继续，断言 export_files 表只有一条记录。
  2. 选择层级：能在 API 层断言的不上 UI；本例在服务层模拟网络中断比 E2E 模拟便宜得多。层级选择见自动化框架对比。
  3. 标注来源：用例注释里写「来源：2026-09 导出 charter，缺陷 #8821」——回归用例有出处，将来讨论「这条还测不测」有依据。
  4. 进矩阵：矩阵格子从「从未覆盖」改「已自动化」，下轮探索不再重复消费这块。

什么不该固化：探索中「感觉不顺」的体验类观察（文案位置、交互犹豫）转给可用性评估而不是写成脆弱的 UI 自动化。固化只对「可机判」的行为。

动手实践

任务：给一个你熟悉的 Web 应用（或本仓库 028 示例场景：导出功能）设计一次 60 分钟探索：

  1. 写 charter（目标 + 资源 + 约束，含「不测什么」）；
  2. 把 60 分钟切成 3-4 个任务块并分配时长；
  3. 预设会话表的「风险与问题」字段格式与后续 charter 的候选方向；
  4. 从预设的崩溃路径中挑一条，写出它的自动化用例判据（断言什么、在哪层测）。
参考要点（先自己写，再展开对照）
  • charter 示例：探测「并发编辑同一文档」的冲突处理边界；资源：两个浏览器会话、同一账号+两个账号两种模式；约束：60 分钟，不测权限体系；重点记录「用户数据丢失或无法理解的表现」。
  • 任务块示例：15 分钟两账号并发编辑基线；20 分钟同账号双 Tab 竞争（最容易被忽视的场景）；15 分钟编辑中一端掉线的表现；10 分钟汇总。
  • 后续 charter 候选：「探测冲突提示文案是否让用户做出正确选择」（把功能问题延伸到认知问题）。
  • 自动化判据示例：双 Tab 同段文字编辑保存，断言服务端保存的是后提交版本且先提交方收到覆盖提示事件——在 API 层用两个并发请求即可机判，不需要真开两个浏览器。

常见陷阱

  1. 探索 = 随便点点：没有 charter 的探索产出随机、不可汇报；先写三句话任务书。
  2. 会话表写成操作流水账：记录单元是发现不是步骤。
  3. 发现只提缺陷不固化：崩溃路径三个月后随重构复活；可机判的发现进回归。
  4. 一次会话塞多个 charter：记录与汇报混杂；一个会话一个目标。
  5. 探索成果不回填测试矩阵：下一轮把同样的格子再探一遍；矩阵是探索的累积层。

相关阅读

参考与致谢

  • Session-Based Test Management 框架（James Bach, Satisfice，框架概念按公开资料重写并给出原创示例）：https://www.satisfice.com/
  • ISTQB Foundation 4.0 术语表 exploratory testing 词条（开放大纲，本文表述为原创）：https://www.istqb.org/
  • 测试矩阵全景模式参考本仓库扫描素材（c-projects.md 028 节游戏项目门禁清单）。