Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Общий тестовый фреймворк для Mobile и Web (Appium + Selenium)

ios
android
selenium
appium
framework
page-object
web
mobile
Теги: #<Tag:0x00007fedb6ad2c98> #<Tag:0x00007fedb6ad2b58> #<Tag:0x00007fedb6ad2a18> #<Tag:0x00007fedb6ad28b0> #<Tag:0x00007fedb6ad2720> #<Tag:0x00007fedb6ad25e0> #<Tag:0x00007fedb6ad24a0> #<Tag:0x00007fedb6ad2338>

(Igor Balagurov) #1

Всем привет!

Кто-нибудь сталкивался, может видел какие-нибудь статьи выступления на тему построение общего фреймворка для UI тестирования и Web(пока больше Desktop интересует) и Mobile(iOS + Android)?

Что хотелось бы / как выглядит пока в теории:

  • Иметь какую-то общую кодовую базу для всех платформ и избежать дублирования
  • Вынести общую логику приёмочных тестов отдельно
  • Локаторы для разных платформ отдельно
  • Экшены по возможности переиспользовать (конечно не обойдётся без особенностей для каждой платформы)
  • Page Objects скорее Page Elements соответствуют React компонентам

Почему так:

  • React\React Native, в принципе всё строится на компонентах, работа которых будет не сильно отличаться от разных платформ (iOS, Android, Web-Desktop).
  • Бизнес сценарии везде одни, собственно их будет не так много, плотное покрытие будет уровнями ниже.
  • Думается, что на 3 платформы можно будет переиспользовать хотя бы 50-60% кода, что уже будет проще поддерживать, меньше писать.

Гуглил, пока ничего не нашёл, но у меня было ощущение, что когда-то видел про подобные решения.
Что интересует:

  • Какие были проблемы, как решали
  • Какие инструменты использовали
  • Что получилось, как оценили

Может кто видел что-то на эту тему или даже опытом поделится?

P.S. Текущий стек на Python, но это не принципиально, интересуют общие решения и какие грабли встретились. А вообще копаю в сторону Selenium + Appium + Py.test + что-то из (Selene/Webium/PyPom), можно конечно и свой велосипед писать, но не хочется, пока вроде на Selene выглядит всё хорошо.


Процесс автоматизации мобильного приложения from scratch. 2017
QA weekly #24: Инструменты тестировщика, разница Smoke, Sanity, Regression, Selenium, Google, Allure, Don't repeat yourself
(Denis Yaremenko) #2

Привет. Мы работаем с Protractor + Appium, но у нас Mobile Web, В принципе точно так же можно сделать и для Native/Hybrid но наверное немного больше будет заморочек с PO и локаторами.

  • Какие были проблемы, как решали
  • настройка аппиума на сервере
  • Protractor асинхронный и надо делать много приседаний чтоб тесты были стабильными
  • Какие инструменты использовали
  • Protractor + Appium
  • Что получилось, как оценили
  • У нас были тести на Web, Но Chrome emulator не отображает действительность для IOS и Самсунг Браузеров, по этому решили запускать тесты на реальных девайсах. Просто прикрутили конфигурирования Аппиума и все взлетело из коробки.

(Igor Balagurov) #3

Спасибо за ответ, а получилось тестовые сценарии вынести в отдельный уровень?
Как решали проблемы с тем, что на разных платформах разный UX(разные гайдлайны)?
Как оценили поддержку такого решения?


(Denis Yaremenko) #4

Так как у нас mobile web, то приложения очень похожу, конечно сами элементы отличаются, но место нахождения и функционал одинаковый, так что у нас одни сценарии под все платформы.

Для всех платформ мы добавляли test-id - локаторы на каждый необходимый элемент.

-Как оценили поддержку такого решения?
Очень сильно зависит от размеров проекта.

На сколько у вас функционал отличается для IOS/ Android/ Web?


(Nikita) #5

Посмотрите в сторону JDI фреймворка.
Он как раз предоставляет такую возможность, использовать одни тесты для разных платформ
http://jdi.epam.com/


(Igor Balagurov) #6

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


(Michael Bodnarchuk) #7

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

// тест
I.click('~startUserRegistrationCD');
I.fillField('~email of the customer', 'Nothing special'));
I.see('davert@codecept.io', '~email of the customer'));

// использование разных локаторов на разных системах
I.click({
   android: '//android.widget.Button', 
   ios: '//UIAApplication[1]/UIAWindow[1]/UIAButton[1]', 
   web: '#clickMe'
});
// использование разного кода в зависимости от платформы
I.runOnAndroid(() => );
I.runOnIOS(() => );
I.runInWeb(() => );

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


