探索性测试是一种动态且无脚本的软件测试方法，您可以根据特定的目标或任务而不是正式的脚本或一组测试步骤来测试应用程序或产品。

探索性测试对于发现应用程序中的未知风险或缺陷特别有用——尤其是从用户接受度的角度来看——并且它在很大程度上依赖于测试人员的领域知识、创造力和直觉。

执行探索性测试的最常见方法遵循基于会话的测试管理的五个阶段（也称为“SBTM 周期”）：

1. 定义测试的任务或目标
2. 创建测试章程
3. 测试的时间范围
4. 查看您的结果
5. 听取汇报

如何构建探索性测试

虽然探索性测试比传统的脚本测试更自发、适应性更强，但它是采用分步、基于时间的 SBTM 循环方法构建的。

1. 设定测试任务或目标

• 对类似软件或过去项目中最常检测到的错误进行分类（您可以按严重性和优先级对它们进行分类）。
• 识别、记录和研究错误的根本原因
• 收集屏幕截图、评论和报告等详细信息并明确问题
• 提出诸如“哪些事件导致了该问题？”之类的问题 “涉及哪些系统？” “谁参与其中？”
• 识别风险并创建测试场景来测试应用程序（应用程序测试）

2. 创建测试章程

测试章程是一份简洁的高级指南，可作为使命宣言，帮助您集中探索性测试工作并适应不断变化的条件，同时留出创造力的空间。

例如，如果您正在测试电子商务平台的 Web 应用程序登录，则测试章程可能类似于“分析主页登录菜单功能并报告潜在风险区域”或“分析 Web 应用程序的登录功能， ”或“了解拥有虚假数据的人是否仍然可以登录我们的网络应用程序。”

章程旨在帮助您保持正轨并通过监督将特定风险降至最低。 创建测试章程时，应包括以下内容：

• 会议的主要任务
• 要测试的目标领域或功能以及如何测试它们
• 涉及的风险和假设
• 预期成果或可交付成果以及用户如何使用系统
• 您将在会话期间使用哪些启发法或工具

探索性测试章程示例

例如，社交媒体应用程序的章程可能是“围绕配置文件创建进行快速攻击”或“测试组成员内部和外部的多用户评论、权限和竞争条件”。

例如，社交媒体应用程序的章程可能是“围绕配置文件创建进行快速攻击”或“测试组成员内部和外部的多用户评论、权限和竞争条件”。

通常，章程侧重于应用程序的特定部分，例如购物车、结账、登录/丢失密码流程或报告面板。 然而，他们也可以探索特定的用户旅程或新功能。 当公司发布新的浏览器或检查并了解支持浏览器或平板电脑需要什么时，通常会进行快速概述会议。

使用章程可以采用模糊的黑匣子流程，并将其转变为在此运行中管理的风险集合。

3. 测试的时间范围

时间盒是测试人员集中精力且不受干扰的测试会话。

时间盒涉及在预定时间内执行以下步骤：

• 测试人员在指定的时间内不间断地进行指定的测试
• 这通常是两名测试人员一起工作 60 到 90 分钟
• 时间范围可以根据测试进展或根据需要进行更改。 这通常意味着时间延长或减少 45 分钟

4. 检查结果

• 审查并记录您的结果
• 评估您发现的错误，并决定是否需要进行更多调查，或者是否有足够的测试证据来报告问题
• 分析覆盖区域

5. 汇报

基于会话的测试管理的一个重要部分是从进行的测试会话中学习并使测试负责。 为了从测试中学习，与其他团队成员或利益相关者一起对测试会话进行汇报是改进未来会话的好方法，确保覆盖了被测系统的所有重要方面并审查测试的有效性。

• 编译结果和输出，并将实际结果与测试章程中的预期结果进行比较。
• 识别问题和风险
• 找出改进的机会
• 清楚地记录您的结果
• 用证据和示例传达测试结果以支持您的主张。
• 决定是否需要进行更多测试。 您可以借助精心编写的测试摘要报告来完成此操作。

图片：TestRail 提供实时报告，帮助您满足合规性要求并跟踪您的探索性测试。 TestRail 还保留所有注释、屏幕截图和报告的缺陷的透明时间历史记录，因此您可以在中心位置轻松查看所有测试会话。

汇报是会议中经常被忽视的信息辅助手段，因为无论谁担任测试经理，都会对应用程序的质量和覆盖范围有一个整体的了解。 汇报反馈的示例包括对测试目标进度的评估或检测到的最重要缺陷的摘要。

探索性测试的示例

以下是现实场景中探索性测试的示例：

场景：您是一名测试人员，为一家零售公司开发基于 Web 的电子商务应用程序。

测试章程：测试结帐流程的可用性和功能。

