SavePearlHarbor

Как я перестал бояться и полюбил автоматизацию мобильных приложений — Robot Framework

—

от автора

admin

Часто автотестирование кажется новичкам чем-то невероятно сложным и недостижимым. Многие думают, что для того, чтобы начать писать автотесты, необходимо сначала получить глубокие знания в программировании, разобраться во всех технических тонкостях ручного тестирования и только лишь потом пробовать писать автоматизированные тесты.

Это, конечно, не так. Я предлагаю вам познакомиться с Robot Framework — инструментом, который позволит писать автотесты, даже если у вас не было никакого опыта программирования.

Эта статья — адаптация моего видеотуториала. Если в формате видео вам проще воспринимать информацию — велком!

Начнем с демонстрации

Давайте сразу посмотрим пример автотеста, написанного с использованием Robot Framework:

*** Settings *** Test Setup        auth_reg.Precondition: User At Auth Form Test Teardown     android.Quit App Test Timeout      2m   *** Variables *** ${INCORRECT_LOGIN}      test@test.ru ${INCORRECT_PASSWORD}   123   *** Test Cases *** Standard Authorization     [Documentation]    Процесс авторизации через логин и пароль     [Tags]    android    authorization      Fill Both Fields Incorrectly     Page Should Not Contain Element    ${PROFILE_USERNAME}      Fill One Field Incorrectly     Page Should Not Contain Element    ${PROFILE_USERNAME}      Input Correct Data     Wait Until Element Is Visible      ${PROFILE_USERNAME}  *** Keywords *** Fill One Field Incorrectly     [Documentation]    Заполняем одно из полей (email или пароль) некорректно      Input Text                       ${LOGIN_FIELD}       ${INCORRECT_LOGIN}     Input Password                   ${PASSWORD_FIELD}    ${PASSWORD}     Click Element                    ${LOGIN_ENTER_BTN}

Сразу заметно отсутствие того, чем пугает нас программирование, — классов, методов и сложных синтаксических конструкций. Вместо этого — простые и понятные английские слова, знакомые любому тестировщику, который знает хотя бы основы теории тестирования.

То, что отмечено звёздочками с обеих сторон, — это блоки теста.

Блок Settings

