分类频道
测试开发
该分类下的文章、提问与讨论帖。
背景 我负责一条结算/账务链路的接口自动化(Python + pytest,约 300 条用例,MySQL 8.0)。其中约 40 条用例的业务逻辑强依赖「真实时间」:典型如「订单 T+1 才允许发起结算」「优惠券次日 00:00 后生效」
discussion
测试造数到底谁该负责:自己造、找开发要,还是脱敏生产数据?
背景 做了 10 年测试开发,最近在新团队接手一条交易链路时,被"测试数据从哪来"这件事卡了整整一周。不是用例写不出来,而是数据造不出来:一个下单接口要依赖用户、商品、库存、风控、优惠券五个前置状态,每个状态背后还有一张配置表和一次异步落库
question
覆盖率 90% 也防不住线上 bug,变异测试怎么低成本落地到 CI
【背景】 我做了 5 年测试开发,现在维护一条 B 端 SaaS 的核心计费链路(Java 17 + JUnit 5 + Spring Boot 3,接口自动化 pytest + httpx 约 1200 条用例,跑在共享 staging)
discussion
CI 里 5% 的 flaky 用例:重试、隔离还是删掉?聊聊不稳定用例的团队策略
背景 做了 3 年测试开发,最近维护一套 B 端 SaaS 的接口自动化(pytest + httpx,约 1800 条用例,跑在共享 staging 环境 + MySQL 8 + Redis 7)。撞上一堵很现实的墙:CI 里大概有 3%
question
flaky 用例该不该隔离,靠什么客观数据判据,而不是凭感觉拉黑
【背景】我负责一条支付清算链路的接口自动化(Python 3.11 + pytest 7.4 + httpx,约 1800 条用例,跑在 3 人共享的 staging 上,MySQL 8 同库 + Redis 7)。近 3 个月套件里有 4
question
接口自动化里异步任务终态断言,大家是轮询等待还是事件驱动?
背景 做了 3 年接口自动化(pytest + httpx,约 2000 条用例,跑在多人共享的 staging 上)。其中约 15% 的用例涉及异步链路:提交任务 → 后台 worker 处理 → 查询状态接口返回终态(SUCCESS /
discussion
测试数据到底该怎么管:造数、隔离、清理,三种路线你们怎么选?
先讲个我亲历的"血案":某次回归,一条自动化造了 2 万条订单流水,测试库和生产库共用同一个主从集群(当时为了省事),造数那条事务因为断言失败中途没回滚,结果从库上的报表任务直接把这 2 万条"假订单"算进了当天的 GMV 大盘,值班同学对
背景 我维护一条支付清算链路的接口自动化套件(Python 3.11 + pytest 7.4 + httpx,约 1800 条用例),底层连 3 个共享 staging:MySQL 8(同一库)+ Redis 7 + Kafka 3.4。
discussion
自动化用例挂了到底谁修?聊聊「用例归谁维护」这条边界怎么画
背景 做了 8 年测试开发,最近在一次跨团队复盘会上听到一句让我很扎心的话:「测试用例挂了,测试开发就该负责修,这是你的交付物。」我当时没接话,但回来反复在想——这条边界真的该这么画吗? 我自己的处境很典型:负责一条 B 端 SaaS 链路
question
怎么量化每条自动化用例的「抓缺陷价值」,让删冗余用例有据可依
背景 我是测试开发,维护一套 B 端 SaaS 接口自动化(Python 3.11 + pytest 7.4 + httpx,约 1800 条用例,跑在 4 人共享的 staging + MySQL 8 + Redis 7)。套件从 700
discussion
全绿就敢发版吗?聊聊「测试通过」和「线上不出事」之间到底隔着什么
背景 做了 15 年测试开发,我最近在一个 12 人后端团队做发布质量复盘时,撞上一堵反复出现的墙:过去 18 个月,团队接口自动化从 600 条涨到 2100 条,CI 全绿率长期 95%+,单测覆盖率 78%,但同期线上 P1/P2 事
question
接口自动化造数清理失败让共享环境越用越脏,怎么设计可观测与自愈?
背景:我负责一条 B 端 SaaS 的接口自动化(Python 3.11 + pytest 7.4 + httpx,约 900 条用例),后端 Spring Boot 3 + MySQL 8 + Redis 7,跑在 4 人共享的 stag
discussion
接口自动化断言该追「绝对确定」还是「合理容忍」?聊聊非确定性用例的取舍
背景 做了 5 年测试开发,最近盘一套 B 端 SaaS 的接口自动化(Python 3.11 + pytest 7 + httpx,约 800 条用例),一个反复出现的痛点不是「断言写错」,而是「断言写多严」的尺度问题。举几个真实例子:一
【背景】 我负责一条 B 端 SaaS 的接口自动化(Python 3.11 + pytest 7.4 + httpx,约 600 条用例),后端 Spring Boot 3 + RabbitMQ 3.12 + MySQL 8。核心链路是「
question
用例依赖"手工造好的存量数据"当地基,一改就炸,怎么低成本解耦?
【背景】我负责一套 B 端 SaaS 的接口自动化(Python 3.11 + pytest 7.4 + httpx,约 700 条用例,MySQL 8)。里面有一批"老用例"是 2 年前从手工用例平移过来的,它们的共同特征是不自己造数,而
discussion
flaky 用例:当场重试救火,还是拉黑等修?想听大家的取舍
背景 做了 3 年接口自动化(pytest + httpx,套件 2000+ 条,跑在多人共享的 staging 上),我最怕的不是"用例红了",而是"红的里面有几条是真的"。flaky 用例是自动化套件的头号天敌:它不报错,它只是间歇性地
question
pytest-xdist 并发下"跨用例隐形状态依赖"怎么系统性找出来?
背景 我在一家 B 端 SaaS 团队负责接口自动化(Python 3.11 + pytest 7.4 + httpx 0.25,约 800 条用例),后端 Spring Boot 3 + MySQL 8 + Redis 7 + Rocke
背景:我维护一套 B 端 SaaS 的接口自动化(Python 3.11 + pytest 7 + httpx,约 400 条用例),后端 Java + Spring Boot。很多用例的造数不是"一步到位",而是一条 5~6 步的依赖链,
question
接口自动化断言粒度怎么定?断到字段级天天碎,断到业务级又怕漏
背景:我维护一套 B 端 SaaS 的接口自动化(pytest + requests,约 350 条用例),团队 4 人,后端 Java + Spring Boot,前端 React。每次发版前跑一轮回归,CI 上大约 20 分钟跑完。 现
question
带限流/熔断的接口,自动化断言总被 429 和熔断态污染,怎么设计才稳?
【背景】我负责一条 B 端 SaaS 的接口自动化(Python 3.11 + pytest 7 + httpx,约 500 条用例),后端 Spring Boot 3,网关层挂了 Sentinel 限流 + 熔断。用例是「造数 → 调接口
已经到底了
article
标题
摘要