大家好，我是阿萨。今天学习下探索性测试放入历史和概念。
探索性测试是一种软件测试方法，通常被描述为同时学习、测试设计和执行。它关注于发现，并依赖于单个测试人员的指导来发现在其他测试范围内不容易覆盖的缺陷。
近年来，探索性测试的实践已经聚集了势头。测试人员和QA经理被鼓励将探索性测试作为全面测试覆盖策略的一部分。
探索性测试历史
探索性测试已经存在了一段时间，但通常被称为“特别测试”。术语“探索性测试”是由软件测试专家Cem Kaner在他的经典著作《测试计算机软件》中正式引入的。
引言现在很有名:“不管你创建了多少类型的多少测试用例，你都会用完正式计划的测试。你可以继续测试。运行您想到的新测试，而不需要花费太多时间准备或解释测试。相信自己的直觉。”
为什么使用探索性测试
今天的团队需要采用持续集成，并交付高质量数字体验的市场需求，以满足不断增长的客户期望。虽然推向市场的速度很重要，但也有价值数百万美元的bug或简单的用户体验灾难的例子是非常昂贵的。从波音(Boeing)到Instagram，有很多急于在最后期限前交付产品和低质量测试导致声誉和财务损失的例子。
大多数软件质量测试使用结构化方法。测试用例是基于已经定义的用户故事定义的，测试数据是基于定义的测试用例结构化的。测试覆盖率是使用软件工程度量来度量的，在大多数情况下，测试覆盖率在技术上是足够的。
它经常忽略的是边缘情况，这些情况是通过用户验收测试(UAT)发现的，并基于用户角色进行测试。另一方面，探索性测试本质上是随机的或非结构化的，可以揭示在结构化测试阶段未被发现的错误。
通过探索性测试，测试人员可以按照一定的顺序处理用户故事。测试人员可以注释缺陷，添加断言和语音备忘录，并动态地创建文档。这就是如何将用户描述转换为测试用例。这些信息也可以用于QA。
实际上，测试执行是在没有正式创建测试步骤的情况下实现的。然后，探索性测试工具成为自动化的先驱。它有助于将发现形式化并自动记录下来。在视觉反馈和协作测试工具的帮助下，每个人都可以参与探索性测试。这使得团队能够快速反应和适应变化——促进敏捷工作流程。
此外，测试人员可以使用自动化测试用例文档的工具将探索性测试序列转换为功能测试脚本。这加强了传统的测试过程。
通过集成诸如Jira和测试管理产品等工具，团队可以直接将记录的文档导出到测试用例。
因此，探索性测试加快了文档编制速度，促进了单元测试，并有助于创建即时反馈循环。正如上下文驱动的软件测试学校的联合创始人James Bach所说，“探索性测试鼓励实时的科学思考。”
什么时候应该使用探索性测试?
探索性测试适用于特定的测试场景，例如当某人需要快速了解产品或应用程序并提供快速反馈时。它有助于从用户的角度审查产品的质量。
在许多软件周期中，当团队没有太多时间构建测试时，就需要进行早期迭代。探索性测试在这种情况下非常有用。
在测试任务关键型应用程序时，探索性测试可确保您不会错过导致关键质量故障的边缘情况。另外，使用探索性测试来帮助单元测试过程，记录步骤，并在以后的sprint中使用这些信息进行广泛的测试。
找到新的测试场景来增强测试覆盖率是特别有用的。
何时对探索性测试说不
组织必须能够在探索性测试和脚本测试之间取得正确的平衡。探索性测试本身不能提供足够的覆盖率，团队不应该尝试它，除非他们已经达到了一些最初的里程碑。
特别是对于任何类型的规范测试或基于遵从性的测试，脚本测试是可行的方法。在基于遵从性的测试中，由于法律原因需要遵循某些检查表和命令，建议坚持使用脚本测试。这方面的一个例子是可访问性测试，其中几个法律管理测试协议，并且需要通过已定义的标准。
探索性测试对CI/CD的重要性
探索性测试向所有关键涉众开放测试，而不仅仅是训练有素的测试人员。使用探索性测试工具，可以捕获屏幕截图，记录语音备忘录，并在会议期间注释反馈。这使得传统软件测试人员以外的人员能够更快、更有效地进行审查。
探索性测试补充了QA团队现有的测试策略。它包括一系列未记录的测试会话，用于发现尚未发现的问题/bug。当与自动化测试和其他测试实践相结合时，它增加了测试覆盖率，发现了边缘用例，潜在地增加了新特性，并全面改进了软件产品。它没有结构僵化，鼓励团队内部的实验、创造和发现。
几乎即时的反馈有助于缩小测试人员和开发人员之间的差距。最重要的是，探索性测试的结果为开发团队提供了面向用户的视角和反馈。目标是补充传统的测试，以发现通常隐藏在已定义工作流背后的价值数百万美元的缺陷。
