微服务测试是很有挑战性的,为什么这样说呢?原因有以下几点:
结果不稳定, 分布式系统,服务之间的通信都是通过网络调用,然而在网络上传送,都会面临网络延时、超时、带宽等因素,容易导致不稳定的测试结果。
验证成本高,为了验证多个服务协作后的功能正确与否,需要为每个服务搭建基础设施(包括数据库、缓存等),并执行部署、配置等步骤,以确保服务能正确运行。
反馈周期长, 相比单体应用而言,微服务架构下,可独立部署的单元多,因此集成测试的反馈周期比之前会更长,定位问题的时间就会更久。
沟通成本高, 微服务常由不同团队开发并维护,当服务频繁进行改动和版本升级的时候,很容易导致不兼容,加大团队之间的沟通成本。
测试金字塔很好的帮助我们在制定测试策略的时候,区分不同层次测试关注点,同时,一般来说,测试颗粒度越粗,越脆弱,执行的时间越长,维护成本也越高。
在微服务中,不得不聊聊消费者契约测试,
契约,一种定义在Consumer与Provider之间的交互方式
契约是Consumer和Provider团队之间达成的交互协议,更多的看中的是请求和响应的Payload结构(Schema),由服务消费者构建并生成contract,然后将contact上传到Pact broker or server; 对应的服务提供者,需要在Pipeline中,有一个task进行契约的验证,保证契约不会被破坏。
测试分层,Consumer和Provider分别测试。
测试前移,为Consumer提供Mock,不需要真实的集成环境,稳定性高。
反馈周期短,单元测试级别,测试运行快,毫米级。
沟通成本底
为服务消费者提供了信心,更为服务提供者提供了更大的价值(通过与不同消费者约定的契约,可以保证服务安全的升级变迁,不会破坏之前已有的功能)
一个服务需要被多个消费者使用,每个消费者的诉求并不完全一样(一对一的场景,没有太大意义)。
服务消费者与服务提供者由不同的团队开发维护。
服务消费者与服务提供者,一定要对契约达成一致,并一直保持这种约束(如果有一方没有遵守,比如提供者根本不将契约验证集成到流水线中,那么就没有任何意义),契约的不符合预期的变化应当会造成测试的失败。
检查Consumer构建的请求是否匹配到了对应的Contract
检查Provider的响应是否满足Consumer的需要
Provider的业务逻辑是否正确
Consumer的处理响应的逻辑
可参考的工具: Pact, Spring Cloud Contract等
集成测试验证服务或者组件之间的连通性和交互以检查接口缺陷,集成测试旨在通过集成不同的Downstream服务,来覆盖基本的成功和错误的场景,在我们项目中,选用REST Assured作为集成测试工具,使用非常方便:
@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureRestDocs
public class UserDocumentationTests {
@LocalServerPort
private int port;
@Autowired
private RequestSpecification documentationSpec;
@Test
public void listUsers() {
given(this.documentationSpec).filter(document("list-users")).when()
.port(this.port).get("/").then().assertThat().statusCode(is(200));
}
}
当downstream服务非常不稳定的时候,我们会通过wiremock作为proxy对请求和响应进行录制,使用wiremock做测试替身,隔离外部调用,避免多服务间的复杂情况(网络,其他团队服务可用性等),并以可重复的方式模拟任何场景(超时,Down机,SSL验证失败,丢失HTTP头,请求响应不匹配等),运行稳定,且反馈周期短。
以上就是极悦小编介绍的"不得不说的微服务测试",希望对大家有帮助,想了解更多可查看Java教程。极悦在线学习教程,针对没有任何Java基础的读者学习,让你从入门到精通,主要介绍了一些Java基础的核心知识,让同学们更好更方便的学习和了解Java编程,感兴趣的同学可以关注一下。
你适合学Java吗?4大专业测评方法
代码逻辑 吸收能力 技术学习能力 综合素质
先测评确定适合在学习