Перезапуск упавших тестов TestNG, Java, Webdriver


(qw1564) #1

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


(Mykhailo Poliarush) #2

делал с помощью стандартных средств, но так чтобы прослеживать историю нескольких прогонов, то нет 

а зачем вам это? чего Вы хотите добиться?

5.11 - Rerunning failed tests

Every time tests fail in a suite, TestNG creates a file called testng-failed.xml in the output directory. This XML file contains the necessary information to rerun only these methods that failed, allowing you to quickly reproduce the failures without having to run the entirety of your tests.  Therefore, a typical session would look like this:

Note that testng-failed.xml will contain all the necessary dependent methods so that you are guaranteed to run the methods that failed without any SKIP failures.


(Mykhailo Poliarush) #3

вот еще ссылка http://stackoverflow.com/questions/473911/how-can-i-merge-multiple-testng-suite-results-to-one-report


(asolntsev) #4

Может, стоит выяснить, откуда берётся рандомные упавшие тесты, и исправить настоящую причину?

 


(qw1564) #5

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

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

btw, используем мы для сборки Jenkins/Maven.

собственно я вижу 2 подхода к решению :)

  • просветите плз - на каком этапе testng генерирует репорты и где до записи в репорты хранятся результаты? как их прочитать и вмешаться?

             правильно ли я понимаю что можно переопределить

 

 

@Override
public void onTestFailure(ITestResult result) {
 
result.getMethod();
 
//запустить тот тест что мы получили по getMethod() ещё раз (если так вобще возможно то как?), получить newResult и если в нем фейл - 
 
super.onTestFailure(newResult);
}
 
  • идея мержить репорты отошла на 2й план, но если всёже прийдется идти по этому пути - правильно ли я вижу порядок действий: 
  1. выполняем тест сьют, сохраняем testng-results.xml как part1.xml
  2. выполняем testng-failed.xml (кстати в двух словах если в курсе - как это лучше сделать из под CI?)  берём part2.xml и сохраняем testng-results.xml как part2.xml
  3. мержим part1 и part2 в testhg-final.xml
  4. говорим jenkins брать репорты из testhg-final.xml (кстати сейчас в дженкинсе всё настроено вот так:  "Post-build actions: Publish JUnit test result report - **/target/surefire-reports/*.xml" . просветите плз кто в курсе - почему нет конкретного указания репорта?

заранее спасибо :)


(Mykhailo Poliarush) #6

ну тогда вам стоит попробовать IRetryAnalyzer

http://testng.org/javadoc/org/testng/IRetryAnalyzer.html

описываем класс, который будет задавать логику перезапуска теста, например https://code.google.com/p/testng/source/browse/trunk/src/main/java/org/testng/util/RetryAnalyzerCount.java

и подключаем его к самому тесту через аннотацию @Test

если погуглите, я думаю найдете код, например первая попавшияся ссылка http://sqa.stackexchange.com/questions/5140/testng-iretryanalyzer-not-working


(asolntsev) #7

По-моему, очевидно, что решать проблему надо не перезапуском.

Просто автоматические тесты надо запускать не на том же серваке, где работают ручные тестеры. Чтобы они не пересекались. 

Я понимаю, стандартный ответ на это - что поддерживать два сервера дорого, но поверьте, вся та путаница, которая появится с перезапуском тестов, обойдётся фирме гораздо дороже. А самое опасное - это "если проблема действительно будет в приложении то она так или иначе себя обнаружит". Таким образом ошибки очень легко попадают на продакшин. Я это видел своими глазами много-много раз. 

Настоящая ваша цель - добиться того, чтобы тесты работали стабильно, и все в компании верили, что если тест упал, это точно бага, и её надо срочно исправлять. 


(Vitalik) #8

Я запускаю тесты из-под Jenkinsa, а там всегда очень четко разложено что упало и когда. Советую...


(Sergey Korol) #9

Мне кажется, что идея перезапуска зафейлившихся тестов себя не окупает в ситуации огромного кол-ва кейсов. По сути вы жертвуете экзекьюшен таймом ради достаточно сомнительной фильтрации. Ведь далеко не факт, что зафейлившийся тест через минуту после перезапуска даст вам достоверный результат. И вообще, такой подход может сыграть с вами злую шутку: тест упал в результате рендомно проявляющегося бага, вы перезапустили - баг не всплыл. В итоге, якобы все хорошо, а потом на продакшене этот рендомный баг скажет всем - hello. Виноватых найдут быстро. И в первую очередь пострадают автоматизаторы. Впрочем, если общий экзекьюшен тайм в последствии станет больше времени мануальной проверки, то вашу автоматизацию просто напросто прикроют.

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


(qw1564) #10

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

вот пример из недавнего - не открывается регистрационная форма в одном из 500 тестов после клика по RegisterLink - при этом локаторы уникальные и правильные - проверял на сохраненном при падении теста html страницы, в логах приложения никаких проблем на этом этапе нет. заводить баг причин не вижу, в нашем коде очевидных проблем тоже нет.

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

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


(vmaximv) #11

Неочевидных проблем в автоматизации гораздо больше, чем очевидных. Я уверен, что все на данном форуме сталкивались с тем, что *иногда* не кликнуло/не выбрало/не натайпало. В 90% слово *иногда* будет связано с необходимостью добавления дополнительных ожиданий (зачастую даже несвязанных с проблемным элементом). Решать проблемы синхронизации через итеративный запуск не самый лучший вариант. Заваленные в первый проход "рабочие" тесты становятся "тестами Шредингера", на которые вы будете смотреть с позиции "жив".

Ведь если есть вероятность, например 10%, что тест упадет, то ни что не мешает ей резко увеличится до 50%. Т.е. количество необходимых итераций заведомо не известно, и делать какие-то выводы по статистическим данным - это не научно :)

Даже если вы пойдете по пути итераций, убьете кучу времени на реализацию "two pass verification" и получите цельный "зеленый" репорт, это не даст вам 100% гарантии, что всегда два прогона будет достаточно. Тервер подлая штука - если тест случайно один раз упал, он обязательно упадет еще раз, причем в самое неподходящее время в самом неподходящем месте :)

И вы не описали, есть ли корреляция между "рандомными" фейлами. Если нету, надо решать проблему глобально, если есть - локализировать проблему.


(asolntsev) #12

В подавляющем большинстве случаев причина таких проблем в том, что какой-то JavaScript не успел сработать, и поэтому текст не появился, проперти не добавилось и т.д. 

Типичное решение для этого - wait.

Позволю себе порекомендовать вам библиотеку Selenide - это надстройка надо Selenium, которая автоматически добавляет wait ко всем вызовам, что снимает львиную долю проблем с рандомными фейлами.