Это настройки теста. Они могут быть разные, но тут используются три:

  • Test Setup — это «Инженер по тестированию» в Яндекс Практикуме и основатель Брейни QA.

    Уговорил, давай попробуем!

    Чтобы начать, нам необходимо сделать две вещи:

    1. Установить инструменты, необходимые для работы Robot Framework и мобильной автоматизации.

    2. Выбрать и установить среду разработки (IDE)

    Об установке инструментов

    Скачать и установить нужно будет следующее:

    • Java JDK — для корректной работы инструмента автоматизации и среды разработки приложений на Android 

    • Android Studio — для установки вспомогательных пакетов Android и работы с эмуляторами

    • NodeJS — для установки инструмента автоматизации через его встроенный менеджер пакетов 

    • Homebrew — для более простой установки NodeJS на Mac

    • Appium — для непосредственной автоматизации тестирования

    Чтобы не терять время и не растягивать статью инструкцией по установке (которая, впрочем, сильно разнится в зависимости от операционной системы), я просто приложу туториалы из публичного доступа:

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

    Об установке IDE

    Среду разработки обычно рекомендую выбирать исключительно по предпочтениям, но советовал бы остановить выбор на одной из этих двух:

    У каждой из них есть плагины (расширения), поддерживающие функционал нашего с вами инструмента. На момент написания статьи рекомендую RobotCode для VSCode и Language Server для PyCharm.

    Если вы ранее не работали с этими средами разработки, выбирайте ту, которая больше нравится. Я, например, использую VSCode, потому что эта IDE — как швейцарский нож в мире разработки.

    Создание проекта

    На данном этапе для нас главное — создать проект с виртуальным окружением Python. В PyCharm при первом открытии нам предложат создать проект, и если мы согласимся, то виртуальное окружение нам создадут автоматически. Ничего в настройках менять не нужно, можно оставить как есть..

    Как выглядит экран создания проекта в PyCharm

    Как выглядит экран создания проекта в PyCharm

    Далее нам нужно уже в проекте создать файлик requirements.txt, где будут указаны зависимости для скачивания. Их можно просто записать так:

    robotframework robotframework-appiumlibrary

    Первое — сам Robot Framework, второе — библиотека Appium, которая как раз таки и позволяет проводить мобильные тесты. На её основе, кстати, сейчас работает большинство ненативных проектов автоматизации мобильного тестирования.

    PyCharm предложит эти зависимости установить, если не предлагает — открываем встроенный терминал и пишем pip3 install. С этого момента можно уже начинать писать тесты.

    В случае с Visual Studio Code процесс немного отличается. При старте нового проекта я обычно делаю так:

    1. Создаю папку в файловой системе

    2. Открываю эту папку через VS Code

    3. Создаю файлик requirements.txt и вписываю то, что написано выше.

    4. Нажимаю Ctrl (Cmd) + Shift + P и в выпадающем меню набираю “Python: Create Environment”. Сначала выбираем виртуальное окружение (venv), затем файлик, из которого возьмутся зависимости (мы его создали в шаге 3).

    Если всё сделано правильно, то зависимости установятся вместе с виртуальным окружением, что также открывает нам дорогу к написанию нашего первого теста.

    Пишем первый автотест

    Прежде чем начать писать тест в Robot Framework, нужно создать файл для него. Мы можем назвать его как угодно — я назову, например, first_test. Главное — прописать правильное расширение файла — это .robot

    Итак, как я уже писал ранее, самое важное происходит в специальных блоках. Создадим блок Settings, выделив его тремя звездочками (***) с каждой из сторон. В нём мы подключаем библиотеки и ресурсы, а также устанавливаем предусловия и постусловия.

    На первом этапе нам нужно подключить библиотеку, для этого пишем Library, ставим таб (отступы в Robot Framework, как и в Python, используются не только для декорации, но и для правильного выполнения теста) и пишем название — AppiumLibrary.

    *** Settings *** Library    AppiumLibrary

    Следующий блок называется Test Cases, и он отвечает за тест-кейсы.

    Чтобы создать тест-кейс, под объявлением блока мы пишем его название — First Test.

    В этом автотесте мы выполним три простых действия:

    1. Открыть приложение

    2. Подождать 5 секунд

    3. Закрыть приложение

    За действия в Robot Framework отвечают кейворды, или, говоря языком традиционного программирования, функции. Какую-то часть функций предоставляет сам Robot Framework, какую-то — его библиотеки, а какую-то придётся писать нам самим.

    К счастью для нас, документация по кейвордам у «робота» есть, и она достаточно понятна и хорошо написана. Для начала нам хватит вот этих ссылок:

    Нам нужно открыть приложение. Что нужно делать, когда не знаем, какой кейворд нам нужен? Правильно, идём в документацию!

    Если перейдём по второй и в поиске наберём магическое «Open«, то найдём кейворд Open Application:

    Документация к кейворду Open Application

    Документация к кейворду Open Application

    Здесь мы видим аргументы, которые кейворд принимает (remote url, alias, strict_ssl), — это то, что мы пишем, разделяя табами. Ниже — пример использования, где видим remote_url во втором столбике, а в третьем — alias. Всё, что пишется дальше, это так называемые capabilities — параметры сети, устройства и приложения, которое хотим запустить. Их сюда можно написать много разных, но я расскажу о самых основных, которых хватит для почти любого проекта:

    • remote_url — это адрес сервера. Сервер мы будем включать на нашем компьютере, поэтому нам нужно ввести локальный адрес и порт — для всех компьютеров он будет такой — http://127.0.0.1:4723

    • automationName — это драйвер для прогона тестов — тот, который будет нажимать кнопки, делать свайпы, скроллы и прочие подобные штуки. Самый популярный для Android — это UiAutomator2

    • platformName — это название операционной системы устройства — Android

    • platformVersion — версия операционной системы. Чтобы её узнать, на телефоне переходим в Настройки — О телефоне.

    • deviceName — название устройства. Оно тоже пишется и настраивается там же, где и версия ОС.

    • udid — это id устройства. Чтобы его узнать, нужно перейти в терминал вашего компьютера и ввести команду adb devices. Если команда не распознана, вам нужно установить и настроить adb (но если вы шли по шагам из уроков установки, то у вас оно уже будет). Если у вас есть подключённые по USB устройства (или активные эмуляторы), то вы увидите id там.

    • appPackage — это ID приложения. Я использую Афишу — агрегатор событий с возможностью купить билеты. Чтобы узнать его ID, нам нужно перейти в Настройки — Приложения, затем найти приложение и нажать на иконку информации. Имя пакета — это то, что нам нужно.

    • appActivity — это активность, которую нужно запустить. Суть в том, что в Android мы не просто запускаем приложение — мы запускаем конкретную активность с конкретным айди. На реальном проекте название активности можно уточнить у разработчиков либо найти самому с помощью приложений вроде apk info или с помощью специальных консольных команд.

    Теперь это нужно записать в код. У меня получилось вот так:

    *** Test Cases *** First Test     Open Application    remote_url=http://127.0.0.1:4723         ...                 automationName=UiAutomator2         ...                 platformName=Android         ...                 platformVersion=13         ...                 deviceName=POCO         ...                 udid=6c01a765         ...                 appPackage=ru.afisha.android         ...                 appActivity=ru.afishaog.android.presentation.app.AppActivity

    Обратите внимание на то, как мы задаём значения свойств. Сначала вводим название, затем знак «равно» — и значение. Чтобы это всё лучше читалось, можно переносить строки. Для этого нужно проследить, чтобы перед строкой были … (три точки) — это означает «мы продолжаем предыдущую строку и переносим текст для лучшей читаемости».

    Уже на этом этапе мы можем запустить тест, но перед этим мы должны запустить сервер Аппиума. Это просто: переходите в терминал на вашем устройстве и пишете команду appium. Если у вас показывает нечто подобное, то всё сделано правильно:

    Так выглядит запущенный сервер в терминале

    Так выглядит запущенный сервер в терминале

    Далее, у вас установлен один из рекомендуемых плагинов, то можно просто нажать на зеленую стрелочку возле теста:

    Запуск тестов в Visual Studio Code с расширением RobotCode

    Запуск тестов в Visual Studio Code с расширением RobotCode

    После этого на вашем девайсе вы увидите, как откроется приложение, а в терминале в IDE напишут, что тест прошёл успешно:

    Так выглядит запуск в терминале Visual Studio Code

    Так выглядит запуск в терминале Visual Studio Code

    На ранних этапах могут возникать разные ошибки (adb не работает, appium не открылся, телефон не настроен, приложение не запустилось), но, к счастью, когда один раз настроишь процесс, дальше такие проблемы уже не беспокоят. Если вы чётко следовали инструкциям, но у вас появилась ошибка, которую не можете решить, — приходите в комментарии, посмотрим, что с этим можно сделать 🙂

    Кстати, в Robot Framework уже встроены отчёты, которые создаются после каждого прогона:

    Встроенный отчёт от Robot Framework

    Встроенный отчёт от Robot Framework

    А если есть необходимость погрузиться в процесс прогона с максимальной детализацией всего, что произошло, помогут логи:

    Встроенные логи от Robot Framework

    Встроенные логи от Robot Framework

    Но вернемся к нашему тесту, который выглядит так:

    1. Открыть приложение

    2. Подождать 5 секунд

    3. Закрыть приложение

    Чтобы подождать какое-то время, мы можем использовать кейворд Sleep. В него нужно передать время ожидания — у нас это пять секунд.

    После того как мы подождали нужное время, нам нужно закрыть приложение. Подходящий кейворд можно найти — это Close Application.

    Наш тест теперь выглядит так:

    *** Test Cases *** First Test     Open Application    remote_url=http://127.0.0.1:4723         ...                 automationName=UiAutomator2         ...                 platformName=Android         ...                 platformVersion=13         ...                 deviceName=POCO         ...                 udid=6c01a765         ...                 appPackage=ru.afisha.android         ...                 appActivity=ru.afishaog.android.presentation.app.AppActivity      Sleep    5s      Close Application

    Чтобы сделать код красивее и проще, мы можем сделать две вещи:

    1. Внедрить переменные

    2. Перенести Open Application в отдельный кейворд

    Работа с переменными

    Программирование очень не любит «magic numbers/strings/etc». Это значит, что по возможности каждое число или строчка, которые мы передаём в код, должны выноситься в отдельные переменные.

    Здесь нам стоит вынести все свойства в отдельные переменные. В этом нам поможет блок Variables:

    *** Variables *** # Название устройства ${DEVICE_NAME}  POCO # Идентификатор устройства ${DEVICE_UDID}  6c01a765 # Используемая платформа ${PLATFORM_NAME}  Android # Версия платформы ${PLATFORM_VERSION}  13 # Компания устройства ${COMPANY}    "XIAOMI" # Automation Name ${AUTOMATION_NAME}    UiAutomator2 # Connection ${MAIN_CONNECTION}    http://127.0.0.1:4723 # Ссылка на приложение ${APP_PACKAGE}     ru.afisha.android # Ссылка на активность приложения ${APP_ACTIVITY}    ru.afishaog.android.presentation.app.AppActivity   *** Test Cases *** First Test     Open Application  remote_url=${MAIN_CONNECTION}     ...               automationName=${automation_name}     ...               platformName=${platform_name}     ...               platformVersion=${platform_version}     ...               deviceName=${device_name}     ...               udid=${device_udid}     ...               appPackage=${APP_PACKAGE}     ...               appActivity=${APP_ACTIVITY}      Sleep    5s          Close Application

    Тут мы видим, как пишутся переменные — ${VARIABLE}. Значения передаются через таб. То, что начинается с #, — это комментарии, которые нужны для удобства разработчика и понимания того, что это за переменные. Комментарии при выполнении кода игнорируются, они нужны только для вас.

    Создание кейвордов

    В целях демонстрации мы можем вынести Open Application со всеми его свойствами в отдельный кейворд в блоке Keywords и назвать его, например, Open App. Всё, что нужно сделать:

    1. Создать блок Keywords

    2. Создать (инициализировать) новый кейворд

    3. Перенести нужные функции в только что созданный кейворд

    4. Заменить функции в тесте на название кейворда

    Должно получиться вот так:

    *** Test Cases *** First Test     Open App      Sleep    5s      Close Application   *** Keywords *** Open App     Open Application  remote_url=${MAIN_CONNECTION}     ...               automationName=${automation_name}     ...               platformName=${platform_name}     ...               platformVersion=${platform_version}     ...               deviceName=${device_name}     ...               udid=${device_udid}     ...               appPackage=${APP_PACKAGE}     ...               appActivity=${APP_ACTIVITY}

    Такой подход не только помогает нам добиться удобства читаемости кода, но и помогает с его поддержкой. Если мы, например, хотим при старте приложения делать какое-нибудь ещё действие, то можем это действие поместить в Open App, и его не придётся каждый раз прописывать заново. Один раз вызвал кейворд и пользуешься.

    А теперь — настоящий автотест!

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

    У нашего приложения есть онбординг — стартовые экраны, которые помогают пользователю сориентироваться в приложении, параллельно запрашивая важные для работы доступы.

    Один из экранов выглядит вот так:

    И, соответственно, у нас есть тесты, онбординг проверяющие. Предположим, есть такой:

    Заголовок: Онбординг с разрешением геолокации и подтверждением предлагаемого города

    Предусловие: приложение открыто

    Шаги:

    1. Разрешить геолокацию

    2. Подтвердить предлагаемый город

    3. Разрешить уведомления

    Такой тест в Robot Framework может выглядеть так:

    *** Settings *** Resource    onboarding.resource   *** Test Cases *** Allow Location And Confirm Town     [Documentation]    Онбординг с разрешением геолокации и подтверждением выбранного города          launcher.Open App     onboarding.Allow Location     onboarding.Confirm Town     onboarding.Allow Notifications     Wait Until Element Is Visible    ru.afishaog.android:id/itemTileEventIv

    Здесь мы видим, что тест очень короткий, потому что всё необходимое мы вынесли в отдельные ресурсные файлы. В Robot Framework такие файлы обладают расширением .resource, и именно такой файл мы подключаем в блоке Settings.

    А теперь давайте заглянем в этот файл:

    *** Settings *** Resource    ../common.resource   *** Keywords *** Allow Location     [Documentation]     Разрешить приложению использовать геолокацию          Wait Until Element Is Visible    ru.afishaog.android:id/fragOnboardinSubmitBtn     Click Element                    ru.afishaog.android:id/fragOnboardinSubmitBtn      Wait Until Element Is Visible    com.android.permissioncontroller:id/permission_allow_foreground_only_button     Click Element                    com.android.permissioncontroller:id/permission_allow_foreground_only_button  Confirm Town     [Documentation]     Подтвердить предлагаемый системой город      Wait Until Element Is Visible    id=android:id/button1        timeout=10     Click Element                    id=android:id/button1  Allow Notifications     [Documentation]    Разрешить уведомления      Wait Until Page Contains Element    ru.afishaog.android:id/fragOnboardinSubmitBtn     Click Element                       ru.afishaog.android:id/fragOnboardinSubmitBtn     Wait Until Page Contains Element    com.android.permissioncontroller:id/permission_allow_button     Click Element                       com.android.permissioncontroller:id/permission_allow_button

    Здесь видим, что в этом файле мы подключаем ещё один ресурс — common, который может подключать другие дополнительные ресурсы. Именно там мы подключили другой ресурсный файл (launcher.resource), отвечающий за открытие приложения.

    Как вы видите, в ресурсном файле нет тест-кейсов — только кейворды, причем с такими же названиями, как и в тесте выше. Да, мы прописываем их логику здесь, а вызываем там. Это помогает избежать повторения одного и того же кода между тестами, а также упрощает процесс поддержки (если что-то сломалось — можно поправить только в одном месте).

    Каждый кейворд задокументирован, и легко понять, что именно происходит: в одном мы разрешаем геолокацию, в другом — подтверждаем город, в третьем — разрешаем уведомления.

    Здесь используются два новых кейворда, которые предоставляются библиотекой AppiumLibrary:

    • Wait Until Element Is Visible — дождаться, пока нужный элемент станет видимым

    • Click Element — кликнуть на элемент

    Этот тест на самом деле очень простой — он просто ждёт элементы и кликает по ним.

    Вы спросите: а как нам найти элементы, которые ждёт и прокликивает робот? А для этого мы используем программу Appium Inspector. Её интерфейс выглядит так:

    Инструмент довольно простой. Он подключается к нашему девайсу и делает интерактивный скриншот. Мы можем нажимать на разные части этого скриншота и находить идентификаторы элементов — это именно то, что мы вписываем справа от Wait Until Element Is Visible и Click Element. Подробнее про Appium Inspector можно найти, например, в этом видео.

    По сути, когда мы пишем автотест в Robot Framework, наша работа чрезвычайно проста:

    1. Взять ручной тест

    2. С помощью Appium Inspector найти все элементы, с которыми нужно взаимодействовать

    3. Выбрать подходящие кейворды (чему помогает документация или личный опыт)

    4. Вписать кейворды в тест с использованием локаторов из шага 2

    Вот такой простой алгоритм на самом деле.

    Дорабатываем тест

    В первую очередь непонятные локаторы нужно поместить в понятные переменные, чтобы кейворды в ресурсном файле выглядели так:

    *** Keywords *** Allow Location     [Documentation]     Разрешить приложению использовать геолокацию      Wait Until Element Is Visible    ${ONBOARDING_SUBMIT_BTN}      Click Element                    ${ONBOARDING_SUBMIT_BTN}       Wait Until Element Is Visible    ${PERMISSION_FOREGROUND}     Click Element                    ${PERMISSION_FOREGROUND}  Confirm Town     [Documentation]     Подтвердить предлагаемый системой город      Wait Until Element Is Visible    ${ONBOARDING_CONFIRM_CITY_BTN}        timeout=10     Click Element                    ${ONBOARDING_CONFIRM_CITY_BTN}  Allow Notifications     [Documentation]    Разрешить уведомления      Wait Until Page Contains Element    ${ONBOARDING_SUBMIT_BTN}      Click Element                       ${ONBOARDING_SUBMIT_BTN}      Wait Until Page Contains Element    ${PERMISSION_ALLOW}     Click Element                       ${PERMISSION_ALLOW}

    Сами переменные с локаторами выносим в отдельный ресурсный файл:

    *** Settings *** Documentation    Блок для локаторов онбординга  *** Variables *** ${ONBOARDING_SUBMIT_BTN}            ru.afishaog.android:id/fragOnboardinSubmitBtn ${ONBOARDING_CONFIRM_CITY_BTN}      id=android:id/button1 ${PERMISSION_FOREGROUND}            com.android.permissioncontroller:id/permission_allow_foreground_only_button ${PERMISSION_ALLOW}                 com.android.permissioncontroller:id/permission_allow_button

    Запуск приложения и его закрытие лучше вынести в отдельные кейворды и пометить их как Test Setup (предусловие) и Test Teardown (постусловие) соответственно:

    *** Settings *** Resource    onboarding.resource Test Setup        common.Launch App Test Teardown     common.Close App   *** Test Cases *** Allow Location And Confirm Town     [Documentation]    Онбординг с разрешением геолокации и подтверждением выбранного города          onboarding.Allow Location     onboarding.Confirm Town     onboarding.Allow Notifications     Wait Until Element Is Visible    ${VERTICAL_EVENT_TILE}

    А еще можно разветвить код с использованием условных операторов. Дело в том, что экран с разрешением уведомлений показывается только в случае, если у пользователя Android версии 13 и выше. В таком случае, тест будет выглядеть так:

    *** Test Cases *** Allow Location And Confirm Town     [Documentation]    Онбординг с разрешением геолокации и подтверждением выбранного города          onboarding.Allow Location     onboarding.Confirm Town     IF    ${PLATFORM_VERSION} >= 13    onboarding.Allow Notifications     Wait Until Element Is Visible    ${VERTICAL_EVENT_TILE}

    С помощью конструкции IF ${PLATFORM_VERSION} >= 13 onboarding.Allow Notifications мы говорим программе действовать так — «Если версия операционной системы выше 13-й, добавь новый шаг с разрешением уведомлений».

    В итоге у нас получился готовый автотест, который уже прямо сейчас может сократить время регрессионного тестирования. Чем больше таких тестов автоматизировано — тем проще жизнь тестировщика.

    Что еще умеет Robot Framework с AppiumLibrary?

    Практически всё! Если говорить о мобильном тестировании, то он позволяет работать:

    • с переменными

    • с предусловиями и постусловиями

    • с условными операторами (IF, ELSE, ELSE IF), где нужно разветвление кода в зависимости от условий

    • с циклами (WHILE, FOR), где определённые части кода нужно повторять несколько раз

    • с вводом текста (заполнение полей)

    • с жестовой навигацией (скроллы, свайпы, зумы — всё поддерживается)

    • с манипуляциями приложением (закрыть, отправить в фон, перезапустить, переключить на другое)

    • со многими другими сценариями

    Фактически этим инструментом можно покрыть практически любые ручные сценарии тестирования. Напомню, что этот инструмент активно используется в большом количестве компаний (в том числе и на российском рынке, например, в нашем Рамблере).

    Стоит отметить, что Robot Framework действительно не является стандартом индустрии автоматизации тестирования, и на мой взгляд — очень зря.

    Как вам инструмент?

    Если он понравился — я очень рад!

    Вы уже прямо сейчас можете использовать Robot Framework в своей работе — автоматизировать тесты, которые вам не нравится проходить вручную. Если сейчас такой необходимости нет — в качестве практики перед полноценным погружением в мир автотестов.

    Надеюсь, вместе мы сможем популяризировать «робота» и помочь IT‑компаниям понять, что автоматизация — это не только не дорого, не сложно и не страшно, но иногда даже и приятно!


ссылка на оригинал статьи https://habr.com/ru/articles/794064/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *