探索性测试，exploratory testing，简称ET, 是1983年由Cem Kaner提出，近些年得到了越来越多人的关注。这个季度的读书计划主要是阅读探索性测试相关的图书。我看的这本书，中文名为《探索吧!深入理解探索性软件测试》，译者徐毅，前同事，早些年也主要从事Robot Framework相关自动化测试工作，目前主要从事敏捷推广工作，这些年也有过不少次交流。原书为《Explore it, Reduce Risk and Increase Confidence with exploratory testing》。中文的书名翻译过程中，丢了一个非常关键的含义，就是“降低风险”。这也是这本书没有明示的一个要点，当然除了标题。
先从风险谈起
先问一个问题，那就是探索过程的依据是什么？换个说法，就是若你开始探索性测试，那么要先探索什么？后探索什么？要依据什么来进行探索？我的答案是“风险”。具体是什么风险呢? 产品未达到预期目的风险，丢失用户的风险等。风险才是探索性测试的核心。控制了风险，也就保障了质量。测试的目的是保障质量，这也是很多互联网公司的测试部门，也叫“质量保障部”的原因吧。
为什么说风险这么重要呢？举一个例子，由于某些特别的原因，一个产品原计划测试10天，现在突然只给2天时间进行测试。作为测试的负责人，怎么办？有些人会说，可以加人，也可以加班。但是如果找不到人，而加班时间也有限，还测不完呢？那么就从用户使用频次最高的场景开始，从产品的可能最大风险点出发，开始探索性测试吧。
从实施流程上，传统测试的过程一般是分析需求，制定测试策略，测试设计，编写测试用例，用例评审，测试执行，报告汇总串行进行。而探索性一般采用分析需求，学习产品，测试设计，测试执行，结果评估并行进行的方式。
传统的测试，一般针对需求编写测试用例，测试的依据是 “需求”，测试的过程也主要是检验需求。而较少从控制风险的角度出发来编写用例。这也许就是探索性测试和传统测试的在侧重点上的不同。
那么如何发现产品中的最大的风险呢？James Bach 在1999年提出过一个概念，叫“Heuristic Risk-Based Testing”，即启发式基于风险的测试。提出了一些基于风险的测试思维方法，这些方法很适合指导探索性测试。比如“Inside-Out启发式分析方法”，采用三个引导词：
可能的失效点在哪里？
什么情况下会触发？
严重程度有多大？
来引导测试者采用基于风险的测试。
本书中谈到的“噩梦头条”游戏的方式也是一个很好的办法。当然，这也是风险控制管理上常用的一种演习方式。通过这种游戏，能让团队意识到产品的最大风险是什么，产品的哪个方面才是需要首先进行测试的。
探索之路
若把测试当成远航。传统测试，因为有完整的需求，依照需求，制定测试策略，也就有了测试地图。那么探索性测试呢，有人误以为，探索性测试是随意的，盲目的，无期限的测试，这是不对的。相反，探索性测试更关注测试策略，以需求为大纲，以风险为导向。
探索性测试要也有探索地图，也就是书中谈到的探索章程。一个探索章程一般需要指定探索的范围，探索可使用的资源，和探索目的。可以有固定的描述格式，例如“探索编辑档案，使用非法用户名，以图发现是否存在用户名限制未被执行的情况”。
恰逢在2016年的Scrum gathing day 上听邰晓梅老师，玩“智慧金字塔”游戏，也主要锻炼测试者避免陷入探索的迷宫中。
敏捷开发与探索性测试
这个世界变化越来越快，用户也是。产品开发过程中，有时候很难把握什么才是主流用户想要的，有时候甚至用户自己也不知道自己想要什么。敏捷开发主要依赖“迭代开发”的方式，实现快速试错。你快速开发了一个功能，推向市场，收集用户的反馈，再根据反馈，决定下一步怎么做。这样每个迭代留给测试的时间也会非常短。Scrum框架推荐2到4周进行一个迭代版本。传统的测试方式，周期相对较长，很难适用。探索性测试的最大的优点，也是速度快。探索性测试，再结合一定程度的自动化测试，特别是接口服务层的自动化测试已经成为敏捷开发质量保障的两大利器。
可见，探索性测试和敏捷开发是绝配。探索性测试适合应用到实现了敏捷开发的产品和团队中。探索性测试也很适合新产品的测试。
对于传统的项目管理方式，探索性测试也适合作为传统测试的补充。
测试管理平台与探索性测试
实施探索性测试一段时间之后，就会思考这样一个问题，“探索性测试需不需要平台系统管理起来？”。其实这个问题，简化下，就是“探索性测试需不需要记录？”
我的答案是需要。
首先，我们需要根据前几个测试章程的测试结果来确定怎么做下一个探索章程。更需要整个测试过程的记录来回过头来做反思和“复盘”。管理起来，能在探索性测试中强制执行容易忽略的测试策略制定环节。管理起来，最重要是避免探索者陷入“迷宫”，盲目探索。
因为探索性测试和传统测试在流程，侧重点，适应场景的不同。探索性测试的管理方式和传统测试差异很大。那到底要管理什么呢？ 我认为主要包含三个方面：探索地图、探索章程、探索总结。下面分别展开分析。
其中，探索地图，更像传统的测试策略，一般一个产品的一个版本或一个测试轮次，或者一个探索session，需要一个就可以了。
探索章程，更像路线图的一个个环节，有顺利性，也更像测试用例，有独立性。下一个探索章程，一般根据这次探索的结果和风险确定。但是探索章程一般比传统测试用例的颗粒度更大，内容没测试用例那么详细，只是指明了可能的风险点。这部分书里有详细讲述，不再累述。并且，将探索章程管理起来，也可以关联缺陷进行管理。
探索总结，测试工程师在系统里总结这次探索的收获和未来的风险点。另外，系统还可以自动统计缺陷数量及其分布特征。
结束语
这次探索性测试的读书笔记，没有对做探索性测试的思维方法比如观察细节、分析变量、改变顺序，转换状态、跨越程序边界、破坏系统生态等做深入的阐述，也没有对不同类型系统做具体的场景分析。不是不重要，而是相信具体实施探索性测试时，经过思维训练，经过实践思考，测试工程师肯定都能掌握这些技能。
参考文献：
First published in Software Testing and Quality Engineering Magazine, 11/99