1. 先说一个普遍存在的“测试环境焦虑”在微服务架构成为主流的这些年团队里最折磨人的往往不是业务代码本身而是“测试环境”。服务拆到几十个之后维护一套集中式测试环境的成本已经高到让人怀疑人生每个团队共享一套环境有人正在跑数据造数有人顺手改了配置还有人把服务停掉换版本结果你辛辛苦苦跑了一条业务流最后红在了一个跟代码毫无关系的环境污染上。“无需测试环境”这个思路本质上是把“测试环境”从一个长期存在的固定资产变成一种按需生成、用完即焚的计算资源。核心手段就是测试脚手架把被测微服务真实启动出来把它依赖的周边服务在协议层用可控的替身撑住然后在这个临时拼装出来的迷你环境里跑功能自动化。说白了你不是没有环境而是不再把环境当成一个需要运维去维护、需要排序等待的共享资源。这样做有一个很直接的好处确定性和可复现性。集中测试环境之所以让人头大本质上是因为所有依赖都是共享的、不受控的。测试脚手架把“被测对象”和“外部依赖”的边界往回收被测服务是真实代码依赖是替身数据是自己初始化的用例跑完环境销毁。每次红就是代码红、契约红而不是“环境红”。这篇文章主要面向正在被测试环境问题困扰的测试开发、后端开发、DevOps 同学。脚手架的思想不绑定语言以下示例我会以 JVM 生态为主因为 Testcontainers、WireMock、Spring Cloud Contract 这组工具在微服务测试里确实最成熟但对应的思路完全可以迁移到 Go、Node.js 等其他技术栈。2. 测试脚手架到底是什么跟 Mock 不是一回事先把这个概念摆清楚。测试脚手架Test Scaffolding这个词借自建筑工程工地上搭的脚手架不改变房屋结构只是给施工人员在特定高度提供临时的支撑平台。软件测试里的脚手架也是一样为了验证某个服务或者某条业务链路临时搭建一套支撑设施包括被测服务的启动方式、依赖替身、测试数据种子、自动化入口用完之后拆掉。很多人一听到“用替身模拟依赖”就以为是在讲 Mock其实两者粒度完全不同。单元测试里的 Mock 是进程内的把外部依赖直接替换成一个对象验证的是方法层的逻辑测试脚手架里的替身则是进程外的它运行在独立的容器或进程里被测服务通过真实的网络协议去调用它。换句话说被测服务根本不知道自己在跟替身说话它走的还是 HTTP/gRPC、连接池、超时重试那一整套真实链路。为什么这个区别很重要因为功能自动化的目标是验证“服务作为一个独立进程在真实部署形态下是否正常工作”。如果依赖全部 Mock 在进程内那网络异常、超时、序列化、连接池耗尽这些真实场景全部被掩盖了。而用脚手架的方式被测服务启动后就完全处于真实运行状态只是它的下游被替换成了可控的服务桩这才能等价于“在生产环境里调用一个固定返回的下游”。我习惯叫这种做法“伪端到端”测试被测服务本身端到端地真实运行业务链路跑通到外围依赖为止。外围依赖不真实但对外围的每次调用都真实发生而且可以被断言、被注入故障、被记录报文。这里顺带说明一个边界测试脚手架适合功能自动化、接口自动化、契约验证和业务流验证不适合压测、全链路联调、性能摸底。压测要求真实容量全链路联调要求所有真实服务都在场。脚手架解决的是“功能对不对”的问题不解决“性能高不高”的问题。3. 隔离边界怎么划哪些依赖必须真实哪些可以做替身这是整套方案里最核心、也是最容易拍脑袋的地方。我的经验是不要为了追求“隔离”就把所有东西都 Mock 掉也不要为了追求“真实”就把所有服务都拉起来。正确做法叫“按断言边界切分”。先给一个我常用的判断表格依赖类型推荐做法原因被测服务自己的数据库真实中间件推荐容器化镜像SQL 方言、事务、锁、唯一约束是功能的一部分Mock 数据库会漏掉一堆真实问题被测服务自己的缓存轻量嵌入式或容器化 Redis 等缓存语义过期、逐出策略会影响业务逻辑不能当成无脑 KV下游业务服务协议层替身WireMock / MockServer / Stub下游只要返回协议约定的结果被测服务的行为就应该确定消息队列业务状态强相关尽量真实内存版或容器版消息的异步性、顺序、重试是业务逻辑的一部分消息队列旁路通知型替身断言发送即可跟断言目标无关只关心“有没有发”第三方外部系统短信、邮件、支付回调替身记录调用参数外部不可控且不能依赖真实环境替身可以构造各种返回划这条线的底层逻辑是凡是跟被测服务的“内部事实来源”强相关的组件应该真实。什么是内部事实来源业务状态的存储和流转。比如订单服务的数据库、支付服务的账户余额这些必须真实因为 SQL 写错了、事务没提交、锁冲突了在 Mock 上是测不出来的。凡是跟被测服务“互动但不需要持久化”的下游可以做替身因为被测服务只关心协议层的返回。为什么要在协议层切断而不是在代码层切断这涉及到服务调用的本质。微服务之间通过 HTTP/gRPC 交互调用方眼里只存在“接口契约”——你给我什么参数返回什么结构什么状态码多快返回。只要替身遵守同一个契约被测服务在业务逻辑上就不会区分真假。这就是协议层替身能够成立的根本原因。切断点定在协议层还有一个额外收益被测服务代码零改动环境变量改一下地址就能切换真下游或替身。顺着这个思路脚手架的替身不能“手搓”。最理想的来源是契约测试的产物比如 Spring Cloud Contract 生成的 Stub JAR或者从真实服务录制的流量回放文件。原因很简单手写的替身容易跟真实接口产生漂移——你以为下游返回这个结构实际返回的是另一个那被测服务的正确逻辑也可能测出一个错误结果。契约测试的价值就在于把接口契约固化成可执行产物脚手架直接从契约生成替身两边永远一致。也正是因为切断点在协议层脚手架才能轻松实现独立测试环境很难做到的故障注入。真实环境里你想测“下游超时”“下游返回500”“下游熔断”得求着运维去配置而在脚手架里替身的配置文件改一行就能把响应延迟加到设好的值或者直接返回错误。这对于验证重试逻辑、熔断降级、超时处理特别有用。4. 落地一套测试脚手架的全过程理论说完直接上一套可以照抄的落地过程。我拿一个典型场景举例被测服务是 order-service它依赖 user-service、payment-service、message-service自身使用 PostgreSQL 和 Redis。目标是在本地和 CI 里都只启动固定容器不依赖公司集中测试环境跑通“下单全流程”的功能自动化。4.1 第一步定义“真实组件 替身组件”的清单先列一张组件清单明确哪些用真实容器哪些用替身容器组件形态说明order-service被测服务真实进程本地直接跑 IDE 或构建镜像PostgreSQL真实容器订单表结构必须真实Redis真实容器缓存逻辑需要真实语义user-serviceWireMock 替身用户查询接口返回固定契约数据payment-serviceWireMock 替身预授权/支付接口返回成功、失败、超时等场景message-serviceMockServer 替身断言消息发送参数不真正发送清单是脚手架的地基。别上来就先写代码先把“哪些东西必须真”和“哪些东西可以用假”定下来后面所有配置都围绕这张表展开。4.2 第二步准备被测服务的脚手架配置被测服务的正常运行配置叫 application.yml脚手架运行配置叫 application-scaffold.yml。这个 profile 专门给自动化测试使用里面的核心变化就是下游地址。先看 order-service 的配置片段# application-scaffold.yml server: port: 0 # 随机端口避免冲突 spring: datasource: url: ${ORDER_DB_URL} username: ${ORDER_DB_USER} password: ${ORDER_DB_PASSWORD} redis: host: ${ORDER_REDIS_HOST} port: ${ORDER_REDIS_PORT} app: user-service: url: ${USER_SERVICE_URL} # 指向 WireMock 容器 payment-service: url: ${PAYMENT_SERVICE_URL} # 指向 WireMock 容器这里有几个经验点。第一server.port 不要写死用 0 表示随机端口测试代码再从 Spring 上下文里取实际的端口。第二数据库、Redis、下游地址全部走环境变量注入这样同一套配置在本地和 CI 都能用只需要环境变量不同。第三把这个 profile 加到被测服务的构建配置里如果服务本身藏着依赖 Spring Cloud 配置中心脚手架 profile 要绕开或者提供本地配置源不要让测试运行到一半去连一个不属于脚手架的东西。4.3 第三步用 Testcontainers 把整个脚手架跑起来如果只用 Docker Compose也能实现“启动一组容器”但 Testcontainers 的进阶价值在于它可以跟测试框架的生命周期绑定测试结束自动销毁容器还能在 CI 里为每次构建拉起一套全新的实例。这是“确定性”的保障——用例之间互不污染上一轮跑挂了下一次又是全新环境。下面是一段典型测试基类的代码片段Testcontainers SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT) class OrderScaffoldTestBase { Container static PostgreSQLContainer? postgres new PostgreSQLContainer(postgres:16-alpine) .withDatabaseName(order_db) .withUsername(test) .withPassword(test); Container static GenericContainer? redis new GenericContainer(redis:7-alpine) .withExposedPorts(6379); Container static WireMockContainer userServiceStub new WireMockContainer(wiremock/wiremock:3.5.0) .withMappingFromResource(user-service-stubs.json); Container static WireMockContainer paymentServiceStub new WireMockContainer(wiremock/wiremock:3.5.0) .withMappingFromResource(payment-service-stubs.json); DynamicPropertySource static void reserveProps(DynamicPropertyRegistry registry) { registry.add(spring.datasource.url, postgres::getJdbcUrl); registry.add(spring.datasource.username, postgres::getUsername); registry.add(spring.datasource.password, postgres::getPassword); registry.add(spring.redis.host, redis::getHost); registry.add(spring.redis.port, () - redis.getMappedPort(6379)); registry.add(app.user-service.url, () - http:// userServiceStub.getHost() : userServiceStub.getMappedPort(8080)); registry.add(app.payment-service.url, () - http:// paymentServiceStub.getHost() : paymentServiceStub.getMappedPort(8080)); } }DynamicPropertySource 是 SpringBoot 测试里最顺手的一个钩子它把容器动态映射出来的端口实时注入到测试上下文。注意看 WireMock 串整个流程的价值被测服务根本不知道 user-service 是一个跑在容器里的替身它只是按配置发起了一个 HTTP 调用返回值完全可控。针对“数据库要不要用 H2 模拟”这个问题我的答案很直白如果被测服务用的是 PostgreSQL测试就要上 PostgreSQL 镜像。H2 的兼容模式能蒙混过大部分 CRUD但一旦业务里用了 JSON 字段、特定函数、行级锁、部分索引语法就会在本地测试通过、生产环境炸掉的反差里吃大亏。Testcontainers 多花几秒钟拉镜像换回来的是数据库行为完全一致。4.4 第四步写好替身契约文件替身不是拿着“随便返回 OK”就完了。我的建议是所有替身映射文件来源于真实契约至少要是下游接口文档的忠实实现。下面是一个订单流程里 user-service 的替身定义片段{ request: { method: GET, url: /api/users/1001 }, response: { status: 200, jsonBody: { userId: 1001, name: ScaffoldUser, level: NORMAL, balance: 5000 }, headers: { Content-Type: application/json } } }每次给替身加接口第一件事是确认真实接口的响应结构。最稳的方式是从下游服务导出契约文件或者至少把真实接口在旧环境里跑一次把响应存成模板。手动编字段也不是不行但字段名写错了被测服务的反序列化就会失败这时候你查半天可能还在怀疑自己的业务代码。除了正常返回我还建议在替身里预留“故障场景”映射。WireMock 支持按请求头或 URL 参数路由到不同响应所以可以用同一个替身容器提供两种行为正常的 user-service 和 timeout 的 payment-service。做法很简单给故障场景加一个独立映射路径测试代码里通过环境变量切换或者直接给被测服务一个不同的下游地址。4.5 第五步跑真实的业务流用例脚手架搭好之后写自动化用例就轻松了。看一个典型的“下单全流程”用例的逻辑Test void shouldCreateOrderAndCallPayment() { // 调用被测服务的创建订单接口 String requestBody { userId: 1001, productId: P001, quantity: 2 } ; Response response RestAssured.given() .contentType(ContentType.JSON) .body(requestBody) .post(/api/orders); assertThat(response.statusCode()).isEqualTo(201); assertThat(response.jsonPath().getString(status)).isEqualTo(CREATED); // 验证替身确实收到了支付预授权请求 userServiceStub.verify( WireMock.getRequestedFor(WireMock.urlPathEqualTo(/api/users/1001)) .withHeader(Authorization, WireMock.containing(Bearer)) ); paymentServiceStub.verify( WireMock.postRequestedFor(WireMock.urlPathEqualTo(/api/payments/pre-auth)) .withRequestBody(WireMock.matchingJsonPath($.orderId, WireMock.equalTo(...))) ); // 验证真实数据库落库 jdbcTemplate.queryForObject(select count(*) from orders where ..., Long.class); }这个用例有三个关键点。第一它验证了真实的 HTTP 调用链路从请求进入到拿到返回全程没有进程内 Mock网络层面的序列化、连接、超时都真实发生。第二它对替身的调用做了 verify这保证了被测服务确实以正确的报文调用了下游而不只是“自己返回了正确答案”。第三它直接查真实数据库做断言把业务状态的最终事实关在数据库里。三层断言下来这个功能的可靠性就非常扎实。业务流用例不需要太多一条主流程加几条关键分支下游超时、下游 500、库存不足就够了。太多反而会陷入维护泥潭。脚手架的价值在于把“环境不干净”这个最大的干扰变量干掉用例数量的价值才能被释放出来。4.6 第六步接入 CI 流水线最后一步是让脚手架进入日常开发流程。集中测试环境时代的逻辑是“代码合并后部署到测试环境才能跑自动化”脚手架时代的逻辑变成“拉一个 PR 就拉起一套临时环境跑自动化”。GitLab CI 的一个典型 job 可以这样设计stages: - test-scaffold scaffold-functional-test: stage: test-scaffold image: maven:3.9-eclipse-temurin-17 services: - docker:dind script: - mvn test -Dgroupsscaffold after_script: - docker compose logs scaffold-logs.txt || true artifacts: when: always paths: - scaffold-logs.txt tags: - docker跑完测试之后不管成功失败把容器日志留成 artifact 作为失败现场这是排查问题的生命线。要特别注意 CI worker 上的 Docker 资源限制一次性拉起多个容器内存不够就会随机杀容器这类问题容易跟用例失败混在一起。建议在容器编排层加上资源限制确保每个容器拿到的内存是固定的。5. 典型问题排查与避坑实录脚手架方案看着清爽真正落地时你会遇到一批很有共性的问题。下面是我实际踩坑总结出来的速查表。现象原因解决办法本地能过CI 必挂端口写死或依赖本地资源所有端口走动态映射不得在配置里写死测试偶发报 SQL 语法错误用了 H2 模拟生产数据库换 Testcontainers 真实镜像替身返回的数据被被测服务反序列化失败替身字段和真实接口漂移契约测试生成 Stub不从手写开始下游超时用例测不到替身响应太快没触发超时分支在替身里配置固定延迟用例跑完数据污染下一轮没有清理测试数据每个用例独立数据库 Schema 或独立容器容器被随机杀掉CI 内存不足限制并发测试数量配置容器资源上限替身收到重复请求被测服务执行了重试在验证逻辑里允许大于等于 1 的调用次数或者断言重试策略本身第一个问题是最常见的也是最让人挫败的。微服务开发阶段习惯在配置里写死 localhost:8080 这样的地址Knock 到了脚手架环境被测服务去连 localhost 时连的是自己容器或者测试进程的本机连不上就是一片红。根治的办法是花一天时间把所有配置全部改成环境变量注入。第二个问题值得展开。H2 确实很轻最开始我也用过直到一个业务字段用了 PostgreSQL 的 JSONB 类型H2 直接报错。后来测试库统一走真实镜像问题就消失了。如果你们用的是 MySQL那就上 MySQL 镜像别在数据库上省这几秒。第三个问题要引入信任链。替身一旦跟真实接口漂移脚手架上的自动化就测了个寂寞。我后来的标准做法是所有下游服务的替身映射文件必须产出自契约测试至少也是录制回放生成不允许手写。这样替身的正确性由契约测试保证脚手架的可信度才立得住。还有一个容易让新人懵的场景被测服务有重试机制支付替身第一次返回 500第二次返回 200。被测服务自己重试成功了但你在 verify 里断言“只调用了一次”就红。这时候你要想清楚自己的断言目标。如果你想验证重试逻辑那就断言调用次数大于等于 2如果你只关心最终结果那就别断言次数只断言状态。排查工具上也有一点建议。一定要给微服务加上全链路 traceId在本地脚手架里也要打日志。场景是一个请求跨了 order-service 和它调用的替身如果两边日志不带 traceId你根本没法把请求对应起来。WireMock 本身会记录所有收到的请求把这个文件在失败时导出能直接看到被测服务到底发来了什么报文。对了还有一个坑替身容器的启动顺序。如果被测服务启动时就会在初始化阶段调用下游而替身还没就绪服务会直接启动失败。这时候要用健康检查机制等 WireMock 返回 200 再让被测服务启动。Testcontainers 里可以用 waitingFor 配置正儿八经的容器场景里一般用 docker compose 的 depends_on condition: service_healthy。6. 最后聊几句我的经验这套测试脚手架的做法我建议你从一个小业务开始试点不要试图一次性把全部微服务都搬过来。挑一个链路最短的服务写好一个关键用例让它在本地跑通、在 CI 跑通再逐步扩展。我见过很多团队一上来就定了很大的目标最后都折在复杂度里反而是从一条链路先跑通的团队走得更远。我还想特别说一个体会脚手架方案最大的收益不是省了多少测试环境服务器而是让失败信息恢复了它本该有的含义。以前自动化用例一红大家先怀疑环境消耗半天再定位到代码问题。现在红就是代码问题、契约问题或替身配置问题三种情况都有清晰的排查路径。排查成本降下来之后团队对自动化的信任度提升了这个信任比那几台服务器值钱得多。另外一个一直有用的习惯是每次脚手架的失败现场必须保留下来。不管是用例失败时的容器日志、WireMock 请求记录还是数据库快照全存成 CI 的 artifact。很多偶发问题当时看不出规律攒上几次之后比对一下原因就很明显了。我之前遇到过的好几个“偶发”问题最后都是靠对比几次失败现场的 WireMock 请求记录找到的——原来替身收到了预期之外的重复请求。最后再分享一个小技巧把脚手架的定义本身当成产品代码一样去维护。它值得一份 README、一个版本号、一个有明确的负责人。因为它是开发、测试、CI 三方共享的基础设施一旦烂掉所有跑在它上面的用例都会跟着烂。当成产品维护它才会越来越稳定这也是“无需测试环境”这个理念真正落地的前置条件。