定义

集成测试 测试系统中两个组件的组合。它关注的是组件之间的关系,而不是组件本身。它回答了“这些组件是否按预期协同工作”的问题。

系统测试

验收试验

请注意,这些测试都不能回答“此软件有用吗?”或“此软件易于使用吗?”。

所有自动测试都受到axiom的限制” “-最终,人类必须坐在计算机前,查看您的用户界面。

比较

单元测试越来越容易编写、运行和诊断。它们不依赖于文件系统或数据库等“外部”元素,因此它们更简单/更快/可靠。大多数单元测试都会在重构时继续工作(好的单元测试是安全重构的唯一方法)。他们绝对要求您的代码 解耦 ,这很难,除非你先写测试。这些因素的组合使得TDD的红/绿/重构序列工作得非常好。

集成测试介于两者之间:它们比系统测试更容易编写、运行和诊断,但覆盖范围比单元测试更广。

对

即使所有“单位”都做了他们应该做的事情,也不能保证整个系统按设计工作。

是的,此外还有一些不同类型的代码覆盖

from wiki:

• 功能覆盖率
• 报表覆盖范围 -源代码的每一行都被执行了吗?
• 决策覆盖率 (也称为分支覆盖率)-每个控制结构(如if语句)的评估结果是否同时为true和false?
• 条件覆盖率 -是否对每个布尔子表达式求值为true和false(这并不一定意味着决策覆盖)?
• -是否已执行通过代码给定部分的所有可能路径?
• 出入境保障

例如,路径覆盖率,仅仅因为每个方法都已被调用,并不意味着如果您按给定顺序调用各种方法,就不会发生错误。

其次,您不知道发送器单元的输出是否与其接收器单元的输入兼容。这就是集成测试的目的。

最后,单元测试可以在不同于生产环境的环境中执行。集成测试可能会发现差异。

我还没有看到一个能涵盖这些考虑因素的答案。现在,我是从整体系统的角度讲的,不是从软件开发的角度讲的,而是。。。 集成基本上是将低级产品组合成高级产品的过程。每个级别都有自己的一套需要遵守的要求。尽管有些需求可能是相同的,但不同级别的总体需求集将不同。这意味着测试目标在不同的层次上是不同的。 此外,较低级别的组件开发人员对需求和设计的理解可能与较高级别的产品开发人员不同,因此集成测试也在一定程度上验证了较低级别的产品开发。

只是想说明一点:如果我必须选择,我会转储单元测试并进行集成测试。经验告诉我们,单元测试有助于确保功能,并在开发周期的早期发现bug。

集成测试是在产品外观接近最终用户外观的情况下完成的。这也很重要。

单元测试通常都是关于单独测试类。它们的设计应该确保在给定特定输入的情况下,您的类表现出可预测和预期的行为。

“不透明(当有人破坏时,必须深入所有层以找出错误所在)”——这正是进行集成测试的原因——否则这些不透明的问题将出现在生产环境中。

是的,因为您的软件的功能取决于它的不同部分如何交互。单元测试取决于您提供的输入和定义的预期输出。这样做并不能保证它能与系统的其余部分一起工作。

是的,当您引入故意更改输出的代码更改时,集成测试是一个很难处理的问题。在我们的软件中,我们通过将集成测试的保存结果与保存的正确结果进行比较,来最大限度地减少这种情况。

我经常看到良好的集成测试所发现的各种问题——特别是如果您可以自动化一些集成测试的话。

如果你在你的软件中构建了一个API,你可以用它来进行自动化集成测试——过去我从中获得了很多经验。我不知道我会说我会放弃单元测试而支持集成测试,但是当它们做对了,它们是一个非常强大的补充。

This exact question 基本上一天前才被问到。看见 this question 即使代码覆盖率为100%,您也可能会遇到许多错误。

它看起来不像这里提到的,但实际上永远不会有100%的单元测试覆盖率(如果涉及数据库)。当您为数据库连接和CRUD操作编写单元测试时,您已经创建了一个集成测试。原因是您的测试现在在单个工作单元之外有一个依赖项。我所从事的项目以及与我交谈过的开发人员总是表示,剩下的10%是DAO或服务层。最好的测试方法是使用集成测试和模拟(内存中)数据库。我见过为了对DAO进行单元测试而模拟连接的尝试,但我并不真正理解这一点——DAO只是一种将原始数据从一种格式序列化到另一种格式的方法,您的管理者或委托人将决定如何操作它。