全链路测试不是银弹

微服务概述

微服务应用是由多个独立运行的服务构成，并且每个 service 只负责处理特定的功能块。它们就能实现更为复杂的任务。与单体复杂的系统相比，开发者需要维护一组相对简单但功能齐全的服务集群，并且这些 service 可能会以多种方式进行交互。消息传递的方式可能包括基于端到端的形式以及异步通信类型等不同的设计选项。

这种思路看似简单易懂,但其实际效果却非常显著地降低了复杂系统开发过程中的摩擦与冲突.在传统软件工程理念中,人们普遍推崇设计良好系统的最佳实践是遵循高内聚、低耦合的原则.遵循这一原则的设计使得相应的系统不仅易于维护,并在 undergo changes 时同样表现出较高的灵活性与扩展性.

内部集成度是衡量模块中各要素如何紧密整合在一起的一个重要指标。接口相关性则反映了不同组件之间交互所需理解的程度。在讨论内部集成度时，请注意罗伯特·C.马丁（Robert C. Martin）提出的单一职责原则这一方法具有显著的优势：通过将每个组件限定在一个特定的功能领域来提升系统的可管理性。

将同一类问题需要优化的地方归并为一类，并对不同类问题需要分别处理的地方进行拆分和优化。

在单体应用开发中, 开发人员会根据应用的不同层次（如类、模块、类库）来规划和配置功能属性. 相比之下, 微服务架构的目标则是将复杂的应用分解为多个独立的功能单元, 这些单元能够以相对独立的方式运行并相互协作. 每个功能单元都需要具备完善的功能属性配置. 同时, 每个微服务应该专注于实现单一职责, 并且具有较高的内聚性. 同样地, 在微服务架构中主张各服务之间应尽量保持较低的耦合度和信息隔离度.

何为全链路测试？

注

例如，在上文中提到微服务中的下单支付场景已经被分解为多个领域协同工作以实现功能；因此，在进行全链路测试时必定涉及对从下单到支付完成这一完整流程的考察；即在处理一笔下单支付业务请求时不仅需要关注输入输出结果是否正确还需要确保收单方支付方金融等相关领域的数据库数据具有完整性

域内测试

所谓域内测试即是单一业务单元（服务）的测试工作，如收单领域。值得注意的是单一业务单元并不是单一接口，在领域与接口呈一对多关系的情况下即单一业务单元通过多个接口对外提供不同服务

由此可见，在微服务架构中进行域内测试与接口测试是等价的操作。主要为基于TCP协议的RPC实现了非Http协议的支持。因此，在现有的工具如Postman和JMeter无法直接应用于微服务环境下时，请各位同学自行构建符合自身需求的测试架构。

全链路测试，为什么不是银弹？

下面分析以下三个原因并结合几个场景说明阐述下：

成本高

自动化用例开发成本高

无需多言，在单体架构或是微服务架构之下，其自动化运维成本也相对较高。从全局视角来看，自动化运维成本会进一步提高。这是因为全链路下的用例开发涉及多个领域之间的流程编排工作，在此过程中需要处理服务间的各种异常重试情况（包括超时和网络异常），同时各个模块的输出都需要经过严格的断言检验。这些因素共同作用的结果就是显著提升了每条用例开发的成本。

问题排查成本高

在全链路测试中遇到外域报错的情况时，请相关负责人介入协助排查。

跨部门的沟通与协作效率明显降低，并且人员变动以及系统的调整都会导致问题排查结果受到显著影响。

环境不稳定

基于单一应用架构的微服务系统部署相较于传统单体应用的集中式部署具有显著的不同之处

然而，在单体架构中也存在环境问题不稳定性对自动化测试用例造成影响的情况；相比之下，在微服务架构中这一问题更为严重

服务依赖错综复杂

如前所述，在微服务架构下并不存在完全独立的服务，在这种架构设计中各服务之间均存在相互依存的关系。在Java项目中通常通过将其他服务的jar包导入pom的方式建立相互依存的关系，在实际开发过程中若需对依赖项的jar包版本进行更新（主动升级或被动升级）则需特别关注原有合同条款是否发生变更

在测试过程中，
通常会先将依赖服务虚拟化，
在确认保障域内的服务质量达到预期后，
随后进入与其他领域间的集成测试阶段。
为了确保项目的顺利推进，
在启动前需预先搭建大量模拟服务环境。

在链路联调阶段中, 为了确保各区域服务都处于可运行状态, 通常情况下却难以达到预期目标. 在进行自动化测试时, 在分析这些服务的同时也需要深入理解业务系统提供的接口以及数据库等关键组件.

下面分析几个场景

场景01.

（主动/被动）优化服务对jar包版本的升级策略, 如果该服务无法自主识别相关问题, 则可能导致变更失败的风险存在.

参与过一个项目，在某个领域升级了 JAR 包以满足上游需求的目的。经过全链路测试未发现问题，并且用例成功运行。然而，在该领域的自动化测试中出现了问题：发现该 JAR 包升级未能满足向下兼容的需求而导致错误出现

场景02.

有一条链路：服务A-服务B-服务C

通过服务B进行信息传递的服务A接口在扩展字段中新增业务标识信息后会被应用于服务C。假设考虑到扩展字段的长度限制，在实际应用中可能会面临业务标识新增的风险。

不少学生也曾参与过类似项目的实践；由于负责的领域不在项目的修改范围之内，在实际操作中往往就会忽视对项目的深入关注。在这样的情况下,若服务B域内的自动化测试用例中缺乏针对长字段的数据校验,很可能会影响到整个系统功能的一致性检验（从全链路测试的角度出发考虑业务逻辑的一致性）。

就全链路测试而言，在进行理性分析时需要特别注意

往期推荐

接口之间的数据传输是一种途径

经验交流｜测试工程师向测试开发之路踏上征途

探讨Mock平台架构设计的思路

该系统采用模块化设计原则，在确保用户体验的同时实现了高效的业务流程处理能力；基于此提出了一种新型的架构设计方案；该方案通过引入先进的自动化测试技术；以确保系统功能的全面覆盖；同时能够有效提升开发效率；并支持多平台环境下的统一管理机制

基于自动化测试的接口模块设计第一部分：深入探讨了基于自动化技术的接口特性分析