不稳定的视觉测试（Flaky）：为什么它们摧毁你的 QA 以及如何稳定它们
Flaky 测试（或不稳定测试）是指在相同代码和配置下产生不同结果——通过或失败——而被测系统未做任何修改的测试。
这里有一个可能让你不舒服的观点：一个 flaky 的视觉测试比没有测试更糟糕。缺失的测试日常不花费任何成本。它不阻塞你的 pipeline。不消耗团队时间。不破坏对测试基础设施的信心。Flaky 测试每天都在做这些事，而且是悄无声息地——因为每次假失败看起来都足够像真的，需要调查。
Google 关于自身测试系统的数据很说明问题：在任何时刻大约 1.5% 的测试是 flaky 的，但这些测试消耗了不成比例的工程时间。
为什么视觉测试特别容易不稳定
自动化视觉测试引入了单元测试或功能测试没有的非确定性层。网页的渲染是一系列复杂过程的结果，每个过程都引入自己的变异性。
Flaky 视觉测试的四个主要原因
时序：无法忽视的问题
Web 本质上是异步的。页面加载不是单一事件——而是事件级联。没有任何信号能保证视觉渲染已完成。
动画：静态媒介中的运动
截图是固定图像。动画是持续变化。两者对自动化比较来说根本不兼容。
动态内容：所有不受你控制的变化
日期、时间、广告、随机生成的头像——测试运行之间全部不同。
网络和基础设施：你无法控制的变量
测试运行在依赖外部资源的环境中。延迟因运行而异。
Flaky 测试的真实成本
最具破坏性的成本是信心丧失。当团队得知视觉测试"总是"无故失败时，他们会养成自动重新运行的条件反射。而 bug 就进入了生产环境。
有效的稳定化策略
控制渲染环境
在受控容器中使用 headless 浏览器，固定分辨率，预装字体，确定性网络配置。
中和动画
注入样式表，强制所有动画和过渡的持续时间为零。
稳定动态内容
固定日期和时间，禁用第三方小部件，mock API 数据。
智能等待
基于页面实际状态的等待策略，而非固定延迟。
采用能容忍噪音的比较方式
结构化方法——比较 DOM 和计算后的 CSS 属性——对渲染噪音最具抵抗力。
No-code 视觉测试作为维护问题的解决方案
No-code 工具如 Delta-QA 消除了脚本的脆弱层。你不写脚本——而是可视化地配置测试。
何时删除 flaky 测试
如果视觉测试在所有稳定化尝试后仍间歇性失败，最勇敢——也往往最明智——的决定是删除它。目标不是拥有最多的测试——而是拥有团队信任的测试。
常见问题
Flaky 测试和误报有什么区别？
误报信号一个不存在的问题。Flaky 测试在相同代码的不同运行之间产生不一致的结果。
如何测量 flakiness 率？
在不更改代码的情况下多次运行同一测试套件，统计结果在运行之间发生变化的测试。
No-code 视觉测试是否更少 flaky？
它们消除了一类 flakiness——与脚本相关的。但仍受浏览器渲染的相同约束。
应该自动重试失败的测试吗？
重试是创可贴，不是解决方案。如果启用，限制为一次重试并标记需要调查的测试。
CI/CD 中可接受的 flakiness 阈值是多少？
目标低于 1%。超过 5%，你的团队几乎肯定会养成系统性重新运行失败 pipeline 的习惯。
Delta-QA 能帮助稳定视觉测试吗？
Delta-QA 通过使用结构化方法从源头减少 flakiness。Sub-pixel rendering 变化、抗锯齿和时序问题原生被忽略。结合消除脆弱测试脚本的 no-code 方法，Delta-QA 无需复杂配置即可产生可靠且可重现的测试结果。
视觉测试只有在团队信任它时才有价值。 Flaky 测试日复一日地摧毁这种信任。