Pull to refresh

Comments 15

Из всей статьи полезными оказались только ссылки…
Это статья для тех, кто отказывается от селениума столкнувшись с первыми трудностями. Здесь описан общий подход к решению проблем, с которыми рано или поздно придется столкнуться. Я нарочно опустил о распаралеливании, динамической замене driver'a и прочих вещах, которые пригодятся при более сложной интеграции.

Если нужно о чем-то написать подробнее — пишите, поясню, и приложу примеры кода.
Добрый день.
Спасибо за статью, натыкался на подобные подводные камни.

У меня вот какой вопрос.

У меня есть тесты, которые гоняются через связку Thuсydides + Easyb.
WebDriwer — phantomJS.

И следующая проблема:
На моей рабочей машине тесты прогоняются за 50 минут.

На linux сервере с xvfb они прогоняются за 7 часов.

Мне думается что узкое место где-то в linux + xfvb, ибо на моей машине под XP они гоняются гораздо быстрее.

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

Можете описать вашу проблему более подробно?
Да на обоих машинах доступ к сайту одинаковый, обе в одной сети с сервером, на котором сайт.

Машина на которой Jenkins и xvfb мощнее в плане оперативки и процессора, но там нет видео.
У меня на рабочей машине есть видео.

Там все шаги дольше выполняются намного. Поиск, считывание значение с полей, установка значений.
Коллега, которой выкладывал, говорит, что создается ощущение, что где-то в phantomJs или xvfb sleep стоят, ибо он некоторое время простаивает.
Может быть дело в TCP_NODELAY?
Мне кажется что проблема непосредственно в настройках линуска. К слову, у нас на на centOS выполняются в разы быстрее чем на XP или win8.
Сейчас все пытаюсь этот TCP_NODELAY победить, как его настроить не могу нагуглить. Решил пересобрать pahntomjs из исходников с небольшим дополнением, которое добавляет данную опцию для сокета, с которым phantomjs работает.

Дополнительная информация:
Поставил на рабочей машине на Vbox Ubuntu 13.10, под ней тесты прошли чуть медленнее, ввиду слабых параметров. Но все равно быстрее чем на сервере с jenkins. Кстати узнал, что там centOS.

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

Как только разберусь с TCP. Обязательно отпишусь. Думаю, что решение моей проблемы помжно будет добавить в хвост статьи, мало ли у кого такая же проблема возникнет.
Скажу так. У нас никаких проблем с производительностью не было.
Попробуйте поставить плагин «Monitoring» или что-то в этом духе. Гораздо удобнее наглядно понимать проблему.
К примеру у нас были случаи, когда многопотоковое приложение попадало в swap, с коим java не очень хорошо работает. Были случаи, когда сборки забирали 100% CPU и прочее.
Блин все дело оказалось в гипервизоре.
На той машине где тесты гонялись он криво работает.
Жалко что кучу времени потратил, на поиски проблем на более высоком уровне =(
Приходилось в работе сталкиваться с Jenkins, но больше всего мне понравилось использовать open source инструмент — Thucydides, в основе которого лежит WebDriver.
Для данного инструмента нужен CI сервер. У jenkins есть плагины для работы как и с Thucydides так и для Selenium. Возможности последнего, к сожалению ограничены, по этому мы и пользуемся связкой Selenium+TestNG
Давно пользуетесь? Решена ли в итоге проблема разборки логов?
Уже больше года. Тесты запускаются после каждого коммита в тестируемый проект и\или в Selenium тесты. Все результаты выполнения тестов публикуются в виде отчета. Есть 3 варианта: опубликовать результаты в форме jUnit, testNG или html сайта. Первые 2 варианта — это набор xml файлов с результатами тестов, последний — генерируемый статический сайт. Если на html наложить стили — получается вполне себе приятный для чтения вариант. Сейчас мы используем результаты в виде html и testNG. TestNG xml парсятся посредством jenkins — он хранит историю падений каждого теста, количество успешных и неуспешных(как на картинке в заголовке статьи) ну и отчеты об ошибках. Ну и если хотя бы один тест упал — отсылается уведомление о ошибке ответственному за тесты человеку и последнему коммитевшему в тестируемый продукт\набор тестов.
Да-да, проблему со слипом в selenium (правда, без явы) пришлось обарывать очень сложно. Особенно, если ожидается изменение элемента (то есть не waitforelement, а ждать, что внутри div'а текст поменяется). В этом случае даже implicity wait не срабатывает, приходится писать свой костыль, который обнаружит изменение элемента.

И даже в этом случае нужно быть очень осторожным, потому что можно нарваться на сообщение о том, что element no longer attached to DOM, потому что элемент, который мы только что find, уже не содержит ожидаемый text (элемента после замены больше нет) — рейс между find, .text и обновлением его браузером. В этих случаях всё обворачивается в except/try с пониманием «пожет поменяться».
Sign up to leave a comment.

Articles

Change theme settings