标签频道
pytest
该标签下的文章、提问与讨论帖。
question
怎么量化每条自动化用例的「抓缺陷价值」,让删冗余用例有据可依
背景 我是测试开发,维护一套 B 端 SaaS 接口自动化(Python 3.11 + pytest 7.4 + httpx,约 1800 条用例,跑在 4 人共享的 staging + MySQL 8 + Redis 7)。套件从 700
question
接口自动化造数清理失败让共享环境越用越脏,怎么设计可观测与自愈?
背景:我负责一条 B 端 SaaS 的接口自动化(Python 3.11 + pytest 7.4 + httpx,约 900 条用例),后端 Spring Boot 3 + MySQL 8 + Redis 7,跑在 4 人共享的 stag
结论先行:行覆盖率证明"代码被执行了",但不证明"输出被校验了"。变异测试(Mutation Testing)专门补这个盲区。下面是我团队一次真实落地记录,数字均可复现。 一、现象与背景:用例 100% 全绿,线上照样出 bug 先摆数字。
【背景】 我负责一条 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 用例是自动化套件的头号天敌:它不报错,它只是间歇性地
背景:我维护一套 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
接口回归挂了怎么"一键复现":现场快照该抓哪些东西才够?
背景 我在一家做 B 端 SaaS 的团队负责接口自动化(Python 3.11 + pytest 7 + httpx,约 600 条用例),后端是 Spring Boot 3 + MySQL + Redis + RocketMQ,CI 用