探索式测试的相关问题的个人理解

　　首先需要声明的是，目前我对探索式测试理论和实践的理解还停留在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。数据仅供参考。

　　我之前也说过，如果仅仅把ET当做ST的补充，实践的策略不好的话，会造成一个问题，那就是ET的很多测试执行思路和之前ST做过的很多是重复的，这样不利于ET的发挥，同时在成本上是划不来的。我们这边是允许重复的，不可能做到完完全全的不重复，怎么减少这个重复度，是我们大家需要思考的一个问题，我的看法是，首先从意识上就要区别我们做的ET和ST是不一样的，测试思路和方法策略都不一样，但是结果(测试思路列表)可能会存在重复的，但不影响我们的思考的重点是什么，我们会分析和收集ET和ST在测试思维上的区别和测试集合，这些也许会帮助你找到ET设计和执行的重点;最后，多去分析传统测试设计方法和ET测试方法的区别和背景，了解到深层次的使用方法，做一些基础的积累，这个也会帮助大家减少这个重复度。

　　(3)如何避免与标准的测试流程冲突?

　　这个问题就是标准的流程问题了，对于ET在项目中如何实践，如何和标准的ST流程融合，书中都有非常详细的流程说明和注意点。这里个人就说几个看法，敢于去尝试新的想法和东西，有时候不是坏事，也许就可能看到不一样的天空呢，再有，我们可以选择一些不太重要的项目进行实践，减低风险。

　　这里我需要强调的是，无论你使用什么方式去实践ET，流程中的一些细节需要做到位，比如交叉测试的测试思路和方法，需要充分考虑自己的测试思维以及测试tips的作用。主要流程也许不会有大的区别，都需要做测试设计和测试执行，但是如何去做，会有一些细节的差别，请把这些细节做到位，再说实践后的效果，否则，很容易做到表面，没做到本质。

　　(4)如何避免只有测试精英才能执行探索式测试?

原文转自：http://blog.sina.com.cn/s/blog_6cf812be0101f0wf.html