自动化测试应该有效吗？

#1 楼

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


许多人似乎忽略了一个技巧，就是确保所有测试都真正有用。很多时候，测试会随着时间的流逝而衰减-它们的有用性逐渐降低，以至于测试本身不管时间有多快，都是在浪费时间。通过电子邮件将完成情况报告发送给了一大群人。几天后，我注意到它始终表示总体“通过”，但是我的手动测试表明存在重大故障。当我深入研究自动化时，我发现代码是一团糟，没有机会真正检测到任何实际的错误。我删除了大部分自动化程序，并用一个更小，更短的测试代替了它，它实际上能够检测到一些错误。

#2 楼

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


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

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

OTOH，如果您已经工作了5年，并且GUI测试的数量稳定增长，并且现在是4到10个小时，那么您也许可以在在接下来的5年中，仍将仅使用几种简单的优化策略在一台机器上运行所有内容，例如按优先级顺序运行，并在运行时间过长时缩短运行时间。

#3 楼

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

为什么重要


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

为什么没关系


如果您有足够的硬件（和许可证）来执行只要您可以走出晚上的门，然后在第二天早晨走回去，并且100％的测试已执行，就可以扩展我们的执行速度。它们运行得足够快。

就是说，一旦您进行的测试运行速度达到了硬件允许它们运行的​​速度（即瓶颈是严重的响应时间），其他一切都会变得缓慢而无效。

#4 楼

效率与您的需求有关。与其问“自动化测试应该有效吗？”，还不如问“自动化效率何时重要？”可能更有趣。例如，如果您希望开发人员在签入更改之前运行自动化测试，那么该测试需要多长时间才能运行就很重要。您可能会轮询您的开发人员，并找到痛苦的阈值，超过该阈值，开发人员将停止使用您的测试-他们可能对此有强烈的感觉。

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

#5 楼

记住缩放总是很重要的。如果您将测试数量（最终将要进行的测试）增加一倍，直到现在达到20小时，这会成问题吗？也许。您离开时会从5点开始，直到第二天午餐后才得到反馈。

我想考虑的另一件事是它们的速度有多快？如果您将它们从4-10小时减少到4-10分钟，则可以每小时运行一次，而不是每天运行一次。这似乎值得。如果您将其减少到3-8个小时，那么您可能不会从中获得太多收益。

我还要考虑的另一件事是优化工作。优化需要多长时间？您是否尝试过优化其中一些？您可以在一个机器上进行艰苦的工作，而在其他人上重复使用该工作吗？

要问的问题是...产生第二台机器以进行测试并移动一些机器是否一样容易？那里的套房？如果要花40个小时进行一些优化，而仅用8个小时的劳动加上一些资本支出来“投入更多硬件”，这样做是很经济的。

是一个简单的成本效益分析。确定通过优化获得的收益，并将其与这样做的成本进行比较。做一些研究（在这种情况下，包括做一些优化以了解所需时间的范围）并计算数字。

最后，我敢打赌，任何经理/面试官都会很高兴认识即将/即将成为其员工的人，很高兴知道您能够采取主动行动，并使团队的基础设施变得更好！

#6 楼

我认为您应该努力争取快速的反馈。理论上，使用并行测试执行，您的测试运行可能需要最慢的测试时间。在几分钟而不是几小时内完成的测试运行，可以帮助您以更短的周期工作，更快地发现错误，更快地改善测试套件等。

开发人员想知道他们所做的更改导致了产品中的错误。系统尽快。如果第二天他们听到了有关更改的内容，他们将不得不重新记忆。如果他们在事实发生半小时后才听到它，则修复起来要容易得多，因为他们所做的更改仍在内存中。

并行执行可能是使测试更高效的第一步。如果同时运行4个测试，则需要4个小时的测试运行大约需要1个小时，而同时运行30个测试，则大约需要8分钟。取决于系统，很难设置并行测试执行，但这可能是值得的。

使测试套件并行运行后，您可以选择最慢的测试并进行优化。

#7 楼

自动化的测试应该足够高效，而不能再有更多的效率。 ，因此运行4到10个小时并不太重要。另一方面，即使是很小的效率也会有所不同。“

这里不尝试使用循环逻辑，但这只是一个如果在您的环境中有问题，那么就会出现问题。

如果您有一个晚上可以运行所有测试，而您只会用10个小时来运行效率低下的测试，那可能没关系。使测试更加高效所花费的时间可能浪费了。您总是可以“使它变得更好”，而诀窍​​是变得“足够好”并继续前进。

另一方面，如果在某个时候需要运行如此多的测试，那么您就可以开始如果没有足够的通宵时间，那将是一个问题。

只有您才能确定是否存在问题，潜在问题或根本没有问题。

#8 楼

我在同一条船上，可以接受12到16个小时的测试时间。但是，如果除了编辑和调试之外，没有其他原因，那么高效就是路要走。尽管编写智能搜索可能会花费一些时间，但从长远来看，它将节省大量时间。此外，如果在窗口较少的情况下发生任何事情，则无需进行重构以使其效率更高。

但是，我要说的第二点是，您的团队重视效率您正在测试的代码中，您应归功于团队以高效地编写您的自动化测试代码。

#9 楼

在确保产品质量时，测试脚本的质量同样重要。因此，自动化应该非常有效。 （这比要求更好。）在现实世界中，自动化应该尽可能地高效。

某些方式：


**模块化测试**-如果测试可以完整且独立地运行，则可以执行所需的操作。应用程序的许多部分从未/没有那么频繁地受到影响。通过良好的判断，可以消除一直运行所有TC的需要。我们曾经在团队中开过一个玩笑，如果重建弗雷斯诺附近的I-5桥，则无需测试从圣地亚哥到西雅图的整个高速公路。

