代码之家  ›  专栏  ›  技术社区  ›  John Farrell

随机的Selenium E2e测试由于azuredevops上的超时而失败,但是可以在本地和远程Selenium(BrowserStack automatic)上工作

  •  7
  • John Farrell  · 技术社区  · 7 年前

    我有一套Selenium测试,可以在本地环境中完美地工作,并使用Browserstack automatic,但在azuredevops上失败。

    在Azure Devops上运行时没有配置或设置更改。

    我们遵循了这里的所有文档: https://docs.microsoft.com/en-us/azure/devops/pipelines/test/continuous-test-selenium?view=vsts

    随机测试失败,从来不是相同的测试。

    测试总是因为超时而失败。我等待页面加载5分钟,这样就不会出现超时过低的情况。

    没有防火墙,应用程序是公共的。

    身份验证总是成功的,因此测试能够加载应用程序。

    下面是Azure DevOps日志的副本。4项测试通过了,但其他的都失败了。通常,只有4-5个测试失败。

    这个测试使用BrowserStack automatic(远程selenium)和本地测试非常有效。

    2018-11-17T05:40:28.6300135Z  Failed   StripeAdmin_WhenOnTab_DefaultSortIsByIdDescending
    2018-11-17T05:40:28.6300461Z Error Message:
    2018-11-17T05:40:28.6304198Z  Test method CS.Portal.E2e.Tests.Admin.StripeAdmin.StripeAdminTests.StripeAdmin_WhenOnTab_DefaultSortIsByIdDescending threw exception: 
    2018-11-17T05:40:28.6305677Z OpenQA.Selenium.WebDriverTimeoutException: Timed out after 300 seconds
    2018-11-17T05:40:28.6307041Z Stack Trace:
    2018-11-17T05:40:28.6307166Z     at OpenQA.Selenium.Support.UI.DefaultWait`1.ThrowTimeoutException(String exceptionMessage, Exception lastException)
    2018-11-17T05:40:28.6307999Z    at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
    2018-11-17T05:40:28.6308188Z    at CS.Portal.E2e.Tests.Utility.WebDriverUtilities.WaitForElement(IWebDriver driver, By by, Boolean mustBeDisplayed) in D:\a\1\s\CS.Portal.E2e.Tests\Utility\WebDriverUtilities.cs:line 26
    2018-11-17T05:40:28.6319651Z    at CS.Portal.E2e.Tests.Admin.StripeAdmin.StripeAdminTests.StripeAdmin_WhenOnTab_DefaultSortIsByIdDescending() in D:\a\1\s\CS.Portal.E2e.Tests\Admin\StripeAdmin\StripeAdminTests.cs:line 51
    2018-11-17T05:40:28.6319982Z 
    2018-11-17T05:40:34.4671568Z Results File: D:\a\1\s\TestResults\VssAdministrator_factoryvm-az416_2018-11-17_03_08_24.trx
    2018-11-17T05:40:34.4692222Z 
    2018-11-17T05:40:34.4695222Z Attachments:
    2018-11-17T05:40:34.4697610Z   D:\a\1\s\TestResults\672f4d28-5082-42e9-a7e7-f5645aadcfd8\VssAdministrator_factoryvm-az416 2018-11-17 03_02_43.coverage
    2018-11-17T05:40:34.4697943Z 
    2018-11-17T05:40:34.4698278Z Total tests: 34. Passed: 4. Failed: 30. Skipped: 0.
    
    2 回复  |  直到 7 年前
        1
  •  0
  •   Vladimir Efimov    7 年前

    以下是我要做的一些步骤:

    1. 在类似的情况下,帮助我们的是临时向测试中添加一个录像机,然后观察VM上从开始到失败的测试执行过程。视频中可能有一些线索,有助于了解到底出了什么问题 I was able to find this link for a C# example

    2. 我会对不同测试失败的地方做更详细的分析。

      • 是否有可能发现不同测试失败之间的相似之处。它总是在点击之后发生吗?重新加载页面之后?在其他类似的事情之后?如果是的话-尝试用最奇怪但简单的,有时是救命的解决方案,在失败之前的动作前后加上3-5秒的睡眠(添加只在Azzure运行时才发生的条件睡眠(是的,不建议和{ }但是。。。如果他们神奇地保存了你的跑步记录,那么你可以用一些智能等待来替换它们(当然可以)
    3. 如果在代码中使用日期/时间API,请确保系统时间/区域设置/时区设置完全相同。或者在测试运行期间天数不变。总的来说-围绕日期进行调查。

        2
  •  7
  •   undetected Selenium    7 年前

    你的几句话 代码块 有助于更好地分析你的问题。

    然而,由于你的测试总是失败,因为 值得一提的是,总的来说 失败 ExpectedConditions

    避免这些问题的一些方法如下:

    WARNING :不要混合隐式和显式等待。这样做会导致不可预知的等待时间。

    Locator Strategies_W3C

    • 这两种方法有些不同 CSS选择器 XPath . 一些外卖:
      • 对于初学者来说,XPath和CSS在性能上没有显著差异。
      • 在旧浏览器(如IE8)中遍历DOM不适用于CSS,但可以使用XPath。XPath可以遍历DOM(例如从子对象到父对象),而CSS只能遍历DOM(例如从父对象到子对象)。然而,在旧浏览器中不能用CSS遍历DOM并不一定是坏事,因为这更像是一个指示器,表明您的页面设计不好,可以从一些有用的标记中获益。
      • 支持CSS的一个理由是,当CSS是一个主观调用时,它们更具可读性、简洁性和简洁性。
      • Ben Burton 提到您应该使用CSS,因为这是应用程序的构建方式。这使得测试更容易编写、讨论,并且让其他人帮助维护。
      • Adam Goucher 建议采用一种更混合的方法——首先关注IDs,然后关注CSS,只有在需要时才利用XPath(例如,在DOM中漫游),而且XPath对于高级定位器来说总是更强大的。
      • Why should I ever use CSS selectors as opposed to XPath for automated testing?

    结论

    Locator Strategy 明智地与上面讨论的其他方法一起使用,这些方法将帮助您摆脱 .

    推荐文章