Случайные тесты Selenium E2e не выполняются из-за тайм-аутов в DevOps Azure, но работают локально и с удаленным Selenium (BrowserStack Automate)

У меня есть набор тестов Selenium, которые отлично работают в моей локальной среде и используют Browserstack Automate, но не работают на DevOps Azure.

При работе в Azure Devops изменений в конфигурации или настройках нет.

Мы следили за всей документацией здесь: https://docs.microsoft.com/en-us/azure/devops/pipelines/test/continuous-test-selenium?view=vsts

Случайные тесты проваливаются, никогда не повторяются.

Тесты всегда терпят неудачу из-за тайм-аутов. Я жду загрузки страниц в течение 5 минут, поэтому время ожидания не слишком велико.

Там нет брандмауэров на месте, приложение является публичным.

Аутентификация всегда успешна, поэтому тесты могут загрузить приложение.

Не уверен, что попробовать дальше.

Ниже приведена копия журнала DevOps Azure. 4 теста пройдены, но все остальные не пройдены. Обычно только 4-5 тестов не пройдены.

Этот тест прекрасно работает с использованием BrowserStack Automate (удаленный селен) и локально.

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 ответа

Решение

Вот несколько шагов, которые я бы сделал:

  1. Что помогло нам в аналогичном случае, так это временно добавить видеомагнитофон в тесты, а затем наблюдать процесс выполнения тестов на ВМ от начала до сбоя. Могут быть некоторые подсказки на видео, которые помогают увидеть, что на самом деле идет не так, как я мог найти эту ссылку для примера C#

  2. Кроме того, я бы дважды проверил, чтобы убедиться, что версии браузера в Azure точно такие же, как и в прогоне, где все работает хорошо. Делать их одинаково важно, чтобы убедиться, что нет "волшебства". То же самое для размера окна браузера по умолчанию.

  3. Я бы сделал более подробный анализ мест, где разные тесты не пройдены.

    • Можно ли обнаружить сходство между различными неудачами испытаний. Всегда ли это происходит после кликов? после перезагрузки страниц? после всего, что похожее? Если да - попробуйте самое странное, но простое, а иногда и спасительное решение, и добавьте 3-5 секундный сон до / после действия, предшествующего сбою. (добавить сны с условием, которое должно происходить только во время пробега Azzure) (да, сны не рекомендуются, и {много известной информации, почему они не рекомендуются, могли быть здесь}, но... если они волшебным образом спасут вас запускает, потом их можно заменить на некоторые умные ожидания наверняка)
    • Возможно ли, что сбои происходят в определенное время? После того же времени после запуска? В то же время в течение дня?

  4. Если вы используете API-интерфейсы Date / Time в своем коде, убедитесь, что настройки System time / locale / timezone точно такие же. Или что дни не меняются во время тестовых прогонов. В общем и целом - исследуйте даты.

Я знаю, что вышесказанное больше похоже на общий совет, но по моему опыту такие "случайные ошибки" могут быть вызваны буквально всем, что кажется "не заслуживающим внимания".

Источник

Несколько строк из вашего блока кода помогли бы лучше проанализировать вашу проблему.

Однако, поскольку ваши тесты всегда терпят неудачу из-за тайм-аутов, стоит отметить, что в общем случае TimeoutException является результатом неудачных ExpectedConditions. Однако могут быть и другие проблемы.

Вот некоторые из подходов, позволяющих избежать этих проблем:

  • Как вы упомянули, я жду загрузки страниц в течение 5 минут... это будет противоречить всем лучшим методам. Вместо этого вам нужно реализовать PageLoad, ImplicitWait или же WebDriverWait

ВНИМАНИЕ: не смешивайте неявные и явные ожидания. Это может привести к непредсказуемому времени ожидания.

  • Вы можете найти подробное обсуждение в Как я могу убедиться, что некоторые элементы HTML загружены для Selenium

  • Если вы используете ChromeDriver и Chrome Browser, вы должны убедиться, что двоичные файлы совместимы, как указано ниже:

    • ChromeDriver v2.44: поддерживает Chrome v69-71 (аналогично ChromeDriver 2.43, но с дополнительными исправлениями ошибок, выпущенными 20 ноября 2018 года)
    • ChromeDriver v2.43: поддерживает Chrome v69-71
    • ChromeDriver v2.42: поддерживает Chrome v68-70
    • ChromeDriver v2.41: поддерживает Chrome v67-69
  • Различные браузеры отображают HTML DOM по- разному. Поэтому вам необходимо убедиться, что используемые вами стратегии локатора оптимизированы.
  • Согласно текущей Рекомендации WebDriver-W3C, ниже приведен список предпочтительных стратегий локатора:

Locator Strategies_W3C

  • Существует некоторая разница в производительности при использовании CssSelector и XPath. Несколько забрать:
    • Для начала, нет никакой разницы в производительности между XPath и CSS.
    • Обход DOM в старых браузерах, таких как IE8, не работает с CSS, но подходит для XPath. И XPath может подниматься по DOM (например, от дочернего к родительскому), тогда как CSS может проходить только по DOM (например, от родительского к дочернему). Однако невозможность обходить DOM с помощью CSS в старых браузерах не обязательно является плохой вещью, поскольку это скорее показатель того, что ваша страница имеет плохой дизайн и может извлечь пользу из некоторой полезной разметки.
    • Аргумент в пользу CSS заключается в том, что они более читабельны, кратки и кратки, хотя это субъективный вызов.
    • Бен Бертон упоминает, что вы должны использовать CSS, потому что именно так создаются приложения. Это облегчает написание тестов, их обсуждение и помощь в поддержке других.
    • Адам Гучер говорит, что должен принять более гибридный подход - сначала сосредоточиться на идентификаторах, затем на CSS, и использовать XPath только тогда, когда вам это нужно (например, прогуливаясь по DOM), и что XPath всегда будет более мощным для продвинутых локаторов.
    • Вы можете найти подробное обсуждение в разделе Почему я должен когда-либо использовать селекторы CSS, а не XPath для автоматического тестирования?

Заключение

Принимая во внимание вышеупомянутые факторы, необходимо грамотно реализовать Стратегию локатора вместе с другими подходами, рассмотренными выше, которые помогут вам избавиться от таймаутов.

Источник
Другие вопросы по тегам