答案。

手动集成测试是手动检查不同模块、服务或外部系统之间交互的过程，没有自动脚本的参与。

问题历史：

在IT产品发展的早期，所有系统都是以单体架构开发的，但随着公司规模和第三方服务数量的增长，集成测试变得越来越重要。测试人员开始思考：如何确保数据和操作在系统之间正确传递——例如，成功的支付是否同时反映在计费系统和会计系统中。

问题：

最大的难度在于缺乏功能齐全的环境：集成可能依赖于第三方服务、不稳定的API或外部限制。此外，在每个集成点上进行手动测试可能非常繁琐，容易在步骤顺序上出错或遗漏重要的级联后果。

解决方案：

• 使用带有“存根”（mock/stub）的测试环境，以确保测试的可重复性。
• 结构化测试用例，逐步验证消息、日志、状态。
• 首先检查边界案例、超时、集成调用的重试、系统对故障的反应。

关键特点：

• 需要理解两个集成方的业务逻辑。
• 考虑异步性和状态传递的误差。
• 支持对部分故障的韧性。

误导性问题。

什么是测试替身（test doubles），在手动集成测试中为什么需要它们？

测试替身是集成组件的模拟（例如，mock，stub，fake）。在手动测试中，它们用于处理真实外部系统不可用或者其调用需要费用的场景。

如果测试用例只覆盖了快乐路径，是否可以认为集成已经测试完成？

不。必须测试边缘情况：连接错误、数据格式错误、超时、意外响应。

只检查数据的发送/接收是否足够，还是需要其他检查？

重要的是检查数据内容的正确性、数据转化和系统在不同错误交互时的表现。

常见错误和反模式

• 只处理“自己”系统的部分，而不检查合作方的行为。
• 忽略负面场景。
• 不分析日志或不收集集成错误的历史记录。

生活中的例子

负面案例

测试人员仅检查CRM和计费系统的集成，确认成功添加订单，而未检查同步错误和事务遗漏。

优点：

• 快速覆盖主要场景。

缺点：

• 集成故障的错误只会在真实数据上显现出来。

正面案例

测试人员创建了一组测试，包括断开和重新连接网络、插入无效令牌。验证双方的日志。

优点：

• 在上线前发现了关键错误。
• 节省了维护时间。

缺点：

• 准备环境和场景的工作量更大。