认清探索性测试

　　原本想把探索性测试(ET)和敏捷测试(Scrum)放在一起谈论，后来想想，两者需要注意的点还是很不同的，所以先谈论下探索性测试吧。

　　现在可能越来越多的测试开始谈论ET，也就是所谓的探索性测试。但是这里我想说的是，不要盲目依赖ET，也不要不清晰的去认知ET。需要了解其真正的意义然后根据自己的实际情况做相应的改变才是上策。

　　首先不要理解ET就是Free Style，就是所谓的随机测试。所谓探索和自由的测试，随机测试还是有差别的。探索是有很多方法支持，并不是漫无目的的随便针对软件测试。这里举两个例子，比如A心中想着一个数字让B猜测，B每猜一个数字，A会告诉B是比心中想的数字大了还是小了。最终B会准确的猜出A心中所想的数字。再比如你去超市shopping，除了你直接有目的性的之外，大部分情况都是会先进行物品的挑选，无论是种类，还是价格的比较，最终挑选出符合你想要的那个商品。这个两个例子虽然在我们生活中一直发生，但是却就是最原始的一种探索性测试。这里不得不提的就是联系上下文的测试，两个例子都是根据上下文进行一种探索，最终达到了自己的一个目的。

　　再来我想谈一下怎么施行ET，或者说怎么权衡ST和ET。经过ChinaTest以及之后的几场沙龙，我发现很多测试的问题都是围绕在这样几个点上面。

　　我想在谈论这些问题前先理清楚几个概念：

　　1.ST和ET绝对没有哪个是通用工具，都不可能一条路走到底

　　2.计划永远赶不上变化，我们的测试必须根据实际情况灵活改变

　　3.任何的测试都应该基于风险评估

　　4.任何的测试都应该根据上下文来实施

　　5.ST中的所有的步骤在ET中都是需要去做到，唯一不同的只是我们可能会简化某些步骤，而达到更高的效率。

　　6.测试活动是一个长期的活动，是一个循序渐进的过程。

　　那么接下来我先来说一下怎么实施ET。个人认为ET本身的方法很多，其实就实施而言，我们根据自己产品项目的具体情况然后有针对性的进行ET。这里可能在执行的过程中大部分会碰见的一些问题如下：

　　1.公司或者测试团队如何先踏出第一步

　　我觉得首先如果你是一个leader或者manager，你想推ET自己先得想清楚推的过程中的一些框架，如何推，如何考评，如何引导大家去做等。然后再走，否则可能会造成一团乱的局面。你可以选择和公司上层直接进行沟通表达测试团队可能接下来会引入一种新的测试方法。如果你的上层并不能那么容易就能够说服的话，那么你可以先抽几个骨干在有空的时候进行一些ET，将结论总结好然后再去和上层交涉，那么我相信绝对更加有说服力。而对于测试团队来讲，应该进行相应的概念和方法的培训，让测试团队充分的了解ET和ST的区别，ET的优缺点分别是什么，我们为什么要引入这样的方法等。至少以上这些是你要进行ET前必须要做的事情。

　　2.每个测试人员的经验能力各不相同，ET之后就自由了好多，如何在风险可控范围内有效的进行ET，如何考评呢?

　　这里我有一个初步的原创的方案。确实，这个问题几乎在每个公司都会存在。而我主张在初期ET必须被引导。而这种引导又必须是老测试人员或者资深的测试来做。我在一个月前使用过如下的方法。我将每次ET的活动都定成一个Test Task，其中高风险的全部由测试leader主动分配给测试人员，低风险的由测试人员自己去认领。每个Task中都会写明ET的目的，范围，时间等。最终根据每个测试人员对于高低风险Task的完成量，完成时间，完成质量进行相对应的考评。这样也很有说服性。

　　另外，如果时间充裕，那么进行交叉的ET也是非常有效率的一种方式。无论是新测试还是老测试，每个人都会有测试盲点。那么交叉测试既能够保证ET的覆盖面的同时也会给测试带来更多的想法，灵感。

　　在每个项目发布前的一段时间最好能够组织全公司或者全team进行bug bash。每次bash时间一般在3个小时。我以前公司每次都会做。这种活动可以看作为全员在做测试，相信这样一轮下来肯定会发现很多之前没有发现的问题。对于实施ET之后的项目也很有帮助。

　　3.ET要写测试用例么?怎么写?回归测试怎么做?发现了bug之后应该做什么处理。

　　这个我觉得ET的测试用例更加像一种思维导图，或者思维引导。并没有具体的形态，每家公司情况都不同。但是我们需要记录的是一种思维，并非一种特定的现象(如果测试步骤和测试结果一直不变，比如数据库的测试，比如一些对话框的测试，那么可以将他们列入ST，也可以在ET的思维导图中标注一下)ET所需要的其实就是一种经验，一种思维，告诉测试引导测试应该从什么测试点入手，可能会在某些情况下发生问题。在2中我提到的Task中测试leader就必须写清楚测试切入点，可能出现的问题点，这样一来降低了因为测试人员能力不同 而导致的风险，二来同时也引导了新的测试人员，将经验很好的传达给了他们。

　　回归测试的话，我觉得可以通过回归bug来达到相应的目的。或者也可以将高风险的功能归类总结出ST的TC，然后作为回归测试来执行。

　　ET发现bug之后我认为首先你需要报这个问题，其次就是要记录到你或者整个团队的思维导图这样一个库中。它是一种思路，以便于引导下次测试该模块的测试人员。

　　那么最后我来谈一下怎么权衡ST和ET，正如我之前提到的几点需要清楚的地方。那么下面举几个例子，我相信你就会明白。

　　假设你对于你的团队信心不是很大，并且对于产品本身的质量抱有一定的质疑。那么你需要将高风险的功能点总结出来，然后进行测试用例的编写。那么这部分的功能就是主要以ST为主，ET为辅的方式进行确保。而其余的功能你可以一半时间使用ST，一半时间使用ET。其思路就是ST保证高风险功能点以及产品的各个基本功能点，至少产品经过ST之后不会产生P1的问题。同时结合ET，让产品从UE、UI等各个ST可能无法覆盖到得方面进一步进行保证。

　　假设你对于你的团队和产品的态度还是有那么点信心的。那么你就可以使用ET为主，ST为辅的方式。同样的这样会加快团队使用ET的经验。ST同样是为了保证基本功能点以及一些固定数据的测试点，而更多时间的ET是能够在短时间内更多的发现产品的缺陷，从而达到测试的目的。

原文转自：http://www.testdao.com/article-320-1.html