如果你是一名测试人员，那么不管你对探索性测试的了解是多是少，我肯定你一定用过探索性测试的方法。想想看，你是否曾经这样测试过？不仅仅按照测试案例或者脚本上写什么，就完全使用那一套相同的数据、一模一样的流程，而是根据你执行时的所见，临时有所想和所动，进行一定程度的自由发挥？我想你肯定有过，这就是探索性测试，它将你的测试与纯基于脚本的测试（script. based testing）区分开来。而这种自由发挥，因为是有大致方向和范围的，所以也与完全盲目乱点的猴子测试（monkey testing）不同。

　　换言之，因为你是人，所以你比猴子和机器人都聪明，你懂得在学习中不断完善自己，而不是漫无目的或者按图索骥。因为你是测试人员，所以探索性测试是你必备的职业技能。而如果不经过一定的理论指导和系统实践，我想凭着那点探索的本能，你还不足以成为一名高效的测试人员。如果想快速提高探索测试的技能，我认为最好的方法是和你测试组的伙伴一起来实践和提高，而不是一个人练习。如果你所在的团队还没有过这方面的实践，那么你可以从本文当中了解到我们团队中基于session的探索性测试的实践和感悟。

　　为什么我们选择基于session的探索性测试？

　　基于session的探索性测试在2000年由James Bach和Jonathan Bach兄弟俩创建。这里的Session其实就是一段指定的时间，比如从8：30到10：00的一个半小时。探索性测试可以不基于session。至少在读完J Whitter的“探索性测试”一书后我完全没有觉得session是探索性测试中的一个关键词。但是查阅探索性测试资料，你会发现实践中的探索性测试很多都是基于session展开的。我们实践了以下三个基于session的探索性测试的要点，并感受到了它的益处。

　　1、因为session，更专注

　　因为每个session都有确定的开始和结束时间，一般长度为一小时、一个半小时或者两小时，所以在这有限的且不算太长的时间里，测试人员会更专注，从而效率更高。

　　我清楚地记得，有一天下午我们小组（4个测试人员）计划了两个各一个半小时的session。第一个session结束，当我们做debrief（下面会介绍debrief）的时候，有两个人明确提出下面即将开始的新的session能否改成一个小时，因为过去的一个半小时太累了，“大脑都要缺氧了！”当然，刚收获了近40个缺陷和近30个疑问的这个session，无疑大家都是很辛苦的。但是，从另一个方面，我们也看到，平时如果没有session，大家的专注程度是否还可以提高一点呢？对我而言，虽然感到这次和我平时个人做探索性测试的专注程度类似，但在一个集体做探索性测试的氛围下，似乎也更有时间的紧迫感了。我想这就象自己在家做模拟卷和在学校里和同学一起模拟考一样，总有那么点不同的压力。

　　2、因为charter，强迫思考

　　在一个既定的方向或者说章程（Charter）上一定要发现缺陷，这其实是强迫你思考和挑战自己的思维局限。

　　我喜欢看钓鱼比赛的节目，也感到它和测试的相通之处很有意思。例如，钓鱼的挑战在于：如何在你已经非常熟悉、觉得无鱼可钓的水域找到鱼；如何在一个你不熟悉的水域，快速钓到大鱼；如果你可以自由选择，你将换到哪个水域（因为根据经验你猜想那里可能有大家伙）？精明的垂钓者不单有专业的钓竿（测试辅助工具），对天气、水域（软件工作环境）和鱼生活习性（被测系统的功能）的了解，还要有一些很重要的临场判断（根据前面几条鱼的大小和难易程度判断今天在这个地方钓上大家伙的概率，以决定下一步是继续在这里守株待兔还是马上转移）和一点点的运气。关于运气，我觉得测试中也一定是有的，但是我更相信机遇或者运气是比较垂青有准备的头脑的。所以，我总是愿意花时间去多测测，花心思去少测测。

　　想想测试中，我们是否也面临和钓鱼类似的挑战？如何在你已经测试了一段时间，觉得比较稳定的功能上找到新的缺陷？如何在你不熟悉的模块，快速找到缺陷？如果一种方法找不到缺陷，接下来该换种什么样的思路？

　　突破自己思维的局限，我们团队中每个人都在实践多种不同的方法。比如，探索性测试一书中的各种方法（遍历法、强迫症法、取消法、超模法。。。），自创或者借鉴的各种测试的常用方法（web测试要点、安全测试常用方法。。。）以及Test Explorer工具的小提示等等。

　　当我们设定所有测试人员都采用同一种方法来测试的时候，报出的不同的缺陷往往非常令人印象深刻。我们也在一起分享、总结、积极寻找测试某个软件的最管用的探索性测试方法是哪一两个。强迫自我突破，学习他人突破，三个臭皮匠顶个诸葛亮！

　　3、因为汇报（debrief），团队力量胜于个人

　　我个人觉得，个人的探索性测试和团队的探索性测试在流程上最大的差别就是汇报（debrief）。这是一个session结束后的短暂讨论环节。我们采用的是Jon Bach提出的PROOF模式。PROOF即Past， Results， Obstacles， Outlook， Feelings的首字母缩写。按照这个形式，我们会逐个分享过去这个session自己完成的工作、得到的结果、碰到的困难、接下来需要进行的工作（可以作为下一个session的目标）、自己的感觉。在这个环节里，我们会对一些公共的问题或者大的障碍进行一些沟通，但不会太长时间讨论，而主要是让团队成员知晓一些我们认为重要的信息。这里，我们经常能够发现共鸣或者别人轻易就解释了我们的疑惑。如果我们做的charter是同一性质的，如易用性，那么我们会在每个人都以PROOF模式做简要汇报后，按照session报告中缺陷和问题的记录，快速过一遍每个缺陷和问题。这对于我们能够及时学习和借鉴别人的测试思路，马上运用到自己接下来的测试过程有一定的帮助。我感到：通过debrief环节的及时沟通和互相学习，我们将探索测试的精髓也扩展到了我们的团队学习和实践中，即在一个很短的周期内，学习和执行是融为一体的，而不是顺序的、隔离的。