Снижение стабильности тестов при параллельном выполнении

Доброго времени суток, коллеги!
Нужен совет по следующей ситуации:

Дано:

  1. Selenide 2.23
  2. JUnit
  3. Allure
  4. Jenkins (удаленный сервер под управление unix системы)
  5. 100 UI тестов.
  6. FireFox - 38.3.0 esr
  7. Maven

При выполнении тестов локально, проблемы, вроде, не возникают. Все елементы находятся. Как только запускаю тесты удаленно в параллельном режиме (параллелизация по классам, 10 потоков) ИНОГДА возникают ситуации, что некоторые елементы просто не находятся.
Местами ситуация доходит до смешного: имеется 20 тестов, которые используют абсолютно одни и те же елементы. Так вот, 19 из них выполнится без вопросов, а один может упасть. При повторных перезапусках могут отработать все, а может упасть другой тест (или пара) по той же причине (бывает, что не найдены разные елементы).
Такая нестабильность просто… ну вы меня поняли :smile:
И нет никакой системы в падениях! Сейчас упали одни - перезапустился - все норм, еще раз - все норм, на третий что-то да отвалится… Такое ощущение, что вопрос в самом FireFox, тип когда их много то им надо дольше времени на “подумать”.
Добавлю лишь, что все ожидания - динамические (спасибо Selenide) и, опять же, локально или в одном потоке к ним претензий нет (вроде…).

У кого есть идее, подскажите в чем может быть дело?

Собственно логичный вопрос, опишите как вы их распараллелили? Желательно с примерами, конфигами и тд.

А мне вот еще интересно, где запускаются все эти 10 потоков - на разных тачках, или в пределах одной?

В пределах одной

Параллелизация реализована с помощью Maven (maven-surefire-plugin v 2.18.1)
Вот кусочек помника:

 <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.18.1</version>
                <configuration>
                    <argLine>
                        -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                    </argLine>
                    <properties>
                        <property>
                            <name>listener</name>
                            <value>ru.yandex.qatools.allure.junit.AllureRunListener</value>
                        </property>
                    </properties>
                    <parallel>classes</parallel>
                    <systemPropertyVariables>
                        <threadCount>threadCount</threadCount>
                    </systemPropertyVariables>
                    <perCoreThreadCount>false</perCoreThreadCount>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.aspectj</groupId>
                        <artifactId>aspectjweaver</artifactId>
                        <version>${aspectj.version}</version>
                    </dependency>
                </dependencies>
            </plugin>
</plugins>

При запуске тестов переменной threadCount присваиваю нужное мне количество потоков.
Собственно, вот и вся магия.

10 одновременно работающих браузеров - очень ресурсоёмкое мероприятие (конечно, ещё от приложения зависит, если и оно не лёгкое, то тем более). Уменьшайте количество одновременных потоков. Либо смотрите чего не хватает в ресурсах - диска, памяти, проца.

3 лайка

Да, верное замечание.
Либо попробуйте параллелить на более “жирной” машине либо же выносить в грид. Т.к. очень вероятно, что в текущей реализации бывают подтормаживания браузера и поэтому драйвер не может что-то найти.

Чтобы избавиться от “вроде” в локально, то поднимите виртуалку с конфигурацией схожей с удалённой и запустите хотя бы раз 10 тесты к ряду, чтобы понять, падают или нет…


Do different tests instead of repeating the same tests

1 лайк

+1.
Еще полезно сохранять скриншот при падении: если элементы не успевают подгрузиться, можно это заметить.

1 лайк

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

А каким образом происходит доступ к элементам страницы? Напрямую или через PageObject?
Если напрямую, то такое поведение может быть слествием самодеятельности браузера по сборке мусора и оптимизации DOM. В этом случае PageObject может помочь.

Я использую PageFactory. Все веб елементы объявлены с аннотацией @FindBy и, на сколько я понимаю принцип работы етого механизма, их поиск происходит в момент обращения теста к етому елементу.

Напрямую или через PageObject?

Мне не совсем понятен етот вопрос… В чем разница доступа на прямую и через пейджу? Что в первом то и во втором случае поиск все равно осуществляется драйвером в момент, когда страница “дала команду” что она загрузилась. Или мое представление не правильное?

Остается еще грешить на плагин, который “натягивает” верстку на елементы, но с другой стороны, если елемент уже в доме и имеет статус visible, какая ему разница что там плагин делает… Если, конечно, плагин не изменяет статус елемента…

Вдруг найдете решение - делитесь, пожалуйста.
Очень похожая проблема у нас. Набор такой же, только Thucydides вместо Selenide.
На локальных машинах тесты проходят успешно, запущенные с дженкинса - падают с ошибкой
AssertionError: org.openqa.selenium.NoSuchElementException: Timed out after 30 seconds. Unable to locate the element: Element is not usable [[RemoteWebDriver: firefox on WINDOWS (ec97b964-b3c3-4c7c-921d-6e041a50d3bc)] -> id: some-id-here]
На скриншоте элемент уже отрисован, вряд ли цсс не успевает подтянуться.
Были догадки, что проблема с совместимостью версий селениума и файрфокса, но эксперименты с версиями пока устойчивых результатов не принесли.

Действительно, вы слишком много хотите от компьютера. 10 поток - это черезчур. Почему не 100?
Кстати, мне вот всегда интересно было. Вы уверены, что именно тесты - самая медленная часть, т.е. параллелить стоит именно тесты? Эти 10 браузеров ведь обращаются к одному приложению, а оно лезет в одну базу данных? И следовательно, если дёргать приложение из 10 браузеров, быстрее оно не станет. Тормозить будет точно так же (точнее, даже больше).

Тестируемое веб-приложение стоит на мощном сервере, и к нему (в т.ч. и базам которые оно использует) ежесекундно обращается гораздо больше реальных пользователей, чем то количество что эмитируют мои тесты. Даже в параллели 10 потоков.

Машина с Jenkins и тестеми - оренда на Amazon, там железо без претензий…

Учитывая изложенное, у меня подозрения что вопрос именно в тестах. Возможно даже в WebDriver или самом FireFox. Но вот что именно и как ето “лечить”. Неисключено что независимо от “мощности” железа ето можно вылечить только уменьшением количества потоков.

Андрей, а в твоей практике какой стабильный придел потоков для параллельного запуска тестов?

Когда я работал с сусиком, то, как не странно, решал аналогичную проблему снижением количества потоков.
Но у меня тогда не было таких ресурсов, какими я располагаю сейчас.
Попробуйте, может получится…

Мы запускаем тесты в 4 потока на Chrome на одной машине. Более-менее работает, но chrome/chromedriver иногда зависает.

Коллеги, еще такой вопрос по теме:
что если для повышения стабильности тестов подымать грид (локально)?
Я никогда с гридом не работал, но судя по литературе - он специально разработан для запуска большого количества разных браузеров. Возможно ета его особенность поможет решить вопрос?

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

Если не хотите интерекшенов - запускайте ваши браузеры в докер контейнерах. На гитхабе селениума уже лежат докерфайлы образов, все что нужно сделать это установить докер на машины и запустить контейнеры, ну и указать тестам путь к гриду.
1 контейнер 1 браузер 1 поток - все изолированно, никаких интерекшенов.
Легко маштабировать
А гонять на одной тачке 100 браузеров друг на дружке это полная жопа

1 лайк

Звучит очень обнадеживающе. Подскажи, плз, а принципиально в чем разница между параллелизмом Maven и запуском тестов в doker?

ЗЫ никто не гоняет 100 тестов сразу. Это их общее количество. Запуск происходит в параллель - макс 10 фаерфоксов.