技术文章

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

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

执行探索性测试的最常见方法遵循基于会话的测试管理的五个阶段（也称为“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 等专用测试用例管理平台作为探索性测试工具来管理、组织、跟踪和简化为探索性测试用例生成报告的过程。

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

探索性测试常见问题解答

脚本测试与探索性测试：

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

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

探索性测试的类型

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

• 自由式探索性测试：测试人员在没有特定指南或先入为主的概念的情况下探索软件，使他们能够自由地与应用程序交互并有机地发现缺陷。

• 基于场景的探索性测试：测试人员专注于特定的用户场景或用例，探索软件在不同情况下的行为方式。这种方法通常用于模拟现实世界的使用情况。

• 基于会话的探索性测试：测试人员将他们的探索性测试工作组织到定义的时间盒会话中。在每次会议期间，他们都会探索软件的不同方面并记录他们的发现。

• 结对探索性测试：两名测试人员一起探索软件。这种协作方法通常可以更有效地发现缺陷，因为测试人员可以互相交流想法。

• 临时探索性测试：这是最非正式的测试类型，测试人员只需根据自己的直觉和经验探索软件，无需任何预定义的结构或测试策略。

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

何时使用探索性测试

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

• 早期测试：在项目的初始阶段，当详细的测试用例不可用时，探索性测试有助于发现问题并验证软件功能。

• 可用性测试：在评估产品的用户友好性和体验时，探索性测试可以揭示脚本测试可能遗漏的真实用户问题。

• 复杂或不熟悉的系统：在处理脚本测试可能不完整的复杂或不熟悉的系统时，探索性测试允许测试人员有机地适应和发现缺陷。

• 快速反馈：在敏捷方法和迭代开发环境中，探索性测试为开发团队提供快速反馈，帮助他们做出快速调整。

• 适应性测试：当测试需要适应不断变化的需求时，探索性测试更加灵活，可以有效地应对不断变化的情况。

• 非功能测试：对于性能、安全性和可靠性等非功能属性，探索性测试可以模拟真实的使用场景来识别漏洞和瓶颈。

• 新功能测试：为了测试新的或最近实现的功能，探索性测试可以发现集成问题和意外的交互。

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

敏捷探索性测试的优势

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

• 灵活性和适应性：敏捷开发的特点是需求不断变化、迭代频繁。探索性测试的无脚本性质使测试人员能够快速适应这些变化，使其非常适合敏捷团队。

• 快速、持续的反馈：探索性测试为敏捷团队提供即时反馈，使他们能够在开发周期的早期发现问题。这有助于快速解决错误和持续改进。

• 满足用户需求：敏捷开发通常旨在提供满足实际用户需求并为最终用户提供价值的软件。探索性测试允许测试人员模拟实际使用场景，发现脚本测试可能遗漏的可用性和功能问题。

• 增加创造力：测试人员可以利用他们的创造力和直觉来发现脚本测试用例可能无法覆盖的边缘情况中的缺陷。他们可以像最终用户一样思考，识别潜在的痛点和可用性问题。

• 增加测试覆盖率的潜力：探索性测试可以提供全面的测试覆盖率，因为预定义的测试脚本不会绑定测试人员。他们可以探索各种路径和交互，确保更广泛的测试场景。

• 早期验证：敏捷团队可以在用户故事和功能实施后立即使用探索性测试来验证它们，从而降低多次迭代中累积缺陷的风险。

• 风险缓解：敏捷项目通常时间紧迫。探索性测试可以帮助及早识别高风险区域，使团队能够及时分配资源并解决关键问题。

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

敏捷探索性测试的挑战

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

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

• 一致性：探索性测试的无脚本性质可能会导致测试工作的不一致。 

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

• 潜在的覆盖问题：如果没有预定义的测试用例，测试人员可能会错过重要的测试场景或忽视特定的需求，特别是如果他们不是经验丰富的测试人员或不了解项目范围的话。

• 可扩展性：随着项目规模的扩大，在多个团队和迭代中保持一致的探索性测试实践可能会变得具有挑战性。

探索性测试最佳实践

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

• 定义明确的使命：首先要清楚地了解您想要通过探索性测试实现的目标。定义测试目的和目标来指导您的测试工作。

• 了解应用程序：测试人员应该了解应用程序的目的、功能和用户期望。熟悉该领域也是有益的。

• 使用章程：使用测试章程或任务来指导您的探索性测试会话。章程定义了您打算探索的内容，帮助测试人员保持专注，同时允许灵活性。

• 时间盒：使用时间盒限制每个探索性测试会话的持续时间。这有助于保持专注、防止过度测试并确保测试资源的有效利用。

• 文档：尽管探索性测试不太依赖文档，但在测试过程中记录您的发现还是很重要的。这包括记录测试覆盖范围、风险、测试执行以及系统上的任何问题。

• 关注风险：根据风险确定测试工作的优先级。首先探索高风险区域和潜在瓶颈，及早发现关键缺陷。

• 反馈循环：与开发团队保持反馈循环。及时报告缺陷并参与讨论以澄清问题并促进更快的解决。

• 回顾：每次探索性测试结束后，回顾你的发现并反思哪些效果好，哪些可以改进。使用此反馈来完善您的测试方法。

• 测试多种格式：如果适用，请在各种平台、设备和浏览器上探索该软件，以确定兼容性问题。

• 报告：提供关于您的探索性测试工作的清晰简明的报告，突出显示重要的发现、问题和改进建议。