testing - 如何在不影响 UI 交付质量的情况下减少 Test pyramid 中的 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 和单元层经过充分测试后编写它们。