**烟雾/健康测试**-具有高效的烟雾测试，可以正常运行，而不是全面的测试。与完整的测试套件相比，健全性测试可以定期且更频繁地运行。

**置信度**（灰色区域）-对于质量检查小组来说，确定不同级别的置信度极为重要应用程序的模块，以便团队可以知道哪些模块需要比其他模块更频繁地进行测试。

**内部管理**-如前所述，“保持”测试套件并弃用或删除不再重要的TC非常重要。随着产品的成熟，可以消除很多TC，这将节省大量时间。例如如果产品中的某个模块计算公式，则在产品成熟且这些公式未更改时，较少的TC就足以对该模块进行完整性测试，而不是进行大量组合。

#10 楼

快速的反馈循环很好

反馈循环越快，您就可以对错误采取行动越快。假设这是每晚24小时运行，这是一个漫长的反馈循环，尤其是在敏捷环境中。

我的目标是让您的整个测试运行在CI上15-30分钟内运行签入代码时自动运行测试的服务器。这可以为开发人员提供快速反馈，以便他们可以快速发现（并修复）错误，甚至可以在自己的计算机上运行测试。

您将如何进行操作？


并行运行单个测试。
编写可在一系列测试中使用的可重用代码段。
删除无意义的测试毫无价值。
在功能更强大的计算机上运行测试。

对我有什么帮助？

1。可重用的代码段将加快未来的自动化速度。

编写一种快速有效的功能来检查下拉列表，您可以在其中提供所需的数据。在每个
测试中重复使用此代码，您还删除了许多缓慢且效率低下的代码
，从而减少了将来进行下拉列表测试所需的工作量。
>
重构在多个测试中使用的代码段更加容易，因此即使它不是当前世界上最高效的代码，您也可以在将来始终使用它，并提高其效率。在编写的每个使用此功能的测试中，您的速度都会提高。

2。如果开发人员知道他们的代码早被破解，我将获得更多的测试时间

一旦您实现了所有的效率节省，下一步就是剥离谷壳并并行运行测试。创建两个测试片将使您的运行时间减少一半（假设您智能地进行了测试，并根据其运行时间放置了测试）。您添加的每个额外片将减少测试时间，并帮助您缩短15-30分钟的运行时间。在他们签入代码的30分钟内，他们仍然会想到这个故事，应该能够迅速切换回代码并为您解决问题。如果您有一个24小时的反馈循环，则开发人员可能会转移到其他事情上，而忘记了他们昨天所做的事情，那么对他们来说，他们花费的时间会更长，而他们执行修复的时间也会更长。 >
作为测试人员，您正处于开发周期的最后，如果很快临近截止日期，那么您的时间就会受到挤压，以便项目可以按时完成。按照上述建议加速测试将为您提供更多的测试时间。假设开发人员在15分钟内解决了每个问题，则您的CI服务器每15分钟运行一次，可能会在一天的时间内捕获14种不同的错误，如果您每晚进行测试，则要花两个星期才能发现。

可以节省13天的测试时间，您需要一个比这更好的理由吗？

#11 楼

回答@corsiKa-关于减少GUI测试的测试时间的任何想法吗？

我经历过的一点是GUI测试，很多时候测试人员在每个操作之间增加了延迟/思考/等待时间，所以在单击/操作之前对象将变为可用。通常，自动化工具将功能/ api提供为waitUntilVisible（object）。如果使用该功能而不是随机等待时间（通常用于快速轻松地完成自动化），则随着时间步数的增加，自动化的运行时间将大大减少。

这是一个简单的提示，但我已经看过很多次了，由于遇到截止日期的压力，编程效率低下等原因，它被忽略了。

#12 楼

除了在这里看到的出色答案之外，我还要添加以下内容：


具有不同的测试集，一个小的“烟雾”测试集仅包含要在每个测试上运行的几个测试CI构建，并且有一个更全面的夜间运行。
避免在测试中使用Sleep语句。这些几乎总是表明测试代码不正确，因为它们会使您的测试变慢和/或变得不可靠。在快速的计算机上，您会浪费时间，而在速度较慢的计算机上，睡眠时间可能不够。自动化的测试工具通常提供进行某种同步的手段，例如等待对话框的出现或消失。

以下几项属于微优化类别，因此它们可能不会有所作为，但是在某些情况下，它们会


对对象进行编码时，请尝试减少必须搜索的对象数量。例如，如果要在对话框中找到按钮，则不要从根对象开始搜索所有对象，而只能在对话框中搜索。
Silk Test允许您重复使用手柄，而无需重新find他们。如果要在对话框上执行20个动作，可以先搜索该对话框，然后再执行20个动作，而不要在每个步骤之前都进行搜索。
还针对Silk Test：您没有提到如果您使用的是Classic Agent或Open Agent，但是对于新测试，建议您使用Open Agent，因为它比CA快得多（如果要缓慢迁移，也可以执行混合代理脚本）。

注意：我作为Silk Test团队的一员在Borland工作，因此表达的任何观点都带有高度偏见。

#13 楼

自动化功能强大，但不足以提供更好的产品。手动干预仍然很重要。但是，自动化使测试团队能够专注于新功能，非自动化功能，维护需求和测试数据需求，从而增强并确保质量。这样可以提高客户满意度，并增强客户对产品和公司能力的信任。 [blog]：http://www.ivesia.com/technology/blog/automated-testing-in-software-product-development-2/“单击此处获取更新”