常被人问到各种探索测试的问题， 我总是不断在重复。因此借一次回答10个问题的机会，把自己的答复都固化下来， 积累在自己的技术博客中， 希望能减少重复回答的次数。
1、探索性测试能解决什么样的问题？不能解决什么类型的问题？
——解决快速发现功能级bug的问题；不能系统的解决性能测试、稳定性测试的问题。
2、一个产品线如何确定是否适合这种方法？如何将探索性测试方法与具体的产品结合起来？
――所有产品都适合应用，只是ET所在投入比例不同（我在硬件驱动软件测试、Linux文件系统测试、windows客户端、web应用都应用过）；
――方法与产品结合的办法是：关注我的ET TOPN方法，这是测试界的数据分析与数据挖掘
3、探索性测试方法的落实？如何培训并运用到项目中？如何让测试人员在项目中将这些方法运行起来，或者说将方法与具体的case（涉及到业务及功能点）对应起来？
――借助脑图工具把此次测试任务的测试对象画于中心位置，然后把ET的方法作为第一层节点，在每个ET方法后面延伸第二层节点（由ET方法启发出来的测试场景）
4、case是怎样的管理粒度？如何维护？
――探索测试的用例大多不适合回归（成本很大），只有部分最有价值的用例适合抽取回归。
――探索测试用例继承性的问题通过脑图积累，每次探索测试都是在前一次脑图的基础上叠加增长（所有测试场景的维护管理：最高层是测试对象、然后是测试方法、最后是测试场景）
5、怎样衡量探索性测试方法的成果？包括阶段性的结果？
――初期学习衡量的方式就是：单位时间内投入测试人时发现的bug数（提升测试效率）；在测试用例设计阶段用探索测试方法补充的测试用例发现的bug数占总用例发现bug（提升用例数）； 在用例执行后补充进行探索测试发现的bug数（提升测试质量）
――后期熟练后：达到代码覆盖率目标的测试时间（测试效率）；用户发现bug数（测试质量）；支持项目的测试周期（测试设计时间＋测试执行时间）缩短。
6、探索性测试有哪些工具支持？有没有可能自动化回归？
――大部分探索测试场景不需要回归。探索测试更多是测试设计的武器。
――脑图工具是目前最好的工具。
7、探索性测试的测试方法是否必需通过bug分析选取，这些方法一般多久更新一次，更新的变化很大怎么办？有通过的或者好用的必选方法吗？
―――必须要通过bug分析选取；如果没有bug，可以参考我所推荐的测试方法分类；
――变化很大没有影响，说明要么产品形态和实现发生很大变化、要么团队的人员资源发生了变化。这正是探索测试可以快速适配变化的优势所在。
8、做ET测试时如何做到覆盖所有的用户场景？通过方法来到达的吗？那选择方法是否很关键？
――所有的用户场景无法做到，这是共产主义社会。但能先做到尽可能先覆盖到大部分的用户行为模式（很多ET方法就是用户行为模式的抽象与集成）。
―――选择方法非常关键，决定影响你ET的效率和质量（能否覆盖到你产品当前的主要风险方向）。
9、流程上的问题：补充性探索性测试是否可以不做漫游测试，补充性探索性测试测试设计是否不是必需用脑图，那还是否能达到ET的目标？
――漫游测试 是ET在预测试和功能基本测试时的方法。
――所有探索测试 都必须事先进行计划（探索测试设计脑图就是计划），没有计划就可能倒退回自由测试，无法积累、无法技术管理、方向错误、降低效率。
10、探索性测试一般占项目测试人力的多少比例？如何平衡投入产出比？
――初期部分同事掌握和实施探索测试、熟练后成为团队内部教练、然后逐步全民掌握和应用探索测试。
版权声明：本文出自 架构师Jack 的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。