测试环境管理实战——多环境配置、测试数据清理、数据库 Schema 管理

适读人群：Java 后端开发者、DevOps 工程师 | 阅读时长：约 16 分钟 | 核心价值：建立一套稳定可重复的测试环境管理体系，彻底告别"我机器上能跑"的困境

"在我机器上是好的"——这句话在我们团队一度是个禁忌词，谁说谁被挂上一块耻辱牌。

背景是这样的：我们有段时间维护了三套环境（开发、测试、生产），每套环境的数据库 Schema 版本都不一样，测试数据也各行其是。开发环境加了新字段没有同步脚本，测试环境缺少某张表，生产环境还在用两个月前的旧 Schema。

最灾难的一次：一个需求开发完，本地测试通过，推到测试环境，测试工程师一运行，数据库字段不存在报错，停下来等 DBA 同步 Schema，花了半天时间。推到生产，又发现生产环境的某个字段类型不对，和开发时的假设不一样，临时回滚。

这一切的根源：没有一套系统性的测试环境管理体系。

今天这篇，把我们团队建立这套体系的完整过程和方法论写出来。

---

一、多环境配置体系

Spring Boot 的 Profile 分层

src/main/resources/
├── application.yml                 # 公共配置（所有环境共享）
├── application-dev.yml             # 开发环境
├── application-test.yml            # 集成测试环境
├── application-staging.yml         # 预生产环境
└── application-prod.yml            # 生产环境

src/test/resources/
├── application-test.yml            # 测试专用覆盖（继承 main 里的 test 配置）
└── application-integrationtest.yml # 集成测试专用

公共配置 application.yml（不包含任何环境特定值）：

spring:
  application:
    name: order-service
  jpa:
    hibernate:
      ddl-auto: validate  # 生产环境不允许自动建表
    show-sql: false
    open-in-view: false

logging:
  level:
    root: INFO
    com.example: INFO

测试环境配置 src/test/resources/application-test.yml：

spring:
  jpa:
    hibernate:
      ddl-auto: none  # 由 Flyway/Liquibase 管理 Schema
    show-sql: true    # 测试时打印 SQL 方便调试
  datasource:
    # url/username/password 由 Testcontainers @DynamicPropertySource 注入
    hikari:
      maximum-pool-size: 5  # 测试环境缩小连接池
      minimum-idle: 1
  flyway:
    enabled: true
    locations: classpath:db/migration,classpath:db/testdata
    # 测试环境额外加载 testdata 目录的数据

logging:
  level:
    org.springframework.test: DEBUG
    com.example: DEBUG

# 测试环境关闭不需要的功能
management:
  endpoint:
    health:
      show-details: never

app:
  email:
    enabled: false    # 测试环境不真实发邮件
  sms:
    enabled: false    # 测试环境不真实发短信
  kafka:
    topic:
      prefix: "test-"  # 所有 Topic 加 test- 前缀，避免和生产混

---

二、数据库 Schema 管理：Flyway 完整方案

Flyway 迁移脚本规范

src/main/resources/db/migration/
├── V1__init_schema.sql
├── V2__add_user_table.sql
├── V3__add_order_table.sql
├── V4__add_index_on_order_user_id.sql
└── V5__add_promotion_price_to_product.sql

src/test/resources/db/testdata/
├── R__test_categories.sql    # R__ 前缀：可重复执行的 SQL（基础字典数据）
├── R__test_roles.sql
└── B__test_baseline.sql      # B__ 前缀：基线数据（首次运行时执行）

V1__init_schema.sql 示例：

