集成测试中真正测试了什么？

#1 楼

克里斯，欢迎您来到SQA。

首先，关于术语，有许多术语描述不同类型的测试。每个人使用它们的方式都不同。在某些情况下，这些术语具有合同或法规文件中定义的特定含义。通常，尽管这些术语只是分配给个体（不一定意识到）的模糊概念的标签。当有人谈论“单元测试”或“集成测试”时，我试图问这些术语对他们意味着什么，以便我们说相同的语言。无论如何，我将假设您的问题不适用于合同或法规文件中定义了特定测试过程的项目。

是的，如果您使用边界值分析（BVA）进行单元测试，则等效划分（EP）在较高级别的测试中就足够了。

我并不是说要回避，但您的集成测试应为所需的任何测试。我认为单元测试是关于测试单个（也许是不可分割的）组件的，而系统测试是关于确保系统作为整体工作的。软件是组件的组合，但是组件本身可以是其他组件的子组合。单元测试仅验证组件的行为符合开发人员的预期。它不能保证组件的行为与其他所有人都假定的行为相同。集成测试是验证这些假设的机会。

将系统测试/集成测试/单元测试层次结构视为诊断过程的逆过程可能会有所帮助。洗碗机修理工到达修理我的洗碗机时，他开始通过与系统界面进行交互来诊断问题，即他关上了门，按下了控制面板上的一些按钮，听了洗碗机发出的声音，然后打开了洗碗机备份看看盘子是否湿。之后，他将搜索范围缩小到特定的子装配，该子装配具有其自己的界面与系统界面不同。最终，他将问题缩小到一个特定的部分，该部分的界面与系统或子装配体的界面不同。测试。这些问题更容易诊断，因为集成测试特定于子组件（具有较少的运动部件），而不是整个系统。因为它可以在子装配级别工作，所以集成测试可以访问系统级别未公开的其他诊断信息。

从另一个方向来看，您的集成测试应该关注子装配体的界面，而不是其零部件的界面。如果在零部件测试和子装配测试之间发现大量重叠，则可能意味着您实际上并不需要测试子装配，或者相反，您需要以其他方式定义子装配。 br />

#2 楼

目的是解决要集成的组件之间的冲突。在单元测试期间找不到此类冲突。 @ user246的洗碗机示例在这里非常说明问题。

您可能遇到的冲突类型：数据。接收
组件无法运行或崩溃（组件中的功能故障，
接口格式不兼容，协议故障）。
通信有效，但是所涉及的组件以不同的方式解释接收到的数据（组件的功能故障，规范相矛盾或被误解）。
数据传输正确，但是在错误的时间传输，或者传输时间太晚（时间问题），或者传输之间的间隔太短了（吞吐量，负载或容量问题） 。



基于Spillner等人的“软件测试基础”书。

请注意，在集成您的软件以及带有现成组件（例如库）的软件。

编辑：我开始分析我和我的同事在集成测试中发现的各种错误。我相信也可以了解我上面提到的冲突类别的示例。对集成中可能出问题的地方更加敏感，可以使我们在测试中强调这些要点。更新”。这是1987年的作品，但看起来并不过分。

#3 楼

在始终确认术语的隐含含义方面，我同意user246。我被教导并且一直使用该参考资料来理解抽象的“测试级别”，并在此处写了一些有关它。 。这意味着，尽管我们依靠开发人员在进行任何签入之前对各个功能和组件进行单元测试。您的责任主要在于测试以下“组件”的功能“方案”或不使用用户界面。这是有益的，因为通常在用户界面稳定到足以使测试自动化之前，对功能或“业务逻辑”进行适当的测试。 （恕我直言，自动化在UI下方执行“业务逻辑”的“功能”测试并使用UI自动化主要集中于UI代码的行为方面更为有效。）

也，如Sam所言，上述单元测试可能依赖存根或模拟，因此集成测试绝不应使用模拟的组件。

WRT BVA和EP，我确实认为应该在单元测试中全面测试边界。但是，EP是一种可以在某些情况下帮助识别数据分区“范围”边缘的子边界条件的机制。通常可以在集成级别更有效地测试EP的边缘情况（例如，EP数据的唯一或特殊集合）。 （在时间方面有效。单元测试不可能永远或完全包含在内。在我们的案例中，我们的集成测试是与开发代码同步开发的，旨在在开发之前就确定“功能”问题合并到主分支中。

#4 楼

任何涉及某些子系统的测试都属于集成测试，这些子系统不属于您的代码库。因此，这包括数据库，文件系统，Web服务等。

因此，您应该返回到业务需求，并确定使用这些“外部”子系统之一作为其实现一部分的那些需求。因此，首先，涉及存储和调用信息的任何要求都是可以的。

然后像进行单元测试一样继续进行。即，根据不同的输入或不同的系统状态，确定需求是否具有不同的情况。然后设置测试，以测试在您的代码库之内和之外都有助于实现每种情况的任何组件。尽管您可能已经在单元测试级别上对它们进行了测试，但是您可能想要确保一个故障案例或“无数据”案例在一个级别内