单元测试：验证特定组件（即类）是否按照设计创建或修改了功能。该测试可以是手动或自动的，但不会超出组件的边界。

集成测试：验证特定组件的交互是否按设计运行。集成测试可以在单元级或系统级执行。这些测试可以是手动或自动的。

回归测试：验证新的缺陷没有引入到现有代码中。这些测试可以是手动或自动的。

根据您的SDLC（瀑布式、RUP、敏捷等），特定的测试可以在“阶段”中执行，也可以或多或少地同时执行。例如，单元测试可能仅限于开发人员，然后将代码交给测试人员进行集成和回归测试。然而，另一种方法可能会让开发人员进行单元测试和某种程度的集成和回归测试（使用TDD方法以及连续集成和自动化单元和回归测试）。

工具集将在很大程度上依赖于代码库，但有许多用于单元测试（JUnit）的开源工具。HP（Mercury）QTP或Borland的Silk Test都是自动化集成和回归测试的工具。

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

对此，我将补充：

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

我刚刚意识到的一个新的测试类别是金丝雀测试。金丝雀测试是一种自动的、非破坏性的测试，它在实时环境中定期运行，因此如果失败了，就会发生非常糟糕的事情。

例如：

只有在开发/测试中才可用的数据是否出现了？后台进程是否无法运行？用户可以登录吗？

集成测试：集成测试是集成的另一个元素烟雾测试：烟雾测试也称为构建版本测试。烟雾测试是初始测试过程，用于检查被测软件是否准备就绪/稳定，以便进行进一步测试。回归测试：回归测试是重复测试。新软件是否在另一模块中生效。单元测试：这是一个白盒测试。只有开发人员参与其中

单元测试针对的是实现的最小部分。在Java中，这意味着您正在测试单个类。如果类依赖于其他类，则这些类是假的。

当您的测试调用多个类时，这是一个集成测试。

完整的测试套件可能需要很长时间才能运行，因此在更改之后，许多团队会运行一些快速完成的测试，以检测严重的损坏。例如，您已经将URI分解为基本资源。这些是烟雾测试。

回归测试在每个构建上运行，并允许您通过捕获所破坏的内容来有效地重构。任何类型的测试都可以是回归测试，但我发现单元测试最有助于找到故障源。

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

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