Автоматизация тестирования
Автоматизация тестирования помогает решить сразу несколько проблем — в том числе если речь идёт о мобильных приложениях. Вместо того чтобы вручную проводить рутинные трудоёмкие процедуры, специалисты могут делегировать значительную их часть фреймворкам.
Автоматизация упрощает проверку и помогает ускорить регрессионное тестирование, а также даёт возможность использовать ранее недоступные типы тестирования.
Автоматизация упрощает проверку и помогает ускорить регрессионное тестирование, а также даёт возможность использовать ранее недоступные типы тестирования.
Чек-лист тестирования мобильных приложений
- Геолокация.
- Работа приложения в разных режимах: portrait/landscape, split screen.
- Поля ввода.
- Пуш уведомления.
- Прерывания — входящие звонки, СМС, доступ к интернету, предупреждение о низком заряде батареи, внезапное отключение устройства и другие.
- Поддержка платежных систем (если присутствуют платежные транзакции).
- Соответствие гайдлайнам операционных систем.
- Влияние на производительность устройства.
Также необходимо проанализировать сетевой трафик: обрыв сети и слабый интернет, исходящие запросы и полученные ответы. Для этого используют снифферы Charles/Fiddler, Proxyman и другие.
При необходимости выполняют тестирование API. Для этой задачи используют специализированные инструменты: Swagger, Postman, SOAPUI. Они помогают документировать запросы и выполнять их интерактивную проверку.
Для тестирования на различных устройствах используют эмуляторы вроде Genymotion, BlueStacks. Однако успешные тесты на эмуляторе не гарантируют, что приложение будет работать без сбоев на реальных устройствах. Чтобы подключиться к реальным мобильным устройствам и интегрировать туда автотесты, используют фермы BrowserStack, Xamarin или AWS. Либо можно поднять собственную ферму на базе OpenSTF — это позволит всем сотрудникам иметь равный доступ к тестовым устройствам, что особо важно в условиях распределенных команд и удаленной работы.
Для автоматизации UI тестирования мобильных приложений используют Appium, Detox, Ranorex — инструменты автоматизации для запуска сценариев и тестирования приложений на Android или iOS с помощью веб-драйвера.
Когда ваш проект имеет большое количество автотестов, будет полезно автоматизировать их запуск при каждой сборке нового билда. Чтобы настроить этот процесс, используйте системы CI/CD — Jenkins/TeamCity.
набор инструментов МОбильного тестировщика
Набор инструментов мобильного тестировщика:
- Тестирование UI/UX: Figma, Zeplin, любой mindmap-like продукт.
- Анализ сетевого трафика: Charles/Fiddler, Proxyman.
- Тестирование API: Swagger/Postman/SOAPUI.
- Автоматизация UI тестирования мобильных приложений: Appium, Detox, Ranorex.
- Фермы устройств для тестирования мобильных приложений: BrowserStack, Xamarin, AWS.
- Системы CI/CD: Jenkins/TeamCity.
Классификация инструментов
Первое, от чего следует отталкиваться — это непосредственно платформа, на которой работает приложение. Исходя из этого, классифицируем перечень инструментов следующим образом:
Android
iOS
Универсальные
Android
- Espresso
- UI Automator
iOS
- XCUITest
- EarlGrey
Универсальные
- Detox
- Appium
- Ranorex
- TestComplete Mobile
Автоматизация тестирования приложений на Android
Espresso
Более лёгкий по сравнению с UI Automator инструмент, не подходящий для взаимодействия с внешними приложениями, но удобный для тестирования “белого ящика” (white-box) с доступом к исходному коду конкретного приложения или тестирования “серого ящика” (grey-box), при котором имеется доступ к некоторым внутренним процессам и структуре.
Вместе с тем, Espresso выделяется мощным API https://github.com/hamcrest. Интерфейс добавляет удобные методы для проверок в автотестах, например:
assert_that(1, less_or_equal(2)). Для тестирования webview при этом используются специальные методы.
UI Automator и Espresso взаимно дополняют друг друга и могут использоваться в комплексе в рамках одного проекта.
Ссылка на документацию
Вместе с тем, Espresso выделяется мощным API https://github.com/hamcrest. Интерфейс добавляет удобные методы для проверок в автотестах, например:
assert_that(1, less_or_equal(2)). Для тестирования webview при этом используются специальные методы.
UI Automator и Espresso взаимно дополняют друг друга и могут использоваться в комплексе в рамках одного проекта.
Ссылка на документацию
UI Automator
Мощный инструмент тестирования с продвинутой внешней интеграцией. Это значит, что данный фреймворк не только позволяет тестировать само приложение, но также способен “общаться” с операционной системой и другими приложениями — например, активировать и деактивировать Wi-Fi, GPS, открывать меню настроек в ходе теста и производить другие внешние взаимодействия.
Предназначение UI Automator — тестирование “чёрного ящика” (black-box testing). Это значит, что анализ производится с позиций внешнего пользователя без доступа к коду.
К основным особенностям относятся:
Ссылка на документацию
Предназначение UI Automator — тестирование “чёрного ящика” (black-box testing). Это значит, что анализ производится с позиций внешнего пользователя без доступа к коду.
К основным особенностям относятся:
- UI Automator Viewer для отслеживания и анализа компонентов, отображаемых на экране в ходе теста. Он даёт информацию об элементах и их свойствах, что облегчает создание более релевантных тестов.
- API для получения информации о состоянии девайса и запуска процессов на нём.
- UI Automator APIs для проведения кроссплатформенных тестов.
Ссылка на документацию
Автоматизация тестирования iOS-приложений
XCUITest
Инструмент для black-box тестирования без обращения к коду приложения. Работает только с нативными продуктами — к сожалению, провести cross-app тесты не получится.
С другой стороны, нативный характер фреймворка является преимуществом с той точки зрения, что при использовании XCUITest степень взаимопонимания разработчиков и тестировщиков находится на гораздо более высоком уровне, чем в случаях, когда одни и вторые используют разные языки.
Полезным дополнением является test recorder, который даёт возможность писать тесты путём записи действий в приложении даже тем, кто не работает с кодом.
Инструмент позволяет избежать типичных ошибок и лишних, недоступных пользователю манипуляций с кодом. Однако, при этом XCUITest имеет и некоторые недостатки.
XCUITest, в отличие от Espresso, работает в отдельном потоке, во время тестирования нужно дождаться появления определенных элементов и параметров. Актуальное состояние приложения не считывается, и задержки в обновлении данных могут привести к невозможности обнаружения запрашиваемых элементов.
Ссылка на документацию
С другой стороны, нативный характер фреймворка является преимуществом с той точки зрения, что при использовании XCUITest степень взаимопонимания разработчиков и тестировщиков находится на гораздо более высоком уровне, чем в случаях, когда одни и вторые используют разные языки.
Полезным дополнением является test recorder, который даёт возможность писать тесты путём записи действий в приложении даже тем, кто не работает с кодом.
Инструмент позволяет избежать типичных ошибок и лишних, недоступных пользователю манипуляций с кодом. Однако, при этом XCUITest имеет и некоторые недостатки.
XCUITest, в отличие от Espresso, работает в отдельном потоке, во время тестирования нужно дождаться появления определенных элементов и параметров. Актуальное состояние приложения не считывается, и задержки в обновлении данных могут привести к невозможности обнаружения запрашиваемых элементов.
Ссылка на документацию
EarlGrey
У EarlGrey акцент сделан на воспроизведении пользовательского опыта. Пока элементы на экране не представлены визуально, имитация работы с приложением не запускается.
При этом отмечается ряд удобств и преимуществ. Во-первых, специалистам нравится то, как фреймворк синхронизирует запросы, UI и потоки. Не нужно никаких waitforview и wait.
Во-вторых, как уже было сказано, особое внимание уделено отслеживанию видимости элементов. Инструмент обладает дополнительным слоем проверки подгрузки интерфейса и воспроизводит пользовательские жесты — свайпы, нажатия — непосредственно на уровне событий приложения.
Ссылки на репозитории: github.com/google/EarlGrey и google.github.io/EarlGrey.
При этом отмечается ряд удобств и преимуществ. Во-первых, специалистам нравится то, как фреймворк синхронизирует запросы, UI и потоки. Не нужно никаких waitforview и wait.
Во-вторых, как уже было сказано, особое внимание уделено отслеживанию видимости элементов. Инструмент обладает дополнительным слоем проверки подгрузки интерфейса и воспроизводит пользовательские жесты — свайпы, нажатия — непосредственно на уровне событий приложения.
Ссылки на репозитории: github.com/google/EarlGrey и google.github.io/EarlGrey.
Универсальные инструменты
Универсальные инструменты (или “комбайны”) позволяют не ограничивать свой выбор только Android или iOS, а работать с обеими платформами.
Такие инструменты применимы для тестирования приложений следующих видов:
Такие инструменты применимы для тестирования приложений следующих видов:
- Нативные приложения (native apps) — написанные непосредственно под Android, iOS и Windows SDK.
- Мобильные веб-приложения (mobile web apps) — доступные через мобильный браузер, например, Safari или Chrome.
- Гибридные приложения (hybrid apps) — пользователь работает с оболочкой веб-приложения, то есть, взаимодействует с веб-контентом через интерфейс нативного приложения.
Detox
На наш взгляд, Detox удобен для приложений, написанных на React Native. Тесты пишутся на JavaScript, при этом iOS и Android приложения генерируются из одного и того же кода JavaScript и максимально похожи. Это позволяет использовать одинаковые тесты для обеих платформ.
Ключевая особенность Detox — тестирование по принципу “серого ящика”. В данном случае фреймворк имеет некоторый доступ к внутренним механизмам, что позволяет соотносить внешнее поведение приложения с тем, что происходит на более глубоком уровне.
Detox может обращаться к памяти и отслеживать выполняемые процессы. Принцип grey-box помогает бороться с неустойчивостью, выражающейся в том, что при сквозном тестировании:
Как ни странно, “серый ящик” показывает не только лучшую устойчивость, но и более высокую скорость по сравнению с “чёрным ящиком”. Избегая разного рода пауз, waitUntil, grey-box может быть в 5-10 раз быстрее.
Detox не нуждается в WebDriver, работая с нативным драйвером через JSON. Он задействует нативные методы прямо на устройстве. Внутри данного фреймворка применяются EarlGrey для iOS и Espresso для Android.
Ссылка на документацию
Ключевая особенность Detox — тестирование по принципу “серого ящика”. В данном случае фреймворк имеет некоторый доступ к внутренним механизмам, что позволяет соотносить внешнее поведение приложения с тем, что происходит на более глубоком уровне.
Detox может обращаться к памяти и отслеживать выполняемые процессы. Принцип grey-box помогает бороться с неустойчивостью, выражающейся в том, что при сквозном тестировании:
- Тест может произвольно вылетать даже без изменений в коде;
- Результаты не детерминированы — ввиду большого количества разнородных функциональностей и процессов внутри приложения результаты каждого запуска могут непредсказуемо отличаться друг от друга.
- Тестировщики вынуждены проводить синхронизацию вручную, что влечёт снижение достоверности и качества результатов.
Как ни странно, “серый ящик” показывает не только лучшую устойчивость, но и более высокую скорость по сравнению с “чёрным ящиком”. Избегая разного рода пауз, waitUntil, grey-box может быть в 5-10 раз быстрее.
Detox не нуждается в WebDriver, работая с нативным драйвером через JSON. Он задействует нативные методы прямо на устройстве. Внутри данного фреймворка применяются EarlGrey для iOS и Espresso для Android.
- Фреймворк работает как с эмуляторами, так и с физическими устройствами.
Ссылка на документацию
Appium
Преимущество Appium состоит в том, что писать тесты под каждую из платформ можно с помощью единого API, не прибегая к преобразованию приложения в какой-либо особый, совместимый с фреймворком вид.
При тестировании используются фреймворки от вендоров — то есть вы работаете именно с исходным приложением. Для Android 4.2+, соответственно, применяется UiAutomator/UiAutomator2, а для iOS 9.3+ — XCUITest. В качестве оболочки фреймворков используется WebDriver (он же — Selenium WebDriver).
Принципы Appium:
Использование Appium оправдано, когда нужен инструмент для автоматизации тестирования сразу на нескольких платформах. Он полезен, если у вас есть специалисты с опытом тестирования веб-приложений, но нет опыта автоматизации тестирования мобильных приложений.
В целом, это гибкий инструмент, который можно доработать под нужды проекта без необходимости подстраиваться под ограниченный набор языков разработки.
Ссылка на документацию
При тестировании используются фреймворки от вендоров — то есть вы работаете именно с исходным приложением. Для Android 4.2+, соответственно, применяется UiAutomator/UiAutomator2, а для iOS 9.3+ — XCUITest. В качестве оболочки фреймворков используется WebDriver (он же — Selenium WebDriver).
Принципы Appium:
- Не нужно перекомпилировать приложение или изменять его для автоматизации тестирования.
- Не обязательно привязываться к одному языку или фреймворку.
- Не обязательно изобретать колесо, когда речь идёт об API автоматизации.
Использование Appium оправдано, когда нужен инструмент для автоматизации тестирования сразу на нескольких платформах. Он полезен, если у вас есть специалисты с опытом тестирования веб-приложений, но нет опыта автоматизации тестирования мобильных приложений.
В целом, это гибкий инструмент, который можно доработать под нужды проекта без необходимости подстраиваться под ограниченный набор языков разработки.
Ссылка на документацию
Ranorex
Платный комплексный инструмент для тестирования десктопных, мобильных и веб-приложений. Позволяет проводить тестирование как с применением программирования, так и вовсе без использования скриптов. Предоставляет возможность тестирования не только через эмуляторы, но также на живых девайсах.
Инструмент даёт возможность создавать и настраивать тесты, а также управлять ими централизованно. Вы можете создать тест в центре управления и запускать его в различных внешних средах и на любых девайсах.
Легко интегрируется с существующей CI-средой: с такими системами управления заявками, как Jira и TFS, а также с системами контроля версий — например, Git и SVN.
В Ranorex прокачано data-driven тестирование с подгрузкой данных из SQL, CSV, Excel.
Инструмент подходит абсолютно для любого устройства, поддерживает параллельное тестирование на каждом из них.
Сочетает все три подхода к тестированию: black-box, white-box и grey-box.
Ссылка на документацию
Инструмент даёт возможность создавать и настраивать тесты, а также управлять ими централизованно. Вы можете создать тест в центре управления и запускать его в различных внешних средах и на любых девайсах.
Легко интегрируется с существующей CI-средой: с такими системами управления заявками, как Jira и TFS, а также с системами контроля версий — например, Git и SVN.
В Ranorex прокачано data-driven тестирование с подгрузкой данных из SQL, CSV, Excel.
Инструмент подходит абсолютно для любого устройства, поддерживает параллельное тестирование на каждом из них.
Сочетает все три подхода к тестированию: black-box, white-box и grey-box.
Ссылка на документацию
TestComplete
Платная среда для автоматизации тестирования мобильных, веб и десктопных приложений. Поддерживает Android и iOS, а в разрезе типов приложений: нативные, веб-приложения и гибридные.
Ориентированный, в основном, на функциональное и юнит-тестирование, инструмент также предоставляет возможность проводить многие другие виды тестирования:
В TestComplete есть Recorder — в нём тесты создаются путём записи действий и настройки команд в редакторе. Далее они могут запускаться как непосредственно в самом инструменте, так и экспортироваться в сторонние приложения.
Данный инструмент распознаёт объекты и элементы управления, предлагая специальные команды для эмуляции взаимодействия пользователя с ними. Интегрируется с Jenkins, Git и Jira, что позволяет запускать непрерывное бесшовное тестирование.
Ссылка на документацию
Ориентированный, в основном, на функциональное и юнит-тестирование, инструмент также предоставляет возможность проводить многие другие виды тестирования:
- Регрессионное;
- Data-driven testing;
- Распределённое тестирование и не только.
В TestComplete есть Recorder — в нём тесты создаются путём записи действий и настройки команд в редакторе. Далее они могут запускаться как непосредственно в самом инструменте, так и экспортироваться в сторонние приложения.
Данный инструмент распознаёт объекты и элементы управления, предлагая специальные команды для эмуляции взаимодействия пользователя с ними. Интегрируется с Jenkins, Git и Jira, что позволяет запускать непрерывное бесшовное тестирование.
Ссылка на документацию
Подбор инструметов для проекта
Если перед вами стоит задача протестировать небольшое приложение в сжатые сроки, в первую очередь нужно учитывать такие факторы, как тип тестируемого приложения и опыт ваших специалистов. Если тесты пишет разработчик, лучше выбрать родной язык и инструмент для его платформы (см. в таблице ниже). Если тестами занимаются специалисты SDET, которые знакомы с другими языками (Java, JavaScript, Python и др.) и работали с Selenium, удобно использовать Appium. Если опытного SDET в команде нет, а тесты будут писать специалисты QA, лучше выбрать платные фреймворки, поскольку в них есть утилиты для записи тестов и более стабильная техподдержка, чем в open source фреймворках.
Таблица, которая поможет подобрать инструмент для вашего проекта. Стоит отметить, что в некоторых случаях приведенное в таблице деление является условным. Где-то для простоты сделано обобщение и приведены только самые основные параметры. Инструменты тестирования постоянно развиваются, поэтому при выборе фреймворка важно проверять актуальную документацию.
Таблица, которая поможет подобрать инструмент для вашего проекта. Стоит отметить, что в некоторых случаях приведенное в таблице деление является условным. Где-то для простоты сделано обобщение и приведены только самые основные параметры. Инструменты тестирования постоянно развиваются, поэтому при выборе фреймворка важно проверять актуальную документацию.
