基于经验的测试¶
一句话
利用历史缺陷、领域知识和测试人员的经验，补充系统方法不容易想到的风险场景。
黑盒方法和白盒方法都有明确的形式化依据，但它们依赖的需求和代码本身可能不完整。基于经验的测试（Experience-based Testing）从"以前在哪里出过问题""这个领域最怕什么""用户会怎样不按常理操作"出发，发现规则之外的缺陷。
它不是"凭感觉随便点"，也不是系统方法的替代品。合理的做法是：先用手册化的方法覆盖明确的规则，再用经验方法补充高风险、难建模、易遗漏的场景。
错误猜测¶
错误猜测（Error Guessing）根据常见错误模式和历史缺陷，直接推测程序可能在哪些地方出错，再针对性地设计用例。
常见错误模式¶
| 类别 | 典型问题 |
|---|---|
| 空值与缺失 | null、空字符串、空集合、字段缺失、只传了部分参数 |
| 边界与极值 | 0、负数、最大值、超大数、超长字符串、分页最后一页 |
| 格式与编码 | 前后空格、全角/半角、大小写、emoji、特殊字符、中文编码 |
| 重复与并发 | 重复提交、并发下单、重复支付、幂等性、超卖 |
| 状态与顺序 | 跳过步骤、乱序调用、重复取消、过期后重试 |
| 权限与安全 | 越权访问、未登录访问、SQL 注入、XSS、敏感信息泄露 |
| 时间与时区 | 跨天、跨月、闰年、夏令时、服务器与客户端时区不一致 |
| 资源与环境 | 网络超时、断网重连、磁盘满、文件过大、依赖服务不可用 |
| 数据一致性 | 部分成功、事务回滚、缓存与数据库不一致、消息重复消费 |
| 交互与兼容 | 快速连点、返回键、刷新页面、浏览器/设备差异 |
示例：登录功能的错误猜测¶
在等价类和边界值之外，可以补充：
- 用户名或密码为空、只有空格；
- 用户名大小写不同、前后有空格；
- 密码错误一次、连续错误达到锁定阈值、锁定期内再次登录；
- 已注销/被禁用账号登录；
- 重复点击登录按钮、网络慢时重复提交；
- 登录后回退页面、直接访问需要登录的 URL；
- 用户名中包含 SQL 关键字或脚本片段；
- 会话过期后继续操作；
- 同一账号多端登录、修改密码后旧会话是否失效。
这些场景未必都写在需求里，但都是历史上真实出现过的问题。
探索式测试¶
探索式测试（Exploratory Testing）把学习、设计、执行同时进行：测试人员边理解产品边设计用例，边执行边根据结果调整下一步，而不是先写完一份固定的用例再照本宣科。
探索式测试适合：
- 需求文档不完整或变化快；
- 新功能、新交互，还没有稳定的测试模型；
- 需要快速获得质量反馈；
- 需要发现"规则之外"的使用方式。
基于会话的探索式测试¶
为了让探索式测试可管理、可追溯，常用基于会话的测试管理（Session-Based Test Management，SBTM）：
- 制定章程（charter）：明确本次探索的范围、目标和时间盒，例如"在 90 分钟内探索优惠券叠加使用和退款场景"；
- 限时探索（timebox）：通常 60–120 分钟，保持专注；
- 记录过程：记下操作、观察、疑问、缺陷和未覆盖区域；
- 复盘（debrief）：评估覆盖了哪些风险、发现了什么、下一步探索哪里。
一个好的章程应该说明"探索什么"，而不是规定"执行哪几步"。例如：
探索订单退款流程，重点关注：部分退款、多次退款、优惠券是否退回、退款中的订单能否再次支付、并发退款请求。
探索式测试的误区¶
- 把"随便点点"当成探索式测试，没有目标、没有记录；
- 只走正常流程，不尝试异常和边界；
- 发现一个问题就停下来，没有继续探索同类风险；
- 结果不可复现，缺陷无法定位；
- 完全抛弃系统方法，导致明确的业务规则反而没有被覆盖。
检查清单¶
检查清单（Checklist）把经验固化成可重复使用的条目，降低"这次想到了、下次忘了"的风险。清单可以按产品模块、质量属性或风险类型组织。
示例：支付功能检查清单¶
功能
- 正常支付成功，订单状态和金额正确；
- 支付失败、超时、用户取消后的订单状态正确；
- 重复支付、重复回调不会重复扣款或重复发货；
- 退款金额不能超过实付金额，部分退款后剩余金额正确；
- 优惠券、积分、余额的组合使用规则正确；
- 金额精度（分/元、浮点误差）处理正确。
异常与边界
- 金额为 0、0.01、最大限额、超过限额；
- 网络中断后恢复，是否重复扣款或状态不一致；
- 第三方支付回调延迟、重复、乱序；
- 支付过程中订单被取消或商品下架；
- 并发支付同一订单。
安全与合规
- 未登录用户不能发起支付；
- 不能篡改金额、订单号、回调签名；
- 支付日志不包含完整卡号、密码等敏感信息；
- 越权查看或操作他人订单。
可观测性
- 失败时有明确的用户提示和可追踪的日志；
- 关键状态变更可以审计；
- 告警能覆盖支付成功率、回调失败等指标。
清单不是越长越好。条目应来自真实风险和历史缺陷，并定期根据漏测问题更新；过期或长期无效的条目要删除，否则清单会变成形式主义。
基于缺陷分析的测试¶
历史缺陷是最好的经验来源。可以从缺陷中提炼测试点：
- 缺陷聚类：统计缺陷集中在哪些模块、哪类操作、哪个阶段；
- 根因分析：是需求理解错误、边界遗漏、异常未处理，还是并发/环境问题；
- 回归用例：每个已修复缺陷至少沉淀一条回归用例，防止问题复发；
- 缺陷模式：把重复出现的根因抽象成检查清单条目或自动化规则。
例如，如果历史上多次出现"重复提交导致重复下单"，就应该把幂等性、防重令牌、并发请求纳入该模块的固定检查项，而不是每次靠临场发挥。
基于风险的测试¶
时间和资源总是有限的，经验方法也需要排序。基于风险的测试（Risk-based Testing）用影响 × 发生可能性决定优先级：
| 风险等级 | 典型场景 | 测试策略 |
|---|---|---|
| 高 | 资金、权限、数据安全、核心链路 | 最完整的用例、自动化回归、专项测试 |
| 中 | 常用功能、可恢复的异常 | 主要流程 + 关键异常 |
| 低 | 低频配置、展示性问题 | 基本路径、抽检 |
风险高的场景即使难测试，也要投入；风险低但容易测试的场景可以顺手覆盖。经验判断的价值在于识别"需求文档没写、但一旦出错后果严重"的场景。
经验方法与系统方法的关系¶
| 方法 | 优势 | 局限 |
|---|---|---|
| 黑盒测试 | 覆盖明确的需求规则，可重复、可度量 | 难以发现规则之外的场景 |
| 白盒测试 | 覆盖代码结构，能发现未执行路径 | 不验证需求是否正确 |
| 基于经验的测试 | 灵活，擅长发现异常、交互和历史问题 | 依赖人员水平，难以保证完整性和可重复性 |
推荐的使用顺序：
- 用等价类、边界值、决策表、状态转换覆盖明确的业务规则；
- 用白盒覆盖检查代码路径和异常分支；
- 用错误猜测、检查清单补充高风险场景；
- 用探索式测试发现前三步没有建模的问题；
- 把新发现的缺陷沉淀为回归用例和清单条目。
探索式测试是不是不需要写测试用例？
不是。探索式测试不要求事先写完整的用例集，但要求有明确的目标（章程）、时间盒和过程记录。记录本身就是轻量级的用例和证据，能帮助复现缺陷、评估覆盖范围。没有目标和记录的"随便点点"不是探索式测试。
检查清单是不是越全越好？
不是。清单过长会导致执行者跳过、敷衍，反而失去作用。好的清单聚焦高风险和历史缺陷，条目具体、可执行、可判断，并定期维护。清单是提醒工具，不是免责声明。
经验丰富的测试人员是否就不需要系统方法了？
不能替代。经验可以发现系统方法想不到的问题，但很难保证"每条业务规则都覆盖到了"。系统方法提供完整性和可重复性，经验方法提供灵活性和风险敏感度，两者结合才更可靠。
小结¶
- 基于经验的测试利用历史缺陷、领域知识和测试直觉补充系统方法；
- 错误猜测从常见错误模式出发，检查清单把经验固化为可重复的条目；
- 探索式测试强调同时学习、设计和执行，但需要章程、时间盒和记录；
- 缺陷分析和风险分析帮助确定测试重点；
- 经验方法应与黑盒、白盒方法配合，并把新发现沉淀为回归用例和清单。
创建日期: 2026-10-27 01:43:13
广告
人要恰饭的嘛🤑🤑