短期/长期场景中的单元测试与探索性测试

Question

您认为什么能给产品带来更多价值，单元测试还是探索性测试？

我知道这两种测试都有不同的一般用途，但是您会优先考虑哪种测试，即您首先会做什么，然后做什么，单元或探索性？

另外，谁在短期内支付的福利更多？从长远来看？

最后，如果你只有时间做这两者之一，你的答案会改变吗？

Answer 1

在我看来，两者都很重要。我遵循 TDD 方法，因此单元测试形成了我的代码的可执行规范。必须首先进行单元测试，但在这个过程中，我经常发现自己在做一些形式的探索性测试来创建我通过的单元测试。此外，有些东西——例如界面设计——如果没有某种形式的探索就无法完全开发。是的，在许多情况下，您可以开发单元测试来确保界面元素按预期方式运行，但您通常需要先了解不同元素的交互方式，然后才能确定它们如何应该互动。探索不同的场景并根据反馈调整测试脚本是设计的重要组成部分。

对于非接口工作，我会先进行单元测试，然后根据需要进行探索性测试。对于界面工作，我会进行原型设计和探索，然后开发单元（脚本）测试（如果有的话）。这部分是由于每个领域的测试工具的能力，但这也与正在完成的工作类型有关。

关于好处，很难比较，因为它们提供不同种类的好处。这两种类型的测试都可以发现和消除缺陷，但是单元测试（使用 TDD）也可以指导和改进应用程序的设计和结构。通过改进设计，我们也提高了可维护性。在我看来，探索性测试主要提高了应用程序的可用性，尽管它可以用来评估我们的设计决策是否真的按照我们预期的方式工作，并随着设计的发展验证设计。

我的观点是，单元测试更为基础，因为它们提供了一个安全网，所有其他测试都可以从中产生变化。从这个意义上说，它们更重要，但在现实环境中你不能没有它们。此外，这些并不是仅有的两种测试类型，它们也不是真正可以直接比较的，就像单元测试和集成测试一样。如果您想使用调试器，您可以进行探索性的单元测试。

我可以想象您没有时间进行自动化脚本测试的场景，但这些都是边缘情况，至少对我来说是这样。我无法想象即使使用手动探索性测试我也不会进行某种程度的单元测试的场景。实际上，在不需要进行某种级别的单元测试之前，应用程序必须非常简单。