当软件组件的单元测试完美运行时会发生什么？您是否曾想过，为什么单元测试 100% 通过的报告对于作为一个单元进行集成和验证时的组件没有好处？发生自发故障的集成测试并不反映故障点位于单元内部，而是反映单元交互的地方。
测试团队非常重视如何有效地依靠自动化、集成测试来确保在当今要求苛刻的世界中生成的软件的质量，在这个世界中，以结果为中心的方法寻求工作软件的持续交付。
什么是集成测试？
集成测试包括围绕接口进行测试，以检查多个软件模块之间的数据流，而不干扰模块的功能。
为了构建系统的“工作”版本，由各个开发人员成功开发和单元测试的单独工作模块以增量方式汇集在一起，以使系统正常运行。
然后对软件进行验证，以发现与接口相关的任何错误，使其满足要求、标准和合规性（如果有），并按照预期的方式满足整体功能。
同样，集成可以在多个系统之间进行，例如：
- 新系统到旧系统
- 旧系统到旧系统
- 由不同服务提供商开发和支持的系统。
- 集成DB、API、Cloud等组件
让我们详细讨论所涉及的各个组件以及它们如何交互，同时考虑到支付网关系统。
系统简介
支付网关的客户端-服务器架构如图所示。
该软件充当网关。它是任何在线零售商的重要组成部分。卡、数字钱包、UPI 和网上银行交易可以借助该软件作为服务进行授权。
这些服务提供一键式导航，并且几乎不需要对网站进行调整。第三方支付服务与商户系统集成很困难。
此外，该系统需要针对集成点进行测试，这些集成点为授权、结算、退款、用户通知和交易报表等提供解决方案。
此外，最终用户可以通过各种平台（包括桌面、移动和基于 Web 的系统）访问系统也至关重要。下面列出的测试用例是测试服务时要运行的一些最重要的测试用例，包括。
- 确保交易彻底、安全。
- 验证所有接受的付款方式的功能。
- 最终用户使用的所有平台上的一致用户体验。
从整合的角度来看，验证网站和服务的整合更为重要。
集成测试的组成部分
考虑到这一点，我们来谈谈尝试自动化集成时要记住的组件。
- 逆向工程可用于预测在选择组件时执行集成套件时会发生的问题。
- 如果你有分析经验的话，集成测试的失败都会来自于环境失败。
- API 或 UI 等组件失败，而不是整个自动化脚本场景失败。
- 在 CI/CD 管道中建立适当的开发分支，以便运行集成测试。
- 在管道中设置特定的测试环境变量，例如特定于执行环境的URL。
- 访问特定于环境的测试资源。
此处详细介绍的组件在上图中进行了总结。
测试脚本
需要准备测试脚本并对其可能要验证的自动化集成场景进行彻底检查。它应该配备能够标记某个部分失败的断言。
管道的设置
对于自动化、集成的套件来说，通过 CI/CD 管道运行以实现测试和开发的协作至关重要。此外，当您的系统与各种平台兼容时，同步自动化集成测试可以加快测试周期，同时仍确保完全覆盖。
预定测试的触发器
CI/CD 管道的配置应该是这样的：在启动相应的测试环境之前，它们首先评估推动更改的开发分支的环境。在多个时区工作的团队必须依赖通过管道执行比平常花费更长时间的测试。
测试结果报告
该报告描述了通过/失败率，以提醒团队发现任何问题，有助于识别故障端点并评估问题的原因，无论是管理不善的界面、不可靠的基础设施还是粗制滥造的实施。
集成时确认所有接口场景概述
考虑到所考虑的系统（支付网关）的重要性，每个交易状态都应该正确地流向每个系统端点。
让我们讨论一个这样的场景，即消费者方面的在线支付失败，在这种情况下，是未经授权的交易。
支付网关用例
“您作为客户在在线商店下订单。支付服务接受信用卡付款。支付网关在将卡信息发送到卡网络进行欺诈检查或卡有效性检查之前对其进行加密。发卡机构批准交易。公司将其批准传达给支付网关，支付网关将其传达给客户。为了验证卡交易，发卡行会向客户注册的手机或电子邮件发送一次性密码。
这些 OTP 是有时间限制的，它们是双因素身份验证的组成部分。如果 OTP 输入错误，交易就会失败。”
预计客户在商家网站上下的任何订单都将失败，并且不会将任何资金存入商家的帐户中。
随着越来越多的第三方支付处理商进入市场，商家方与这些支付处理商集成以收集和分散支付可以有各种排列和组合。
当我们分解场景中的交互时，第一个交互是客户和通过网站或移动应用程序提供软件或服务的商家之间的交互。
客户和应用程序应该能够进行通信，并且应用程序应该验证放入购物车进行付款的产品和价格。
用户提交的卡信息以及通过销售点进行的购买的双因素身份验证应在商家站点和支付网关以及卡网络之间的交互过程中进行加密。
卡网络与发卡银行之间的互动，以便及时将 OTP 交付给适当的客户，并进行时间验证。
卡网络与第三方通知服务之间的交互，以便及时将 OTP 传送给相应的客户。
在这种情况下，客户与支付服务的交互未得到验证，因为用户输入了无效的 OTP，并且支付处理商、卡网络和发卡银行均通知该交易未经授权。
通知服务与卡网络的交互向客户提供“输入的 OTP 错误”的错误通知。
卡网络、收单机构和商户账户之间的支付网关通信。如果付款不成功，则不会向收单机构或商户账户发送任何款项。
最后，客户与商家应用程序的交互导致交易失败而无法成功下单。
正如您所看到的，存在多个界面，各种玩家和系统（主要是支付处理系统）进行交互。
所有这些模块可能不会被编码并接受单元测试或可用于集成测试。
集成测试的美妙之处在于测试统一中的模块和接口以这种方式工作。
在这样的情况下，当系统之间有大量的组件来回通信时，自动化集成测试会非常有用。
自动化集成测试工具
在列出可用于自动化的仪器之前，了解选择标准至关重要。
我们想要执行自动化集成测试。
因此，该工具提供了一个测试各种系统组件（如DB、API和UI）的平台，可用于测试模块之间的接口。应选择使用寿命长、易于维护并支持持续集成运行的工具，从而最大限度地提高投资回报。
有多种可用的工具，我们将在下面讨论：
- Citrus：一种自动化集成测试，可在任何消息传递协议和格式数据上运行测试。它提供了一个用于自动化 Soap 服务、HTTP Rest 以及与 TestNG 和 Junit 等不同测试框架集成的平台。它附带了全面的文档，并且可以用 Java 或 XML 创建自动化脚本。
- SITA（智能集成测试加速器）；该工具可以运行以业务为中心的集成测试。与 HP、IBM Rational 和 IBM 等工具无缝集成。
- TESSY：该工具主要用于安全关键型嵌入式系统的单元测试。它处理测试组织和管理的各个方面，例如需求、覆盖率评估和可追溯性。
- Testsigma：这个测试自动化平台是完全托管的。它为 Web 应用程序、消息传递协议和移动应用程序提供自动化连续测试，并且作为开源提供。
自动化集成测试有哪些好处？
我们真的需要首先将集成测试自动化吗？
答案无疑是“是”。公司在当前的宏观经济环境下安排产品的发布，市场上竞争激烈，发布的产品具有友好的 UI/UX、提供流畅的功能以及在其可能使用的平台上具有最佳性能。
测试团队经常因开发工作的延迟而首当其冲。
你会在质量上吝啬吗？绝不！！
考虑到这种双重困难，测试团队必须寻求创造性的修复来缩短测试执行周期。
这是集成测试从手动到自动化的框架转换。现代组织中敏捷性的采用允许使用自动化技术进行质量控制检查和降低成本。
验证系统的主要瓶颈是执行重复且频繁发生的测试。自动化集成测试消除了这一瓶颈。
自动化至关重要，因为测试是耗时的组件之一，而且每个发布周期都在变得越来越短。
需要一个自动化工具的替代平台来自动化跨多种技术的测试。
大纲
分层质量方法的一个组成部分是集成测试。对于测试人员来说，自动化各种软件组件（而不是单元）可能相当困难。
在上面的段落中，我们尝试使用具有大量交互点的复杂系统来说明自动化集成测试的重要性。
高质量集成测试的一个关键发现是坚持事件的顺序，这将逐个模块地覆盖系统的交互。
确定集成测试先决条件所涉及的各种模块和参与者，制定测试策略，选择高优先级场景，准备测试数据和环境，开发自动化测试，并使用 CI 管道集成套件以在发布后立即运行测试在较低的环境中。
在软件开发周期的早期，自动化集成测试必须发现接口问题。它增强了团队对其向用户提供高质量产品的能力的信心。
为了快速执行复杂的场景，应该明智地选择一个能够满足您的目标、提供简单维护并允许无缝集成的工具。
制定评估自动化测试仪器的精确策略至关重要。
考虑您的项目预算、现有要求以及测试团队在自动化方面的经验，以帮助您缩小决策列表并选择最能满足您需求的解决方案。
自动化集成测试使我们能够生产出满足用户需求的优秀解决方案。
