最近看了不少有关探索性测试的讨论和观点，老实说越看越糊涂。所以忍不住吐槽一下，在这里和大家讨论一下探索性测试。希望对于想学习和尝试探索性测试的朋友有所帮助澄清，或者是更加糊涂，^_^.
   
    探索性测试有很多很多的定义：
   
    百度百科的定义："同时设计测试和执行测试". 嗯什么意思？
   
    Cem 老人家的正式定义："a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project".啊 糊涂了…
   
    有人说："手工测试就是探索性测试". 更糊涂了…
   
    又有人说："探索性测试就是一遍探索一遍测试". 彻底糊涂了…
   
    ……
   
    那么探索性测试到底是啥玩意啊？
   
    我们先来看一个例子吧。很多人都玩过猜数字的游戏吧。我心里想一个数字，你来猜。你可以问任何问题，我回答"是"还是"不是".然后你通过不断问问题和我的回答来最终猜到我心想的数字。在猜对的情况下问的问题越少得分越高。比如，我心里想了一个数字。你可以问"大于零？",我说"是".你现在知道是正数了，你然后问"小于100?",我说"是".你现在知道是小于100的正数，你然后问"小于50?",我说"不是".你现在知道是介于50和100间的数。你继续再问几次后因该就能猜对了。
   
    在这个简单的游戏中有两个策略至关重要：
   
    你要根据前面问题的答案来分析和设计下一个问题。第一个问题可能不着边，但是第二个问题会让你跟接近你想要的答案。第三个会更加靠近，以此类推。
   
    仅仅根据前面问题的答案来设计下一个问题可以最终帮你猜对数字，但是要想用最少的问题来猜对数字不仅要根据前面问题的答案，而且需要对问题本身其它知识加以综合运用使用其它策略和技术。比如在知道是小于100的正数后，你可以使用binary search,最多猜6次就可以猜对；如果你不知道binary search,你可以猜是否小于90?小于80?小于70?… 猜上十几次也可以猜对；或者猜是否小于99?小于98?小于97?… 猜上几十次也可以猜对。所以采用不同策略直接决定你猜对的速度。
   
    所以两个关键因素：前面问题的答案+有效的策略。
   
    探索性测试和猜数字游戏完全一样。在这里要猜的数字就是你要找的bug.你问的问题就是你做的测试，每个问题的答案就是你测试过程中产品的输出。第一轮你只有一个非常模糊的范围比如测试某个模块的某个功能。在你测试的时候通过观察产品的反应和输出来判断分析下一步做什么会发现bug.当然实际测试中不会像猜数字那样直接和简单。
   
    下面我们来看一下一个真实的测试例子。有一次我在测试一个用户界面的录入页面。用户可以输入比如姓名，年龄，等等很多信息，最后系统根据输入的内容处理保存到数据库中。当然我对每一个输入框都会尝试不同的数据比如空值，很长的字符串，空格等等，系统都没有问题。但是我注意到每次保存的时候系统都会生成一个本地文件，该文件的名字是其中一个输入框的我的输入。该输入框的唯一限制就是不可以为空不可以超过255个字符。我想到文件名字中不可以有斜杠"\",于是我就在该输入框中如入"ab\cd",它通过了输入校验，但是保存的时候系统就崩溃了。这就是探索性测试一个非常典型的例子，通过观察分析上一次测试的产品反应和输出来判断系统会有问题的地方，然后设计调整步骤和测试数据反复尝试直到完全验证模块没有问题或找到bug.
   
    探索性测试和手工测试的区别：手工测试通常是指完全按照预先设计好的步骤一步一步人工测试直到验证了所要验证的功能。如果结果和预期结果一致，则验证通过；如果不一致，则是bug.可以看出手工测试过程单调没有思考没有变通。在上面的猜数字的游戏中你明明已经知道是正数，你还在按照游戏开始前设计的步骤问大于-100? 大于-90?…当然现实生活中没有这样的傻子，在你"手工"测试的时候你或多或少已经使用"探索性"了，只不过你没有意识到罢了。所以很多人误认为探索性测试是个时髦新测试技术，研究了半天又不知道到底新在那里和自己一致做的有什么不同。或者恍然大悟原来自己已经探索了很多年了。但是探索性测试有效率高和效率低之分，所以有人干脆就把效率高ET的才叫ET, 效率低的ET叫手工测试。这也是让人糊涂的原因之一吧。
   
    测试自动化就是把手工测试的每个步骤有测试自动化工具来完成。好处是不用人做了，缺点是测试过程中仍然没有思考没有变通。
   
    Ad-hoc测试（随机测试）：没有预先设计好的步骤，也没有明确目标，也没有策略。在上面猜数字的游戏中你明明知道是正数，你还在东一榔头，西一棒槌的乱猜等于100?等于-100?等于0?…当然也有可能被你一不小心蒙对了。
   
    探索性测试和测试自动化各有各的优缺点。至于什么时候开始测试自动化，什么时候开始ET,先测试自动化后ET,还是先ET后测试自动化需要看项目产品具体情况了。没有绝对对错，以尽早发现bug,发现更多的的bug为宗旨。另外既然ET和测试自动化的各自优缺点，微软有些组最近两年在尝试"探索性测试自动化"的方式来把探索性测试和测试自动化相结合，充分发挥各自的优点。看到这里你可能要恨我了，我刚学会测试自动化，你又提倡ET了；我刚搞清楚ET,你又开始提倡探索性测试自动化了… 呵呵，人类发展过程就是通过社会分工，扬长避短。专注于做自己擅长的事情，把自己不擅长做的事情交给擅长的人去做。社会发展是如此，云计算是如此，测试也是如此。有人说过："The computer is incredibly fast, accurate, and stupid （test automation）。 Man is unbelievably slow, inaccurate, and brilliant （exploratory test）。 The marriage of the two is a force beyond calculation."
   
    其实我们可以看到探索性测试入门容易或者你已经在做了多年了，难得是有效地探索性测试，或者做效率高的ET（否则被别人不屑为手工测试了J）。那么如何根据前面的测试结果来分析和思考，如何才能敏锐地嗅觉到通向bug的种种线索？当然有多种方式来训练自己这方面的能力。还有如何衡量考核ET的效率，投入和产出比率？