背景

最近连续给客户做敏捷精益的培训做了两轮，很难得的把敏捷教练系列课程好好回顾了一遍。把敏捷、精益的历史和原则，scrum、kanban 的套路和方法等的知识又反刍了一番。回顾的过程中偶然发现对之前一直没太想清楚的探索式测试有了些新的感悟。

太长不读的版本：探索式测试其实类似测试领域中的 Scrum，都是基于经验过程控制理论，小批次短周期的应对测试中的不确定性的测试方法。

定义

探索式测试是由 Cem Kaner 在 1983 年提出的：

Exploratory testing as "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.

他把探索式测试定义为：一种强调个人自由与责任的测试风格，测试人员在项目周期中，通过让测试学习、测试设计、测试执行与结果分析并行执行，互相促进，以持续不断的优化软件质量。

话说就这个定义，到现在为止我看了应该不下几十遍了，我还清晰的记得我第一次看的时候一脑袋浆糊的感觉。

初步理解

目前多数人基本上都认可探索式测试是一种测试风格，他有别于像等价类划分、边界值分析这种具体的测试用例设计方法，探索式测试从更高层次指导测试人员应该按照探索的风格来做测试。

另外目前比较流行的也有基于 Session 的探索式测试，通过限制固定的时间窗，制定章程的方式来控制探索的方向与程度。

但是实际在执行测试的时候我还是经常有茫然无措的感觉。我到底为什么要探索？我应该怎么探索？我怎么知道我的探索就探完了、探够了？

为什么探索？ - 不确定性

Testing&Checking

13 年在参加 James Bach 在北京举行 workshop 的时候，我学习到 Testing vs Checking（测试与检查）的区别，这应该能够回答我们为什么要探索的问题。

如下图中，他的定义中 Testing 的范畴要大于 Checking，Checking 只是最基本的验证软件行为是否能够满足文档的规定。作为 Testing，我们需要在 Checking 的基础上，不断的去通过实验、学习、观察等手段，发掘软件中更多不为人知的行为。

所以我们才说 Testing 是无限的，软件的行为其实是未知的、不确定的。那么相应的测试执行应该是需要探索的。仅靠 Checking 中那一小部分依赖于脚本的检查工作不足够达到 Testing 的目标。

攻击式测试 &防御式测试

我更习惯于把 Checking 这样的脚本测试形容为防御式测试，他列举了一系列的被测场景，期望保证这些场景是没有问题的。而 Testing 这种更像是攻击式测试，是通过不断探索的方式发现线索，进一步发现潜在问题。显然探索式测试属于后者。

而且探索式 Testing 与脚本式 Checking 在实际测试执行的过程中并不是界线明晰的两个不同的阶段，比如我们在做功能性测试的时候同一时间可能即做 Testing 又做 Checking，而且早期因为未知行为较多 Testing 的比重会相对大，末期因为资产沉淀所以 Checking 比重会更大。

怎么探索？- PDCA&TimeBox

PDCA

这时，从上面的段落里我们嗅到了未知，嗅到了不确定性。这时候熟悉敏捷、Scrum 这样方法的同学们应该可以联想到，我们之所以采用 Scrum 这样的方法来开发软件，一个很主要的原因就是基于经验过程控制理论，利用 Scrum 方法中的短迭代，快速反馈的特性，小批量短周期的交付功能来做到对市场与用户的不确定性的自适应。

同样的，测试活动中软件的行为也是未知的，不确定的。探索式测试与 Scrum 一样，也是希望改变以往脚本测试中，“设计-执行-结果”这种基于瀑布式、确定性思维的做法，转而采用更小步快速的 PDCA 循环的测试方式，以便能够做到对软件行为中不确定性的自适应。

探索式测试形成了“测试设计-测试执行-结果分析-测试学习”的闭环，持续不断的快速执行这个闭环。

TimeBox

Scrum 当中设置了时间盒，那就是迭代的时长。在迭代里，产品经理往往放的是为应对某个业务假设而开发的功能。短迭代里放不下太大的功能，先做一点试试看一看市场是否买单，以达到校准产品的业务方向的目的。

类似的，基于 Session 的探索式测试中通过时间盒限制了测试人员在一个方向探索的时长，保证测试人员可以以较短的时间周期来回顾探索的方向（探索章程 Charter）是否正确，是否还值得继续探索下去。基于 Session 的 PDCA，再加上测试执行时案例级别的 PDCA，形成了双层环状结构，进一步保证了探索式测试的灵活性。

有关探索章程，下面图给大家演示了一个我们比较常用的模型。网上也有很多人总结出来的经验，都可以拿来借鉴。

探多久？- 不知道

这里的探多久指的不是 Session 要持续多久，而是对于软件质量整体，我们执行了多少探索式测试算是足够了。这个问题如果深究起来并不仅仅是探索式测试的问题，而是对于所有测试类型都成立的问题。

我们都知道测试场景是有无限种可能的，永远也无法穷举出所有的可能性来完美的保证软件质量，所以对于探索来说，理论上也是没有止境的。

之所以我们发现总有人会理直气壮问出这种问题我理解是因为传统的、基于脚本（测试用例）的防御式 Checking 经常给人一种错觉，当他们看到脚本是有固定数量的，所以脚本的执行时间是可计算的，当所有脚本都被标上 pass 的时候，他们会很欣慰的点点头，并拍着胸脯告诉老板“我们测完了，上线了之后肯定没问题！”

测试其实是一门妥协的艺术（技术），其实我们可以做的是在项目所给定的资源约束之内，尽可能的探索高优先级的测试场景，来降低质量风险。

同样类比到 Scrum 中，对于某个产品，产品经理应该是会持续不断的产出迭代的需求的，除非产品本身已经步入了衰退期甚至退休的边缘。也许真的只有产品退休时才不用测试人员再继续探索了吧。

总结

与 Scrum 做了类比之后，我是有了一种对探索式测试更理解了的感觉，最起码消除了我对探索式测试的很多疑问。

总体看，探索式测试是在软件行为不确定性的基础上，符合敏捷的思想，以小步快速的 PDCA 循环的方式，不断地从实践中学习的测试风格。它依赖自己的灵活性，更好的做到对软件行为不确定性的自适应，以追求更好的质量。

探索式测试中的章程就好比 Scrum 中的迭代冲刺，基于时间窗实现对测试假设的验证（Scrum 验证业务假设），更宏观的层面探索测试与 Scrum 的过程遵循经验过程控制理论，在不断的测试章程执行之后调整后续的测试方向，最终达到增强覆盖，减低质量风险的作用。