如何将Selenium测试运行时间减少70%(一)

在每个自动化UI测试的实现深处，都有可能将简单的事情变成缓慢且不可靠的事情——只需添加额外的Selenium命令。原因：更长的测试不太可能通过。

下面是一个例子，说明这在现实生活中是如何发生的。在下面的情况下，我将分析一个测试，以揭示和解决测试运行时间中 70% 的低效率问题。您可以将学到的经验教训应用到您自己的测试中。

问题

测试中的许多Selenium命令会使测试显着变慢和不太可靠的原因之一是每个Selenium命令都可能导致无效的元素定位器或同步问题。

在此示例中，旧版本测试需要300秒才能运行并执行364个Selenium请求。

但是在进行了下面描述的测试优化之后，同样的测试在92秒内执行——快了近四倍。

识别低效率

在这种情况下，失败的根本原因是无法定位下面的元素（调度程序）。失败发生在测试72秒后。

测试的其余部分用于执行不会导致进展的不相关和重复的操作。例如，测试继续搜索调度程序另外60秒，直到 2:12。

此时，测试执行一些随机操作，可能会刷新状态，然后继续搜索Scheduler，如果它在前60秒内没有出现，则永远不会这样做（见下文）。

只需300秒中的72秒就可以发现Scheduler元素不存在。因此，76%的测试时间是浪费；它不提供新的或有意义的信息。这意味着反馈循环慢了76%。


 

相关阅读:

软件功能测试的类型之烟雾测试

软件功能测试类型之回归测试

功能测试的类型之集成测试

功能测试的类型之单元测试

功能测试的类型之Alpha和Beta测试

功能测试的类型之用户验收测试

软件功能测试过程中的常见测试点

功能测试和自动化测试的区别