有什么想法可以减少 GUI 测试的测试时间吗？

许多人似乎忽略了一个提示，即确保您的所有测试实际上都是有用的。很多时候，测试会随着时间的推移而衰减——它们的用处会逐渐消失，以至于测试本身就是浪费时间，不管它们有多快。

我曾经加入过一个运行自动化夜间测试的组织，该组织通过电子邮件将完成报告发送给一大群人。几天后，我注意到它总是表示总体“通过”，但我的手动测试表明主要失败。当我深入研究自动化时，我发现代码一团糟，没有机会真正检测到任何真正的错误。我删除了大部分自动化，并用一个更小、更短的测试取而代之，该测试实际上能够检测到一些错误。

我以前也遇到过这种情况。出于类似的原因，我们正在运行实时测试。我不会过早地优化，但如果你看到一个迫在眉睫的问题，我也不会等到它已经是一个问题。我们做了一些事情：

• 跨多台机器的并行测试。使选择测试子集变得容易，这样您就可以将一个测试运行分成多个小运行，并让调度程序处理将这些小运行分配给多台机器。您将需要决定是否要始终在同一台机器上运行相同的测试以保持一致性，或者切换以扩大覆盖范围（您可能只在某些机器上遇到一些错误）。
• 区分功能测试和端到端测试。在您获得要测试的功能之前，无需模拟用户进行功能测试，但对于端到端测试，您需要模拟整个过程。您可以在设置期间快速移动，在实际测试期间减速和模拟，然后在清理功能测试期间再次加速。
• 在操作之间的时间段内使用可配置的常量。如果您发现速度变得越来越重要（然后可能在周末进行“慢速”运行），这不仅可以让您轻松调整运行时间，而且通过重新配置偶尔以不同速度运行的东西，您可以获得更多的覆盖范围（一些讨厌的错误只有在你做事比平时快时才会被击中）。
• 打破了耗时的计算，所以我们有一个“测试”阶段，它只记录东西，一个“分析”阶段，对信息进行分类以获得有用的统计数据。这是性能 GUI 测试，所以我们做了很多数据分析——它可能不适用于您的情况。
• 注意每个测试的优先级，如果时间有问题，不要每晚运行所有测试。您可以每周只运行一次低优先级测试以节省资源。或者按优先顺序运行测试，以便您首先获得最重要的结果。
• 记下缓慢的部分，给他们粗略的时间估计来修复，并注意低垂的果实。

从长远来看，购买更多硬件和并行化通常比花费更多测试人员时间来优化和重新稳定 GUI 测试更便宜。在极端情况下，您可以在每台机器上为数百台机器运行一个测试，并在运行单个测试所需的时间内完成整个运行（包括测试运行设置 - 例如，您是否在进行测试运行之前重新安装操作系统？ ）。测试人员组织多台机器的时间是有初始成本的（需要某种排队服务，加上对无响应机器的警报等），但如果你的产品和测试套件足够大，它会在未来得到回报！

OTOH，如果您已经工作了 5 年并且 GUI 测试的数量稳步增长并且您现在是 4 到 10 个小时，那么您可能能够在接下来的 5 年内让测试数量翻倍并且仍然运行所有内容只有一台机器，只有几个简单的优化策略，比如按优先顺序运行，如果运行时间太长，就缩短运行时间。

是的，但是这是视情况而定的情况之一，关于“效率如何”的最终答案对每个人来说都是不同的。

为什么重要

• 如果您将测试自动化用于冒烟或 BTV 测试，那么您希望能够快速执行广泛的覆盖
• 如果您需要调试或重新运行测试以查看是否发生故障，您不想坐等几分钟，您希望快速执行。

为什么没关系

• 如果你有足够的硬件（和许可证）来扩展我们的执行，只要你可以走出一个晚上的门，第二天早上再走回来，并且 100% 的测试已经执行，那么它们就足够快了.

话虽如此，一旦您的测试运行速度与硬件运行速度一样快（即瓶颈是服务器响应时间），其他一切都会感觉缓慢且效率低下。

效率与您的需求有关。与其问“自动化测试应该高效吗？”，不如问“自动化效率什么时候重要？”可能更有趣。例如，如果您希望开发人员在签入更改之前运行您的自动化测试，那么运行该测试需要多长时间非常重要。您可能会调查您的开发人员并找到开发人员将停止使用您的测试的痛苦阈值——他们可能对此有强烈的感受。

另一件事：我一直怀疑——但从未尝试过凭经验进行测试——人们是否对自己的自动化测试比对其他人的自动化测试更有耐心。也许这是因为，正如我在其他问题的回答中所说，真正理解自动化测试做什么的人是编写它的人。当您不确定测试实际上做了什么，或者更确切地说它是否有用时，就很难证明花时间运行它是合理的。