---
tags:
  - MQ
  - 测试
  - 集成测试
  - 契约测试
create time: 2026-05-24 19:52
---

# MQ 测试策略

## 概述

MQ 的测试面临异步性、消息顺序、环境依赖等独特挑战。本文从单元测试到混沌工程，逐层介绍 MQ 测试策略，重点讲解 Testcontainers 集成测试、Pact 契约测试和影子流量等实践方法。

## 正文

### MQ 测试的挑战

和同步的 HTTP API 相比，MQ 测试难在哪里？

1. **异步性**：消息发送后不立即得到结果，如何验证消息被正确处理？
2. **消息顺序**：测试时如何保证消息的顺序和幂等性？
3. **环境依赖**：没有真实的 Broker，很多行为无法验证（如 Partition 路由、Consumer Group Rebalance）
4. **分布式一致性**：跨多个服务的事件流转，如何端到端验证？

> [!question]
> 传统 API 测试可以用 `assert response.status == 200`。但 MQ 中，消息发出去后"成功"意味着什么？是 Broker 收到？还是被消费者处理完？

### 测试金字塔在 MQ 场景的应用

```mermaid
graph TD
    subgraph Pyramid["MQ 测试金字塔"]
        E2E["E2E 测试 - 完整集群 + 多服务"]
        Integration["集成测试 - Testcontainers 真实 Broker"]
        Contract["契约测试 - Pact 消息契约"]
        Unit["单元测试 - Mock Producer/Consumer"]
    end
    Unit -->|"快速, 大量"| Contract
    Contract -->|"契约保证兼容"| Integration
    Integration -->|"真实环境验证"| E2E
```

### 单元测试：Mock 接口，验证逻辑

单元测试的核心是将消息处理逻辑与 Broker 解耦。在 Go 中，通过接口抽象 Producer 和 Consumer：

```go
// 定义接口，方便 Mock
type MessageProducer interface {
	Send(ctx context.Context, topic string, key, value []byte) error
}

type OrderHandler struct {
	producer MessageProducer
}

// 处理订单创建事件的业务逻辑
func (h *OrderHandler) HandleOrderCreated(ctx context.Context, event OrderEvent) error {
	if event.Amount <= 0 {
		return fmt.Errorf("invalid amount: %d", event.Amount)
	}
	// 发送支付请求事件
	payment := PaymentEvent{OrderID: event.ID, Amount: event.Amount}
	data, _ := json.Marshal(payment)
	return h.producer.Send(ctx, "payment-requests", []byte(event.ID), data)
}

// 单元测试：Mock Producer 验证业务逻辑
func TestOrderHandler_HandleOrderCreated(t *testing.T) {
	mock := &MockProducer{} // 实现 MessageProducer 接口
	handler := &OrderHandler{producer: mock}

	event := OrderEvent{ID: "order-1", Amount: 100}
	err := handler.HandleOrderCreated(context.Background(), event)

	assert.NoError(t, err)
	assert.Equal(t, "payment-requests", mock.LastTopic())
	assert.Equal(t, "order-1", mock.LastKey())
}
```

单元测试快速且无外部依赖，但只能验证业务逻辑，无法保证消息格式与下游兼容。

### 集成测试：Testcontainers 启动真实 Broker

Mock 测试不到的问题——Partition 路由、序列化、Consumer Group 行为——需要真实 Broker。Testcontainers 在测试中启动真实的 Docker 容器：

```go
package main

import (
	"context"
	"testing"
	"time"

	"github.com/IBM/sarama"
	"github.com/testcontainers/testcontainers-go"
	"github.com/testcontainers/testcontainers-go/modules/kafka"
)

func TestKafkaIntegration(t *testing.T) {
	ctx := context.Background()

	// 启动真实的 Kafka 容器
	kafkaContainer, err := kafka.Run(ctx,
		"confluentinc/confluent-local:7.5.0",
	)
	if err != nil {
		t.Fatal(err)
	}
	defer kafkaContainer.Terminate(ctx)

	// 获取 Broker 地址
	brokers, _ := kafkaContainer.Brokers(ctx)

	// 创建 Producer 发送消息
	config := sarama.NewConfig()
	config.Producer.Return.Successes = true
	producer, _ := sarama.NewSyncProducer(brokers, config)
	defer producer.Close()

	msg := &sarama.ProducerMessage{
		Topic: "test-topic",
		Value: sarama.StringEncoder("hello kafka"),
	}
	partition, offset, err := producer.SendMessage(msg)
	if err != nil {
		t.Fatalf("send failed: %v", err)
	}

	// 创建 Consumer 消费并验证
	config2 := sarama.NewConfig()
	config2.Consumer.Offsets.Initial = sarama.OffsetOldest
	consumer, _ := sarama.NewConsumer(brokers, config2)
	defer consumer.Close()

	pc, _ := consumer.ConsumePartition("test-topic", partition, offset)
	select {
	case msg := <-pc.Messages():
		if string(msg.Value) != "hello kafka" {
			t.Errorf("unexpected message: %s", msg.Value)
		}
	case <-time.After(10 * time.Second):
		t.Fatal("timeout waiting for message")
	}
}
```

这段测试用 Testcontainers 自动拉起 Kafka 容器，发送一条消息后立即消费验证。整个过程在 CI 中无需预置环境，测试结束自动清理容器。

### 消息契约测试

在事件驱动架构中，Producer 和 Consumer 通过消息格式（Schema）解耦。但如果 Producer 改了字段名，Consumer 就会崩溃。**契约测试**解决这个问题。

Pact 框架的工作流程：
1. **Consumer 端**定义期望的消息格式（契约）
2. **Producer 端**验证自己产生的消息满足所有 Consumer 的契约
3. 契约存储在 Pact Broker 中，CI 中自动验证

> [!question]
> 消息契约测试和传统的 API 测试有什么本质区别？为什么在事件驱动架构中更重要？

关键区别在于：API 测试验证的是"请求-响应"的一对一关系，而消息契约验证的是"事件-消费者"的一对多关系。一个事件可能被 5 个服务消费，任何格式变更都必须向后兼容。

### 影子流量（Shadow Testing）

将生产流量复制到测试环境，验证新版本的消息处理逻辑是否正确，而不影响真实业务。

实现方式：
- Producer 端使用拦截器，将消息副本发送到 Shadow Topic
- Shadow Consumer 消费并处理，对比结果
- 关键：Shadow 消费者的处理结果**不会写入生产数据库**

### 故障注入

Chaos Engineering 在 MQ 场景的应用：

- **Kill Broker**：随机杀掉一个 Broker，验证 Producer/Consumer 的自动故障转移
- **网络分区**：模拟 Broker 之间网络隔离，验证脑裂防护
- **消息延迟注入**：人为增加 Broker 响应延迟，验证超时和重试机制
- **磁盘满**：模拟磁盘空间不足，验证告警和降级策略

## 关联笔记

- [[40-MQ-性能调优]]
- [[42-MQ-认证与授权]]
- [[39-MQ-容器化与-K8s-部署]]