首先需要声明的是，目前我对探索式测试理论和实践的理解还停留在1到2年前的水平，很多内容都在《探索式测试实践之路》可以了解到的，但是需要告诉大家的是，虽然国内对ET的理论和实践进步不大，但是国外一些测试大师对ET的理论和实践都有很大的提高，包括工具、流程和总体解决方案。由于最近两年的主要精力不在这个上面，所以对国外这两年ET的发展了解不多，如果有说的不对的地方，欢迎指出来，也让我多学习和了解下。
虽然很多人都看了《探索式测试实践之路》这本书，但是并不是所有人都能理解这里面的来龙去脉，我也在很多场合说明了自己的看法，但是还是会存在一些误读，加上崔老师提的关于ET的4个问题，我觉得非常好，很多看过拿本书的人都会或多或少有自己的看法，我趁这个机会，说下自己的看法，不一定正确。
（1）如何选择探索的深度？
大家都应该知道，探索式测试的探索的涵义吧，基本上就是根据自己所得到的信息去挖掘更多的新的信息，从而判断系统出来是否正确和合理。但是时间是有限，我们到底要挖潜到什么时候呢？我们做测试也是一样的道理，测试不可能很全面，什么都想测试到，代码覆盖率100%等。但是我们应该要测试到什么程度呢，有哪些判断依据呢，很多时候就是平衡，我们需要抓住一些平衡，在一定的context范围内。
我个人是这样理解的，首先我们必须非常清楚我们的任务具体是什么，了解我们现在做的charter和session到底是什么。然后，大家都知道session有自己的一些特点吧，很关键的一个就是 timebox，就是区间，在有限的时间区间内对被测系统就行测试设计和执行层面的探索，当然，这时候又涉及到之前划分session的原则和合理性，这个不在这里细说。
a. 在timebox内，测试人员对具体的任务进行探索，只要思维不枯竭，应该不存在是否需要继续探索的疑问。但如果不知道要测试什么了，该怎么办呢？首先：静下来，梳理之前得到的信息，整合系统处理逻辑和所有异常流程，再次check是否覆盖到所有的测试点；第二，使用通用的测试tips提醒，check自己是否考虑到类似的测试场景，比如session tester工具就有这样的tips；第三，正对被测模块的分析，check相应的探索式测试方法，进行场景方法层面的思维提醒；最后，和相关人进行交流和沟通，在交流的过程中，会得到别人的启发，从而看是否存在遗漏的测试场景。一旦存在，立即执行。
b. 假设在测试人员挖掘的信息比较多，测试的非常high，时间过得也快，也发现了一些问题，从而无形中增加提交bug的时间，减少了真正测试的时间，这个时候，测试人员该怎么办呢。我个人的看法是，首先减少提交bug的时间，采用关键字加截图的方式，快速记录bug；第二，测试人员会使用工具来进行时间提醒，原来确定的时间到了后，测试人员应该停下来，仔细思考我挖掘的是否足够，check前几次异常测试场景是否发现bug，思考开发实现代码逻辑和被测模块的整体质量，综合判断是否需要继续探索更新的信息和测试执行； 第三，如果确定了继续探索，需要考虑是否调配其他的session的测试时间，或者是否加班完成它；第四，如果能判断覆盖80%以上的代码覆盖率，且认可开发的质量，建议测试人员plugin out，去测试其他计划内的session。最后，对于整合信息并作出分析和判断，这个过程需要非常快速和高效的，这个可能就是一些经验的积累，建议大家多去尝试，然后看看结果，给自己增加信心或者教训。
（2）如何衡量探索式测试的有效性？
这个问题其实有点大，个人觉得这个和你实践ET的方式有关，目前来说，大部分人认为ET就是ST的补充，但是补充的效果到底怎么样呢，很多人可能都没有去实践和分析具体的细节。
对于如何衡量ET的效率，我前几年一直在思考这个问题，但是我真的没有得出很好的答案，我目前的看法是这样的：客观数据 + 主观感受。 客观数据，主要包括发现Bug的数量和认可的测试思路。主观感受就是个人在ET执行或设计过程中，对于SUT的探索的过程中的主观感受，是否真正扩展了你的思维，让你思考更多你之前没有思考过的角度。这里说到的bug数量不一定能说服人，因为你不可能一个人针对同一个项目使用ET 或 ST来进行测试，从而比较两个结果，这个只能是单维度的，是 谁用谁知道啊。说ET能提高效率，我采用的是单位时间内发现bug率，大家是否还记得我之前的很多分享都会说这些数据。FreeStyle ET的方式是2.45bug/hour、ET主导&ST辅助的方式是1.5bug/hour、ST主导&ET辅助的方式是1.0bug/hour、普通ST方式是0.46bug/hour。数据仅供参考。
