探索式测试，敏捷开发的最佳拍档

Posted 2021-04-25 晨小菜

传统脚本测试的局限

我们知道，传统的测试一般是先根据需求文档编写出测试用例，而后由测试人员本人或他人再根据测试用例的具体描述步骤（脚本）进行执行与验证。这种已经持续了几十年的测试方法我们又称之为脚本测试（Scripted Test，简称ST）。但是这几年随着敏捷开发的流行以及业务本身快速发展的需要，在开发速度不断得到提升的同时测试却慢慢变成了瓶颈，主要体现在下面两点：

1. 传统脚本测试的速度应对敏捷快速交付的要求有些吃力。当前大部分敏捷项目的迭代周期是1至2周，除掉需求和开发所需工时，留给测试的时间少之又少。而在这么短的时间内还需要经常花费大量的时间来编写详细的测试用例文档，使得测试人员不得不用加班来解决时间不足的问题；

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的一个简单的测试流程，仅供各位读者参考：

总结

探索式测试本身具备的敏捷特性，使得其非常契合应用在敏捷开发项目中，可以看做是敏捷开发的最佳拍档。当然，探索式测试也不是能包治百病的灵丹妙药，最关键还是需要测试人员了解学习探索式测试，同时愿意努力去尝试和实践，并且不断去改进和优化它，因为这个世上不会有银弹。

参考：

《探索式测试实践之路》，史亮，高翔

《埃森哲探索式测试方案》