1. 您首先要探索应用程序、访问网站并了解其主要功能，例如产品浏览、购物车管理和付款处理。
2. 要开始执行测试，您需要将商品添加到购物车并进行结账。 执行此操作时，您会注意到添加或删除商品时购物车有时无法正确更新。 您可以使用屏幕截图和描述来记录此错误。
3. 鉴于这一发现，您进行了调整并决定进一步探索购物车功能，尝试添加和删除商品的不同组合并检查一致性。
4. 您将继续记录遇到的错误并向开发团队实时报告（持续反馈），直到探索会话结束。 错误可能包括控制台中的错误消息、意外行为和可用性问题。

在此示例中，此探索性测试会话使您能够发现仅通过脚本测试无法识别的购物车问题。 它还促进了与开发团队的快速反馈循环，有助于提高软件的整体质量。

如何使用敏捷测试管理工具执行探索性测试

使用章程执行探索性测试在敏捷环境中很有帮助，因为交付时间更快。 然而，在共享电子表格中跟踪探索性测试结果可能会变得难以承受，并且可能会丢失详细信息。 在网络驱动器上的单个文档中跟踪它们可能会更糟。

在 TestRail 中，您可以将章程存储为测试用例。 然后，您可以创建一个测试运行，其中包含您决定为特定版本运行的所有不同类型的探索性测试。

图片：在TestRail中，您可以添加测试用例，选择“探索性会话”模板，添加时间估计，添加任务（探索性会话的目的），并添加目标（探索性会话的特定领域） 验证）。

测试人员可以在会话中留下对测试用例的评论，软件将收集数据并提供有关该数据的摘要报告。

对于结合脚本测试和探索性测试的简单应用程序，测试运行可能是两打脚本测试用例和四个旨在探索特定风险的章程。 下面的示例将会话记录为测试用例。

图像：通过将会话记录为测试用例，使用 TestRail 执行探索性测试。

如何使用测试管理工具报告探索性测试

只有当您为利益相关者提供准确且可操作的结果，为利益相关者提供有关如何推进其流程和产品的见解时，探索性测试才有效。 这包括强调关键发现、问题和风险，以及展示覆盖范围、质量和置信水平。

测试用例管理工具可以提供探索性测试的绝佳视图。 通过将版本之间的会话构建为“测试运行”（即版本）中的“测试用例”，任何具有访问权限的测试人员或利益相关者都可以看到已涵盖的内容和仍需要涵盖的内容。

图片：使用 TestRail 等专用测试用例管理平台作为探索性测试工具来管理、组织、跟踪和简化为探索性测试用例生成报告的过程。

查看这篇文章，了解如何使用测试用例管理工具改进探索性测试！

探索性测试常见问题解答

脚本测试与探索性测试：

脚本化测试遵循具有特定步骤的预定义测试用例，而探索性测试涉及无脚本的临时测试，测试人员直观地探索软件以发现缺陷并评估其行为。

下面的表格详细说明了脚本化测试和探索性测试之间的主要区别：

方面	脚本化测试	探索性测试
测试用例创建	预定义测试用例	无预定义测试用例
测试执行	遵循脚本化步骤	临时、无脚本
测试计划	需要详细的测试计划	不太正式的测试计划
灵活性	不太灵活	高度灵活< /td>
测试文档	广泛的文档	最少的文档
测试覆盖率	具体且有限	更广泛的测试覆盖范围
自动化测试	非常适合自动化测试	不适合自动化（需要人类的本能和好奇心）
Bug 发现	发现新问题的效率较低	有效发现隐藏问题
用例	适合重复性任务	适合新功能测试

探索性测试的类型

探索性测试是灵活的、无脚本的，并且可以根据特定的测试目标采取各种形式。 探索性测试技术的常见类型包括：

• 自由式探索性测试：测试人员在没有特定指导原则或先入为主的概念的情况下探索软件，使他们能够自由地与应用程序交互并有机地发现缺陷。
• 基于场景的探索性测试：测试人员专注于特定的用户场景或用例，探索软件在不同情况下的行为方式。 这种方法通常用于模拟现实世界的使用情况。
• 基于会话的探索性测试：测试人员将他们的探索性测试工作组织到定义的时间盒会话中。 在每次会议期间，他们都会探索软件的不同方面并记录他们的发现。
• 结对探索性测试：两名测试人员一起探索软件。 这种协作方法通常可以更有效地发现缺陷，因为测试人员可以互相交流想法。
• 临时探索性测试：这是最非正式的测试类型，测试人员只需根据自己的直觉和经验探索软件，无需任何预定义的结构或测试策略。

您选择的探索性测试类型取决于您的测试目标、软件的性质和测试团队的专业知识。 通常，结合使用测试来确保彻底覆盖和缺陷发现。

何时使用探索性测试

探索性测试在以下场景和情况下是有益的：

