初探团队基于session的探索性测试

　　若是你是一名测试人员，那么无论你对探索性测试的了解是可能是少，我确定你必定用过探索性测试的方法。想一想看，你是否曾经这样测试过？不只仅按照测试案 例或者脚本上写什么，就彻底使用那一套相同的数据、如出一辙的流程，而是根据你执行时的所见，临时有所想和所动，进行必定程度的自由发挥？我想你确定有 过，这就是探索性测试，它将你的测试与纯基于脚本的测试（script. based testing）区分开来。而这种自由发挥，由于是有大体方向和范围的，因此也与彻底盲目乱点的猴子测试（monkey testing）不一样。 　　换言之，由于你是人，因此你比猴子和机器人都聪明，你懂得在学习中不断完善本身，而不是漫无目的或者按图索骥。由于你是测试人员，因此探索性测试是你 必备的职业技能。而若是不通过必定的理论指导和系统实践，我想凭着那点探索的本能，你还不足以成为一名高效的测试人员。若是想快速提升探索测试的技能，我 认为最好的方法是和你测试组的伙伴一块儿来实践和提升，而不是一我的练习。若是你所在的团队尚未过这方面的实践，那么你能够从本文当中了解到咱们团队中基 于session的探索性测试的实践和感悟。 　　为何咱们选择基于session的探索性测试？ 　　基于session的探索性测试在2000年由James Bach和Jonathan Bach兄弟俩建立。这里的Session其实就是一段指定的时间，好比从8：30到10：00的一个半小时。探索性测试能够不基于session。至少 在读完J Whitter的“探索性测试”一书后我彻底没有以为session是探索性测试中的一个关键词。可是查阅探索性测试资料，你会发现实践中的探索性测试很 多都是基于session展开的。咱们实践了如下三个基于session的探索性测试的要点，并感觉到了它的益处。 　　一、由于session，更专一 　　由于每一个session都有肯定的开始和结束时间，通常长度为一小时、一个半小时或者两小时，因此在这有限的且不算太长的时间里，测试人员会更专一，从而效率更高。 　　我清楚地记得，有一天下午咱们小组（4个测试人员）计划了两个各一个半小时的session。第一个session结束，当咱们作debrief（下 面会介绍debrief）的时候，有两我的明确提出下面即将开始的新的session可否改为一个小时，由于过去的一个半小时太累了，“大脑都要缺氧 了！”固然，刚收获了近40个缺陷和近30个疑问的这个session，无疑你们都是很辛苦的。可是，从另外一个方面，咱们也看到，平时若是没有 session，你们的专一程度是否还能够提升一点呢？对我而言，虽然感到此次和我平时我的作探索性测试的专一程度相似，但在一个集体作探索性测试的氛围 下，彷佛也更有时间的紧迫感了。我想这就象本身在家作模拟卷和在学校里和同窗一块儿模拟考同样，总有那么点不一样的压力。 　　二、由于charter，强迫思考 　　在一个既定的方向或者说章程（Charter）上必定要发现缺陷，这实际上是强迫你思考和挑战本身的思惟局限。 　　我喜欢看钓鱼比赛的节目，也感到它和测试的相通之处颇有意思。例如，钓鱼的挑战在于：如何在你已经很是熟悉、以为无鱼可钓的水域找到鱼；如何在一个你 不熟悉的水域，快速钓到大鱼；若是你能够自由选择，你将换到哪一个水域（由于根据经验你猜测那里可能有你们伙）？精明的垂钓者不单有专业的钓竿（测试辅助工 具），对天气、水域（软件工做环境）和鱼生活习性（被测系统的功能）的了解，还要有一些很重要的临场判断（根据前面几条鱼的大小和难易程度判断今天在这个 地方钓上你们伙的几率，以决定下一步是继续在这里守株待兔仍是立刻转移）和一点点的运气。关于运气，我以为测试中也必定是有的，可是我更相信机遇或者运气 是比较垂青有准备的头脑的。因此，我老是愿意花时间去多测测，花心思去少测测。 　　想一想测试中，咱们是否也面临和钓鱼相似的挑战？如何在你已经测试了一段时间，以为比较稳定的功能上找到新的缺陷？如何在你不熟悉的模块，快速找到缺陷？若是一种方法找不到缺陷，接下来该换种什么样的思路？ 　　突破本身思惟的局限，咱们团队中每一个人都在实践多种不一样的方法。好比，探索性测试一书中的各类方法（遍历法、强迫症法、取消法、超模法。。。），自创 或者借鉴的各类测试的经常使用方法（web测试要点、安全测试经常使用方法。。。）以及Test Explorer工具的小提示等等。 　　当咱们设定全部测试人员都采用同一种方法来测试的时候，报出的不一样的缺陷每每很是使人印象深入。咱们也在一块儿分享、总结、积极寻找测试某个软件的最管用的探索性测试方法是哪一两个。强迫自我突破，学习他人突破，三个臭皮匠顶个诸葛亮！ 　　三、由于汇报（debrief），团队力量胜于我的 　　我我的以为，我的的探索性测试和团队的探索性测试在流程上最大的差异就是汇报（debrief）。这是一个session结束后的短暂讨论环节。咱们 采用的是Jon Bach提出的PROOF模式。PROOF即Past， Results， Obstacles， Outlook， Feelings的首字母缩写。按照这个形式，咱们会逐个分享过去这个session本身完成的工做、获得的结果、碰到的困难、接下来须要进行的工做（可 以做为下一个session的目标）、本身的感受。在这个环节里，咱们会对一些公共的问题或者大的障碍进行一些沟通，但不会太长时间讨论，而主要是让团队 成员知晓一些咱们认为重要的信息。这里，咱们常常可以发现共鸣或者别人轻易就解释了咱们的疑惑。若是咱们作的charter是同一性质的，如易用性，那么 咱们会在每一个人都以PROOF模式作简要汇报后，按照session报告中缺陷和问题的记录，快速过一遍每一个缺陷和问题。这对于咱们可以及时学习和借鉴别 人的测试思路，立刻运用到本身接下来的测试过程有必定的帮助。我感到：经过debrief环节的及时沟通和互相学习，咱们将探索测试的精髓也扩展到了咱们 的团队学习和实践中，即在一个很短的周期内，学习和执行是融为一体的，而不是顺序的、隔离的。