为什么你不写 UI 测试

2025-06-07

为什么你不写 UI 测试

今天是星期五下午。

您的冲刺任务已完成,除了一项。

您最终说服了您的 PM,花一点空闲时间研究编写自动化 UI 测试确实可以减少错误。

任务板上有一个待办事项:“Spike:UI 测试功能”

当你坐在那里,看着任务板上的单个项目时,你内心会对整个事情产生一种痛苦的感觉。

你有考试焦虑。

您很高兴有机会尝试自动化测试;您觉得它有很多好处;但您害怕会浪费这个机会。

如果您花费了这么多时间来设置测试,但最终却没有任何结果,该怎么办?

有很多方法可能会出错:

  • 测试可能太脆弱了,每一个小变化都会破坏,以至于你只能停止运行它们。
  • 即使他们依赖,他们也可能不会测试任何有用的东西。
  • 或者,在弄清楚如何使它们可靠且有用之后,如果您的队友不采用它们,您就必须负责对它们进行每次更新。
  • 也许您正在测试的功能已被废弃,导致您的新测试毫无用处。
  • 而且,仅仅因为今天给了你时间并不意味着明天你就有时间对测试套件进行适当的维护。

这列测试列车有很多可能脱轨的原因。

难怪你对这一切感到焦虑。

我从个人经历中知道这些恐惧有多么令人难以忍受;而且,存在这些恐惧也并非毫无道理。

构建一个好的自动化测试套件需要大量的工作,这不是一个下午就能完成的事情。

另外,走上错误的道路真的很容易;追逐无尽的线索试图解决一个从长远来看并不那么重要的问题。

为了避免考试焦虑和时间浪费,定义什么是“好的考试”非常重要:

  1. 易于编写测试的价值在于,它能长期节省你的时间。如果你花了两周时间才写完一个测试,那么这段时间就很难再省下来了。
  2. 易于运行测试成功的可能性与测试在开发过程中的集成程度直接相关。如果运行测试需要所有这些额外的工作,您和您的团队很快就会对它们失去兴趣/意志力。理想情况下,测试运行起来毫不费力,因为它们与您的开发环境完全集成。
  3. 高度可见性确保你知道测试失败的时间和原因。如果忽略结果,那么在测试上花费的时间就毫无意义。
  4. 有用测试可以做很多事情,但如果它实际上没有帮助,那还有什么意义呢?测试应该能够发现bug,减少手动测试的工作量,并提高整体测试覆盖率。

这些就是我对优秀测试的标准。

有了这个清单,我们现在可以直面考试焦虑并让它闭嘴。

我们会说的是:

我限制了我的乐观

我相信这些测试会有所帮助,但我也知道试图测试一切是一个糟糕的计划。

我将尝试编写自动化程序并遇到一些不值得花费成本去修复的问题。

为了避免无休止的调试陷阱,我将不惜付出一些努力。

我正在写一个测试

为了开始我的测试自动化工作,我必须“垂直”思考。

描述测试架构的所有部分,包括构建系统和测试报告

如果我开始编写十几个测试,它们都会不符合标准 2 和标准 3,从而增加了它们变得无用的可能性。

相反,我将专注于一个测试,编写它,然后在编写更多测试之前将其完全集成到我的系统中。

这样我就知道一次测试满足“好测试”的所有标准。

只有这样,我才会重新编写更多的测试,这些测试现在自动内置了那些核心的“良好测试”功能。

我怀疑哪些测试值得

因为我知道我无法测试所有内容,所以我也知道我需要有选择地编写测试。

为简单的静态页面编写测试可能很容易,但我也知道功能不太可能中断并且通常不重要。

相反,我专注于“赚钱”页面。这些用户流程是业务的动力,一旦中断,就会给用户和公司带来巨大的痛苦。

我还会权衡测试的收益和编写测试的痛苦。

我并不是说我不会为重要的页面破例,但如果一个页面有很多动态元素,需要数周的工作,我会权衡成本与页面的重要性。

我不会为未发布的功能编写自动化程序

虽然测试驱动开发可能对单元测试很有效,但对于 UI 测试来说却困难得多。

我知道过早编写 UI 测试可能会导致大量返工,因为这些新页面在上线后的头几个月可能会发生各种变化。

相反,我会考虑新功能如何影响现有页面,并加强对现有页面的测试,以确保新功能不会干扰它们。

然后,一旦新的流程稳定下来,我就可以回去编写测试,并确信它们会保留下来。

我不会忘记附带的好处

尽管我许下了很多承诺,但我知道人生依然没有绝对的保障。科技可能会让我失望,我原本期待的支持也可能不会出现。

但我确信,除了自动化本身之外,自动化测试还有其他几个好处:

他们澄清了要求

为了编写有效的测试,您必须知道预期的输入和输出。

可悲的是,许多项目可能经过数月的开发却无人问起这些基本问题。

模型已经制作完成,代码也已经编写完成,但却没有人问过这个基本问题:“用户如何获得他们需要的东西?”

通过编写测试,你必须明确你期望用户做什么。当这种情况发生时,你可能会发现你预期的交互路径实际上体验很差。或者你根本没有定义过预期的交互路径。

测试揭示了假设

按照这个思路,测试需要你直截了当。为了使 UI 测试成功,你必须有一份明确的指令列表供计算机运行。

因此,团队对软件工作方式做出的假设通常会通过自动化测试来揭示。

许多假设都是从可访问性的角度做出的。我们不知不觉地假设用户能够直观地浏览网站,却忘记了至少五分之一的人有身体障碍

定义软件使用流程很容易,但用户的实际使用方式可能完全不同。

通过在人类操作系统之外测试代码,您可以摆脱内部的偏见和偏好,从不同的角度体验系统。

你只是在更多地测试代码

无论如何,您都在测试该网站。

通过运行自动化,您可以增加代码的额外时间,让您的团队有更多机会捕捉每 15 次运行才出现一次的隐蔽错误。

即使你没有运行自动化测试,你仍然需要检查代码,以确定测试的运行方式。即使这样做,也能暴露出一些原本可能被忽视的隐藏缺陷或小错误。

它当然不是最有效的,但仍然是有效的。

你已经得到了这个

所有这一切的关键是记住良好测试的核心价值。

它们是:

  1. 易于书写
  2. 易于运行
  3. 高度可见
  4. 有用

这意味着你需要花时间去思考而不是去做。思考哪些测试是重要的,以及这些测试将如何在实际环境中运行。

这可能让人感觉很浪费,但这种思考可能是良好测试开端的关键。

如果您患有考试焦虑症,请了解其背后的恐惧并建立信心以避免这些恐惧。

文章来源:https://dev.to/klamping/why-youre-not-writing-ui-tests-5fdd
PREV
useEffect、useMemo、useCallback 钩子之间的区别?
NEXT
测试时不要欺骗自己