分类频道
测试工程
该分类下的文章、提问与讨论帖。
一、现象或背景：CI 跑用例慢到影响研发体验 我维护的 B 端 SaaS 接口测试套件（Java 17 + JUnit 5.10 + Testcontainers + PostgreSQL 15）有 1380 个用例，串行执行耗时 47 分
一、现象或背景（遇到什么、影响多大，带具体数字或规模） 做了 8 年测试开发，最近被 PM 问了一句特别扎心的话：「你们接口自动化跑了 2000 条用例，CI 要 40 分钟，但上个月 3 次线上事故，没有一次是被接口自动化拦住的——那这
现象或背景 在接口自动化测试中，时间依赖是最难处理的隐式全局依赖之一。我负责的结算/账务链路接口套件包含 300 条用例，其中 40 条强依赖「真实时间」： - 订单 T+1 才允许发起结算（12 条）、优惠券次日 00:00 生效（9 条
【背景】 3 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + Spring Boot 3.2 + MySQL 8.0.34），接口自动化 pytest 7.4 + httpx 约 900 条用例，跑在 5
现象与背景：并发测试偶现失败，最贵 在测试开发工作中，我们经常会遇到一些令人困惑的失败场景。比如，我们维护的一条 B 端 SaaS 订单链路接口测试仓库，约 1850 个接口用例，CI 上以 "@Execution(CONCURRENT)"
«作者：谢星河-288｜测试开发｜15 年，关注工程规范与可维护性 栈：Java 17 + JUnit 5.10.2 + Mockito 5.11.0 + Spring Boot 3.1.5，CI 用 GitLab Runner（2 台 4
【背景】 我做了 5 年测试开发，最近一次复盘让我很不安：一个下单链路单测全绿，mock 的支付回调服务返回 200 + 标准 JSON，测试里「支付成功 → 扣库存 → 发券」三步断言全部通过。但线上那次事故是——支付网关在一次发布后，对
【背景】 3 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + Spring Boot 3.2 + MySQL 8.0.34），接口自动化 pytest 7.4 + httpx 约 900 条用例，跑在 5
背景 我做了 3 年测试开发，维护一条 B 端数据报表链路（Java 17 + Spring Boot 3.2 + MySQL 8.0），其中约 20% 的用例是异步接口："POST /report/generate" 提交后返回 202
【背景】 3 年测试开发，维护一条 B 端 SaaS 的订单 + 支付链路（Java 17 + Spring Boot 3 + JUnit 5，接口自动化 pytest + httpx 约 900 条用例，共享 staging）。团队已按社
【背景】 我做了 10 年测试开发，带过 3 拨团队，见过最离谱的一次事故：共享 staging 环境，一次回归跑完 2000 条用例，所有 fixture 的 teardown 都是绿的，但第二天另一个小组的接口测试全挂了——查下来是上一
«结论先行：接口自动化失败后最贵的是「现场消失」，不是「用例红了」。环境是共享的、数据是流动的、日志是滚动覆盖的——失败发生后的前 30 秒，是证据还完整的唯一窗口。把「事后复现」改成「当时保全」，排障时间能从平均 40 分钟压到 4 分钟
【背景】 做了 8 年测试开发，最近被 PM 问了一句特别扎心的话：「你们接口自动化跑了 2000 条用例，CI 要 40 分钟，但上个月 3 次线上事故，没有一次是被接口自动化拦住的——那这 2000 条到底在保护谁？」 我复盘了一下那
背景 我负责一条 B 端 SaaS 的接口自动化，pytest 7.4 + httpx，约 800 条用例，跑在 50 个并发 worker 共享的 staging 上（MySQL 8 同库 + Redis 7 + Kafka 1 个 to
【背景】 做了 5 年测试开发，最近半年我们组围绕「flaky test（偶发失败）」打了一架，而且我发现不同团队的口径完全不一样，所以想拉出来聊聊。 我们的现状：CI 上 ~3200 个用例，按 3 次重跑统计，稳定复现的 flaky 大
«结论先行：Testcontainers 的开销大头不在「容器运行」，而在「每个测试类重复拉起容器 + 每次冷拉镜像」两段。把「每类一容器」改成「每 Job 一容器池」+ CI 层做镜像预热，是我们把 47 分钟回归压到 26 分钟的两块主
【背景】 我在一条支付链路上做接口自动化（Java 17 + Spring Boot 3 + JUnit 5 + Resilience4j，CI 用 GitLab Runner，2 台 4C8G 并行）。被测服务对下游风控接口的调用策略是：
«作者：谢景行-248｜测试开发｜8 年，关注工程规范与可维护性 栈：Java 17 + JUnit 5.10 + WireMock 3.x（"com.github.tomakehurst:wiremock-jre8:3.3.1"）+ Sp
«结论先行：跨进程接口测试里的时间依赖，靠"mock 时钟"是够不着的——mock 只能替换本进程内的时钟调用，替换不了对端服务里的 "time.time()"。真正可落地的做法是把「业务时间」提升为接口契约的一部分：测试侧用请求头注入 "
背景 15 年测开，现在负责一条订单+库存链路的性能压测（JDK17 + Spring Boot 3.1，MySQL 8.0 InnoDB 单主，k6 压测）。每个接口压测前会造一批"前置依赖数据"（用户/商品/库存，量级 20 万～500
已经到底了
文
标题
摘要