如何在不影响 UI 交付质量的情况下减少测试金字塔中的 UI 测试

Question

我们公司有一个基于 Java 的大型桌面应用程序，我们正在为其构建测试用例。 我们希望遵循测试金字塔方法：

1) 我们要求开发人员编写大量单元测试（但不验证他们在哪里编写了高质量的单元测试）。

2) 我们编写服务测试，遍历每一行代码并编写 Junit 测试来测试代码中所有可能的方法和条件。

3) 我们计划创建 UI 测试以确保 UI 正常工作。

我阅读了很多关于测试金字塔方法的博客，并了解到我们应该在编写 UI 测试上投入更少的时间，因为它们不利于测试 ROI，因为它们通常需要大量时间来执行并且由于它们很脆弱他们对 UI 元素的依赖。我完全同意这些观点。

但是，问题是，当我们说我们需要的 UI 测试数量要少得多时，我们的意思是我们只需要针对优先级为 1 的情况（或冒烟测试）进行 UI 测试吗？相反，UI 是用户与之交互的元素，所以我们不需要首先确保它没有损坏吗？我的意思是，当我们说我们需要减少 UI 测试的数量时，它不会影响 UI 交付的质量吗？ 例如，我写了很多服务测试，确保后端业务逻辑是完美的，但如果 UI 搞砸了怎么办？不是同样重要吗？

Answer 1

我认为 UI 测试的数量 并不那么重要。

我认为测试自动化金字塔意味着单个 UI 测试用例涵盖了许多较低级别的测试。例如，一个 UI 测试用例可能会进行 5 次 API 调用并调用 10 个方法。这使得 UI 测试更加脆弱和复杂，因此最好在 API 和单元层经过充分测试之后编写它们。