探索性测试可以代替执行手动功能测试吗？

#1 楼

如果您花费时间进行探索性测试，您是否会发现目前由手动测试套件发现的剩余5％的bug？管理人员是否对测试范围充满信心，无需进行功能测试就可以做出决策？

我认为没有手动功能测试套件的最大风险将是减少覆盖范围，从而使事情容易遗漏。但是，可能不需要完全手动回归测试来确保覆盖范围。自动化测试通常被认为是理想的选择，因为它们简化了回归测试并节省了长期的测试时间。他们可以真正腾出您的探索性手动测试人员，使他们可以专注于最具生产力的测试形式。

您还可以尝试指导性探索性测试，在这种情况下，测试人员会得到一份清单，而不是完全编写脚本的手动测试，然后测试人员只需确保在执行探索性测试时就覆盖了清单，就可以进行其他他们认为值得尝试的事情。有时将这种技术称为“引导式探索性测试”。对于您的团队来说，这可能是一个不错的选择，因为听起来您手头上有一些非常熟练的探索性测试人员。

#2 楼

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

这取决于-编写它们以发现缺陷的目的是什么？如果是这样，那么听起来您最好将精力投入更多的时间进行测试。如果您正在考虑放弃它们，那么听起来并不像您有任何合同或政治义务来生产它们。手动功能测试套件的生产成本往往很高，维护成本也很高，因此，除非您真的有充分的理由来制作该文档，否则可能会有更好的方法来花费金钱/时间。

那么，什么阻止了您？

一些常见的问题可能是：

1）我们如何看待测试对系统的覆盖程度？我们所有人最终都会运行相同的测试吗？也许我们都将运行相同类型的测试，而没有人会想到测试安全性或安装？

如果您对此感到担忧，那么解决此问题的一种方法是编写一个一组探索性测试章程，而不是测试脚本。迈克尔·凯利（Michael Kelly）的这篇文章很好地解释了如何通过章程管理测试，这是该系列的一部分。

我真的很喜欢Darren McMillan的博客文章，内容涉及他如何使用思维导图计划测试和记录测试会话。我还没有为ET自己认真地使用过思维导图，但是我看到其他探索性测试人员使用的思维导图只是一种非常清晰的方式来介绍所涵盖的内容，而且容易发现仍有待测试的差距。 >
2）我们如何证明自己的所作所为？

在测试之前，您不必写下任何东西来证明您已经进行了测试。您可以在测试时写下内容，然后仍然可以对发现的内容做出回应。 （实际上，比起以前做测试，在测试时记下好的笔记比以前更容易反映出您真正测试过的内容-我观察到的大多数脚本化测试人员经常都“脱稿”，因此这些脚本不是指导您进行测试的好指南。测试过的内容。）

在录制ET会话时，这里有一些很好的资源/想法： / 11 / template-for-session-notes /
用于记录探索性测试会话结果的Session Tester的替代方法

这是有关探索性测试的大量常规资源的列表。

#3 楼

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

您和您的团队需要决定跳过附加测试是否值得让漏洞漏掉的风险。在考虑风险时，请考虑可能会漏出的错误的种类，这些错误的发生频率（即情况是罕见还是普遍？），严重性（错误发生时，危害程度如何）以及您如何认为自己的客户会宽容（例如，高科技的早期采用者可能比在线银行客户宽容得多）。在某些行业中，您的测试过程是私人的内部事务。在其他行业中，必须严格遵循记录完整的过程才能获得认证。基础成熟。也许今天的探索性测试就足够了，但是两年后，您需要在手动测试套件中投入更多的精力。

#4 楼

我们在探索性测试中发现了95％的缺陷，因此，如果几乎没有发现任何缺陷，那么花时间编写全套手动功能测试值得吗？ br />使用一种方法可以找到当前发现的95％的错误这一事实很有趣。但是真正的问题是：


您是否有效？
您是否通过这种方法找到了所有重要的错误？所有？
您将大部分/全部精力都集中在一种方法上，您会错过什么？进入生产环境后，我会报告未发现的错误，那么我可能已经失败了。并考虑使用非探索性方法发现5个错误的价值。我可能会确定会找到更多的探索性测试，或者我能找到它们的唯一方法是使用其他方法。

#5 楼

您如何执行脚本化的手动测试？如果只是由测试人员执行一次或两次然后扔掉它们，您可能可以更改过程并减少/消除多余的文书工作。

但是，如果还有其他人在使用它们，那么在消除它们之前，请考虑质量保证体系之外的影响。还是您对编码人员，分析师或其他人员期望并用来帮助他们发现差距或其他问题的测试计划进行审查？是否将某些测试纳入长期回归之中，这意味着其他人可能不得不选择编写这些测试？ （而且我敢肯定还有其他事情我没想到。）

假设您发现并解决了更改流程的任何下游影响，我会说编写和维护的文书工作较少通常更好。

#6 楼

在使用“探索性”测试时，我们发现它非常依赖于测试人员的经验和对系统的理解。如果测试人员对软件应该如何工作以及应该显示什么有广泛的了解，那么他们将能够捕获所有这些小错误。手动过程可能会提供更好的覆盖范围，但可能会丢失应在现有报告上显示的元素。

探索性测试非常适合吸引外部用户。在整个应用程序中自由漫游的步骤越来越少。话虽这么说，当涉及到数据完整性时，探索并不是最好的方式……只是我的两点。祝大家测试愉快！

#7 楼

探索性测试可以帮助计划和编写有效的功能测试套件。当需要测试新功能时，最好在计划或自动化它之前先对其进行探索。探索性测试可以产生新的测试思路/路径，并可以在我们探索软件时揭示未发现的测试区域。

正如埃塞尔·埃文斯（Ethel Evans）所说，借助自动化，我们可以更好地跟踪测试范围。

此外，自动化比手动测试便宜。因此，应该使用探索性测试来补充功能测试套件的运行，而不是替代它。

#8 楼

在这种情况下，您可以定期查看手动功能测试套件，比方说每个其他发布周期或每月一次，并弃用不太重要的测试用例。在对手动功能测试套件进行精心整理之后，您可以确保它们仅测试关键场景。这将节省您的时间，并确保该代码不会与关键组件中的错误一起投入生产，而这些错误应该在运行功能测试时就很容易找到。

根据您对测试套件进行定期整理的时间，相对来说应该花费最少的时间。

#9 楼

手动和探索是两个不同的事物，但是一起可以对测试产生巨大的影响。当时间成为决定因素时，这两种情况都会显现出来，因此，如果有时间，脚本化的手动测试是一个不错的选择，但是当时间较少时，探索性测试显然是个不错的选择。

#10 楼

探索性测试和手动测试不是互斥的，您可能是指脚本回归与探索性测试。