不得不说的微服务测试
2018-08-25 本文已影响170人
魔镜的技术心经
在微服务架构下，给我们测试带来了如下挑战：
- 验证成本高，为了验证多个服务协作后的功能正确与否，需要为每个服务搭建基础设施（包括数据库、缓存等），并执行部署、配置等步骤，以确保服务能正确运行。
-
结果不稳定， 分布式系统，服务之间的通信都是通过网络调用，然而在网络上传送，都会面临
网络延时、超时、带宽等因素，容易导致不稳定的测试结果。 - 反馈周期长， 相比单体应用而言，微服务架构下，可独立部署的单元多，因此集成测试的反馈周期比之前会更长，定位问题的时间就会更久。
- 沟通成本高， 微服务常由不同团队开发并维护，当服务频繁进行改动和版本升级的时候，很容易导致不兼容，加大团队之间的沟通成本。
测试金字塔
image.png
测试金字塔很好的帮助我们在制定测试策略的时候，区分不同层次测试关注点，同时，一般来说，测试颗粒度越粗，越脆弱，执行的时间越长，维护成本也越高。
不得不说的契约测试
在微服务中，不得不聊聊消费者契约测试，
契约，一种定义在Consumer与Provider之间的交互方式
消费者驱动的契约测试
image.png
契约是Consumer和Provider团队之间达成的交互协议，更多的看中的是请求和响应的Payload结构（Schema），由服务消费者构建并生成contract，然后将contact上传到Pact broker or server； 对应的服务提供者，需要在Pipeline中，有一个task进行契约的验证，保证契约不会被破坏。
契约测试的好处
- 测试分层，Consumer和Provider分别测试。
-
测试前移，为Consumer提供Mock，不需要真实的集成环境，
稳定性高。 -
反馈周期短，单元测试级别，测试运行快，
毫米级。 - 沟通成本底
为服务消费者提供了信心，更为服务提供者提供了更大的价值（通过与不同消费者约定的契约，可以保证服务安全的升级变迁，不会破坏之前已有的功能）
image.png
契约测试的应用场景
- 一个服务需要被多个消费者使用，每个消费者的诉求并不完全一样（一对一的场景，没有太大意义）。
- 服务消费者与服务提供者由不同的团队开发维护。
- 服务消费者与服务提供者，一定要对契约达成一致，并一直保持这种
约束（如果有一方没有遵守，比如提供者根本不将契约验证集成到流水线中，那么就没有任何意义），契约的不符合预期的变化应当会造成测试的失败。
应该关注
- 检查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头，请求响应不匹配等），运行稳定，且反馈周期短。
