聊聊什么是探索式测试

本篇开始分享第三个主题系列文章-探索式测试。

除了自动化测试建设这个众所周知的方向，另辟蹊径的敏捷测试方案层出不穷，在过去的实践中，鼎叔最希望着力推广的是三大敏捷测试利器（方案）：探索式测试，众包测试，精准测试。三大利器自成体系，具备不断深度挖掘的价值，投入产出很可观，而且从不同方面阐述了敏捷价值观在测试领域应用的精髓。

历经四个公司的亲身组织实践，我认为探索式测试是非常有趣的，任何人都可以从中获得适合自己的知识和经验。

我们先从一个笑话讲起

测试工程师走进酒吧，

要了一杯啤酒，

要了0杯啤酒，

要了999999999杯啤酒，

要了一只蜥蜴，

要了-1杯啤酒，

要了一个sfdeljknesv，

酒保从容应对，测试工程师很满意。

接下来，一名顾客来到了同一个酒吧，问厕所在哪？

酒吧顿时起了大火，然后整个建筑坍塌了。

这个笑话很生动地告诉我们，无论设计的测试数据多么周详，总有客户能发现测试工程师遗漏的严重问题场景，这个场景往往是出人意料的，也是经常能见到的。

探索式测试的由来

首先我们思考一个问题，人工测试，相对于自动化测试，有什么优势？

1) 人工测试，更容易发现不同业务逻辑的关联缺陷。

2) 人工测试，可以给出灵活多变的测试计划，灵活多变的测试用例，发挥人的想象力。

3) 人工测试，不只是看断言，还会随时查看各种异常：日志，UI，资源监控，动效，弹框，不一而足。

人工测试通常会有一个事前的测试计划，里面列明了详细的用例执行过程。

如果我们看重人的“灵活性”和“积极性”，逐步摆脱测试计划的束缚呢？

那就是我们要介绍的探索式测试。

有不少测试同学曾提到，第一次听说探索式测试理论，觉得很高大上，但是并没有真正深入了解。

实际上，探索式测试对于突破重复劳动的束缚，降低漏测率，提高测试交付效率，都会有明显的价值。测试人员工作更加自由自主，不需要被大量的测试用例所包围，不用花大量时间写非常细致的用例集。

测试专家Cem Kaner在1983年提出了探索式测试，并把它定义为一种软件测试风格，而不是一个具体的测试技术，如边界值分析方法，因果图等。探索式测试强调的，是测试人员应该持续的同步开展测试学习，测试设计，测试执行，测试评估等多种活动，不断闭环提升，而不是被事前的测试计划文档所牢牢束缚。

我经常看到有些团队会考核测试用例的缺陷相关性指标，评判测试用例的有效性。但在探索式测试的实践中，我们更鼓励从实时探索中发掘缺陷，而非依赖事前的用例挖掘。

探索式测试的发展阶段

通常理解，探索式测试（Exploratory Test，ET）有如下几个发展阶段。

一开始，鼎叔觉得3.0阶段是个很虚的口 ，随着在多个知名公司深入实践和理解，我感受到探索式测试理念的常用常新，它可以更自由地在新业务中沉淀新理论，给人惊喜。基于以人为本的敏捷价值观，探索式测试广泛适用于各种业务场景，并能被工程师赋予更多的创意和乐趣。

对探索式测试的误解

我参加过不少技术峰会的测试专场，大多数都是讲测试工程效能实践的，而讲探索式测试实践的主题基本没有。

“高大上”显然并不是探索式测试流行的理由，以下是探索式测试实践可能带来的好处：

除了个人直观感受到的优点，还有一些在全员实践团队中可见到的收益：

尽管行业有不少成功的实践例子，但是坚持实践探索式测试的团队还是少之又少。究其原因，还是因为人们对探索式测试有以下各种误解。

误解一：探索式测试是自由测试、随机测试（random test），不利于能力提升。

探索式测试并非那么自由，有目的和策略的探索式测试才能更容易达成收益目标，高效引导方法也不断推陈出新。掌握它看似没有学到“硬本事”，其实能领悟更深刻的测试理论，吸收不少敏捷工程的精髓思想。

误解二：探索式测试不需要写文档。

探索式测试需要的文档，可以是记下事前的牵引想法，事中的启发和变化记录，事后的风险判断，以及下一次的抓虫策略。

误解三：探索式测试是黑盒测试，技术门槛低。

误解四： 探索式测试依赖员工的项目经验。

事实数据证明并非如此，并非在项目待很久的老手才能玩转探索式测试。很多新手员工探索问题的效率很高，甚至有自己独特的探索诀窍。而且非测试岗位员工，也可能在探索式测试活动中发现大量缺陷。

误解五： 探索式测试不借助任何工具。

探索式测试可以不借助工具，但也可以利用工具完成更多维度的探索。比如录屏/输入监听软件，接口工具，日志/调试工具，都可以是探索过程中的好帮手。

误解六：探索式测试通常在项目测试后期进行，那时已经测不出太多问题，发现问题也来不及解决了。

实际上，探索式测试可以在任何时期进行，初期探索可以尽快暴露更多问题，减少测试人员进入集成测试的负担。后期的探索测试可以多轮进行，通过探索的结果梳理对发布的信心。结合集体探索活动能在发布前又锁定一批遗留的风险问题。

总之，探索式测试不是漫无目的的测试，需要科学有效的指导方法。

探索式测试与计划式测试

探索式测试天然适合周期短的敏捷研发，它与敏捷原则更加契合。这是计划式测试所不具备的。

在挖掘软件缺陷成本很高的年代，测试工具平台也不成熟，软件一旦发布后，出问题的代价很大，因此计划驱动的测试模式自然成为主流。但随着探索试错的成本不断下降，实时探索缺陷越来越成为软件研发团队的偏好，可以基于风险更加灵活地探索软件。

芬兰赫尔辛基科技大学做过一个实验，让79位软件工程专业学生执行测试，测试对象是包含真实植入错误的开源软件，每个学生分别用探索式测试和计划式测试，各做了两个90分钟的测程，从下面图中的数据，我们可以得到一个结论：除了性能测试和技术架构测试，其他测试种类在探索式测试风格下，都取得了更好的效果。

敏捷原则告诉我们，过度的前期设计必然产生大量浪费，而传统的测试计划也是在前期做了大量的设计考虑，往往力图通过事无巨细的用例覆盖，为后面的执行扫除风险，期待一劳永逸。因此这种依赖事前设计的计划用例，必然产生相当大的浪费，导致后面测试执行的盲目和低价值。这也是因为团队成员在质量风险评审上，通常不愿节外生枝，往往只做加法不做减法，担心减少用例导致严重漏测的话会被指责。

通常而言，测试活动光有探索，没有计划，或者光有计划，毫无探索，都不是最佳做法。需要团队不断寻找最佳的平衡比例。

计划式测试就像事先绘制好的地图，而探索式测试确实给地图的探险带来令人期待的变化，进而能补充更多高质量的测试脚本（用例）。

高水平实践的团队，可以看到计划式测试和探索式测试的价值是非常互补的，让总的缺陷挖掘水平保持高位。在测试的初期，计划测试可以发现较多的基础问题，对探索式测试投入精力就比较少，但在测试后期，计划测试发现的Bug越来越有限，自动化测试很难发现新缺陷，这时探索式测试会更有惊喜。