(Igor Balagurov) #8

Спасибо! Выглядит круто, буду думать)
Интересует ещё опыт использования таких инструментов\подходов…


#9

Можно еще на Serenity посмотреть.
Для различных платформ указываются локаторы для элемента, а при выполнении выбирается нужный в зависимости от запущенной платформы:

...
@iOSFindBy(id = "<ios/elementName>")
@AndroidFindBy(id = "<android/elementName>")
@FindBy(className = "<web/elementName>")
private WebElementFacade elementName;
...

(Dmitri Korobtsov) #10

Я такую возможность закладывал на уровне пейж объектов.
Связка - appium + selenide
Грубо говоря, при запуске сьюта передается параметр - иос, андроид или веб…
В зависимости от параметра происходит инициализация полей в конструкторе пейдж объекта:

public Login() {
    switch (ENVIRONMENT) {
        case WEB:
            break;

        case ANDROID:
            registerButton = By.id(APP_ID + "register_btn");
            loginButton = By.id(APP_ID + "login_btn");
            facebookButton = By.id(APP_ID + "login_btn_facebook");
            googleButton = By.id(APP_ID + "login_btn_google");
            break;

        case IOS:
            break;
    }
}

Соответственно, если бизнес логика одна и та же - тесты в основной массе должны работать одинаково.

Вариант с аннотациями мне не нравится от слова совсем - если на страница несколько десятков элементов - слишком много лишнего текста выходит.


(Igor Balagurov) #11

Да, слышал-видел, там есть репортинг, Gherkin, selenium wrapper но:

  1. это только Java,
  2. Gherkin, как минимум пока не планируется
  3. хочется, чтобы это всё было отдельно и была возможность поменять какой-то компонент(репортинг\тестраннер\selenium-based framework)

(Nikolay) #12

Сложность как правило враг тестовых фреймворков. Может вам пересечения на уровне тест кейсов (например геркин спецификаций) будет достаточно?


(Igor Balagurov) #13

Да, примерно всё так и сделал, только на пайтоне это получше смотрится :slightly_smiling_face:

Собственно вопрос больше про опыт поддержки и использования такого решения, например, когда кейсов много становится, ну и 3 платформы могут с разной скоростью развиваться…


(Igor Balagurov) #14

Я не очень верю, что в реальной жизни геркин-спецификации нужны, чаще всего это просто лишний слой (при этом есть опыт написания и поддержки 1000+ UI тестов c API прекондишинами), редко кто-то эти спецификации кроме автоматизаторов читает\пишет, зелёные тесты никто не смотрит, а красные: либо хватает сообщения об ошибке\скриншота из тестового фреймворка либо автоматизаторы идут уровнем ниже…

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


(Igor Balagurov) #15

Посмотрел внимательнее и остался вопрос по тому, как планируется в CodeceptJS тесты запускать в несколько потоков?


(Michael Bodnarchuk) #16

Тесты в несколько потоков можно вот так запускать: http://codecept.io/advanced/#multiple-execution
Пока ещё для мобильных платформ увы не тестировали, но по идее должно и там заработать


(vmaximv) #17

Для mobile нужна параллель по тестам, а не по платформам.


(Igor Balagurov) #18

Из примера вижу, что codecept предлагает запустить несколько одинаковы потоков тестов с разными конфигурациями, но это не так важно (можно через CI запустить несколько job с разными параметрами), хоть и неплохо.
Даже при одной кодовой базе на все платформы что-то, надо под каждую тюнить и собирать приложения отдельно…

Важнее, чтобы была быстрая обратная связь и не писать самому распараллеливание потоков\процессов, т.е. параллелить сами тесты.

Я так понимаю именно такой возможности пока нет?


(Igor Balagurov) #19

Решил апнуть тему, мало ли кому пригодится.

В итоге про данный подход и имплементацию на python + pytest + selene рассказал на гейзенбаге

Пока в открытом доступе есть презентация.

В ответах на вопросы обещал, что будет какой-то базовый пример, в котором можно своё приложение подложить и попробовать: вот он


(vmaximv) #20

Я не критикую, но с моей точки зрения довольно сыро для продакшена.
Обычно для iOS и Android разные только локаторы

Steps
def submit_login_form():
  if config.test_run.IS_MOBILE:
    next_button.click()
  else:
    login_form.submit_button.click()

PS: Разные локаторы - это наименьшее из всех зол в кросс-мобайл+веб.