应对片状测试的另一种方法

在QA测试自动化世界中,我们都知道这是不可避免的一件事-“片状测试失败,我们只需要处理它”。 现在,您知道我在这里谈论什么测试。 这些是为Web应用程序创建的众所周知的自动化测试,通常称为“ UI”,“用户接受”或“端到端”测试。

每个QA自动化工程师或SDET希望每天早晨上班,并希望绿色建筑(所有测试通过)。 自动化测试套件应该是可靠的,因为任何失败的测试都应表明存在错误,而不是表明误报的易碎测试。 如果测试仅由于不稳定而失败,则会降低对自动化的信心,并随着时间的流逝而产生挫败感-更重要的是,重新运行它们所浪费的时间只是为了让这些不稳定的测试在重新运行时通过。

今天可能有解决方案来处理这些片状测试。 即使我们大多数人都认为自动重新运行将有助于节省时间,我们还是有许多可用的解决方案,尤其是在开源社区中。 最受欢迎的基础网络自动化框架是“ Selenium”。 有几种开源工具,例如“ Geb”,即“自动实现Web浏览器和Web内容之间的交互”,具有自己易于使用的DSL,并且基本上是其底层Selenium WebDriver框架的包装。

处理不稳定测试的一个一般想法是使用自定义解决方案自动重试失败的测试。 开源社区中已经有几种解决方案。 一旦这种解决方案是Spock-Retry。 只需使用RetryOnFailure注释您的Spec, 它就可以立即运行测试。 我观察到的一件事是,尽管这些是重试的好方法,但它们有时不起作用,因为即使在其他测试并行运行时,这些解决方案也会重试。

当计划每天晚上运行数百个回归测试时,通常将这些测试配置为在5或6个浏览器或有时12个浏览器中并行运行,具体取决于运行测试的计算机的CPU核心数。 因此,当您使用重试解决方案时,当其他测试并行运行时,片状测试将立即重试(或经过一些延迟时间)。 在运行其他测试时重试不是一个合适的时间,因为计算机仍在忙于运行多个浏览器以及该计算机中发生的许多其他事情,例如在后台运行的多个自动化代理进程,其他测试事件(例如DB CRUD操作等)……最后,即使重试,易碎的测试也可能再次失败。

我们需要在单独的作业中重新运行片状,而该机器上没有其他测试在运行。 这个想法是将所有那些失败的失败测试记录并存储在一个文件中,然后将其作为切换传递到下游的Jenkins作业(称为隔离作业),该作业将仅运行那些失败的测试。

  1. 在夜间运行期间将失败的规格记录在文件中。
  2. 自动启动下游作业,然后仅运行那些失败的测试。 该下游读取文件并生成命令以运行特定测试(顺便说一句,此下游作业有条件地运行-如果全部通过上游作业则不运行)。 例如,在Gradle中,您可以调出要运行的特定测试( gradle test --tests package1.MyFailedSpec1 package2.MyFailedSpec2

以这种方式重新运行测试的优点:

  1. 通常,通常有2-3%的测试无法通过一次测试。 只运行那些失败的测试,使我们能够在一个浏览器中使用它们来顺序运行它们(现在,测试机具有更多的资源来呈现页面),而不是并行运行它们。 避免并行运行大大降低了这些测试由于其他原因而再次失败的可能性,这些其他原因是我们无法控制的(例如,并行运行更多测试时机器CPU忙等)。
  2. 将不稳定的测试记录在一个单独的文件中,使我们可以利用该文件有机会根据此数据创建仪表板,并查看哪些测试始终失败。

即使您不喜欢在Jenkins中进行下游运行的工作方式,也可以在方便的时候运行它们。 您甚至可以将此文件共享给团队中的任何人,这样他们就可以将其复制并完全重新运行那些失败的测试。

在评论中分享片状测试的经验。 它可能以某种方式帮助某人。