回答。

测试用例是事先准备好的场景，详细列出了步骤、输入和预期结果。**探索性测试（exploratory testing）**是在实践中构建的：测试人员在了解产品的过程中，利用自己的专业知识和直觉生成检查。历史上，最初主导的是测试用例，但随着系统的复杂化和手动检查量的增加，探索性测试开始补充正式的方法。

问题

仅仅盲目遵循一种测试方法会限制测试人员的创造力，并可能使产品留下未在用例中描述的bug。

解决方案

在平衡的情况下使用两种方法：测试用例用于回归和关键功能，探索性测试用于新的、还没有完全正式化的部分，以及在时间短的情况下。

关键特点：

测试用例 — 保证可重复性和可比结果
探索性测试 — 提高发现非标准和狡猾bug的机会
两种方法应当共同进行

设问。

是否可以仅使用测试用例实现100%的覆盖？

不可以。即使是最详细的用例集也无法覆盖用户的意外行为或非标准bug。

探索性测试需要提前准备吗？

是的。在自由探索产品之前，需要了解功能，学习需求，理解业务逻辑。

探索性测试后是否需要bug报告？

是的。任何发现的缺陷应与正式场景中的bug一样详细记录，否则会很难重现和修复。

常见错误和反模式

忽视其中一种方法
在探索性测试中缺乏对发现的bug的记录
在开始探索性会议前不了解产品的功能

生活实例

负面案例

团队仅通过正式的测试用例覆盖了发布。一个测试人员严格按照指示执行了它们，没有检查"相关"用例，导致在未提前考虑的特定操作顺序下，遗漏了一个bug。

优点：

快速而简单的自动化报告

缺点：

检查深度不足
缺乏灵活性

正面案例

测试人员在完成关键测试用例后，花了一个小时进行探索性测试，找到了一个只有在应用程序运行时更改设备时间时才会重现的bug。