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

什么是临时测试？

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

简单来说，假设我刚刚在设备上安装了一款新应用。我没有勾选测试步骤，而是开始四处点击。我可能会尝试输入一些奇怪的数据，以意想不到的方式使用应用，甚至故意打断它的流程。我的目标是看看这款应用如何处理 现实世界中不可预测的使用—不仅仅是理想情况。

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

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

以下视频指导你如何进行临时测试

点击 点击这里 如果视频无法访问

何时进行临时测试？

了解进行临时测试的最佳时机可以极大地提高软件质量。多年来，我认识到时机对于这种灵活且自发的测试方法至关重要。当您需要快速检查结构化测试用例可能遗漏的问题时，临时测试非常适合。让我们探讨一下临时测试最有价值的主要情况：

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

临时测试的类型

临时测试可能不遵循正式的计划，但随着时间的推移，出现了几种实用的测试风格。这些风格并非严格的分类，但它们反映了测试人员如何根据实际需求进行调整。根据我的经验，在正确的情况下使用这些方法可以更快、更有效地发现隐藏的错误。

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

这些方法各有优势。选择合适的方法取决于项目需求、团队动态以及所需的反馈速度。据我所知，结合使用这些方法可以最大限度地发挥临时测试的优势——发现脚本测试可能遗漏的问题。

临时测试的优势

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

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

临时测试的缺点

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

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

有效临时测试的最佳实践

尽管临时测试具有非正式性质，但为了最大限度地发挥其优势，请考虑以下做法：

1）良好的商业知识

测试人员应该对业务有充分的了解，并清楚地理解需求 - 对端到端业务流程的详细了解将有助于轻松发现缺陷。经验丰富的测试人员能够发现更多缺陷，因为他们更擅长猜测错误。

2）测试关键模块

应确定关键业务模块并针对其进行临时测试。应首先测试业务关键模块，以确保系统质量。

3）记录缺陷

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

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

4）配对

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

临时测试示例

临时测试是指在没有固定计划的情况下探索应用程序。我们不遵循脚本，而是依靠直觉和过往经验。我发现这种方法在尝试捕获脚本测试可能遗漏的异常或意外错误时非常有用。

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

探索性测试的比较分析

虽然临时测试和探索性测试经常被混淆，但它们表现出不同的操作参数：

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

结语

临时测试仍然是发现其他测试方法可能遗漏的隐藏错误的有效方法。它依赖于测试人员的经验、直觉和创造力。从我数十年的测试经验中，我见证了这种方法如何经常发现结构化测试所忽略的实际问题。

然而，谨慎使用临时测试至关重要。如果没有规划或记录，重复结果或分享发现可能会很困难。因此，我始终建议结合适当的笔记并使用跟踪测试内容的工具。这在自由和控制之间取得了平衡。

随着人工智能的不断发展，我相信我们将看到由机器学习支持的更智能的临时测试。这些工具可以帮助测试人员将他们的直觉集中在最需要的地方。虽然临时测试最初是一种灵活的、人为驱动的实践，但在当今的质量保证工作流程中，它正迅速变得更加可衡量和有价值。