2. О себе
• Игорь Хрол
• Специализируюсь на
автоматизации тестирования с
2006 года
• Инструменты:
– Selenium, HP QTP, Watir,
TestComplete, Jmeter
• E-mail: khroliz@gmail.com
• www.autotest.by - основатель
3. О чём говорить будем?
• Зачем мигрировать?
• Как запланировать миграцию?
• Во сколько обойдётся?
• Как сделать её?
7. Зачем мигрировать?
• Поддержка мобильных устройств
– Android Browser
– iPhone Browser
• Но для Navite-приложений пока надо
искать что-то другое
8. Что было до миграции?
• 70% кода связано с Selenium Flex API
• 30% - работа с HTML
• 500k строк кода
• 7 дней выполнения тестов
Начало активной работы с HTML –
дополнительная причина
мигрировать
11. WebdriverBackedSelenium
• Почему отказались:
– Наличие большого объёма JavaScript-вставок
– Половинчатое решение, которое надо было бы
всё равно переписывать в будущем
– Проблемы с CSS-локаторами
12. Структура работ по миграции
Инициация
проекта
Прототипирование
Миграция
ядра/архитектуры
Миграция
реиспользуемых
компонент
Выполнение и
отладка тестов
15. Этапы – переписывание ядра
Selenium Flex API
Вместо user-extensions.js:
((JavascriptExecutor)webdriver).executeScript(script)
Подходит для других расширений
executeScript(java.lang.String script,
java.lang.Object... args)
Удобно работать с параметрами
16. Этапы – переписывание ядра
BaseUIElement class (Selenium 1.0)
BaseWebUIElement class (Selenium 1.0)
23. Этапы – run & debug
Цель:
• Выполнить все тесты, чтобы убедиться, что
миграция закончена
24. Как влияет на текущие задачи?
• Миграция проводилась в
отдельной ветке в системе
контроля версий
• На первых нескольких этапах
был вовлечён только один
человек (Test Automation
Architect)
• Работы велись между фазами
проекта
25. Как влияет на текущие задачи?
• Итого: на использование
автоматизации
тестирования миграция
не повлияла
26. Как планировали?
«Заточка» ядра и
Всего компонент
Всего тестов всякие
(java-классов)
неприятности
Промигрировали Время на Промигрировали Промигрировали
компонент компоненты тестов тестов
27. Сколько времени ушло?
50% команды (7-10 человек) Архитектор
2 месяца
1 месяц
Ядро и основные
компоненты
Большинство
компонент и тесты
Всего: около 10-12 человеко-месяцев
30. Ввод текста в поля
• Selenium 1.0: просто выставлялся
• Webdriver: clear() – не всегда работает
31. Выводы
• Переход на WebDriver не страшен
• В миграции помогает хорошо
сформированных до этого фреймворк
• В WebDriver еще есть проблемы, но они
быстро исправляются
Добрый день,Спасибо вам за присланную первую версию. Ревью осуществляется Николаем Алименковым и Алексеем Солнцевым. Вот наши комментарии и замечания по поводу доклада:Николай: Доклад достаточно интересный. Хотелось бы побольше узнать о самом переходе, о том как шел процесс, на кого легла нагрузка, останавливали ли тестирование пока шел переход на WebDriver, просчитывали ли сколько займет переход, не пришлось ли за это решение бороться с менеджментом. Возможно что-то еще выиграли при переходе?Алексей: С точки зрения тем, которые затрагиваются - доклад однозначно полезный и интересный. Основное замечание - выносите побольше примеров на слайды (маленькие куски кода, как было и как стало) и старайтесь не использовать на слайдах выражения которые содержать слова "некоторые" (например, про css селекторы). Когда дойдёте до части где будете описывать миграцию - то первым делом покажите общую последовательность работ, а потом расскажите про каждый шаг в отдельности. Неплохо бы всегда давать комментарии по поводу таких вещей как WebdriverBackedSelenium, не все могут знать что это такое.Вы неплохо поработали и мы ждем очередной версии на второй этап ревью 10 февраля.
ЗакатSelenium?
[SG] Кроме того, некоторые вещи на WebdriverBackedSeleniumне работали (у меня не сохранились логи, где мы это обсуждали, но по-моему среди прочего были проблемы с некоторыми CSS-локаторами), иначе говоря, переход WebdriverBackedSeleniumне спасал от необходимости серьезно рефакторить код.
1.Причины выше.2. Удобный момент.3. Прототип в первую очередь.
Говорю про важность прототипирования.Позволит оценить работу и соответственно запланировать.
[SG] Можно упомянуть, что сам формат JS для webdriverтоже слегка меняется, в частности, исчезают всякие браузерботы и добавляется return.Также можно сказать про то, что в executeScript() можно передавать данные через аргументы, вместо того, чтобы клеить длинную строку JS.В примере наверное какая-то ошибка. Правильно Object result = ((JavascriptExecutor)webdriver).executeScript(script).
[SG] В общем случае неочевидно, для чего этот класс вообще нужен и почему нельзя обойтись без него. При необходимости можно воспользоваться «WebDriver-based framework.doc», к-рый я рассылал.
[SG] В общем случае неочевидно, для чего этот класс вообще нужен и почему нельзя обойтись без него. При необходимости можно воспользоваться «WebDriver-based framework.doc», к-рый я рассылал.
[SG] Можно сказать, что SeleniumRC позволял иногда халявить и не селектать фреймы, благодаря чему в изначальной версии фреймворка их переключение и не было толком реализовано. В WebDriverэто нужно делать всегда; поэтому тесты, работавшие на RC, могут из-за этого перестать находить элементы.
[SG] Здесь несколько под-этапов (считаем, что ядро уже написано):Замена локаторов со строковых на вебдрайверовскиеBy. В некоторых случаях замена типов локаторов (например, с CSS на Xpath, т.к. а) CSS может не работать, more of this later; б) скорость Xpathбольше не такое серьезное ишью). Помогает то, что локаторы в основном лежат в одном месте (UI map).Получаем ряд ошибок в реюзабл компонентах, связанных с неправильными типами аргументов в конструкторах и getInstance(). Заменяем их на исправленные в п.1. Если компонент не включал в себя сложные манипуляции со склеиванием длинных локаторов, исполнением JS напрямую и т.п., то на этом рефакторинг компонента заканчивается.В противном случае исправляются еще и эти ошибки. Полезно, если низкоуровневые вызовы методов DefaultSelenium в основном делались в ядре, т.к. в этом случае в бизнес-компонентах и скриптах не приходится ничего править.
[SG] Здесь несколько под-этапов (считаем, что ядро уже написано):Замена локаторов со строковых на вебдрайверовскиеBy. В некоторых случаях замена типов локаторов (например, с CSS на Xpath, т.к. а) CSS может не работать, more of this later; б) скорость Xpathбольше не такое серьезное ишью). Помогает то, что локаторы в основном лежат в одном месте (UI map).Получаем ряд ошибок в реюзабл компонентах, связанных с неправильными типами аргументов в конструкторах и getInstance(). Заменяем их на исправленные в п.1. Если компонент не включал в себя сложные манипуляции со склеиванием длинных локаторов, исполнением JS напрямую и т.п., то на этом рефакторинг компонента заканчивается.В противном случае исправляются еще и эти ошибки. Полезно, если низкоуровневые вызовы методов DefaultSelenium в основном делались в ядре, т.к. в этом случае в бизнес-компонентах и скриптах не приходится ничего править.
В ходе миграции была возможность улучшить моменты, до которых раньше «не доходили руки».
Фактически – финальный этап, после которого можно было сказать, что миграция завершена.В ходе этого этапа выполнялись все тесты:Сравнивались результаты с результатами на Selenium 1.0Исправлялось, если возникало что-то «специфическое»
Почему «около»? После окончания миграции при написании новых тестов всё еще всплывали новые проблемы, решение которых можно отнести к миграции.
[SG] Ишью №2700 только частично описывает проблему. Базовая концепция WebDriverзаключается в том, чтобы точнее эмулировать действия пользователя; в частности, применительно к клику это означает нажатие мышью в определенной точке экрана, а не вызов некоторого JS-метода на некотором объекте. Однако WebDriverне всегда корректно рассчитывает координаты элемента (к примеру, для IE есть требование использовать 100% зум, но даже при его соблюдении нет гарантии, что координаты будут определены правильно, особенно если на странице есть фреймы (№2950) или сложные комбинации CSS-стилей). При этом далеко не всегда будет брошен какой-либо эксепшн, значительно чаще WebDriverмолча кликает куда-то не туда. В результате, поскольку мы так и не смогли со 100% гарантией определить, когда он сможет корректно кликнуть нативным кликом, а когда нет, пришлось заменить его на джаваскриптовый. Сначала это было сделано только для IE, потом также и для FF. Так что мы здесь отошли от устава и заимплементили уродливый хак.
ввод текста в текстовые поля. Это само по себе не ишью, а просто что-то, что нужно знать. В SeleniumRCтекст в поле обычно сетался, т.е. все, что там было, заменялось на новое значение. WebDriver изображает юзера, а потому просто тайпает в поле то, что ему сказано, не заботясь о его очистке. Существует ф-ияclear(), но если на поле повешен JS, не допускающий пустого значения, то он может мешать исполнению теста (например, если он кидает алерт). Сейчас мы перед вводом выделяем текст при помощи хоткеев (e.sendKeys(Keys.chord(Keys.CONTROL, Keys.HOME));e.sendKeys(Keys.chord(Keys.CONTROL, Keys.SHIFT, Keys.END));). К сожалению, и тут была проблема http://code.google.com/p/selenium/issues/detail?id=2908, но возможно она уже не проявляется.Если будет оставаться время (40 мин на всё про всё…), то еще расскажу про:captureNetworkTraffic[SG] Другие проблемы, помимо нативных кликов и сетевого трафика:переключение из удаляемыхфреймов в топовое окно (из описания бага 13441735: WebDriver sometimes hangs when a project is deployed/deleted via UI. It seems to be related to switching to top frame when source frame disappears during this operation. <…> It occurs more frequently in IE than FF. As it seems, when the page is reloaded/document in a frame is created, there is some interval during which WebDriver should not be allowed to switch to this frame; switch completes successfully, but no further action can be performed within this window (probably because the reference to it becomes broken). However if the switch occurs just a little bit later, everything works properly.).переключение между фреймами из разных доменов (http://code.google.com/p/selenium/issues/detail?id=2863).отсутствие waitForPageToLoad(). Впрочем, она в SeleniumRCтолком все равно не работала. Сейчас мы опрашиваем состояние document.readyState, но его, естественно, надо вызывать отдельно в каждом фрейме; кроме того, это тоже не гарантирует, что после readyState=complete не продолжают исполняться какие-либо скрипты, создающие новые элементы. Так что правильнее всего в каждом случае ждать какого-то конкретного события или элемента, а для этого в вебдрайвере есть соотв. инструменты в виде WebDriverWait и более generic FluentWait.Sizzle-локаторы не всегда работают (http://groups.google.com/group/webdriver/browse_thread/thread/a02d35e57c366e3b). Поскольку локаторы вида "css=a:contains('some text')" все равно не слишком надежны, в вебдрайвере проще от них вообще отказаться и воспользоваться XPath.Можно также сказать, что вебдрайвер поддерживает JS-алерты (если RC их прятал, то вебдрайвер в явном виде выполняет в них какие-то действия:Alert alert = driver.switchTo().alert();alert.getText();alert.accept();)