标签频道
测试数据
该标签下的文章、提问与讨论帖。
【背景】 我做了 10 年测试开发，带过 3 拨团队，见过最离谱的一次事故：共享 staging 环境，一次回归跑完 2000 条用例，所有 fixture 的 teardown 都是绿的，但第二天另一个小组的接口测试全挂了——查下来是上一
背景 我维护一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 2000 条用例），跑在 5 人共享的 staging 上（MySQL 8.0 + Redis 7.2，GitLab C
背景 5 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + JUnit 5 + Testcontainers + MySQL 8.0.34）。团队约 800 个接口用例，测试数据用一套自研 Fixture 工
背景 我这边是一套 B 端 SaaS，约 40 个服务，测试同学 + 各业务线开发共 60+ 人挤在一套"准生产"的共享测试环境里。近半年我们被同一类问题反复咬： - 集成测试跑到一半，某条断言挂了，抓出来一看——不是用例错，是别人 3 分
背景 做了 10 年测试开发，最近在新团队接手一条交易链路时，被"测试数据从哪来"这件事卡了整整一周。不是用例写不出来，而是数据造不出来：一个下单接口要依赖用户、商品、库存、风控、优惠券五个前置状态，每个状态背后还有一张配置表和一次异步落库
测试数据工厂的隐性耦合：Fixture 魔法值让 23 个用例互相依赖，用「单一数据源」重构后偶现失败归零 «结论先行：测试数据（Fixture）不是「随便造一行插入数据库」就能糊弄过去的东西，它和测试逻辑一样需要工程化管理。我们团队 7
先讲个我亲历的"血案"：某次回归，一条自动化造了 2 万条订单流水，测试库和生产库共用同一个主从集群（当时为了省事），造数那条事务因为断言失败中途没回滚，结果从库上的报表任务直接把这 2 万条"假订单"算进了当天的 GMV 大盘，值班同学对
背景：我负责一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 900 条用例），后端 Spring Boot 3 + MySQL 8 + Redis 7，跑在 4 人共享的 stag
【背景】我负责一套 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 700 条用例，MySQL 8）。里面有一批"老用例"是 2 年前从手工用例平移过来的，它们的共同特征是不自己造数，而
文
标题
摘要