探索性测试的范围探索性测试是一种黑盒测试吗？显然，探索性测试不区分黑盒和白盒，可以用在任何测试中，但它需要我们更好地理解产品，了解产品内部的设计细节，才能发现一些更深层次的东西和隐藏的问题。探索性测试可以应用于硬件吗？从理论上讲，纯硬件很难做探索性测试，脚本测试更难。一般我们在硬件上侧重于线号校验和硬件老化测试。可以探索性地测试软件。在纯硬件上进行某个领域的探索性测试，如果造成损坏，结果往往是不可逆的。探索性测试如何融入用户体验测试？探索性测试是一种测试方式，并不局限于任何一种测试。将用户体验测试融入探索性测试就足够了。以ET（探索性测试）为主导，ST（基于测试用例的测试）为辅助的探索性测试方式适合什么类型的项目？我们牢牢把握探索性测试更灵活、适应性强、不需要复杂的测试用例、鼓励测试人员探索难以发现的问题等，因此可以得出结论，ET主导和ST辅助的探索性测试测试方法适用于：使用MVP模型的敏捷项目。在Bug优先级定义中，出现的Bug不会有很高的优先级，项目本身属于中等类型的项目（因为特别高优先级的Bug往往需要记录在标准化测试用例中以供审查）。核心模块边缘的项目。探索性测试的价值探索性测试能为团队提供什么帮助？探索性测试最大的特点就是机动性。通过探索性测试获得的结果以及对检测到的缺陷密度的分析可以帮助调整团队的测试计划、测试策略和测试设计，并且探索性测试可以分布在整个软件生命周期中。探索性测试的价值高吗？目前很多企业还没有实施呢？很多时候，在做探索性测试之后，会得到一些额外的测试用例。当你想获得高价值的时候，那么它的价值就非常高。高的。为什么公司没有实施？因为有些公司对软件质量要求不高。当一个软件的质量关系到重大利益，对质量的要求也很高时，那么探索性测试就非常有价值，公司自然会去推行。.如何在合理的时间内进行有效的探索性测试，并衡量探索性测试的结果是否合理充分？无论是敏捷模型还是瀑布模型，都会有测试轮次的概念，第一轮会跑完整个环节的情况，第二轮会做BUG验证，第三轮会是用于全链接案例的回归；第一轮测试往往会用到交叉测试的思路，也就是探索性测试的思路。做探索性测试，可控到什么程度；还有一个判断标准是不是在独立的Session中，是否关注过很多探索性测试的执行。执行完型式测试后，你在这个会话中测试了很多东西。就算没发现bug也没关系，因为你知道自己测试了什么，哪些部分是正确的，然后按照自己的计划停止。停止也是可以的，所以它进行到什么程度就和我们的测试模式有关。衡量探索性测试好坏，可以衡量bug和问题的输出，但很难证明探索性测试的价值。从bug输出来看，不同实践做的探索性测试输出的bug数量是不一样的。例如，使用ET-led、ST-led、FreeStyleET或pair-testingBugBash得到的bug数是不同的；Session完成后，将Bug数和Issues数合并。Quantity,TestNote,TestData可以体现一个值。探索性测试的先决条件探索性测试对测试工程师的能力有哪些特殊要求？探索性测试也应该分阶段进行。这里的阶段包括熟悉软件系统业务流程和数据流程的不同阶段，以及测试设计能力的不同阶段，所以不要想着自己要多完美，做好探索即可测试你现在的能力，每个阶段都可以做探索性测试。探索性测试方法论更依赖经验，是不是不适合新手？除了ET-led和ST-assisted不适合新人，新人可以尝试学习其他方法，只要不把自己当成新人，这些方法都可以练习。如何做探索性测试项目工期紧，如何保证足够的探索性测试？如果你不能抽出60-120分钟的时间在瀑布模型中进行探索性测试，那你就做不到。你必须抽出一些时间。探索性测试，一个功能至少要进行两到三个探索性测试，并且要探索功能与功能的组合；敏捷模式基本上是在敏捷开发的每个阶段都完成的，每个阶段也会有一个卡实现。如何在大量回归测试的过程中进行探索性测试？第一种是先使用交叉法，第二种是使用PITesting（变异测试），可以缩小测试范围，准确测试应该测试的地方。三是实在是没有时间，那就用BugBash，借用更多人的力量，不仅覆盖回归测试的范围，还要找到一些测试范围之外的场景。探索性测试的区别和优势探索性测试和传统测试有什么区别？书上说，从结果来看，传统测试流程和方法每小时发现的bug数量约为0.2-0.3个，ETassistedAndSTleading约为每小时1.0个，STassisted和ETleading约为1.5个，FeelStyle是关于3个bug，其次，探索性测试是看系统是否能做超出既定预期的事情，以及做超出预期的事情后系统的后续反应。探索性测试和随机测试有什么区别，探索性测试有什么优势？Adhoc测试可以理解为错误猜测法的升级版。随机测试没有这样的重点目的。探索性测试具有明确的重点，可以发现bug的核心影响。它比adhoc大。探索性测试以发现bug为目的，更注重UT。探索性测试和混沌工程之间有什么联系和区别？没有联系，思路不同；混沌工程的核心是故障注入，子系统级、应用级、中间关键级、断网、超时等破坏性测试的故障注入，有日志级和代码级的故障注入；在做故障注入的时候，你已经知道这个区域会出现故障，你也已经知道这里会设计什么场景。探索性测试不清楚情况。继续探索以了解可能存在的位置。问题。探索性测试的内容扩展探索性测试是否与我们的测试覆盖率相矛盾？一点都不矛盾。在计算测试覆盖率时，我们必须有一个明确的分母来计算它。如果探索性测试是为了保证每一个功能都被测试到，那么我们的测试覆盖率就是100%；如果探索性测试的分母是整个测试用例集，则无法计算测试覆盖率。QA记录和管理活文件是否需要更多时间？“活着”这个词要看你怎么理解了。开发者的单元测试和swagger文档就是典型的例子。对于QA来说，活文档就是对自动化测试代码的改动，改动其实和修改传统测试用例是一样的。花时间维护活文档的好处是，它会让活文档与产品代码保持一致，及时提醒你哪些文档有问题需要修改，所以花时间去管理是必须的。非常有意义。如何提高测试设计能力？首先要了解测试的基本理论，还要加深对被测对象的理解，然后熟悉相关测试类型所需的测试知识和工具。探索性测试的发展探索性测试会不会越来越重要，它未来的发展趋势是什么？国外是稳扎稳打的趋势，经常可以在Facebook上看到很多探索性测试和一些新奇的东西，国内的讨论逐渐被自动化测试的声音淹没。这种趋势与大环境有关。事实上，很多公司虽然说是在做敏捷，但其实并不是真正的敏捷。探索性测试很差，他们甚至不知道该怎么做。实施探索性测试，真正敏捷的公司和项目会觉得探索性测试真的很重要，回报往往在敏捷项目上体现得最清楚（感觉作者也认可敏捷）。当我把这些问题总结出来，再和前辈们交流的时候，我有了一些感悟。实际上，测试的本质是对软件系统各个变量的单变量验证和各种变量的组合验证。假设整个软件系统中所有变量的组合结果是如图所示的空间几何，已知变量组合结果空间为S（可以理解为我们期望软件系统能做什么和不能做什么，通常AC写在故事卡上），则未知变量空间区域为S'（可以理解为软件系统是否能做更多意想不到的事情，做更多不能做的事情的反应），则S'是我们想要探索的领域。在我们平时的测试过程中，页面上的一个按钮和一个选择框其实就是一个变量。我们会验证按钮和选择框各自的功能，也会一起验证选择框和按钮的组合功能，然后在这些变量方面，我们可能会有探索其他场景的想法；API的各种参数的验证也是如此。最后，如果你想对探索性测试有更深入的了解，可以阅读《探索式测试实践之路》和《Explore It!: Reduce Risk and Increase》这本书。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
