如果您花时间进行探索性测试，您认为您会发现目前由一套手动测试发现的剩余 5% 的错误吗？经理们是否有信心在没有这些功能测试的情况下做出决策所需的测试覆盖率？

我认为没有手动功能测试套件的最大风险是覆盖率降低，因此可能会遗漏一些事情。但是，可能不需要“全套”手动回归测试来确保覆盖范围。自动化测试通常被认为是理想的替代方案，因为它们简化了回归测试并长期节省了测试时间。他们可以真正解放您的探索性手动测试人员，以便他们可以专注于最高效的测试形式。

您还可以尝试引导式探索性测试，其中给测试人员一份清单，而不是完全脚本化的手动测试，然后测试人员只需确保他们在执行探索性测试时涵盖了清单，以及他们认为值得尝试的任何其他事情。这种技术有时被称为“引导式探索性测试”。对于您的团队来说，这可能是一个很好的选择，因为听起来您手头有一些非常熟练的探索性测试人员。

“如果几乎没有发现任何缺陷，是否值得花时间编写一整套手动功能测试？”

这取决于 - 编写它们的目的是为了发现缺陷？如果是这样，那么听起来你最好把精力花在测试上。如果您正在考虑放弃它们，那么听起来您没有任何合同或政治义务来生产它们。手动功能测试套件的生产成本和维护成本往往很高，因此除非您有充分的理由来制作该文档，否则可能有更好的方式来花费您的金钱/时间。

那么是什么阻止了你？

一些常见的问题可能是：

1）我们如何看待我们的测试覆盖系统的情况？不存在我们最终都将运行相同测试的风险吗？或者，也许我们都将运行相同类型的测试，而没有人会想到测试安全性或安装？

如果您对此感到担忧，那么解决此问题的一种方法是编写一组探索性测试章程而不是测试脚本。Michael Kelly 的这篇文章很好地解释了使用章程管理测试，这是系列文章的一部分。

我也非常喜欢 Darren McMillan 关于他如何使用思维导图来计划他的测试和记录测试会话的博客文章。我自己还没有认真地为 ET 使用过思维导图，但是我看到其他探索性测试人员使用的思维导图是一种非常可爱的清晰方式来呈现所涵盖的内容，而且更容易看到仍有待测试的差距。

2) 我们如何证明我们做了什么？

你不必在测试之前写下东西，以证明你测试过它。你可以在测试的时候写下东西，然后你仍然可以对你的发现做出回应。（实际上，在测试时做笔记比以前做笔记更能反映你真正测试的内容——我观察到的大多数脚本测试人员经常“脱离脚本”，所以脚本不是一个很好的指导测试了什么。）

以下是一些关于录制 ET 会话的好资源/想法：

• http://www.quicktestingtips.com/tips/2009/11/template-for-session-notes/
• 用于记录探索性测试会话结果的 Session Tester 的替代品

这里有一份关于探索性测试的一般资源列表。

我的回答假设你相信你正在尽可能地利用探索性测试；换句话说，您不相信您可以通过探索性测试发现超过 95% 的缺陷。我认为您的问题的要点是，“为了发现其他 5% 的缺陷，是否值得进行一整套手动测试的额外工作。”

您和您的团队需要决定跳过额外的测试是否值得冒让错误漏掉的风险。在考虑风险时，请考虑可能漏掉的错误类型、这些错误的频率（即这种情况是罕见的还是常见的？）、严重性（错误发生的时间，它会有多大的危害？），以及您认为您的客户会有多宽容（例如，高科技的早期采用者可能比网上银行客户更宽容）。

除此之外，您还需要考虑客户将如何看待您的测试过程。在某些行业中，您的测试过程是私人的内部事务。在其他行业中，拥有严格遵循的记录良好的流程是获得认证的必要条件。

最后，随着您的产品、组织和客户群的成熟，您回答这些问题的方式可能会随着时间而改变。也许今天你的探索性测试就足够了，但两年后你需要在手动测试套件上投入额外的精力。

我们在探索性测试中发现了 95% 的缺陷，所以如果几乎没有发现任何缺陷，是否值得花时间编写一整套手动功能测试？

使用一种方法发现当前发现的 95% 的错误这一事实很有趣。但真正的问题是：

• 你有效率吗？

• 您是否找到了这种方法的所有重要错误？

• 您是否找到了所有重要的错误？

• 通过将大部分/全部精力集中在这一方法上，您会错过什么？

如果我一共发现了 100 个 bug，其中 95 个是通过探索性测试发现的，但是在我投入生产后，随后又报告了 100 个我没有发现的 bug，那么我可能已经失败了。

另一方面，如果在我投入生产后没有报告任何错误，我会深入研究并考虑使用非探索性方法找到 5 个错误的价值。我可能会确定更多的探索性测试会找到它们，或者我可以找到它们的唯一方法是使用不同的方法。