探索式测试的范围
探索式测试是不是就是一种黑盒的测试?显然探索式测试不区分黑盒还是白盒，可以用在任何一个测试里面，但是它需要我们更加理解产品，去产品内部理解产品的设计细节，才能发现一些更深层次的、隐蔽的问题。
探索式测试能不能用于硬件上?理论上来说，纯硬件是很难做探索式测试的，脚本测试都很难，硬件一般我们关注的是行数验证，硬件的老化测试，但是硬件上的软件是可以用探索式测试的。对纯硬件进行某一领域的探索式测试，如果造成了损坏，结果往往是不可逆的。
探索式测试怎么融入用户体验测试?探索式测试是一种 Test Style，不会局限于哪一种测试，把用户体验测试融入探索式测试就可以。
ET(探索式测试)主导和ST(基于测试用例的测试方法)辅助的探索式测试方法适合什么类型的项目?我们牢牢抓住探索式测试更灵活、适应性强、不需要编制繁杂的测试用例、鼓励测试人员探索出难以发现的问题等特点，所以就能得出ET主导和ST辅助的探索式测试方法适用于：
- 采用MVP模式的敏捷项目。
- 在Bug优先级定义中，出现的Bug不会是很高优先级且项目本身是中等类型的项目(因为特别高优先级的Bug往往是需要记录在规范的测试用例中以便审查的)。
- 离核心模块比较边缘的项目。
探索式测试的价值
探索式测试能够提供给团队什么帮助?探索式测试最大的特点就是机动性，通过探索式测试得出的结果，分析探索出来的缺陷密度，可以帮助调整团队的测试计划、测试策略以及测试设计，并且探索式测试可以分配到整个软件生命周期中。
做探索式测试的价值高吗，目前很多公司没有推行?有很多时候，在做了探索式测试之后，才会得到一些额外的测试用例，想要得到价值高的时候，那么它的价值就是很高的。为什么公司没有实行，因为有些公司对软件质量的要求不高，当一个软件的质量关乎重大利益的时候，对质量要求也很高的时候，那么探索式测试就很有价值，公司自然也会推行。
怎么在合理的时间内，进行有效的探索性测试，并且度量探索性测试的结果是合理并且是足够的?不管是敏捷模型还是瀑布模型，会有测试轮次的概念，第一轮会跑全链路的 Case，第二轮做 Bug 验证，第三轮会做全链路 Case 的回归;第一轮测试往往会用交叉测试的思路，这就是探索式测试的思路，在计划内、时间内去做探索性测试，做到什么样的程度是可控的;还有一个判断标准是，有没有在一个独立的 Session 内，到底有没有关注到很多探索式测试的执行，你关注到在探索式测试执行中后，你在这个 Session 内测了很多东西，即使没有发现 Bug 也没有关系，因为你知道自己测了什么，哪部分是没有问题的，然后根据自己的计划想停止就停止，不停止也可以，所以进行到哪种程度是和我们的测试模式是有关系的。
度量探索式测试做得好还是不好，Bug 和问题的产出可以来度量，但很难证明探索式测试的价值，从 Bug 产出的角度来看，不同实践方式做的探索式测试产出的 Bug 数量是不一样的，例如用ET主导、ST主导、Free Style的 ET，还是结对测试 BugBash 得出的 Bug 产出是不一样的;一个 Session 做完了，综合起来看 Bug 的数量、Issue 的数量，Test Note，Test Data 可以反映出一个价值。
探索式测试的前提条件
探索式测试对测试工程师的能力有什么特别的要求?探索式测试也要分阶段，这里的阶段包括对软件系统业务流以及数据流熟悉程度的不同阶段，还有测试设计能力的不同阶段，所以不要想到自己要做多么完美，把自己当前能力能做的探索式测试做好就行，每个阶段都可以做探索式测试。
探索式测试方法论比较依赖经验，是不是不适合新人?除了ET主导和ST辅助不适合新人以外，其它的方式新人都可以尝试学习，只要不把自己当新人，这些方法都可以去实践。
探索式测试怎么做
项目安排紧张，怎么保障足够的探索式测试?瀑布模型内做探索性测试，60-120分钟的时间都抽不出来，那就没办法做了，肯定是要抽一定时间来做探索式测试的，一个功能至少要进行两到三次探索式测试，还要进行功能与功能间结合式的探索;敏捷模式基本在敏捷开发中每个 Stage 都会做，在一张卡的各个阶段也会进行实施。
如何在大量回归测试过程中，进行探索式测试?第一是先用交叉方式，第二用 PI Testing(突变测试)，可以缩小测试的范围，精确的测试该测的地方，第三实在没有时间，那就用 Bug Bash 借助更多人的力量，不仅能 cover回归测试的范围，还可以找到一些测试范围以外的场景 case。
探索式测试的区别和优势
探索式测试和传统测试的区别是什么?依书中所言，从结果来看的话，传统测试流程和方法每小时发现 Bug 的数大概在0.2-0.3个，ET辅助和ST主导每小时大概在1.0左右，ST辅助和ET主导大概在1.5左右，Feel Style大概3个 Bug，其次探索式测试为了看系统是否能做超出既定期望的事，以及做了超出期望的事之后系统所做出的反应。
探索式测试和随机测试的区别以及探索式测试有什么优势?adhoc测试可以理解为错误猜测方法的升级版，随机测试没有那么聚焦的目的，探索式测试有明确的聚焦，发现 Bug 核心的影响力要比 adhoc 更大，探索式测试是抱着发现 Bug 的目的去做的，更重视UT。
探索式测试和混沌工程之间有什么联系和差异?没有关联，思路不同;混沌工程的核心就是故障注入，故障注入分系统层面、应用层面、中间键层面，断网，超时等一些破坏性测试，有日志级别的和代码级别的故障注入;做故障注入已经是知道这一块会出现故障，已经知道这里会设计怎样场景，探索式测试是不清楚情况，不断去探索，才会知道哪里可能有问题。
探索式测试的内容延伸
探索式测试跟我们的测试覆盖率是不是矛盾的?根本不矛盾，算测试覆盖率的时候我们要有明确的分母才能算出，如果探索式测试是保证每个功能都测试到了，那么我们的测试覆盖率就是100%;如果探索式测试的分母是整个测试用例集，是无法统计出测试覆盖率的。
活文档会花费 QA 较多时间来记录和管理吗?这个“活”字看大家怎么去理解，开发们的单元测试和 swagger 文档就是典型的例子，对于 QA 来说活文档是自动化测试代码的更改，要改其实和修改传统的测试用例一样的，花时间维护活文档带来的好处是会使活文档与产品代码保持一致性，并且及时提醒哪些文档错了需要修改，所以花时间去管理是很有意义的。
如何提高测试设计能力?首先要了解测试的基本理论，还要加深了解被测对象，然后去熟悉相关的测试类型所需要的测试知识和工具。
探索式测试的发展
探索式测试会越来越重要吗，它以后发展的趋势是怎么样的?国外是一种稳中求胜的趋势，在 Facebook 上都经常能看到很多探索式测试一些新奇的讨论;国内逐渐被自动化测试的声浪盖过去了，这个趋势跟大环境有关，其实有很多公司虽然说在做敏捷，其实并不是真正的敏捷，探索式测试做得很差，甚至不知道如何实施探索式测试，真正意义上在做敏捷的公司和项目，就会觉得探索式测试是真的很重要的，得到的回报往往在敏捷项目上反映得最明显(感觉作者也很认可敏捷)。
在我把这些问题总结出来然后去和前辈们交流的时候，有一些感悟，其实测试的本质就是对软件系统各个变量的单变量验证以及各种变量的组合验证，假设整个软件系统所有变量的组合结果为如图所示的空间几何体，已知的变量组合结果空间为S(可理解为我们期望软件系统能做和不能做的事，往往是故事卡上写的 AC)，那么未知的变量空间区域为 S’(可理解为软件系统能不能做更多期望之外的事，以及做了更多不能做的事的反应)，那么 S’就是我们要探索的一个领域。
在我们平常测试过程中，页面上的一个按钮、一个选择框其实就是一个变量，我们会去验证按钮和选择框各自的功能，也会去验证选择框加上按钮一起的组合功能，然后在这些变量上我们可能会去产生探索其他场景的想法;API的各个参数验证也是相同的道理。
最后大家对探索式测试想要有更深入了解的话，可以去阅读《探索式测试实践之路》和《Explore It!: Reduce Risk and Increase》这两本书。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
