标签频道
测试工程
该标签下的文章、提问与讨论帖。
一、现象与背景：52 分钟的 CI，40 分钟在"等环境" 先给一组让我坐不住数字。我维护一条支付清算链路的接口自动化套件（Python 3.11 + pytest 7.4 + httpx，约 1800 条用例），底层依赖 4 个中间件：M
背景 我这边是一套 B 端 SaaS，约 40 个服务，测试同学 + 各业务线开发共 60+ 人挤在一套"准生产"的共享测试环境里。近半年我们被同一类问题反复咬： - 集成测试跑到一半，某条断言挂了，抓出来一看——不是用例错，是别人 3 分
一、现象与背景：全绿的套件，拦不住一次 0.01 元的差 先摆数字。我做了 5 年测试开发，现在维护一条 B 端 SaaS 核心计费链路，接口自动化是 pytest + httpx 共 1200 条用例，跑在共享 staging，CI 常年
把「时间」当依赖注入：Clock 抽象 + JUnit 5 Extension 让 31 个时间敏感用例告别 flaky «结论先行：时间是测试里最容易被忽视的隐式全局依赖。"new Date()" / "Instant.now()" /
背景 我负责一条结算/账务链路的接口自动化（Python + pytest，约 300 条用例，MySQL 8.0）。其中约 40 条用例的业务逻辑强依赖「真实时间」：典型如「订单 T+1 才允许发起结算」「优惠券次日 00:00 后生效」
«作者：谢景行-948｜测试开发｜8 年，关注工程规范与可维护性 栈：Java 17 + Spring Boot 3.2 + Testcontainers 1.19.3 + MySQL 8.0.34（InnoDB）+ JUnit 5.10
背景 做了 3 年测试开发，最近维护一套 B 端 SaaS 的接口自动化（pytest + httpx，约 1800 条用例，跑在共享 staging 环境 + MySQL 8 + Redis 7）。撞上一堵很现实的墙：CI 里大概有 3%
测试数据工厂的隐性耦合：Fixture 魔法值让 23 个用例互相依赖，用「单一数据源」重构后偶现失败归零 «结论先行：测试数据（Fixture）不是「随便造一行插入数据库」就能糊弄过去的东西，它和测试逻辑一样需要工程化管理。我们团队 7
«结论先行：「staging 全绿」是一个没有量纲的结论。它只说明「在这套配置、这个数据量级、这个时钟下没炸」，对生产零承诺。我 10 年做测试开发，经手过 5 起「测试全绿、生产事故」，根因没有一起是代码逻辑 bug，全是配置与环境的隐性
一、现象与背景：CI 跑 47 分钟，谁都不敢动 先摆数字。我负责的是一条 B 端 SaaS 的结算链路接口测试仓库（Java 17 + JUnit 5.10 + Testcontainers + PostgreSQL 15），共 1380
背景 我是测试开发，维护一套 B 端 SaaS 接口自动化（Python 3.11 + pytest 7.4 + httpx，约 1800 条用例，跑在 4 人共享的 staging + MySQL 8 + Redis 7）。套件从 700
背景 做了 15 年测试开发，我最近在一个 12 人后端团队做发布质量复盘时，撞上一堵反复出现的墙：过去 18 个月，团队接口自动化从 600 条涨到 2100 条，CI 全绿率长期 95%+，单测覆盖率 78%，但同期线上 P1/P2 事
背景 做了 5 年测试开发，最近盘一套 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 800 条用例），一个反复出现的痛点不是「断言写错」，而是「断言写多严」的尺度问题。举几个真实例子：一
结论先行：行覆盖率证明"代码被执行了"，但不证明"输出被校验了"。变异测试（Mutation Testing）专门补这个盲区。下面是我团队一次真实落地记录，数字均可复现。 一、现象与背景：用例 100% 全绿，线上照样出 bug 先摆数字。
一、现象与背景：用例全绿，线上却炸了 先给数字。我接手一条 B 端 SaaS 的订单+履约链路接口测试仓库（Java 17 + JUnit 5 + WireMock），约 1600 个接口用例。做了两件「审计」的事： - 用正则统计断言："
一、现象与背景：同一套压测脚本，今天 p99=42ms 明天 p99=87ms 先摆数字。我们团队 9 人，负责一条订单+库存的 Java 服务链路（JDK 17 + Spring Boot 3.1，Nginx 网关，k6 做压测）。性能回
背景 做了 8 年测试开发，我越来越觉得一个尴尬的事实：我们天天教团队「测试代码也是代码，要 review、要重构、要删死代码」，但真正落到「删一条自动化用例」这件事上，绝大多数团队都卡住了。 我最近盘了一条 B 端 SaaS 的接口自动化
一、现象与背景：接口"悄悄变了"，没人通知你 先给一组真实数字。我们团队 11 人，维护 5 个 Java 微服务（订单、库存、支付、营销、结算），Spring Boot 3.1 + JDK 17，网关 Nginx。2024 年 Q4 的三
背景 做了 10 年测试开发，我始终觉得有一类 bug 特别「冤」：功能逻辑本身没错，代码评审也过了，单测全绿，但上线后因为环境和数据形态的差异翻车。我盘点过自己经手的 5 次发布事故，至少 3 次的根因都能归到这一类： - 生产数据里存在
一、现象与背景：改一个字段，要翻 47 个文件 先给数字。我接手一条 B 端 SaaS 的订单链路测试仓库（Java 17 + JUnit 5 + Testcontainers），约 2100 个用例、18 万行测试代码。做了一次 "gre
已经到底了
文
标题
摘要