探索式测试的历史（History of Definitions of ET）
| 1988 | First known use of the term, defined variously as “quick tests”; “whatever comes to mind”; “guerrilla raids” – Cem Kaner, Testing Computer Software (There is explanatory text for different styles of ET in the 1988 edition of Testing Computer Software. Cem says that some of the text was actually written in 1983.) |
| 1990 | “Organic Quality Assurance”, James Bach’s first talk on agile testing filmed by Apple Computer, which discussed exploratory testing without using the words agile or exploratory. |
| 1993 | June: “Persistence of Ad Hoc Testing” talk given at ICST conference by James Bach. Beginning of James’ abortive attempt to rehabilitate the term “ad hoc.” |
| 1995 | February: First appearance of “exploratory testing” on Usenet in message by Cem Kaner. |
| 1995 | Exploratory testing means learning, planning, and testing all at the same time. – James Bach (Market Driven Software Testing class) |
| 1996 | Simultaneous exploring, planning, and testing. – James Bach (Exploratory Testing class v1.0) |
| 1999 | An interactive process of concurrent product exploration, test design, and test execution. – James Bach (Exploratory Testing class v2.0) |
| 2001(post WHET #1) |
The Bach View
Any testing to the extent that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. The Kaner View Any testing to the extent that the tester actively controls the design of the tests as those tests are performed, uses information gained while testing to design new and better tests, and where the following conditions apply:
– Resolution between Bach and Kaner following WHET #1 and BBST class at Satisfice Tech Center. (To account for both of views, James started speaking of the “scripted/exploratory continuum” which has greatly helped in explaining ET to factory-style testers) |
| 2003-2006 | Simultaneous learning, test design, and test execution – Bach, Kaner |
| 2006-2015 | An approach to software testing that emphasizes the personal freedom and responsibility of each tester to continually optimize the value of his work by treating learning, test design and test execution as mutually supportive activities that run in parallel throughout the project. – (Bach/Bolton edit of Kaner suggestion) |
| 2015 | Exploratory testing is now a deprecated term within Rapid Software Testing methodology. See testing, instead. (In other words, all testing is exploratory to some degree. The definition of testing in the RST space is now: Evaluating a product by learning about it through exploration and experimentation, including to some degree: questioning, study, modeling, observation, inference, etc.) |
探索式测试，敏捷开发的最佳拍档
我们知道，传统的测试一般是先根据需求文档编写出测试用例，而后由测试人员本人或他人再根据测试用例的具体描述步骤（脚本）进行执行与验证。这种已经持续了几十年的测试方法我们又称之为脚本测试（Scripted Test，简称ST）。但是这几年随着敏捷开发的流行以及业务本身快速发展的需要，在开发速度不断得到提升的同时测试却慢慢变成了瓶颈，主要体现在下面两点：
1. 传统脚本测试的速度应对敏捷快速交付的要求有些吃力。当前大部分敏捷项目的迭代周期是1至2周，除掉需求和开发所需工时，留给测试的时间少之又少。而在这么短的时间内还需要经常花费大量的时间来编写详细的测试用例文档，使得测试人员不得不用加班来解决时间不足的问题；
那么测试人员在这种敏捷开发的环境下到底如何应对才能更加从容呢？敏捷测试专家Lisa Crispin在她的著作《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中提到了解决思路，那就是大家所熟知的测试金字塔：
测试金字塔最初的原型分三层，底层是单元测试，中间层是API测试，上层GUI自动化测试。后来Lisa在金字塔的塔尖再补上了一片“云”，这片“云”就是探索式测试（Exploratory Test，简称ET）。
什么是探索式测试？
那么究竟什么是探索式测试？不同的测试专家都曾经对其下过定义，但最新的一种定义如下：
探索式测试是一种强调测试人员的自由和责任以不断优化其工作价值的测试方法，它通过将学习、测试设计和测试执行作为互相支持的活动在整个项目过程中并行执行。
首先，它不是新的测试技术而更像是新的测试模式或风格。正如Scrum其本质是把工作按批次来完成但具体的开发方法没有变化一样，探索式测试本身也是会使用到我们熟悉的如等价类、边界值等测试技术，同时探索式测试也可以被应用到不同的测试阶段中；
其次，和敏捷宣言更强调个体一样，探索式测试同样强调测试人员个人的主观能动性，在这点上探索式测试的观点与敏捷不谋而合，尽管探索式测试概念的提出比敏捷还要早（探索式测试由CemKaner博士在1983年提出）；
最后，探索式测试把测试学习、测试设计和测试执行这些在传统脚本测试中需要分开不同阶段来完成的任务并行的执行。当然，这里说的并行其实就是一个小的循环迭代，以此可以最快的得到反馈，并且指导优化下一轮的迭代。在这里大家是不是觉得有点熟悉的味道？和Scrum的核心思想是否一致？
其实探索式测试还有其它一些体现敏捷思想的地方，比如和敏捷轻文档一样，探索式测试不再要求详细的测试用例文档；再比如和Sprint有固定的时间盒一样，后面介绍的Session-Based Test Management（简称SBTM）也是基于固定时间盒来完成等等，这里就不一一展开讨论了。
脚本测试一般会分为两个阶段：第一阶段根据需求、标准、测试规范等文档先输出测试计划、测试用例等测试交付件；第二阶段则根据之前准备好的测试用例由本人或者他人对被测系统进行操作来执行测试，最终输出测试报告、缺陷报告等。如下图：
而探索式测试只有一个阶段，测试人员根据一切可能掌握的信息和资料，针对被测系统进行学习，在学习的同时一边设计测试要点一边进行测试，最终得到相关测试结果。如下图：
那么对于这两种不同测试的效果如何呢？我们来看一个扫雷的例子，如下图所示：黑色四边形框框代表是雷区，而红色小方块则代表地雷。
而如果按照探索式测试的方法，会看到更加发散，覆盖度更大，所以其效率更高，发现的地雷的也更多，如下图：
探索式测试是随机测试吗？
很多人觉得，既然测试前不再需要提前准备测试用例了，同时测试又要依靠个人的自由发挥，那不就变成随机测试（Ad-Hoc Testing）了吗？ 为了解释这个问题，我想给大家举一个猜数字游戏的例子：
你预先在心里想好一个1到100之间的数字（假如是66），让我来猜。我可以问任何问题，而你只有两种回答：是或者不是。然后你我之间通过不断的问答，最后猜中那个数字，而问的问题次数越少得分越高。
我可能会天马行空，想到什么数字就问什么数字，比如问是不是80？是不是2？是不是60等等，这种没有规律随机猜测的方式就像随机测试一样，相对来说是比较难快速找到答案的。
另外一种方式我会有策略，比如先问是否比50小？这里得到的回答应该是“否”。那么我就会根据之前这个回答来判断答案一定在50-100之间，而在下一个问题的时候我就会根据二分法原则问是否比75小，从而层层缩小范围。这种通过对前一个结果的反馈进行分析然后指导和优化重新设计问题的方式其实就是探索式测试的核心理念所在，它和没有策略完全依靠随机的方式是截然不同的。
如何开展探索式测试？
这里谈的开展包括两个层次：首先，我们需要知道什么时候采用探索式测试。笔者认为无论是脚本测试还是探索式测试，都有其优势和劣势。最好的方式是两者能结合在一起。但是至于哪个为主哪个为辅则取决于不同的项目情况和环境。甚至有时在时间很短的情况下直接只使用探索式也是可行的。具体的分类如下：
另外，对于具体执行层面，我们会采用一种称之为Session-Based Testing management（简称SBTM）的方法来进行测试。关于SBTM术语的中文翻译，史亮、高翔两位老师在他们的著作《探索式测试实践之路》中把它翻译成“基于测程的测试管理”，有兴趣的朋友可以去查阅。
SBTM把整个测试工作分成了多个Session来完成，每个Session包含了下面几个要点：
- Charter：一个session所要完成的使命；
- Time Box：一段固定的不被打扰的时间段，一般为60-90分钟；
- Reviewable Results：汇总的关于Session的结果测试报告，常见的是Session Sheet；
- Debriefing：测试人员与测试主管的汇报交流，就本次测试的发现进行检查，并且看看优化改进的地方。
-
下面是埃森哲关于SBTM的一个简单的测试流程，仅供各位读者参考：
总结
探索式测试本身具备的敏捷特性，使得其非常契合应用在敏捷开发项目中，可以看做是敏捷开发的最佳拍档。当然，探索式测试也不是能包治百病的灵丹妙药，最关键还是需要测试人员了解学习探索式测试，同时愿意努力去尝试和实践，并且不断去改进和优化它，因为这个世上不会有银弹。
探索式测试，到底应该如何开展？
01
基于测程的测试管理
对于探索式测试的具体执行层面，我们会采用一种称之为Session-Based Testing management（简称SBTM）的方法来进行测试。关于SBTM术语的中文翻译，史亮、高翔两位老师在他们的著作《探索式测试实践之路》中把它翻译成“基于测程的测试管理”。至于为什么不把它翻译成“基于会话的测试管理”的原因在书上也特别做了注释，有兴趣的朋友可以去查阅。
SBTM把整个测试工作分成了多个Session来完成，每个Session包含了下面几个要点：
- Charter（章程）：一个Session所要完成的使命和目标；
- Time Box：一段固定的不被打扰的时间段，一般为45-90分钟；
- Reviewable Results：汇总的关于Session的结果测试报告，常见的是Session Sheet，比如下面的一个SessionSheet的例子是来自国外期刊《软件测试与质量工程》杂志：
- Debriefing：测试人员与产品负责人和开发团队的汇报交流，就本次测试的发现进行检查，并且看看优化改进的地方。
下图是关于SBTM的一个简单的测试流程，供各位读者参考：
02
实例介绍探索式测试SBTM如何开展
接下来我们以一个酒店入住登记的场景作为例子来看看SBTM是怎么进行的，场景如下：
某酒店针对其酒店APP系统的旅客入住自助登记模块进行优化更新，针对不同级别的会员，在办理入住登记的时候会有相应的福利。例如：针对金卡会员预定了普通房，当豪华房型有空房的时候，可以自动升级到豪华房型；而要是金卡权益过期的会员，则不会有升级的福利。
我们来看看如何开展SBTM进行探索式测试。
1. 计划步骤
在计划的过程中，我们需要确定测试的目标，分解测试的Session，准备安排相关的测试资源等。
那么什么时候开始创建Session呢？可以在Sprint计划时、也可以在开发过程中或用户故事准备好测试时。具体的时间没有明确的规定，但是我们建议尽可能早地进行一些初始计划。
可以尽早创建和准备进行探索性测试的Session，然后在测试开始之前对现有测试Session进行重新review——是否需要额外增加的Session？指定的Session仍然和测试目标相关吗?
一个Session包括:
- 说明本次Session范围/目标的Charter。
- Session的固定时间段，这应该在45分钟到90分钟之间。
- 一个简短的标题来描述Session和它的Charter。当在讨论中提到一个Session时，这是很方便的。
您可以马上将新的Session分配给测试人员，但是建议在故事进入测试阶段时再分配测试人员，这样可以保证团队成员分配的灵活性。
关于Charter
一个好的Session Charter并不用那么精确，它本质上是一个单一的测试场景，但它也不应该太宽泛和模糊，以至于Session没办法在我们指定的时间盒内完成。
当你刚接触SBTM时，你可能很难知道要计划什么Session，试试这个简单的技巧——识别对用户故事和被测应用中重要且相关的风险，并分别为这些风险创建Session：
- 某个变更或特性对性能特别敏感吗？如果是，则创建一个关于性能测试的Session。
- 可用性是产品成功的关键吗？如果是，则创建一个关于可用性的Session。
- 是否对现有的高价值功能进行了更改？如果是，需要创建一个或多个专注于回归测试的Session。
需要考虑的基本风险列表包括：性能、可靠性、可用性、安全性、可伸缩性、可安装性(软件安装过程)和兼容性等。请记住，这个列表只是Session Charter思考的一部分。
所以针对上面的场景，我们定义一个Session Charter的例子如下：
“通过APP入住自助登记功能探索住客在自动办理入住过程中的用户体验和接收到相关的房间升级福利，自助办理入住过程的体验需要和前台办理入住的体验一样好。”
2. 执行步骤
开始一个Session
计划和跟踪你在执行Session过程中的测试工作非常重要，因此一个Session可以分为三个状态：开始、处理中和结束。这三个状态是不是让您联想到了看板的泳道？是的，我们建议使用Jira和看板进行Session状态的监控，使得session状态透明可见。
我们可以在Jira中把Session当成是一个issue type，把Charter和Time Box等设置成属性字段，并可以设置“开始”、“处理中”和“结束”三个流程状态。
我们规定在Session是“开始”状态时编辑Charter，但是不能记录任何Notes或缺陷。只有在“处理中”的状态时才可以。“开始”状态是确保我们去思考测试想法的过程。
如果发现了缺陷，我们需要在Jira中报告缺陷。登记缺陷一般有两个入口：一个在Session流程中登记；一个是在Jira的主菜单登记。从Session中报告缺陷比在Jira中创建一个常规缺陷有很多优势:
- 在Session中报告缺陷时可以为用户自动关联相关的问题类型
- 记录关于在一个Session中发现的缺陷数量的度量
- 记录报告的缺陷的可跟踪性信息，显示它的父问题和找到它的Session。
- 如果配置了问题链接，那么被测试的Session可以显示所发现的缺陷列表
- 在Session活动中添加一个Notes可以自动链接到所报告的缺陷
Taking Notes（记笔记）
很多测试可能会在几个小时内进行，所以在Session期间做笔记是很重要的。特别是在Session结束时，您需要编写简短的Session结果摘要，并向产品所有者或团队简要说明。
有了笔记，写一份准确的总结就容易多了，也意味着你不会忘记重要的事项。在必须提交证据的监管环境中，Session记录和附件也可以作为证据。
如果在Session中有各种不同的笔记类型需要记录，我们可以为每个笔记打上不同的Lable标签:
- 想法（Idea）——用于在执行之前记录您的测试想法，并记录您所进行的测试的类型
- 问题（Question）——有些东西不是很清楚，你可能会留在Debriefing期间询问，它可能是一个缺陷，也可能是一个新功能。
- 惊讶（Surprise）——在测试过程中让您感到惊讶的事情，需要在稍后的测试过程中进行进一步的调查，因为一个缺陷可能隐藏在惊讶背后。
- 问题（issue）和关注（Concern）——一些不需要提出缺陷但需要在Debriefing期间讨论或在Session期间进一步调查的事情
- 积极（Positives）——测试不一定是消极的，为什么不记录和分享团队的优点。
在这个场景中，比如我们增加一条Notes，并且打上”Idea“标签：
- 关注酒店住客自助办理的事务时间
- 关注页面的加载时间
- 关注手机屏幕点击后APP响应时间
小技巧：
如果你发现自己花了很多时间在charter上，想要回到正轨，那么记录当前这个转移，并创建一个新的Charter。Session期间的观察和发现常常为今后的Session提供很好的Charter。
停止一个Session
当您完成测试后，剩下要做的就是选择“结束”状态以结束该Session。完成此操作后，设置jira将提示用户编写Session的简短摘要、对已测试的工作质量和会话覆盖率进行评级，并可选地记录他们的时间是如何使用的。参照如下图所示：
Summary只是Session结果的一个高级视图，应该进行一个完整的汇报以最大化探索式测试的价值。
3. Debriefing步骤
在测试过程中会捕获大量的信息，这些信息需要在一个紧凑且简洁的节奏中传递给团队才能发挥作用，这就是汇报的作用所在。汇报不只是与团队共享信息，还使Session和测试工作对团队负责，并提供一个机会来评审和改进Session的执行方式。
Debrief由包括负责总结会议进展情况、发现关键信息以及其它人对质量看法的测试人员、以及产品负责人、Scrum Master(如果你使用Scrum)和其他团队成员组成。
汇报期间讨论的主要领域如下:
- 检查在Session期间发现的缺陷——这些需要进行分类
- 在Session内的覆盖范围——是否由于时间限制而遗漏了任何领域?
- 在Session中发现的任何风险或问题——讨论这些问题常常会产生新的缺陷/缺陷报告
- 关于应用程序、系统或软件测试的积极信息——测试不只是报告消极的
请注意，所有这些信息都是在Session中通过记录Notes而捕获的，这些Notes使执行汇报变得更容易。
Debriefing输出
在Session Debriefing结束时，通常会决定一系列的行动。这可能需要开发人员在Story或缺陷上做更多的工作，特别是在发现缺陷或之前未知的风险被识别的情况下。如果产品所有者或团队发现仍然存在风险或者Session覆盖率很低，那么Session Debriefing的一个结果可能是创建另一个Session。
Session改进
让测试人员参与Debriefing通常是一个好主意，她或他可以从会议中回顾执行的测试想法，并为备选的测试想法和技术提供建议，以供将来考虑。您可以将此视为对测试Session进行回顾。
把看过读过的文章 引用在这里，对整个探索测试的一个整体认识。
