已经有一些很好的答案，但我想进一步完善它们：

单元测试是这里白盒测试的唯一形式。其他都是黑盒测试。白盒测试意味着你知道输入；你知道机构的内部工作原理，可以检查它，你知道输出。使用黑盒测试，您只知道输入是什么，输出应该是什么。

很明显，单元测试是这里唯一的白盒测试。

单元测试测试特定的代码片段。通常是方法。集成测试测试您的新功能软件是否可以与其他所有功能集成。回归测试。这是为了确保您没有损坏任何东西而进行的测试。一切过去有效的东西都应该继续有效。烟雾测试是作为一项快速测试来完成的，以确保在您参与更激烈的测试之前一切都正常。

单元测试：测试类内部工作的自动测试。它应该是与其他资源无关的独立测试。集成测试：在环境中进行的自动测试，与单元测试非常相似，但使用外部资源（数据库、磁盘访问）回归测试：在实现新功能或bug修复后，您重新测试过去有效的场景。这里您将介绍新功能打破现有功能的可能性。烟雾测试：测试人员可以断定是否继续测试的第一次测试。

单元测试

单元测试通常由开发人员完成，而测试人员在这种类型的测试中是部分进化的，测试是逐个单元完成的。在Java JUnit中，测试用例也可以测试编写的代码是否设计完美。

集成测试：

当所有/部分组件集成时，在单元测试之后可以进行这种类型的测试。这种类型的测试将确保当组件集成时，它们是否会影响彼此的工作能力或功能？

烟雾测试

这种类型的测试是在系统成功集成并准备在生产服务器上运行时完成的。

这种类型的测试将确保从开始到结束的每个重要功能都能正常工作，并且系统可以部署到生产服务器上。

回归测试

这种类型的测试对于测试开发人员修复某些问题时系统中是否不存在意外/不需要的缺陷非常重要。该测试还确保成功解决所有错误，因此不会出现其他问题。

每个人都会有稍微不同的定义，并且经常有灰色区域。然而：

单元测试：这一点（尽可能隔离）是否有效？集成测试：这两个（或更多）组件是否一起工作？烟雾测试：整个系统（尽可能接近于一个生产系统）是否结合得很好？（即，我们有理由相信它不会产生黑洞吗？）回归测试：我们是否无意中重新引入了以前修复过的bug？

烟雾测试已经在这里解释过了，而且很简单。回归测试属于集成测试。

自动化测试可分为两种。

单元测试和集成测试（这是最重要的）

我会将所有测试（如集成测试、功能测试、回归测试、UI测试等）使用短语“长测试”（LT），将单元测试称为“短测试”。

LT的一个例子是，自动加载网页，登录帐户并购买一本书。如果测试通过，则更有可能以相同的方式在现场运行（因此“更好的睡眠”参考）。Long=网页（开始）和数据库（结束）之间的距离。

这是一篇很棒的文章，讨论了集成测试（长测试）相对于单元测试的好处。

单元测试：指定并测试类的单个方法的契约的一个点。这应该有一个非常狭窄和明确的范围。复杂的依赖关系和与外部世界的交互会被破坏或嘲弄。集成测试：测试多个子系统的正确互操作。从测试两个类之间的集成，到测试与生产环境的集成，这是一个完整的过程。烟雾测试（也称为健全性检查）：一个简单的集成测试，我们只需要检查当被测试的系统被调用时，它是否正常返回并且不会崩溃。烟雾测试与电子设备都是一个类比，在电子设备中，当电路通电时会进行第一次测试（如果它冒烟，那就糟糕了！）。。。……显然，还有管道系统，管道系统被烟雾填满，然后进行目视检查。如果有任何东西冒烟，系统就会泄漏。回归测试：在修复错误时编写的测试。它可确保此特定错误不会再次发生。全名是“非回归测试”。它也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。

对此，我将补充：

验收测试：测试功能或用例是否正确实现。它类似于集成测试，但侧重于要提供的用例，而不是所涉及的组件。系统测试：将系统作为黑盒进行测试。在测试过程中，对其他系统的依赖性通常会被嘲笑或清除（否则这将更像是一个集成测试）。飞行前检查：在类似生产的环境中重复进行的测试，以缓解“在我的机器上构建”综合症。这通常通过在类似生产的环境中进行验收或烟雾测试来实现。