如果你是一名测试人员，那么不管你对探索性测试的了解是多是少，我肯定你一定用过探索性测试的方法。想想看，你是否曾经这样测试过？不仅仅按照测试案例或者脚本上写什么，就完全使用那一套相同的数据、一模一样的流程，而是根据你执行时的所见，临时有所想和所动，进行一定程度的自由发挥？我想你肯定有过，这就是探索性测试，它将你的测试与纯基于脚本的测试（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环节的及时沟通和互相学习，我们将探索测试的精髓也扩展到了我们的团队学习和实践中，即在一个很短的周期内，学习和执行是融为一体的，而不是顺序的、隔离的。
用ET测试自己的模块和别人的模块
1、测试自己的模块
当用探索性测试方法测试自己的模块时，在功能方面能更为有效地发现缺陷，尤其是那些复杂功能。另外，我们觉得有些探索性测试的方法应该被本模块负责的测试人员优先采用而保证其质量，不应该由别的测试人员来尝试。比如，确保所有按钮都可以工作，所有报错信息都正常显示，所有字段最大长度检查都通过等。因为如果一个别的测试人员随机地去检查字段长度，而结果是被测的正好没问题，漏测的地方正好有问题，这就可能给团队一个错误的信息。这种情况属于基于脚本的测试没有到位。或者别的测试人员逐个检查每个字段长度而发现全部都没有问题，最后才知道这是因为已经被本模块测试人员测试过并且缺陷被修复过了，这就是一种资源的浪费。
2、测试别人的模块
（1）为什么要测试别人的模块？
有人也许会问：“如果每个测试人员都可以熟练有效地运用探索性测试方法来测试自己的模块，那为什么要互相交换，去测试别人的模块呢？”这是个很好的问题。带着这个疑问，我们尝试了测试别人的模块，并发现了以下的必要性和好处。
● 避免自己难以发现的问题被遗漏
人无完人，测试人员也不例外。每个人每次测试中的盲点并不都能被自己及时发现。而换个人，这样的问题容易很快被发现。对于团队来说，这是一种高效的做法。
● 利于知识传递和储备
测试别人的模块，利于及时深入了解被测对象的详细复杂逻辑。当你被要求去探索性测试一个不熟悉的复杂功能时，如果事先不做一些功课，相信你甚至都很难订出一个自己觉得合理的charter。硬着头皮上的后果是在一个明明有大贝壳的沙滩，花了时间却只捡到一些零零碎碎的小贝壳。这对组织是危险的，对自己也是令人沮丧的。
● 有很多好的问题（issue）被提出，或者再次被提出
不难理解，因为视角不同，交换测试的时候会有很多好的问题被提出。再次被提出是指原来测试的人员也有类似的感觉，但不那么强烈；或者曾被诸如“用户不会这么做或者这样想”而遭到过开发人员的拒绝。这种问题一旦被再次提出，往往就更具有说服力，值得旧话重提。
（2）测试别人的模块时如何选择charter？
经过实践，我们发现利用探索性测试测试别人的模块时，在易用性、用户界面显示、模块交互、类似功能的一致性等方面能够高效地发现有价值的缺陷。
（3）测试别人的模块时应避免的情况
为了避免资源的浪费，我建议在测试别人的模块的时候先告知原来负责测试这个模块的人员你接下来的session里测试的范围和方向。尽量不要去测试那些已经做过大量测试的非主要功能，而主要功能则可以运用以前没有运用过的探索性方法再深入测试。比如，原来的测试人员在主要功能的数据多样性方面已经进行过大量测试，而按照操作顺序这种探索性测试方法相对运用得比较少，这就将是你的更好的方向。
另外，测试时报告的缺陷数量固然重要，但我们的目标不是报告更多的缺陷，而是报告更多有商业价值的缺陷，所以应该避免在一些很边缘的或者细小的地方报很多类似的缺陷，同一类型的小缺陷算一个缺陷就够了。
（4）如何看待别人在你的模块报告的缺陷？
正如在你的一亩三分地上，当你自己已经觉得收割完毕，而看到别人仍然收获颇丰的时候，除了不敢相信，我很难想像你会有更开心的第一反应。而我觉得人与人的差别往往在于第二反应，在于不敢相信之后你会做什么。当别人在你的模块报告较多的缺陷时，大多数人会仔细看一下，确认到底是什么问题，接着以“了解了”结束。有一部分人会想“如果也给我一个同样charter的session，我能报出这个缺陷么？为什么？”还有人会去汇总背后的原因，分享这些心得，以后测试的时候能提醒自己和团队朝这些方面改进。
经过初步尝试团队的基于session的探索性测试，我感到了其与个人的基于session的探索性测试的互为补充之处，也实践了如debrief这样的团队实践。下一步，我们将对测试的结果进行分析，持续探索利用探索性测试提高测试有效性和效率的有效方法。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/