断言与等待机制横评：硬编码 / 轮询 / 智能等待，谁的回归最稳

引言flaky 测试的源头往往在这里回归测试最怕偶发失败flaky。而 flaky 的头号来源就是断言和等待写得不讲究。本文横评三种等待实现硬编码、轮询、智能等待并附 DSL 片段示例看看谁的回归最稳。方案 A硬编码等待Hardcodedsleep(8000) – 网络慢时仍可能误判网络快时纯浪费思路固定 sleep 一段时间再继续。实现最简单但本质是赌——设长了浪费时间设短了 UI 没加载就断言直接误判。规模化时总时间随 sleep 累加爆炸是回归稳定性的最大敌人。方案 B轮询等待Pollinglocal ok falsefor i 1, 40 doif AICheck(“loading 圈消失”) then ok true; break endsleep(500)end思路循环检查某个条件满足即继续超时则失败。比硬编码可控能自适应加载快慢。缺点条件要手写代码冗长当检查什么缺乏清晰信号如动画渐隐无明确状态时轮询条件难写仍可能漏判。方案 C智能等待Smart Wait– 语义驱动条件满足即续无需手写循环AISmartWait(“战斗结算弹窗出现”, timeout 15000)AICheck(“结算文案含’胜利’”)思路用自然语言描述等某个语义条件出现/消失引擎在超时内自动探测满足即继续。跨 UI 微调鲁棒弹窗位置变了也能等到代码极简且每次等待都带语义留痕便于排查失败原因。横向对比表选型与落地建议智能等待在回归稳定性上明显占优能显著减少 flaky。但落地时有三点要注意必须设超时智能等待不是无限等超时即失败避免挂死。保留兜底语义难判的组件如纯动画状态仍可用轮询补位。关键断言不省等待解决时机断言解决结果两者配合才是稳的回归。推荐实践主线交互用智能等待如虎鲸的 AISmartWait扛变更、保稳定系统级固定锚点可用极短硬编码疑难状态用轮询兜底。把等待当成一等公民来设计比盲目加 sleep 更能救你的回归绿灯率。