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

你认为什么会给产品带来更多的价值，单元测试还是探索性测试

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

还有，哪一个在短期内支付的福利更多？从长远来看呢

---

最后，如果你只有两个答案中的一个，你的答案会改变吗？

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

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

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

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

---

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

首先，感谢您的详细阐述。这是非常有趣的。我的案例可以如下所示：；使用户能够使用布尔运算符（和/或/或非）和一系列参数条件（Param1>x、Param2==y等）创建一组规则的功能。这是通过一个模块创建规则来完成的，另一个模块定义一组操作（如果触发了规则），还有一个引擎，它将使用规则评估一个对象，并启动相关的操作（如果有的话）。我试图为开发人员在将功能交给QA之前花时间创建相关的单元测试进行辩护，这不仅仅是为了测试而发布，而是为了解决最明显的问题而依赖探索性测试。据我所知，开发人员应该在单元级提供他们有信心的代码，然后QA将专注于功能、单元之间的集成等等……当然开发人员应该在所有级别上都有信心——在QA中发现一个在Dev@EKI-开发人员编写的自动化单元测试应该是标准。附加的、脚本化的或手动的QA测试（如果您有一个QA小组）将不会取代这些测试。您的自动化单元测试将在一定程度上确保您为响应失败的QA测试所做的任何更改不会破坏其他内容。IMO称，作为TDD范例的一部分，首先编写单元测试时，支付的费用最高。