• 早期测试：在项目的初始阶段，当无法获得详细的测试用例时，探索性测试有助于发现问题并验证软件功能。
• 可用性测试：在评估产品的用户友好性和体验时，探索性测试可以揭示脚本测试可能遗漏的真实用户问题。
• 复杂或不熟悉的系统：在处理脚本测试可能不完整的复杂或不熟悉的系统时，探索性测试使测试人员能够有机地适应和发现缺陷。
• 快速反馈：在敏捷方法和迭代开发环境中，探索性测试为开发团队提供快速反馈，帮助他们快速做出调整。
• 自适应测试：当测试需要适应不断变化的需求时，探索性测试更加灵活，可以有效地应对不断变化的情况。
• 非功能测试：对于性能、安全性和可靠性等非功能属性，探索性测试可以模拟真实的使用场景来识别漏洞和瓶颈。
• 新功能测试：为了测试新功能或最近实现的功能，探索性测试可以发现集成问题和意外交互。

当灵活性、适应性和发现意外问题的能力对于有效测试至关重要时，探索性测试就很有价值。 它通过提供更全面的软件质量视图来补充脚本测试。

敏捷探索性测试的优势

探索性测试在敏捷开发环境中具有多种优势：

• 灵活性和适应性：敏捷开发的特点是不断变化的需求和频繁的迭代。 探索性测试的无脚本性质使测试人员能够快速适应这些变化，使其非常适合敏捷团队。
• 快速、持续的反馈：探索性测试为敏捷团队提供即时反馈，使他们能够在开发周期的早期发现问题。 这有助于快速解决错误并持续改进。
• 满足用户需求：敏捷开发通常旨在提供满足实际用户需求并为最终用户提供价值的软件。 探索性测试允许测试人员模拟实际使用场景，发现脚本测试可能遗漏的可用性和功能问题。
• 增强创造力：测试人员可以利用他们的创造力和直觉从脚本测试用例可能无法涵盖的边缘案例中发现缺陷。 他们可以像最终用户一样思考，识别潜在的痛点和可用性问题。
• 提高测试覆盖率的潜力：探索性测试可以提供全面的测试覆盖率，因为预定义的测试脚本不会绑定测试人员。 他们可以探索各种路径和交互，确保更广泛的测试场景。
• 早期验证：敏捷团队可以在用户故事和功能实施后立即使用探索性测试来验证它们，从而降低多次迭代中累积缺陷的风险。
• 风险缓解：敏捷项目通常时间紧迫。 探索性测试有助于及早识别高风险区域，使团队能够及时分配资源并解决关键问题。

探索性测试通过提供跟上敏捷开发生命周期所需的灵活性、适应性和快速反馈来补充敏捷开发中的脚本测试。 它帮助敏捷团队交付满足不断变化的需求和用户期望的高质量软件。

敏捷探索性测试的挑战

虽然探索性测试在敏捷开发中提供了多种优势，但它也带来了敏捷团队应该意识到并解决的一些挑战：

• 缺乏文档：探索性测试的文档记录通常比脚本化测试少，这可能会导致可追溯性降低，并最终导致随着时间的推移，重现和跟踪问题变得困难。
• 一致性：探索性测试的无脚本性质可能会导致测试工作的不一致。

探索性测试在很大程度上依赖于判断和直觉。 不同的探索性测试人员对于关键缺陷或可用性问题的构成可能有不同的观点，从而导致主观评估。

• 潜在的覆盖问题：如果没有预定义的测试用例，测试人员可能会错过重要的测试场景或忽视特定的需求，特别是如果他们不是经验丰富的测试人员或不了解项目范围的话。
• 可扩展性：随着项目规模的扩大，在多个团队和迭代中保持一致的探索性测试实践可能会变得具有挑战性。

探索性测试最佳实践

虽然这些最佳实践提供了指导，但探索性测试是一种动态且灵活的方法，您应该对其进行调整以满足项目和组织的特定需求。 以下是进行探索性测试的一些一般最佳实践：

• 定义明确的使命：首先要清楚地了解您想要通过探索性测试实现的目标。 定义测试目的和目标来指导您的测试工作。
• 了解应用程序：测试人员应了解应用程序的用途、功能和用户期望。 熟悉该领域也很有好处。
• 使用章程：使用测试章程或任务来指导您的探索性测试会话。 章程定义了您打算探索的内容，帮助测试人员在保持灵活性的同时保持专注。
• 时间框：使用时间框限制每个探索性测试会话的持续时间。 这有助于保持专注、防止过度测试并确保测试资源的有效利用。
• 文档：尽管探索性测试不太依赖文档，但在测试过程中记录您的发现还是很重要的。 这包括记录测试覆盖率、风险、测试执行以及系统上的任何疑问和问题。
• 关注风险：根据风险确定测试工作的优先级。 首先探索高风险领域和潜在瓶颈，及早发现关键缺陷。
• 反馈循环：与开发团队保持反馈循环。 及时报告缺陷并参与讨论以澄清问题并促进更快的解决。
• 审核：每次探索性测试结束后，审核您的发现并反思哪些内容效果良好以及哪些内容可以改进。 使用此反馈来完善您的测试方法。
• 测试多种格式：如果适用，请在各种平台、设备和浏览器上探索该软件，以确定兼容性问题。
• 报告：提供关于您的探索性测试工作的清晰简明的报告，突出显示重要的发现、问题和改进建议。