Добрый день.
После перевода тестов на на IE8, скорость выполнения тестов упала минимум в 3 раза. А некоторые оперции (заполнение текстовых полей) выполняются оооооооочень медленно, прям по одной букве.
если заполнение полей можно ускорить используя вставку из буфера, то что делать с общим падением скорости выполнения тестов?
встерчал упоминания о прослойке из js файла, но с js не знаком и не имею предсталения как эту прослойку реализовать
тесты пишутся на Java c использованием Selenium 2.0, Thycidides, ранятся на IE8 под Win7x64
используется следующая приоритетность локаторов: name; css; xpath (выиграш css над xpath не видно)
битность браузера х86 над х64 разница по скорости в пределах погрешности
есть подозрение что некоторое замедление вносят @Steps oт Thycidides, но не в 3 раза
Собственно вопрос как ускорить выполнение тестов в IE?
есть ли реальный выиграш в скорости IE8 vs IE9?
если можно небольшой пример использования этой прослойки из js файла (мне кажется я встречал подобную тему на портале, но к сожаление не нашел)
Поиграйтесь с Protected Mode. Вначале включите для всех зон, замерьте время прогона, пары тестов, а затем выключите и прогоните те же тесты.
Тесты могут работать быстрее, если окно браузера зарвернуто на весь экран
Тесты могут работать быстрее, если окно браузера находится в фокусе
Тесты могут работать быстрее, если указатель мыши находится вне области веб-страницы
Тесты будут работать быстрее, если они работают с браузером локально, а не через RemoteDriver/Selenium Server
Тесты в IE работают медленнее всех остальных браузеров. С этим сделать ничего нельзя.
Движок IE9 сам по себе быстрее чем движок IE8. Следовательно, и тесты в нем выполняются быстрее. Отдельно не измерял, но на глаз ощутил на своей собственной шкуре.
проблема с очень медленным печатанием текста по буквамможет быть решена заменой IEDriverServer 64-бит на 32-битную версию (не увидел у вас в описании какая версия IEDriverServer у вас используется).
браузер на весь экран,
браузер в фокусе,
мышка за пределами веб страницы,
разная битность браузеров - выиграш по времени в пределах погрешности.
скриншоты в Thucydides на каждом шаге отключили сразу, стоит только на фейл.
Но как то этот Thucydides заметно тормозит между выполнением степов.
пока медленную печать текста победили вставкой из клипборда
разница по скорости просто сногшибательная, например ввод текста длинной 2000 символов с помощью type() занимает 126000ms, а вставка из клипборда 200ms (для FF этот показатель стал 40ms)
IE9 не одобрили.
сейчас выполнение тестов в IE8 происходит в 2-4 раза долльше чем FF.
задача чтобы в IE тесты проходили как минимум в 1.5 раза дольше чем в FF, а в иделе что бы разницы по скорости не было.
Собственно, я так понимаю, что достичь этого можно используя js. Вопрос в том как это делается, если кто сталкивался, приведите пожлуйста несколько примеров.
Встречал упоминания что наиболее дорогие операции в Selenium это getText() и isDisplayed().
Может ли кто из опытных пользователей Selenium дополнить список дорогих операций:
Так точно, это не так просто определить, видимый элемент на самом деле или нет. Для этого используется не малые вычисления.
Кстати, забыл очень важную деталь.
А вы пробовали capatibility драйвера
nativeEvents=false ?
Дело в том, что по умолчанию, она стоит в true, и вебдрайвер старается работать с веб-браузерам по средством OS Windows, а не через выполнения JavaScript.
Отключив эту опцию при инициализации вебдрайвера, вы потеряете эмуляцию работы пользователя, очень близкую к реальной, зато – приобретете очень существенное ускорение работы.
DesiredCapablitity dc = DesiredCapabilitues.internetExplorer();
dc.setCapablitities("nativeEvents", false);
InternetExplorerDriver driver = new InternetExplorerDriver(dc);
Есть еще момент - IE ищет элементы значительно дольше чем FF или Crome, на особо загруженных страницах разница может составлять 6-10… раз, в зависимости от количества элементов на странице вообще, в массиве (для findElements) или “сложности” к примеру xpath. Был случай когда на странице с таблицей в 1500 строк и 30 колонок с данными элементы (любые) искались по 4 минуты .
Можно попробовать ускорить процесс попробовав свести количество поиска элементов к минимуму кешируя их к примеру.
У меня была точно такая же проблема: Selenium2 + Thucydides + IE8 + Windows7X64.
проблема была решена именно переустановкой драйвера IEDriver с 64-битного на 32-битный.
И да, в IE8 все печатается медленнее, нежели в FF, но это уже не так критично, нежели было с IEDriverх64, когда у меня ввод шести букв пароля занимал около 30 секунд…
не пробовали только nativeEvents=false, но девелоперы уверяют что половина фукционала приложения не будет работать, да и Баранцев против - http://habrahabr.ru/post/130912/ см. комменты
еще не пробовали кешировать элементы.
х86 vs х64 IEDriver разница в пределах погрешности.
сейчас вышли на следующее вр. прохождения тестов FF=45m против IE=1h45m
Приложение написано с использованием GWT/GXT
Верно ли я понимаю что WebDriver работает быстрее чем SeleniumServer, т.к. WebDriver использует наитивные драйвера для работы с браузером, а SeleniumServer общается с браузером через js?
nativeEvents=true – это, действительно, хорошее прикрытие для автоматизатора.
Отключая его, вы действительно должны будете взять на свой код больше ответственности.
Например, в ситуации, при nativeEvents=false:
span id=”createUser”
a href=”http://blahblahblah”
Разработчик, гипотетически может динамически привязать событие onclick к элементу ссылки, у которой нет явного id.
Нам, как автоматизаторам, легче работать с элементом span, потому что у него есть id. Выходит ситуация, что мы кликаем по элементу span, а ничего не проиходит, потому что где-то в недрах кода был привязан обработчик к ссылке, а не к содержащему ее элементу. Сам клик будет не “реальным”, а симулированным посредством JavaScript.
В ситуации nativeEvents=true, произойдет то же событие клика, но в этом случае, оно придет от операционной системы по координатам в окне браузера.
Тут все очень зависит от технологий и от того как написан проект. Из своего опыта скажу, что очень редко сталкивался с проблемами отключенных native events.
Скажу, что эта опция у меня специально вынесена в конфигурационный файл для того, чтобы раз в неделю можно було прогнать тесты со включенной опцией.
Вы вышли на довольно неплохое время в IE. Если много повторных обращений к элементам на странице, и при каждом обращении элемент заново ищется - кеширование еще немного улучшит результат. Но 1:1 получить не получится, просто по тому что перфоманс IE меньше чем FF.
Поэтому я бы советовал смотреть к сторону параллелизации тестов - это самый простой и верный способ ускорить время прохождения.
Кстати, а какая версия IEDriverServer? Несколько релизов назад там было пару твиков на производительность.
Тогда синтетику можете не рассматривать - задолбетесь (с мягким знаком), там и с нативными проблем выше крыши.
ЗЫ: по поводу type() - старайтесь избегать заглавных букв и символов - время их “тайпанья” в два раза больше, так как эмулируется нажатие шифта.
у меня была проблема с IE на разных удалённых машинах я пытался заранать на IE9, IE11 и что только не пробовал какие только комбинации драйверов и селениума я не пробывал,
изначально таска была сделать one click solution чтобы можно было просто запускать через Jenkins тесты с IE
IE ругалось на разные зоны Protected Mode, это захендлил поставил одинковые,
затем ран стал очень медленный и мы очень много пробывалм солюшенов, но скорость была преждней как только мы запускали slave-agent руками иоткрывался браузер - скорость ставала обычной
вообшем помогло как раз таки выключение скришотов, я выставил только для failures, спасибо огромное Aleksey
testomat.io управление авто тестами
.