单元测试？ 集成测试？ 回归测试？ 验收测试？

Question

有没有人可以清楚地定义这些测试级别，因为我发现在进行 TDD 或单元测试时很难区分。 请如果有人能详细说明如何，何时实施这些？

Answer 1

简要地：

单元测试- 您对每个单独的代码段进行单元测试。 想想每个文件或类。

集成测试- 将多个交互单元放在一起时，您需要进行集成测试以确保将这些单元集成在一起不会引入任何错误。

回归测试- 在集成（或者修复）之后，您应该再次运行单元测试。 这是回归测试，以确保进一步的更改不会破坏任何已经测试过的单元。 您已经进行的单元测试已经生成了可以一次又一次运行以进行回归测试的单元测试。

验收测试- 当用户/客户/企业收到功能时，他们（或您的测试部门）将进行验收测试以确保功能满足他们的要求。

您可能还想研究白盒和黑盒测试。 还有性能和负载测试，以及要考虑的“'ilities”测试。

Answer 2

单元测试：当它失败时，它会告诉您需要修复哪一段代码。

集成测试：当它失败时，它告诉您应用程序的各个部分没有按预期协同工作。

验收测试：当它失败时，它告诉您应用程序没有按照客户期望的那样做。

回归测试：当它失败时，它会告诉您应用程序不再像以前那样运行。

Answer 3

以下是对每个提到的测试以及它们何时适用的简单解释：

单元测试单元测试是在一个独立的单元（通常是一个类或方法）上执行的，并且应该在单元已经实现或单元更新已经完成时执行。

这意味着它会在您编写类/方法、修复错误、更改功能时运行......

集成测试集成测试旨在测试多个单元之间的交互情况。 每当在单元之间建立了新的通信形式或它们的交互性质发生了变化时，都应执行此类测试。

这意味着只要最近编写的单元集成到系统的其余部分，或者与其他系统交互的单元更新（并成功完成其单元测试），它就会运行。

回归测试只要系统中的任何内容发生变化，就会执行回归测试，以检查是否引入了新的错误。

这意味着它在所有补丁、升级、错误修复之后运行。 回归测试可以看作是单元测试和集成测试相结合的特例。

验收测试只要与检查子系统（可能是整个系统）是否满足其整个规范相关，就会执行验收测试。

这意味着它主要在完成新的可交付成果或宣布完成更大的任务之前运行。 将此视为您在跑向客户/老板并宣布胜利之前是否真正完成了目标的最后检查。

这至少是我学习的方式，尽管我确信还有其他相反的观点。 无论哪种方式，我希望这会有所帮助。

Answer 4

单元测试：我的单一方法工作正常吗？ （没有依赖关系，或者依赖关系被嘲笑）

集成测试：我的两个单独开发的模块放在一起时是否能正常工作？

回归测试：我是否通过更改/编写新代码破坏了什么？ （在每次提交时运行单元/集成测试在技术上是（自动）回归测试）。 更常用于 QA 环境中 - 手动或自动。

验收测试：由客户完成的测试，他“接受”交付的软件

Answer 5

我会尽力：

1. 单元测试：开发人员会编写一个单元测试来测试单个组件或类。
2. 集成测试：更广泛的测试，涉及多个需要协作的组件或包
3. 回归测试：对应用程序进行一次更改会迫使您重新运行所有测试并检查所有功能。
4. 验收测试：最终用户或 QA 在签署接受应用程序交付之前执行这些测试。 它说“该应用程序符合我的要求。”

Answer 6

无法评论（声誉低：-|）所以......

@Andrejs 很好地说明了与每种类型的测试相关的环境之间的差异。

单元测试通常在开发人员机器上运行（也可能在 CI 构建期间），并模拟出对其他资源/系统的依赖关系。

根据定义，集成测试必须具有（某种程度的）依赖关系； 其他资源和系统被调用，因此环境更具代表性。 用于测试的数据可能是模拟的，也可能是真实生产数据的一个小的混淆子集。

UAT/验收测试必须向接受软件的 QA 和业务团队展示真实世界的经验。 因此需要完全集成和真实的数据量以及完整的屏蔽/混淆数据集，以提供真实的性能和最终用户体验。

其他“设施”也可能需要环境尽可能接近现实来模拟生产体验，例如性能测试、安全性……