什么是临时测试？类型与示例

什么是临时测试？

临时测试 是一个意念波· 自发 和 柔软 这是一种无需遵循任何既定计划或文档即可测试软件的方法。无需提前准备测试用例，而是直接深入研究应用程序。术语 “到这个” 意思是“为了特定目的”或者“无计划的”，真实地体现了这种测试风格。

简单来说，假设我刚在设备上安装了一个新应用。我没有按照步骤清单逐项进行测试，而是直接点击屏幕。ping 我可能会尝试输入一些奇怪的数据，以意想不到的方式使用这款应用，甚至故意破坏它的运行流程。我的目的是看看这款应用是如何处理的。 现实世界中不可预测的使用—不仅仅是理想情况。

临时测试之所以脱颖而出，是因为它常常能发现正式测试可能忽略的问题。通过创造性地思考并设身处地地为不同用户着想，我能够发现…… 虫子 和 可用性问题 其他人可能会忽略这一点。这种方法依赖于测试人员的 直觉、经验、 深入了解应用程序至关重要。尤其是在时间紧迫或文档有限的情况下，这是及早发现错误的绝佳方法。

虽然临时测试看似非正式，但其真正的价值在于测试人员的专业知识和能力。 创造性思考它通常被视为一种 黑盒测试 因为它侧重于软件的表面行为，而不是其底层结构。与结构化测试结合使用，临时测试有助于确保更可靠的测试结果。 可靠 和 用户友好的产品.

以下视频将指导您如何进行临时测试。

点击 开始 如果视频无法访问

何时进行临时测试？

了解执行临时测试的最佳时机对软件质量至关重要。多年来，我发现对于这种灵活且随机的测试方法而言，时机至关重要。当您需要快速检查结构化测试用例可能遗漏的问题时，临时测试就显得尤为重要。让我们来探讨一下临时测试最有价值的几种主要场景：

• 早期开发： 当正式测试用例尚未准备好时，这种方法非常有效。您可以在创建正式测试计划之前快速发现新功能中的错误。
• 正式测试开始前： 使用临时测试进行快速扫描，确保基本功能正常运行。这有助于避免在正式测试周期中浪费时间在失败的构建版本上。
• 完成正式测试后： 即使执行了所有测试用例，仍然可能遗漏一些缺陷。临时测试可以帮助您查找结构化测试可能忽略的缺陷，特别是那些超出文档要求范围的缺陷。
• 当你时间不够时： 有时候，时间根本不够进行一整轮测试。在这种情况下，经验丰富的测试人员可以使用临时测试快速发现最重要的问题。
• 深入探索某个功能： 如果您想真正了解软件特定部分的运行方式，临时测试允许您自由地进行调查，而无需遵循脚本。
• 对于可用性检查： 你可以站在用户的角度，看看软件中是否存在令人困惑或沮丧的地方。这有助于改善整体体验。
• Beta 测试期间： 许多 beta 测试人员在实际使用软件时，自然会采用临时测试方法，从而发现只有在实际使用中才会出现的问题。

临时测试的类型

临时测试可能没有正式的计划，但随着时间的推移，已经涌现出几种实用的方法。这些并非严格的分类，而是反映了测试人员如何根据实际需求进行调整。以我的经验来看，在合适的场景下使用这些方法可以更快、更有效地发现隐藏的缺陷。

• Buddy 测试： 这种方法将开发人员和测试人员配对，并肩工作。开发人员解释该功能的构建过程。与此同时，测试人员从用户的角度进行探索。这种编码知识和测试技能的结合有助于及早发现问题，通常是在编码结束后立即发现。
• 配对测试： 两名测试人员在同一设备上协同工作。其中一人负责探索应用，另一人则提供不同的输入建议并观察其行为。他们轮流工作并分享笔记。这种实时协作能够激发创造力，并且通常比单独测试能发现更多缺陷。
• 猴子测试: 这是最难以预测的方法。测试人员或工具会随机点击、输入或在应用程序中导航。目标是不断挑战系统极限，直到它崩溃。虽然这看起来可能很混乱，但却是发现崩溃或薄弱环节的绝佳方法。不过请记住，重现通过这种方式发现的错误可能很棘手。

每种方法都有其优势。选择合适的方法取决于项目需求、团队动态以及反馈所需的速度。就我观察而言，将这些方法结合起来可以最大限度地发挥即席测试的优势——发现脚本测试可能遗漏的问题。

临时测试的优势

