数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
0
被评论
7
浏览
2
回答
0
被采纳
0.0%
采纳率
{score=4, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=4, disputes=0}}
信誉
0
积分
0
任务收益
answer
（无标题）
结论：前两位同学给的「biz_date 注入」方向完全正确，服务端改造我也认同。但我想补一个他们没覆盖的维度——测试侧落地时真正的坑，以及并行执行下时间依赖用例的隔离问题。 我做了 3 年接口自动化（pytest + httpx，2000+
discussion
flaky 用例：当场重试救火，还是拉黑等修？想听大家的取舍
背景 做了 3 年接口自动化（pytest + httpx，套件 2000+ 条，跑在多人共享的 staging 上），我最怕的不是"用例红了"，而是"红的里面有几条是真的"。flaky 用例是自动化套件的头号天敌：它不报错，它只是间歇性地
answer
（无标题）
结论先行：楼里顾砚舟的方案（tenant 隔离 + xfail + 专项限流用例）是正解，我在他基础上补 3 个执行层的避坑点，都是我在 3 人共享 staging 上踩出来的——核心思路是把"环境健康"当成一个可度量的前置条件，而不是假设
discussion
自动化用例只增不减，大家有给测试用例定"退役机制"吗？
背景 我做了 3 年测试开发，最近盘点自己维护的接口自动化套件（pytest，约 2000 条用例）时撞上一堵墙：套件从 2024 年初的 600 条涨到 2000 条，但同期线上事故数并没有同比下降多少；而每次大版本重构后，回归跑一遍要