-- 用户表
CREATE TABLE users (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    email VARCHAR(100) NOT NULL UNIQUE,
    username VARCHAR(50) NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    status ENUM('ACTIVE', 'INACTIVE', 'BANNED') NOT NULL DEFAULT 'ACTIVE',
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_users_email (email),
    INDEX idx_users_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- 商品表
CREATE TABLE products (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    price DECIMAL(10, 2) NOT NULL,
    stock INT NOT NULL DEFAULT 0,
    status ENUM('ACTIVE', 'INACTIVE', 'OUT_OF_STOCK') NOT NULL DEFAULT 'ACTIVE',
    category_id BIGINT,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

测试基础数据 R__test_categories.sql：

-- 删除旧数据，重新插入（R__ 脚本每次都执行）
DELETE FROM categories;

INSERT INTO categories (id, name, status) VALUES
(1, '手机数码', 'ACTIVE'),
(2, '电脑办公', 'ACTIVE'),
(3, '服饰鞋包', 'ACTIVE'),
(4, '食品饮料', 'ACTIVE');

---

三、完整的测试环境初始化

@SpringBootTest
@Testcontainers
@ActiveProfiles("test")
public abstract class AbstractIntegrationTest {

    @Container
    static final MySQLContainer<?> MYSQL = new MySQLContainer<>("mysql:8.0.36")
            .withDatabaseName("testdb")
            .withUsername("testuser")
            .withPassword("testpass")
            .withCommand(
                    "--character-set-server=utf8mb4",
                    "--collation-server=utf8mb4_unicode_ci",
                    "--default-time-zone=+08:00"
            )
            .withReuse(true);

    static {
        MYSQL.start();
    }

    @DynamicPropertySource
    static void configureDataSource(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", MYSQL::getJdbcUrl);
        registry.add("spring.datasource.username", MYSQL::getUsername);
        registry.add("spring.datasource.password", MYSQL::getPassword);
        registry.add("spring.datasource.driver-class-name",
                () -> "com.mysql.cj.jdbc.Driver");
    }

    @Autowired
    protected JdbcTemplate jdbcTemplate;

    protected void cleanAllTables() {
        jdbcTemplate.execute("SET FOREIGN_KEY_CHECKS = 0");
        // 按依赖顺序清理
        List.of("order_items", "orders", "products", "users")
                .forEach(table ->
                        jdbcTemplate.execute("TRUNCATE TABLE " + table));
        jdbcTemplate.execute("SET FOREIGN_KEY_CHECKS = 1");
    }
}

---

四、三个踩坑实录

坑 1：Flyway 迁移脚本校验和不一致

现象： CI 环境报 FlywayException: Validate failed: Migration checksum mismatch for migration version 3，本地却能正常启动。

原因： 有人修改了已经执行过的 Flyway 迁移脚本（V3__xxx.sql）来修复错误，导致文件内容和数据库里记录的校验和不一致。

解法：

1. 永远不要修改已执行的 Flyway 迁移脚本，而是创建新的脚本（V4__fix_xxx.sql）
2. 如果真的需要修复，只能修改 Flyway 表里的校验和记录（极不推荐，仅限紧急情况）

// 如果只是测试环境需要快速修复，可以配置出错时继续
// 但生产环境不要这样做
registry.add("spring.flyway.validate-on-migrate", () -> "false");  // 仅测试时用

---

坑 2：多测试类并行运行时 Flyway 重复初始化

现象： 并行跑多个测试类，Flyway 报 Unable to acquire Flyway advisory lock，某些测试失败。

原因： 多个 Spring 上下文同时启动，都尝试运行 Flyway 迁移，但 Flyway 用数据库锁保证单次执行，并发时会有死锁或超时。

解法： 在基类里确保 Flyway 只运行一次：

// 方式一：用静态容器 + @DirtiesContext(classMode = BEFORE_CLASS)
// 确保所有测试类共享同一个 Spring 上下文（不重复初始化）

// 方式二：在测试专用配置里设置更长的锁超时
registry.add("spring.flyway.lock-retry-count", () -> "10");

// 方式三：关闭 Flyway，手动在 @BeforeAll 里执行（完全掌控）
@BeforeAll
static void initDatabase() {
    Flyway flyway = Flyway.configure()
            .dataSource(MYSQL.getJdbcUrl(), MYSQL.getUsername(), MYSQL.getPassword())
            .locations("classpath:db/migration", "classpath:db/testdata")
            .load();
    flyway.migrate();
}

---

坑 3：测试 Profile 配置被生产配置覆盖

现象： 明明用了 @ActiveProfiles("test")，但某些配置还是读到了 production 的值。

原因： Spring Boot 的配置优先级：application-test.yml 中的配置会覆盖 application.yml，但如果有环境变量（高于配置文件），环境变量里的值不会被 profile 覆盖。

解法： 检查 CI 环境变量，不要在环境变量里设置应该由测试 profile 管理的配置：

# CI 环境的 pipeline 配置
env:
  # 不要在这里设置 SPRING_DATASOURCE_URL
  # 让 Testcontainers 的 DynamicPropertySource 来设置
  SPRING_PROFILES_ACTIVE: test  # 只设置这个

---

五、CI 环境隔离配置

# .github/workflows/test.yml
jobs:
  integration-test:
    runs-on: ubuntu-latest
    env:
      SPRING_PROFILES_ACTIVE: test
      TESTCONTAINERS_RYUK_DISABLED: false  # 启用 Ryuk（自动清理容器）
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      # 预热镜像
      - name: Pull Docker images
        run: |
          docker pull mysql:8.0.36
          docker pull redis:7.2-alpine

      # 运行集成测试
      - name: Run integration tests
        run: mvn verify -P integration-test -Dfailsafe.rerunFailingTestsCount=1

      # 上传测试报告
      - name: Upload test reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-reports
          path: |
            **/target/surefire-reports/
            **/target/failsafe-reports/

---

六、Schema 变更的安全发布流程

每次数据库 Schema 变更，遵循这个流程：

1. 写迁移脚本：新建 V{版本号}__{描述}.sql
2. 本地验证：在本地 Testcontainers 环境里跑迁移，确认无误
3. 集成测试通过：所有使用到该 Schema 的集成测试通过
4. Code Review：SQL 脚本和代码变更一起 Review
5. 迁移到测试环境：先在测试环境执行迁移
6. 灰度到生产：分批次迁移生产环境

这个流程看起来繁琐，但每一步都是防线。

测试环境管理的本质，是让"我机器上能跑"变成一句废话——因为所有环境都应该是一样的，都是由代码定义的，可重复的，可验证的。