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

Question

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

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

Мы следили за всей документацией здесь: 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.

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Однако, поскольку ваши тесты всегда терпят неудачу из-за тайм-аутов , стоит отметить, что в общем случае TimeoutException является результатом fail 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 по-разному. Поэтому вам необходимо убедиться, что используемые вами стратегии Locator оптимизированы.
• В соответствии с текущей Рекомендацией WebDriver-W3C ниже приведен список предпочтительных Стратегий локаторов :

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

---

Заключение

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