欢迎来到 SQA，克里斯。

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

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

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

将系统测试/集成测试/单元测试层次结构视为诊断过程的逆过程可能会有所帮助。当洗碗机维修工到我的洗碗机维修时，他开始通过与系统界面交互来诊断问题，即关上门，按下控制面板上的一些按钮，听洗碗机发出的声音，然后打开洗碗机倒过来看看盘子是不是湿的。之后，他将搜索范围缩小到一个特定的子程序集，该子程序集有自己的界面，不同于系统的界面。最终，他将问题缩小到特定部件，该部件与系统或子组件的接口不同。

集成测试是一种以比系统测试更容易诊断的方式识别问题的方法。这些问题更容易诊断，因为集成测试特定于子组件（具有较少的移动部件）而不是整个系统。因为它在子组件级别工作，所以集成测试可以访问未在系统级别公开的附加诊断信息。

从另一个方向来看，您的集成测试应该关注子组件的接口，而不是其组件的接口。如果您发现组件测试和子装配测试之间有很大的重叠，这可能意味着您实际上不需要测试子装配，或者相反，您需要以不同的方式定义您的子装配。

目标是解决正在集成的组件之间的冲突。在单元测试期间找不到那种冲突。@user246 的洗碗机的例子在这里很能说明问题。

您可能遇到的冲突类型：

• 组件传输语法错误或不传输数据。接收组件无法运行或崩溃（组件功能故障、接口格式不兼容、协议故障）。
• 通信正常，但所涉及的组件以不同的方式解释接收到的数据（组件的功能故障、相互矛盾或误解的规范）。
• 数据传输正确，但传输时间错误，或传输延迟（时间问题），或传输间隔太短（吞吐量、负载或容量问题）。

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

请注意，您可能会在集成您的软件以及将您的软件与现成的组件（例如库）集成时发现这些问题。

编辑：我开始分析我和我的同事在集成测试中发现的不同错误。我相信了解我上面提到的冲突类别的示例也会很有用。对集成中可能出现的问题更加敏感可以让我们在测试中强调这些点。

编辑 2：我找到了关于集成错误的更全面的来源，发现“软件接口故障的实证研究 - 更新”。它是 1987 年的，但似乎并没有过时。

关于始终确认术语的隐含含义，我同意 user246 的观点。我被教导并且一直使用这个参考来理解抽象的“测试级别”并在这里写了一些关于它的内容。

在我目前的角色中，我管理着一个测试人员团队，他们进行 90% 的集成测试。这意味着虽然我们依靠我们的开发人员在任何签入之前对各个功能和组件进行单元测试。我们的责任主要在于在用户界面下方或没有用户界面的情况下测试“组件”的功能“场景”。这是有益的，因为通常在用户界面稳定到足以自动化测试之前，对功能能力或“业务逻辑”进行了很好的测试。（另外，恕我直言，自动化“功能”测试更有效，这些测试在 UI 下方执行“业务逻辑”，并使用 UI 自动化主要关注 UI 代码的行为方面。）

此外，正如 Sam 指出的上述单元测试可能依赖于存根或模拟，集成测试不应该使用模拟组件。

WRT BVA 和 EP，我确实认为应该在单元测试中彻底测试边界。但是，在某些情况下，EP 是一种有助于识别数据分区“范围”边缘的子边界条件的机制。EP 的边缘情况（例如，唯一或特殊的 EP 数据集）通常可以在集成级别更有效地进行测试。（在时间方面是高效的。单元测试不能永远持续，也不能完全包容。在我们的例子中，我们的集成测试是与开发代码同步开发的，以便在它们出现之前识别上游的“功能”问题并入主分支。

任何涉及某些不属于您的代码库的子系统的测试都被视为集成测试。所以这包括数据库、文件系统、Web 服务等。

因此，您应该回到您的业务需求，并确定使用这些“外部”子系统之一作为其实现的一部分的那些需求。因此，首先，任何涉及存储和调用信息的要求，如果您选择了基于数据库或文件系统的实现，都是候选者。

然后像进行单元测试一样继续。也就是说，根据不同的输入或不同的系统状态，确定需求是否具有不同的情况。然后设置测试，在您的代码库内部和外部执行任何有助于实现每个案例的组件。

不要忘记包括负面案例。虽然您可能已经在单元测试级别测试了这些，但您可能希望确保在一个级别内出现故障案例或“无数据”案例