可测性 vs. 可自动化性：为什么大多数自动化工作在开始前就失败 - 第2部分

Source: Dev.to

阅读Part 1。

当自动化失败时，通常是设计问题

在自动化部署一段时间后，团队开始注意到一种模式。某些测试间歇性失败。其他测试需要重试才能通过。有些失败在本地重新运行时会消失，但在流水线中又会出现。随着时间推移，测试套件变成了工程师们学会规避而不是依赖的东西。

在这个阶段，问题不可避免地出现：是我们的自动化有问题，还是系统本身有问题？

正确回答这个问题是构建可持续自动化的最重要技能之一。许多团队之所以判断错误，并不是因为缺乏经验，而是因为自动化失败比设计缺陷更容易被发现。

为什么自动化被指责

自动化在公开环境中运行。当它失败时，管道变红，通知触发，进度停止。相比之下，应用程序设计问题往往是隐形的。它们表现为歧义、隐藏的耦合或不明确的状态——人们在不自觉地适应这些问题。

当自动化测试超时、未能定位元素或产生不一致的结果时，失败信息直接指向测试本身。系统本身保持沉默。随着时间的推移，这就形成了一个错误的叙事：自动化脆弱、慢且不可靠。

实际上，自动化往往是在揭示已经不确定的行为。它只是以一致且无偏见的方式做到这一点。

核心诊断问题

一种将自动化问题与设计问题区分开的有用方法是提出一个简单的问题：

人类测试人员是否能够在不多次重新运行测试的情况下，清晰且一致地解释此失败？

如果答案是 no，那么问题很少是自动化导致的。

当人类需要刷新页面、重复操作或“再试一次”时，他们是在弥补系统中缺失的信号。自动化无法做出这些假设；它需要系统明确说明。

设计模糊伪装成自动化失败

许多自动化问题源于掩盖系统行为的设计决策。用户界面不可预测地重新渲染、工作流依赖时间而非状态、以及仅以视觉方式呈现结果的系统，迫使自动化去猜测。

这些猜测表现为脆弱的选择器、复杂的等待条件和重试。虽然这些技术可以让测试通过，但它们也掩盖了根本问题：系统没有清晰地传达它正在做什么。

当测试因“未找到元素”而失败时，真正的问题往往是系统尚未指示该元素应该出现。自动化被指责为不耐心，而实际上是系统保持沉默。

真正的自动化问题是什么样的

并非所有的失败都与设计有关。确实存在真正的自动化问题，识别它们很重要。

自动化问题的典型特征：

• 在相同位置确定性地失败
• 通过更好的工具或实现方式可以显著改善
• 不会影响手动测试的行为
• 仅限于测试代码本身，而不会蔓延到其他场景

例子包括选择器策略不佳、误用自动化框架，或在本可以使用更低层级测试的情况下过度依赖端到端测试。这些问题是真实存在的，但通常更容易修复，长期来看成本也更低。

相比之下，设计问题对工具的更换具有抵抗力，无论使用何种框架都会再次出现。

误诊的代价

当设计问题被误判为自动化问题时，团队会通过加固测试而不是改进系统来应对。他们添加重试、延长超时，并构建抽象层。测试套件变得更慢且更难理解，而系统仍然和以前一样不透明。

最终，自动化套件变得脆弱并不是因为测试写得不好，而是因为它们承担了补偿不明确行为的负担。这正是团队开始质疑自动化价值的时刻。

倾听自动化而非对抗它

自动化往往是设计缺陷在大规模下首次显现的地方。它不间断地与系统交互，对模糊不清毫不容忍。高绩效团队并不是压制这种反馈，而是将其视为信号。

当一个测试难以编写、难以稳定或难以调试时，他们会询问系统未能传达什么信息。他们会寻找缺失的状态信号、不明确的边界或隐藏的依赖。解决这些问题不仅能提升自动化质量，通常也能改善生产环境的行为。

转变对话

最具生产力的团队会把对话从“我们该如何修复这个测试？”转向“系统没有明确说明的是什么？”

这种转变改变了对失败的处理方式。自动化失败不再是挫败感的来源，而是提升系统清晰度的机会。随着时间推移，自动化变得更可靠，这并不是因为测试更复杂，而是因为系统本身更易于推理。

展望未来

在下一篇文章中，我们将探讨导致自动化不稳定的最常见触发因素之一：缓慢且异步的用户界面。阅读第 1 部分。

我们将分析为何性能问题常被误诊，为什么“等待”并不是一种策略，以及可观测性——而非速度——才是实现可靠自动化的关键。

如果你发现你的自动化套件正在揭示系统中令人不安的真相，那你可能正走在正确的道路上。