临时测试具有结构化测试常常忽略的独特价值。它灵活、快速，并且依赖于测试人员的直觉而非固定的流程。根据我的经验，这种测试方式是形式化测试方法的有力补充，尤其是在快速发展的开发环境中。

• 发现隐藏的错误： 它不受预定义测试用例的限制，可以探索错误经常隐藏的意外路径。
• 快速简单的设置： 无需详细的测试计划或文档，这在需要快速反馈时节省了大量时间。
• 时间紧迫时具有成本效益： 非常适合资源有限但仍需要快速找到严重错误的情况。
• 真实用户洞察： 由于测试人员的行为类似于最终用户，因此测试过程可以突出显示正式测试可能遗漏的可用性缺陷。
• 利用测试人员的直觉： 熟练的测试人员可以依靠他们的经验来发现工具或脚本可能忽略的细微缺陷。
• 增强正式测试： 它并不能取代正式测试，而是通过扩大测试覆盖范围来增强可靠性。
• 即时反馈循环： 在敏捷设置中尤其有用，因为必须快速发现并修复错误才能保持事物正常运转。

临时测试的缺点

临时测试存在一些局限性，这些局限性会影响测试质量和产品结果。下面我将根据我的测试经验详细解释这些局限性。

• 难以重现的错误： 由于缺乏结构化的方法或分步记录，重现问题可能很棘手。这使得开发人员修复问题更加困难。
• 依赖于测试人员的经验： 这种方法的成功很大程度上取决于测试人员对产品的熟练程度或熟悉程度。新手可能会错过经验丰富的测试人员能够发现的重要缺陷。
• 没有完整的测试覆盖： 临时测试没有既定的流程。这意味着一些重要领域可能未经测试，直到为时已晚才有人注意到。
• 缺乏 Tracking 以及指标： 如果没有测试用例或日志，就很难衡量进度、识别模式或了解测试内容。这会降低团队和利益相关者的透明度。
• 不适合高风险应用： 医疗保健、银行或安全关键型系统等项目需要详尽的文档记录和验证。仅靠临时测试无法满足这些严格的标准。
• 缺乏专注力会浪费时间： 如果测试人员没有至少一些非正式的目标，他们最终可能会花费太多时间探索优先级较低的功能，从而减慢整个测试周期。

有效临时测试的最佳实践

尽管临时测试性质非正式，但为了最大限度地发挥其优势，请考虑以下做法，这些做法可以弥合非结构化探索和可靠缺陷检测之间的差距。 trac国王：

1）良好的商业知识

测试人员应具备扎实的业务知识和对需求的清晰理解。深入了解端到端的业务流程有助于轻松发现缺陷。经验丰富的测试人员能够发现更多缺陷，因为他们更擅长猜测错误原因。

2）测试关键模块

应识别关键业务模块并针对这些模块进行专项测试。应首先测试业务关键模块，以确保系统质量。

3）记录缺陷

所有缺陷都需要记录或写在记事本中。缺陷必须分配给开发人员进行修复。对于每个有效的缺陷，都必须编写相应的测试用例，并将其添加到计划的测试用例中。

这些 缺陷 应该将调查结果作为经验教训，并在我们规划测试用例时将其反映在我们的下一个系统中。

4）配对

如所见 Buddy 或结对测试，协作可以带来不同的视角并改善缺陷检测。

临时测试示例

即兴测试的核心在于不预设固定计划地探索应用程序。它不遵循脚本，而是依靠直觉和过往经验。我发现这种方法在发现脚本测试可能遗漏的异常或意外错误时非常有效。

• 登录功能压力测试： 测试人员反复使用不同的凭证（有些凭证不正确）登录和退出，以查看系统是否崩溃或做出异常反应。
• 不寻常的用户输入： 输入符号、超长字符串或意外的文件格式，检查系统响应情况。这有助于了解输入验证的处理效果。
• 随机点击和导航： 测试人员随机点击应用程序中的按钮——跳转ping 在页面之间，以不按顺序触发按钮——以发现意外行为。
• 文件上传混乱： 上传不受支持的文件类型或损坏的文件以测试上传功能的稳健性。
• 中断测试： 中断一个进程（例如在保存过程中关闭一个标签或切断互联网连接）以查看系统如何恢复。

探索性测试的比较分析

虽然经常被混淆，但临时测试和探索性测试具有不同的操作参数：

特点	临时测试	探索性测试
文件记录	仅在执行后	连续录音
计划	没有	轻型包机
会话结构	完全非结构化	时间限制迭代
缺陷再现	33% 可重复性	78% 可重复性
自动化整合	适用性有限	42% 的工具整合

常见问题