回答。

集成手动测试是软件生命周期中的一个重要阶段，在单元测试之后进行。其目的是确保系统中的各个模块或组件能够正确地相互交互。

问题的背景： 最初，软件的测试是分阶段进行的：首先检查单个模块（单元测试），然后检查整个系统。然而在实践中发现，大多数关键错误实际上发生在模块之间的交界处。出现了集成测试的需求，它手动识别系统不同部分之间的行为不一致。

问题： 主要困难在于对模块之间交互场景的不足处理和被遗忘的相互依赖关系。这会导致“隐性”缺陷：在孤立测试时一切正常，但集成后会出现故障（例如，API和数据库之间的数据处理不正确）。

解决方案： 正确组织的集成手动测试包括：

• 分析系统架构并绘制组件交互地图。
• 基于用户场景和边界数据开发集成测试用例。
• 模拟部分故障（例如，一个服务的失败）并评估整个系统的反应。
• 记录测试结果并记录缺陷之间的依赖关系。

关键特征：

• 保持最新的架构图。
• 考虑系统各部分之间所有隐藏和显性依赖关系。
• 特别关注模块交界处的数据传输和转换场景。

迷惑性问题。

集成手动测试和系统手动测试之间的区别是什么？

集成测试专注于测试特定模块之间的连接，而系统测试则从业务功能的角度对整个系统进行检查。

在集成测试中是否应使用真实的外部服务，还是只需模拟器就足够了？

对于关键集成，真实环境是更可取的，但可以从模拟器（mock/stub）开始。最终测试应在尽可能接近生产环境（PROD）的环境中进行。

是否可以仅通过自动化发现所有集成错误？

不可以：部分缺陷只能通过手动检查发现，当测试人员注意到数据交换的业务逻辑或未覆盖自动化的用户场景中的不明显问题时。

常见错误和反模式

• 缺乏明确的集成点清单。
• 在没有隔离环境的情况下进行测试。
• 集成测试用例的细节不够充分。

生活中的例子

消极案例

支付模块与订单模块之间的集成测试仅在所有其他测试完成后进行，并且没有单独的文档。

优点：

• 减少了准备测试用例的时间。
• 无需复杂协调即可快速启动测试。

缺点：

• 重大的缺陷泄露到生产环境，导致双重扣款。
• 最后时刻修复发现的错误导致发布延迟。

积极案例

集成场景在一开始就被记录下来，测试数据尽可能贴近用户的实际任务。

优点：

• 早期发现关键缺陷。
• 提高测试覆盖的透明度。

缺点：

• 需要复杂的团队协调。
• 测试文档的量增加。