这是鼎叔的第三十篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。
本篇开始分享第三个主题系列文章-探索式测试。
除了自动化测试建设这个众所周知的方向，另辟蹊径的敏捷测试方案层出不穷，在过去的实践中，鼎叔最希望着力推广的是三大敏捷测试利器（方案）：探索式测试，众包测试，精准测试。三大利器自成体系，具备不断深度挖掘的价值，投入产出很可观，而且从不同方面阐述了敏捷价值观在测试领域应用的精髓。
探索式测试，让创新测试方法趣味化，充分流通，鼓励人员交流和启发。
众包测试，让更多的人低成本高效率地参与测试活动，贡献高 ROI。
精准测试，让测试用例尽量少，覆盖代码尽量准，回归更有信心，打破开发和测试的隔阂。
历经四个公司的亲身组织实践，我认为探索式测试是非常有趣的，任何人都可以从中获得适合自己的知识和经验。
我们先从一个笑话讲起
测试工程师走进酒吧，
要了一杯啤酒，
要了 0 杯啤酒，
要了 999999999 杯啤酒，
要了一只蜥蜴，
要了-1 杯啤酒，
要了一个 sfdeljknesv，
酒保从容应对，测试工程师很满意。
接下来，一名顾客来到了同一个酒吧，问厕所在哪？
酒吧顿时起了大火，然后整个建筑坍塌了。
这个笑话很生动地告诉我们，无论设计的测试数据多么周详，总有客户能发现测试工程师遗漏的严重问题场景，这个场景往往是出人意料的，也是经常能见到的。
探索式测试的由来
首先我们思考一个问题，人工测试，相对于自动化测试，有什么优势？
1) 人工测试，更容易发现不同业务逻辑的关联缺陷。
2) 人工测试，可以给出灵活多变的测试计划，灵活多变的测试用例，发挥人的想象力。
3) 人工测试，不只是看断言，还会随时查看各种异常：日志，UI，资源监控，动效，弹框，不一而足。
人工测试通常会有一个事前的测试计划，里面列明了详细的用例执行过程。
如果我们看重人的 “灵活性” 和 “积极性”，逐步摆脱测试计划的束缚呢？
那就是我们要介绍的探索式测试。
有不少测试同学曾提到，第一次听说探索式测试理论，觉得很高大上，但是并没有真正深入了解。
实际上，探索式测试对于突破重复劳动的束缚，降低漏测率，提高测试交付效率，都会有明显的价值。测试人员工作更加自由自主，不需要被大量的测试用例所包围，不用花大量时间写非常细致的用例集。
测试专家 Cem Kaner 在 1983 年提出了探索式测试，并把它定义为一种软件测试风格，而不是一个具体的测试技术，如边界值分析方法，因果图等。探索式测试强调的，是测试人员应该持续的同步开展测试学习，测试设计，测试执行，测试评估等多种活动，不断闭环提升，而不是被事前的测试计划文档所牢牢束缚。
我经常看到有些团队会考核测试用例的缺陷相关性指标，评判测试用例的有效性。但在探索式测试的实践中，我们更鼓励从实时探索中发掘缺陷，而非依赖事前的用例挖掘。
探索式测试的发展阶段
通常理解，探索式测试（Exploratory Test，ET）有如下几个发展阶段。
原始期：1.0 阶段，自由测试（free test）时期。出现启发式探索方法，但是实践中没有很具体的指南和打法。
发展期：1.5 阶段，启发式探索方法形成打法，具备可管理的模式。
成熟期：2.0 阶段，探索测试（ET）+ 脚本测试（ST）取长补短的测试风格。
持续进化期：3.0 阶段，强调一切皆可探索，各类业务形态、各种场景、各种团队、各种新的测试理念，都能演化为本团队最适合的原创探索测试方法及其匹配流程。
一开始，鼎叔觉得 3.0 阶段是个很虚的口号，随着在多个知名公司深入实践和理解，我感受到探索式测试理念的常用常新，它可以更自由地在新业务中沉淀新理论，给人惊喜。基于以人为本的敏捷价值观，探索式测试广泛适用于各种业务场景，并能被工程师赋予更多的创意和乐趣。
对探索式测试的误解
我参加过不少技术峰会的测试专场，大多数都是讲测试工程效能实践的，而讲探索式测试实践的主题基本没有。
“高大上” 显然并不是探索式测试流行的理由，以下是探索式测试实践可能带来的好处：
被用例文档约束的重复劳动减少了，个人感觉更轻松愉悦；
能发挥更多的独立自主性，学习效果更好了；
缺陷遗漏数量下降了；
测试效率提高，测试占用时间缩短了等。
除了个人直观感受到的优点，还有一些在全员实践团队中可见到的收益：
整个团队更重视用户体验问题了，每个角色对于质量的重视度都有明显增加；
大家更团结了，更愿意互相探讨容易遗漏的测试场景；
不同测试人员之间，不同岗位之间，更积极地分享找 Bug 的 “独门绝技”。
尽管行业有不少成功的实践例子，但是坚持实践探索式测试的团队还是少之又少。究其原因，还是因为人们对探索式测试有以下各种误解。
误解一：探索式测试是自由测试、随机测试（random test），不利于能力提升。
探索式测试并非那么自由，有目的和策略的探索式测试才能更容易达成收益目标，高效引导方法也不断推陈出新。掌握它看似没有学到 “硬本事”，其实能领悟更深刻的测试理论，吸收不少敏捷工程的精髓思想。
误解二：探索式测试不需要写文档。
探索式测试确实不需要写繁重格式的测试计划文档，但探索式测试可以产出原创的，有趣的，多种风格的，有价值的文档。
探索式测试需要的文档，可以是记下事前的牵引想法，事中的启发和变化记录，事后的风险判断，以及下一次的抓虫策略。
误解三：探索式测试是黑盒测试，技术门槛低。
探索式测试普及门槛低，任何人都可以快速掌握，可以快速进行黑盒探索。但这不意味着探索式测试只适用于黑盒。白盒测试和性能测试，同样可以引入启发，原创出探索式测试方法，能让问题挖掘事半功倍。记住，探索式测试是一种工作风格，不是一类特定技术，不限制具体技术的应用。
误解四： 探索式测试依赖员工的项目经验。
事实数据证明并非如此，并非在项目待很久的老手才能玩转探索式测试。很多新手员工探索问题的效率很高，甚至有自己独特的探索诀窍。而且非测试岗位员工，也可能在探索式测试活动中发现大量缺陷。
误解五： 探索式测试不借助任何工具。
探索式测试可以不借助工具，但也可以利用工具完成更多维度的探索。比如录屏/输入监听软件，接口工具，日志/调试工具，都可以是探索过程中的好帮手。
误解六：探索式测试通常在项目测试后期进行，那时已经测不出太多问题，发现问题也来不及解决了。
实际上，探索式测试可以在任何时期进行，初期探索可以尽快暴露更多问题，减少测试人员进入集成测试的负担。后期的探索测试可以多轮进行，通过探索的结果梳理对发布的信心。结合集体探索活动能在发布前又锁定一批遗留的风险问题。
总之，探索式测试不是漫无目的的测试，需要科学有效的指导方法。
探索式测试与计划式测试
探索式测试天然适合周期短的敏捷研发，它与敏捷原则更加契合。这是计划式测试所不具备的。
在挖掘软件缺陷成本很高的年代，测试工具平台也不成熟，软件一旦发布后，出问题的代价很大，因此计划驱动的测试模式自然成为主流。但随着探索试错的成本不断下降，实时探索缺陷越来越成为软件研发团队的偏好，可以基于风险更加灵活地探索软件。
芬兰赫尔辛基科技大学做过一个实验，让 79 位软件工程专业学生执行测试，测试对象是包含真实植入错误的开源软件，每个学生分别用探索式测试和计划式测试，各做了两个 90 分钟的测程，从下面图中的数据，我们可以得到一个结论：除了性能测试和技术架构测试，其他测试种类在探索式测试风格下，都取得了更好的效果。
敏捷原则告诉我们，过度的前期设计必然产生大量浪费，而传统的测试计划也是在前期做了大量的设计考虑，往往力图通过事无巨细的用例覆盖，为后面的执行扫除风险，期待一劳永逸。因此这种依赖事前设计的计划用例，必然产生相当大的浪费，导致后面测试执行的盲目和低价值。这也是因为团队成员在质量风险评审上，通常不愿节外生枝，往往只做加法不做减法，担心减少用例导致严重漏测的话会被指责。
通常而言，测试活动光有探索，没有计划，或者光有计划，毫无探索，都不是最佳做法。需要团队不断寻找最佳的平衡比例。
计划式测试就像事先绘制好的地图，而探索式测试确实给地图的探险带来令人期待的变化，进而能补充更多高质量的测试脚本（用例）。
高水平实践的团队，可以看到计划式测试和探索式测试的价值是非常互补的，让总的缺陷挖掘水平保持高位。在测试的初期，计划测试可以发现较多的基础问题，对探索式测试投入精力就比较少，但在测试后期，计划测试发现的 Bug 越来越有限，自动化测试很难发现新缺陷，这时探索式测试会更有惊喜。
