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

ibalagurov · 2017-07-14 09:53:44 UTC

Всем привет!

Кто-нибудь сталкивался, может видел какие-нибудь статьи выступления на тему построение общего фреймворка для 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 выглядит всё хорошо.

Denis_Yaremenko · 2017-07-14 17:58:47 UTC

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

Какие были проблемы, как решали

настройка аппиума на сервере
Protractor асинхронный и надо делать много приседаний чтоб тесты были стабильными

Какие инструменты использовали

Protractor + Appium

Что получилось, как оценили

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

ibalagurov · 2017-07-17 09:15:48 UTC

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

Denis_Yaremenko · 2017-07-17 17:07:05 UTC

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

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

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

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

iCok · 2017-07-17 18:30:00 UTC

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

ibalagurov · 2017-07-17 18:56:05 UTC

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

davert · 2017-07-25 09:24:29 UTC

Привет, недавно вышел 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(() => );

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

ibalagurov · 2017-07-25 09:52:14 UTC

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

lex32 · 2017-07-26 12:41:21 UTC

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

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

dkorobtsov · 2017-07-26 13:35:08 UTC

Я такую возможность закладывал на уровне пейж объектов.
Связка - 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;
    }
}

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

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

ibalagurov · 2017-07-26 13:37:54 UTC

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

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

nicholascus · 2017-07-26 13:38:02 UTC

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

ibalagurov · 2017-07-26 13:42:01 UTC

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

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

ibalagurov · 2017-07-26 13:54:11 UTC

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

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

ibalagurov · 2017-07-26 14:24:20 UTC

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

davert · 2017-08-03 11:28:55 UTC

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

vmaximv · 2017-08-03 11:49:30 UTC

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

ibalagurov · 2017-08-03 12:59:27 UTC

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

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

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

ibalagurov · 2018-06-26 20:05:55 UTC

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

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

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

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

vmaximv · 2018-06-26 20:43:52 UTC

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

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

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