Работа с тестами Selenium, которые иногда дают сбой во время автоматического развертывания - PullRequest
8 голосов
/ 01 декабря 2011

У нас есть веб-приложение на C # / ASP .Net, которое создается и разворачивается сервером сборки (Jenkins). Одним из шагов сборки перед автоматическим развертыванием является гарантия того, что все автоматизированные тесты пройдены, включая функциональные тесты, которые мы использовали с помощью Selenium 2 WebDriver и NUnit.

Проблема: иногда эти тесты не проходят случайно. Они преуспеют в течение 100 сборок, а затем одна из них провалится Они терпят неудачу по разным причинам - событие .Click () просто игнорируется, элемент не может быть найден, у IE плохой день и т. Д. У нас есть тяжелое веб-приложение AJAX, поэтому мы сильно зависим от WebDriverWaits, но всегда принимаем это учитывается при написании тестов, и, как я уже сказал, тесты проходят большую часть времени.

Какими способами можно избежать или исправить эту проблему? Пара, которая пришла мне в голову:

  • Принять определенное количество неудач (кажется плохой идеей)
  • Неудачные тесты?

Ответы [ 2 ]

9 голосов
/ 01 декабря 2011

Мне не нравится ни одно из упомянутых вами предложений, но я признаю, что использовал их время от времени.Лучшее, что можно сделать, - это убедиться, что в случае «случайного» отказа сделать все возможное, чтобы получить все данные о том, почему это действительно не удалось.Это была проблема окружающей среды?Какой-то другой процесс на машине мешал тестам?Была ли проблема синхронизации, которая появляется только тогда, когда сайт загружается мучительно медленно или быстро?

Одна вещь, которую вы можете попробовать, - это тестирование ваших автоматических тестов.Запустите каждый из них более 100 раз в одной и той же сборке и в одной и той же среде (так что вы можете исключить их в качестве потенциальных точек сбоя) и найти те, которые иногда терпят неудачу.Смотрите, если они терпят неудачу в том же месте или в разных местах.Обычно, выполняя это упражнение, вы обнаруживаете, что некоторые тесты немного ненадежны, и вы можете удалять их из ежедневного цикла, пока они не будут исправлены.Вы могли бы даже включить выдержку в качестве критерия регистрации для любого автоматизированного тестового случая.

Еще одна полезная вещь, которую я обнаружил, которая помогла мне разобраться в некоторых из, казалось бы, случайных отказов, делала снимки экрана при сбое.Часто вы видите, что всплывают другие окна или диалоговые окна, в результате чего браузеры не могут быть в первых рядах и т. Д.

5 голосов
/ 01 декабря 2011

Из двух я предпочел бы повторно выполнить тестовые сбои или, скорее, при неудачном тесте, повторить тесты.

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

Что касается повторного запуска, я не эксперт по тестированию с NUnit, но вы могли бы сами управлять тестами. В JUnit вы можете ввести правило, чтобы в случае сбоя теста она повторялась максимум 3 раза. Это, вероятно, позволит избежать большинства проблем, с которыми вы столкнулись. Я не знаю, как это сделать в NUnit, но посмотрите мой ответ на Как немедленно повторно запустить неудачные тесты JUnit? Это даст вам общее представление.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...