我应该何时（而不是如何）在 Android 上测试 UI 组件？

Posted 2023-02-24

【中文标题】我应该何时（而不是如何）在 Android 上测试 UI 组件？

【英文标题】：When (NOT how) should I test UI components on Android?

【发布时间】：2017-07-26 15:42:39

【问题描述】：

我找到了很多关于如何使用 Espresso 框架和其他框架进行 UI 测试的材料。但是，我很难找到任何信息来告诉我应该在多大程度上测试 UI：我应该编写测试来测试每个 gridView 中的每个可能的 GridItem 吗？只有可点击的项目？我应该如何确定测试任何给定的 android UI 的内容和深度？

对于这个问题，你应该假设你是开发者、所有者和设计者。

如果能得到在一般情况下优先考虑的东西会很好。

【问题讨论】：

测试越多越好。这是一个预算/时间问题。

欢迎您以任何您想要的程度测试 UI，从完全没有到 100% 的代码覆盖率（对于所有可测量的覆盖率类型，例如循环和分支）。我们不能告诉你测试的“深度”，因为它很大程度上取决于应用程序架构（例如，与其他可测试层相比，UI 中绑定了多少逻辑）和应用程序的性质（例如，有多少人会因为更彻底的测试可能发现的编码缺陷而死）。

这可能会被否决，因为答案可能是基于意见的，但对优先事项的回应可能会提供信息。

这可能会因为广泛而关闭：您能否更具体：谁是测试人员（I）以及测试目标是什么？设计（看起来不错）？开发人员（按下按钮时不会崩溃）？产品负责人（用户界面是否符合规范）？人体工程学？ ....

我希望这个问题更广泛，以便人们可以从不同的角度回答。我找不到任何关于在预算/时间方面进行优化的细节信息，比如@PhilippSander 提到的，但我会稍作修改。

【参考方案1】：

此问题的任何答案都将基于意见，并且还取决于许多因素。让我给你一些我自己会考虑的因素。

单元测试：

要问的第一个问题是 UI 测试是否会是唯一的自动化测试。

如果您已经对代码进行了单元测试并拥有可靠的测试套件，那么我不会在 UI 测试上投入太多时间。编写一些测试来检查 UI 元素与应用程序其余部分之间的基本集成，但不要尝试使用 UI 测试来测试内部逻辑——这是单元测试的目的。

如果您没有单元测试并且唯一的自动化测试将通过 UI 完成，那么您希望更深入。映射您的应用程序应该执行的所有流，根据测试复杂性对其进行排序，并从最简单的开始为每个流编写 UI 测试。您还需要测量 UI 测试的覆盖率，以便对应用程序中未测试的部分有一定的了解。

手动测试 (QA)：

下一个因素是您可以负担的手动测试量。

由于您提到这是一场单人表演，因此您可能无法在每次发布之前分配几天进行手动测试。在这种情况下，拥有更广泛的 UI 测试套件是有意义的。特别是对于涉及数据验证的流程 - 您真的不想确保（每个版本）注册流程不接受格式错误的电子邮件/用户名/密码。

另一方面，如果您有专门的测试人员，那么您可以大大减少对 UI 测试的投资。我想说的是，在某些情况下，如果你有专门的测试人员和一套好的单元测试，你可以完全删除 UI 测试。

需求变化率：

如果需求经常变化，UI 测试就是一个巨大的 PITA。特别是如果这些更改影响 UI/UX。

如果你有一个稳定的产品和现有的用户群，那么你可以添加更多的 UI 测试，因为变化率可能会相对较低，并且你想保证现有的功能不会中断。

另一方面，如果您只是在引导应用程序或探索想法并且 UI/UX 非常不稳定，那么 UI 测试的维护将需要付出很多努力。

错误成本：

考虑错误的代价并适当调整您的测试策略。

如果错误的代价只是糟糕的用户体验和轻微的不便，那么您无需在 UI 测试上投入太多。如果错误的代价是个人数据受到损害，我会在测试上投入更多。如果您的应用会导致人员受伤，请务必进行彻底测试并有一个单独的团队来执行此操作。

一般说明：

对于质量保证，恕我直言，三种技术在 Android 上最有效：代码审查、单元测试和探索性手动测试。

UI 测试不如上述三个有效。因此，如果您还没有掌握以上任何一项，那么您最好将时间投入其中，而不是 UI 测试。