Automation test что это за программа на андроид
Учитывая конкуренцию, разработчикам нельзя — никак и нигде — подводить пользователей. Этого реально добиться, если QA-отдел выкладывается на все сто.
Если софт для тестирования Android — твое слабое место, или ты вообще новичок в этой теме, попробуем разобраться с базовыми вещами. Если эта тема интересует, пиши в комментах.
О чем будет идти речь
- Что такое мобильное тестирование?
- Автоматизация или ручное тестирование?
- Особенности
- Советы
- Инструменты
- Что надо запомнить
- Итоги
Что такое мобильное тестирование?
Начнем с простого, рассмотрим мобильное тестирование “в целом”.
Мобильное тестирование — это процесс проверки мобильных приложений, то есть программ для смартфонов, планшетов, и других мобильных устройств (больше о тестировании мобильных приложений можно почитать в нашей статье). Проверяется функциональность, производительность, безопасность, удобство. Тестирование может быть ручным или автоматизированным. Цель тестировщика и всей QA-команды: убедиться, что приложение отвечает прописанным бизнес-требованиям , и ожиданиям пользователей.
Традиционно бывают такие типы мобильных приложений:
- Нативные приложения разрабатываются “под платформу”, то есть под одну из двух основных платформ, на соответствующем языке программирования, и с соответствующим SDK. Приложение устанавливается на смартфон из официального магазина.
- Веб-приложения пишутся с применением server-side-технологий , и работают, грубо говоря, через мобильный браузер. Существуют “адаптивные ” (или “responsive”, мобильные версии сайтов) и “ прогрессивные ” (progressive) мобильные веб-приложения.
- Третий тип — гибридные приложения . Они устанавливаются из магазинов, но работают на веб-технологиях. Разница с «классическими» веб-приложениями в том, что современные гибридные приложения получают широкий доступ к встроенным возможностям смартфона и продвинутым функциям операционки.
Автоматизация или ручное тестирование?
Автоматизированное тестирование важнее день ото дня. Во многих командах стоит вопрос, автоматизировать ли ? Быстрый ответ: это зависит от особенностей приложения.
Скорее всего, для небольших и простых Android-приложений (а они составляют видимо бОльшую часть приложений в маркете) нет большой потребности в автоматизации тестов. Автоматизация может быть полезна, если например жесткие дедлайны; очень широкое таргетирование аудитории; большой предполагаемый парк девайсов . Ну и, производительность вряд ли получится качественно протестировать автоматизированным способом.
Когда делают большие и сложные приложения, автоматизация нужна. Так QA-отдел добивается наилучшей эффективности; ускоряет процедуры; экономит кучу времени, усилий и денег. Хорошо автоматизируется регрессионное тестирование; для него есть удобные инструменты.
Выбор инструментов автоматизированного тестирования уже очень широк. Среди этих инструментов выделяется Appium; инструменты семейства Android Studio; Selendroid; Espresso; Roboelectric; список в конце.
В целом, в тестировании на Android в 2022 году принято, что автоматизировать тесты достаточно на 70%-80%. Ручное тестирование (все еще) незаменимо в некоторых сферах ; поэтому автоматизация — не причина как-то пренебрегать ручным тестированием.
Этапы тестирования Android-приложений
Чтобы хорошо, качественно протестировать приложение, надо правильно составить “ стратегию тестирования”, и построить хороший рабочий процесс (workflow).
Итак, какие этапы будут в тестировании Android-приложения?
Планирование
Написание правильного плана тестирования — уже половина успеха. Важно с самого начала сосредоточиться на правильных вещах; прописать ту самую “стратегию тестирования”. На этом, самом первом этапе, QA-отдел описывает “масштаб/охват тестирования”; тестовое покрытие; покрытие девайсов; ресурсы, нужные для тестирования; примерные дедлайны; и, возможно, другие вещи, зависящие от уже конкретного проекта. Затем решается, в каком объеме будет автоматизация; и какие из тестовых сценариев будут автоматизировать.
Настройка тестового окружения
Надо подобрать соответствующий парк тестовых девайсов. Также на этом этапе будут настраиваться эмуляторы/симуляторы, и возможно облачные девайсы .
Написание тест-кейсов и сценариев
Когда уже решено, какая функциональность будет покрыта тестами, QA-отдел пишет тест-кейсы. В широком смысле, тест-кейс — это список этапов проверки, ведет ли себя приложение “как положено” в некой ситуации. Тестовые сценарии автоматизации пишутся, если QA-команда все-таки решила автоматизировать (некоторые) сценарии.
Выполнение тестов и баг-репорты
Следующий этап — выполнение тестов и баг-репорты . Основной, самый трудоемкий этап. Обычно этап непосредственно тестирования начинается с функционального тестирования ; здесь проверяется, что вся ключевая функциональность приложения работает как положено. Сначала лучше сделать ручное исследовательское тестирование ; и если тестируемое приложение ( AUT на жаргоне тестировщиков, Application Under Test) достаточно стабильное, то тогда переходят к автоматизированному тестированию.
Тестирование интерфейса и тестирование юзабельности . Важная часть процесса: QA проверяют user experience и удостоверяются, что AUT простое в использовании; интуитивное; то что называется юзер-френдли; и что по крайней мере в интерфейсе нет явных дефектов.
Тестирование compatibility проверяет, корректно ли работает AUT на предполагаемых “целевых” смартфонах/операционках. Здесь также “шлифуют” user experience.
Тестирование производительности — важнейший этап в тестировании практически любого приложения в плеймаркете. Типы тестирования производительности: volume-тестирование ; стресс-тестирование ; тестирование стабильности ; нагрузочное тестирование ; спайк-тестирование . В целом тестирование производительности должно проверить, как приложение ведет себя под предполагаемой средней рабочей нагрузкой, и при нагрузке сильно выше средней . Такое тестирование может проводиться с привлечением специальных инструментов, и оно, в основном, автоматизируется.
Когда с производительностью и функциональностью уже все хорошо , пришло время гарантировать, что приложение в достаточной мере безопасное, и что поддерживаются стандарты совместимости , и, если речь идет о солидном приложении для рынков США/Евросоюза, стандарты доступности . То есть выполняется тестирование безопасности , и тестирование совместимости .
Кроме упомянутых тестов, еще может быть: инсталляционное тестирование ; тестирование обновлений ; тестирование прерываний ; тестирование восстановления ; тестирование ресурсов устройства ; тестирование сетевых конфигураций .
Отчеты
И наступает последний этап: создание отчетов (на жаргоне тестировщиков — “репортов”). Создается большой итоговый отчет по результатам тестирования. Найденные и исправленные баги анализируются, определяются самые проблемные модули в приложении. Далее, если есть необходимость, приложение продолжают “шлифовать”, или отдают на релиз (выпускают готовое).
Особенности тестирования Android-приложений
На Android-платформе есть особенности, о которых нужно знать.
Необходимость тестировать на большом количестве девайсов
Android — открытая платформа, и это значит, что ее используют “на свое усмотрение” все производители смартфонов (и не только). Помимо этого, производители “железа” имеют возможность глубоко модифицировать операционную систему “под себя”, что тоже добавляет сложностей в тестирование. Поэтому QA-отдел должен гарантировать, что приложение будет работать на самых распространенных смартфонах (хотя бы), что user experience не пострадает.
Размер и пропорции экрана
Android-смартфоны поставляются с экранами самых разных размеров и типов. QA-команда проверяет, как приложение работает в различных разрешениях, на разных размерах экрана, и пропорциях длины-ширины. Чаще, из-за невозможности “покрыть” все предполагаемые целевые смартфоны, QA тестируют хотя бы модели, самые “ходовые” в данный момент.
Характеристики железа
Производители выпускают мобильные девайсы с самыми разными характеристиками (аппаратными спецификациями). QA-команда должна учитывать, что Android-приложение (особенно гибридное) может работать с аппаратными ресурсами смартфона довольно непредсказуемо.
Обратная совместимость
Каждый производитель решает на собственное усмотрение, обновлять ли свою версию модифицированной операционки, и как часто это делать. Так же и пользователь не всегда обновляет прошивку своего смартфона. Это приводит к ситуации, когда большая часть пользователей запускает приложения на смартфонах со старыми версиями ОС. В таких случаях нужно так называемое тестирование обратной совместимости — по крайней мере для нескольких последних версий ОС.
Много альтернативных каналов распространения
Android-приложения могут ставиться не только из официального магазина Google, но и из многих альтернативных маркетов, или просто из карты памяти после скачки из (подозрительных) сайтов. Это, конечно, проблема, что касается безопасности. Поэтому Android-приложения должны тестироваться на безопасность, с той же, или бОльшей тщательностью, чем iOS-приложения.
Тестировщик Android — уровень “Новичок” — советы
Чтобы быстро продвигаться в тестировании на Android, и справляться с челенджами, тестировщику нужно запомнить некоторые вещи.
Тестировать на самых “ходовых” смартфонах
В самом лучшем сценарии приложение должно быть протестировано на как можно бОльшем парке девайсов, чтобы убедиться что хотя бы 90% пользователей смогут запустить его. В реальной жизни это очень долго и дорого . Поэтому QA-отдел как правило сосредотачивается на самых распространенных устройствах в данный момент.
Сейчас “общемировой” список Android-производителей выглядит примерно так: Samsung, Google, Xiaomi, OPPO, и Vivo. (В России, Беларуси, Украине и Казахстане список примерно такой же).
Тестировать на разных версиях Android
За 14 лет существования вышло больше десятка версий этой чудесной операционки. В целом, нужно стремиться протестировать на как можно бОльшем количестве версий Android. При этом, магазин Google как бы требует, чтобы приложения были ориентированы на самые последние версии. Таким образом, общепринятой практикой является ориентирование сначала на самые последние версии Android, и потом переходят на версии старее, если позволяет дедлайн.
В ручном тестировании нежелательны эмуляторы
То что подходит для разработки, не всегда хорошо в “мире QA”. Разработчики активно пользуются эмуляторами, а вот QA-отдел, в идеале, должен все тестировать на реальных девайсах. Во первых, да, можно качественно эмулировать вид и поведение приложения, но вот user experience — не факт. Особенно жесты пользователя , типа одновременных нажатий несколькими пальцами, промотка, зум — это до сих пор плохо эмулируется, все-таки лучше тестировать на реальном тачскрине. Таким образом, запомним, что юзабилити-тестирование мобильных приложений может быть по настоящему качественным только на реальных устройствах.
Во вторых, непременно надо протестировать производительность, и сделать это на реальных девайсах. На эмуляторе (симуляторе) очень трудно оценить потребление памяти и нагрузку на процессор, расход аккумулятора. Еще сложнее (если вообще возможно) протестировать работу с сотовой сетью.
Особое внимание проблемам с памятью
“Пожирание памяти” это частая проблема мобильных приложений. Случаются ситуации, когда приложения и игры не могут запуститься или вылетают на самых распространенных Android-девайсах именно из-за аномально и необъяснимо высокого потребления памяти. Как правило, самые популярные, топ-рейтинговые приложения в Google Play таких проблем не имеют (потому что их тщательно протестировали в свое время!). Чтобы убедиться, что тестируемое приложение будет таким же надежным как топовое, важно протестировать работу с памятью на самых ходовых девайсах, включая как дорогие, так и дешевые.
Гайдлайны Google Play Store
Это общие указания в Политике Приватности и Политике по Контенту , которые должны соблюдаться разработчиками приложения. Иначе приложение могут просто не принять в магазин; или, на исправление оплошностей уйдет время = сорвутся дедлайны.
Не игнорировать бета-тестирование
Тестирование — “холистический”, целостный и непрерывный процесс, охватывающий все этапы создания приложения. Существуют специализированные, качественные инструменты. Желательно хотя бы поверхностно ознакомиться с ними; чем раньше тем лучше.
Почему тестирование Android это сложно
Достаточно сложно добиться, чтобы приложение было одновременно : эффективным, удобным, стабильным, безопасным, производительным, юзер-френдли. Большая часть этой задачи лежит на QA-отделе. Опытные тестировщики владеют самыми разными типами тестирования, умеют комбинировать их.
Итоги
Нынешний пользователь Android избалован, он привык к качественным, надежным и красивым приложениям «по умолчанию».
Огромная, сложная, открытая экосистема Android — это большие челенджи для тестировщиков, но: слушая советы и накапливая опыт , челенджи можно решать! Постепенно продвигаясь к должности старшего тестировщика или главы QA-отдела .
Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.
Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.
Зачем нужны автотесты?
Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.
Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.
При этом, когда релизный цикл у вас длиной в несколько месяцев, вполне достаточно работы ручных тестировщиков и некоторого покрытия кода юнит- и интеграционными тестами. Однако во времена, когда релизный цикл стремительно сокращается до одной-двух недель (а то и еще меньше), сил ручных тестировщиков зачастую уже не хватает, что вынуждает или жертвовать качеством проверки, или нанимать больше специалистов.
Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.
Картина целиком
Итак, обещанная картина целиком.
Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.
Процесс написания тестов
На первом шаге давайте попробуем написать тесты у себя на машине и запустить их локально.
Выбор инструментов для написания автотестов
Стоит сразу определиться со стеком технологий, который мы будем использовать для написания тестов.
Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.
Спойлер — мы за нативные решения. По нашему опыту, они:
- стабильнее;
- быстрее;
- лучше интегрированы в IDE;
- не содержат слоев, которые вносят нестабильность и заставляют иметь суперширокие экспертные знания.
Кроме того, Google поддерживает Espresso и UI Automator.
Больше почитать про сравнение вы можете в статьях:
На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.
Kaspresso
Kaspresso — это фреймворк, который:
- предоставляет DSL, значительно облегчающий написание автотестов;
- дает встроенную многоуровневую защиту от флекающих тестов;
- ускоряет работу UI Automator;
- предоставляет полные логи о том, что происходит в тесте;
- дает возможность запуска любых ADB-команд внутри тестов;
- предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
- описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.
Вы можете прочитать о Kaspresso на GitHub и Habr.
Test runner
Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.
Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.
Но со временем требований к раннеру становится все больше. Вот некоторые из них:
- запускать отдельные группы тестов;
- запускать тесты только на определенных девайсах;
- перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
- эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
- подготавливать отчеты о прогоне в разных форматах;
- отображать результаты прогона (желательно Allure based);
- поддержать истории прогонов для дальнейшего анализа;
- просто интегрироваться с вашей инфраструктурой.
На рынке есть несколько сторонних раннеров. Среди всех них, самым перспективным мы считаем Marathon, который довольно быстро настраивается и удовлетворяет части обозначенных выше требований. Например, он поддерживает распараллеливание тестов и подготовку результатов прогона в формате, пригодном для отображения в Allure.
Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:
- Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon — к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
- Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.
Кроме того, мы считаем, что раннер должен быть платформенным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.
Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!
На чем запускать тесты
Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:
- Настоящий девайс.
Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот. - Чистый эмулятор.
Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение. - Docker-образ Android-эмулятора.
Docker решает недостатки чистых эмуляторов.
Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
Минусы. Более высокий входной порог.
Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:
Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.
Инфраструктура
Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.
Однако эта область — темный лес для части Android-разработчиков и автоматизаторов. Оно и немудрено, ведь инфраструктура требует знаний железа, конфигурирования серверов, DevOps-практик и прочего. Поэтому обязательно наладьте контакты с людьми, которые во всем этом разбираются, у себя в компании или вовне, ведь они сильно помогут и уберегут вас от ошибок.
Итак, что вам примерно предстоит:
- Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
- Самое трудоемкое — это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
Дальнейшая накатка необходимого ПО, встраивание в сети и прочее — это все за DevOps-инженерами. - На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
В его настройке опять-таки помогают DevOps-инженеры. - Связка полученного сервиса с Test Runner.
Одна из задач Avito Runner — сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.
В ближайшее время мы планируем выпустить Avito Runner и статьи, которые помогут настроить инфраструктуру.
Остальное
Не забывайте про такие немаловажные моменты, как:
- вывод отчета по прогону тестов (Allure);
- внедрение/синхронизация с TMS;
- интеграция в CI/CD;
- обучение разработчиков и тестировщиков;
- процессы — кто, когда, сколько и какие автотесты пишет.
Про все это мы еще обязательно поговорим.
Заключение
Мы постарались описать основные части становления автотестирования под Android. Надеемся, что теперь у вас в головах сложится тот самый пазл, который позволит видеть картину целиком.
Задача — с наибольшей точностью автоматизировать действия, которые выполняет тестировщик. Давайте их рассмотрим. В наличии есть несколько приложений и несколько Android устройств. Для каждого приложения и каждого устройства выполняются следующие шаги:
- Установка приложения на устройство
- Запуск приложения
- Тестирование приложения выбранным способом
- Удаление приложения
- Сброс состояния устройства
Далее рассматриваются средства, позволяющие автоматизировать перечисленные шаги.
Управление Android устройствами
Для начала нужно выделить компьютер на котором будет запускаться автоматическое тестирование и настроить на нем Android SDK. Примеры приводятся для компьютера с установленной ОС Linux.
На всех тестируемых устройствах нужно отключить экран блокировки и максимально увеличить время ожидания. Для некоторых методов тестирования нужно отключить смену ориентации экрана.
В Android SDK имеются две утилиты для управления устройствами: adb и MonkeyRunner.
Я постараюсь подробно описать автоматизацию действий, использующихся при тестировании. Тем, кто знаком с ADB и MonkeyRunner имеет смысл сразу переходить к разделу «Способы автоматизированного тестирования».
Управление с помощью утилиты ADB
Утилита adb находится в директории /platform-tools/ . Путь к данной директории рекомендуется прописать в переменной окружения PATH .
Проверка работы ADB
Устанавливаем и настраиваем Android SDK, подключаем к компьютеру Android устройства и выполняем команду:
Команда выдаст список всех подключенных устройств. Если список устройств не пуст, значит ADB настроен и работает.
Работа с несколькими устройствами
Чтобы указать ADB с каким устройством нужно работать, следует прописать серийный номер устройства после ключа -s :
Серийный номер устройства можно посмотреть командой adb devices . Ключ -s позволяет работать одновременно с несколькими подключенными устройствами. В дальнейшем ключ -s в командах я указывать не буду.
Основные команды ADB
Открыть консоль на устройстве:
Запустить команду на устройстве:
В Android присутствуют многие стандартные утилиты Linux: ls, cat, dmesg,…
Установить приложение из apk файла:
Название package можно получить из apk файла командой:
Загрузить файл с устройства на компьютер:
Загрузить файл с компьютера на устройство:
Примечание:
В большинство директорий на устройстве разрешен доступ только на чтение. Доступ на запись разрешен в директорию /sdcard (из нее нельзя запускать программы) и /data/local/tmp/ .
Запускает указанную activity. Название activity, которая запускается при выборе приложения в меню можно получить из apk файла командой:
Чтение логов
Считать логи с устройства (блокируется до нажатия Ctrl-C):
Очистить буфер логов на устройстве:
Считать буфер логов на устройстве (выдает текущее содержимое буфера, не блокируется):
Снятие скриншотов с помощью утилиты screencap
Утилита screencap сохраняет текущее содержимое экрана в графический файл:
Утилита screencap имеется на телефонах с Android 4.x и выше. На предыдущих версиях Android снятие скриншотов можно производить с помощью MonkeyRunner.
Пример BASH скрипта для тестирования приложения c помощью ADB
Управление с помощью MonkeyRunner
Утилита MonkeyRunner предоставляет API для написания скриптов, которые управляют Android устройстами. С помощью MonkeyRunner можно написать скрипт на языке Python, который устанавливает Android приложение, запускает его, имитирует действия пользователя, снимает скриншоты и сохраняет их на компьютер. Утилита MonkeyRunner использует Jython для выполнения скриптов.
Чтение логов с помощью MonkeyRunner
Скрипт запишет логи в файл example.log в текущей директории.
Снятие скриншотов
Скрипт снимает скриншот и сохраняет его в файл screenshot.jpg в текущей директории.
Пример управления устройством с помощью MonkeyRunner
Средства автоматизированного тестирования
Тестирование с помощью monkey
Представьте, что устройство попало в цепкие лапы очень активной и творческой обезьяны – утилита monkey призвана имитировать подобную ситуацию.
Утилита monkey входит в состав Android SDK. Утилита отправляет на устройство поток псевдо-случайных действий пользователя. Параметры командной строки задают количество действий пользователя, соотношение их типов и имя тестируемого пакета, чтобы, например, обезьяна не вышла за пределы тестируемого приложения и не начала рассылать SMS по всем контактам из адресной книги.
Главное достоинство monkey – отсутствие затрат на поддержку. Кроме того, стресс-тестирование приложения потоком произвольных событий может обнаружить нетривиальные ошибки.
- Неэффективно для тестирования функционала, вызываемого сложной последовательностью действий. Например, monkey не сможет пройти аутентификацию и основной функционал приложения останется без внимания.
- Игры со сложным управлением, требующим быстрой реакции и сложных жестов, будут завершатся в самом начале, либо вообще не начнутся.
- Ошибки, найденные с помощью monkey, очень сложно воспроизвести.
- Нет проверки состояния приложения.
Тестирование с помощью MonkeyRunner
При помощи скриптов использующих MonkeyRunner API можно не только разработать основу для тестирующей системы, но и написать скрипты для тестирования конкретного приложения на конкретном устройстве.
- Гибкость – реализовать можно практически все, что угодно.
- Сложность написания скриптов даже в простых случаях.
Тестирование с помощью getevent/sendevent
- Последовательности действий могут быть записаны без дополнительных затрат в ходе ручного тестирования, если оно уже проводится.
- Для записи сценариев не требуются навыки программирования.
- Последовательности действий необходимо записывать отдельно для каждого приложения и для каждого устройства. При изменении интерфейса приложения все записанные действия необходимо проделать заново.
- Отсутствует проверка состояния приложения. Например, при тестировании браузера открывается страница. Если она открывается дольше, чем в момент записи, то дальнейшие действия будут выполнены до полной загрузки страницы и результат будет некорректный. Иногда возможно записать скрипт таким образом, что во всех подобных случаях ожидание превышает максимально возможное.
- Быстрая и сложная последовательность действий будет воспроизводиться дольше, чем записывалась – поэтому способ не всегда подойдет для тестирования динамичных игр, где критично время реакции и своевременность действия.
На устройстве должны воспроизвестись записанные действия.
Тестирование с помощью Robotium
В отличии от рассмотренных ранее способов Robotium не входит в состав Android SDK, а распространяется под Open Source лицензией.
Главное отличие Robotium в том, что тестовые действия описываются на уровне интерфейса приложения. В рассмотренных ранее способах тестовые действия явно или неявно описывались на уровне устройств ввода.
Например, в приложении нужно нажать кнопку «OK». С помощью скрипта MonkeyRunner нажатие на кнопку реализуется как: «Коснуться точки экрана с координатами (x0, y0)». С помощью Robotium это реализуется как: «Нажать кнопку с текстом «OK»».
Когда действия описываются на уровне интерфейса приложения их можно сделать независимыми от расположения элементов интерфейса, разрешения экрана и положения устройства.
Кроме того, Robotium позволяет проверять реакцию приложения на действие.
Например, после нажатия на кнопку «OK» в приложении должен появиться список с элементом «Item 1». С помощью Robotium можно проверить, появился ли список с таким элементом.
Если выполнять проверки после каждого действия, то легко обнаружить, на каком шаге произошла ошибка.
- Для каждого приложения необходимо разработать сценарий тестирования на языке Java. Это требует навыков программирования и временных затрат.
- При изменении интерфейса приложения сценарий тестирования придется модифицировать.
- Написать сценарий Robotium сложнее, чем записать действия с помощью getevent/sendevent.
Сравнение способов тестирования
Способ тестирования | Достоинства | Недостатки |
---|---|---|
Monkey – поток случайных действий пользователя. | Отсутствуют затраты на сопровождение. Не зависит от устройства. Стресс-тестирование позволяет обнаружить нетривиальные ошибки. | Качество тестирования варьируется от приложения к приложению. Найденные ошибки сложно воспроизвести. Нет проверки состояния приложения. |
MonkeyRunner – скрипт управления устройством. | Гибкость. | Сложность написания и поддержки скриптов даже для простых приложений. |
getevent/sendevent – запись/воспроизведение действий пользователя. | Для записи последовательности действий не требуются навыки программирования. | Записанная последовательность действий подходит только к одному устройству при фиксированной ориентации. При изменении интерфейса приложения необходимо заново записать последовательность действий. Нет проверки состояния приложения. |
Robotium – сценарий тестирования интерфейса приложения с проверкой состояния. | Действия описываются на уровне интерфейса приложения. Сценарий может быть независимым от разрешения экрана и ориентации устройства. После совершения действия можно проверять состояние приложения. | Сложность написания сценариев на языке Java. При изменении интерфейса приложения сценарий придется модифицировать. |
Анализ результатов
В результате тестирования приложения перечисленными выше способами мы получили логи и скриншоты. Теперь их нужно проанализировать на наличие ошибок.
Анализ логов
- I/DEBUG
- FATAL EXCEPTION
- WIN DEATH
Анализ скриншотов
В процессе тестирования вручную можно подготовить серию скриншотов в ключевых моментах тестирования, а затем сравнивать их с содержимым экрана в процессе автоматизированного тестирования. Это позволит определить, правильно ли идет процесс автоматизированного тестирования и выявлять ошибки.
MonkeyRunner позволяет сравнить два скриншота с заданным допуском в процентах:
К сожалению, в API MonkeyImage не предусмотрена функция загрузки из файла. Поэтому для сравнения сохраненных скриншотов придется писать свою функцию, например с помощью Python Imaging Library.
Сброс состояния устройства после тестирования
После тестирования приложения устройство нужно вернуть в первоначальное состояние.
На практике этот вариант оптимален, так как имитирует поведение реального пользователя.
Заключение
В заметке были рассмотрены некоторые способы автоматического тестирования Android приложений, их достоинства и недостатки. Кроме того, рассмотрены инструменты, входящие в Android SDK или распространяющиеся под Open Source лицензией.
Хочется отметить, что автоматическое тестирование не является панацеей и не заменяет другие виды тестирования. Качественный продукт получается при грамотно построенном процессе тестирования, сочетающем различные способы.
Что пишут в блогах
Конференции
Heisenbug 2022 Spring
Большая техническая конференция по тестированию
Online — с 30 мая по 1 июня. Offline-день — 21 июня
Профессиональная конференция по автоматизации в тестировании и рядом
27 и 28 июня, Москва, Radisson Slavyanskaya.
Что пишут в блогах (EN)
Разделы портала
Онлайн-тренинги
Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.
Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.
Зачем нужны автотесты?
Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.
Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.
При этом, когда релизный цикл у вас длиной в несколько месяцев, вполне достаточно работы ручных тестировщиков и некоторого покрытия кода юнит- и интеграционными тестами. Однако во времена, когда релизный цикл стремительно сокращается до одной-двух недель (а то и еще меньше), сил ручных тестировщиков зачастую уже не хватает, что вынуждает или жертвовать качеством проверки, или нанимать больше специалистов.
Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.
Картина целиком
Итак, обещанная картина целиком.
Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.
Процесс написания тестов
На первом шаге давайте попробуем написать тесты у себя на машине и запустить их локально.
Выбор инструментов для написания автотестов
Стоит сразу определиться со стеком технологий, который мы будем использовать для написания тестов.
Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.
Спойлер — мы за нативные решения. По нашему опыту, они:
- стабильнее;
- быстрее;
- лучше интегрированы в IDE;
- не содержат слоев, которые вносят нестабильность и заставляют иметь суперширокие экспертные знания.
Кроме того, Google поддерживает Espresso и UI Automator.
Больше почитать про сравнение вы можете в статьях:
На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.
Kaspresso
Kaspresso — это фреймворк, который:
- предоставляет DSL, значительно облегчающий написание автотестов;
- дает встроенную многоуровневую защиту от флекающих тестов;
- ускоряет работу UI Automator;
- предоставляет полные логи о том, что происходит в тесте;
- дает возможность запуска любых ADB-команд внутри тестов;
- предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
- описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.
Вы можете прочитать о Kaspresso на GitHub и Habr.
Test runner
Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.
Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.
Но со временем требований к раннеру становится все больше. Вот некоторые из них:
- запускать отдельные группы тестов;
- запускать тесты только на определенных девайсах;
- перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
- эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
- подготавливать отчеты о прогоне в разных форматах;
- отображать результаты прогона (желательно Allure based);
- поддержать истории прогонов для дальнейшего анализа;
- просто интегрироваться с вашей инфраструктурой.
На рынке есть несколько сторонних раннеров. Среди всех них, самым перспективным мы считаем Marathon, который довольно быстро настраивается и удовлетворяет части обозначенных выше требований. Например, он поддерживает распараллеливание тестов и подготовку результатов прогона в формате, пригодном для отображения в Allure.
Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:
- Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon — к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
- Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.
Кроме того, мы считаем, что раннер должен быть платформенным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.
Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!
На чем запускать тесты
Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:
- Настоящий девайс.
Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот. - Чистый эмулятор.
Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение. - Docker-образ Android-эмулятора.
Docker решает недостатки чистых эмуляторов.
Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
Минусы. Более высокий входной порог.
Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:
Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.
Инфраструктура
Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.
Однако эта область — темный лес для части Android-разработчиков и автоматизаторов. Оно и немудрено, ведь инфраструктура требует знаний железа, конфигурирования серверов, DevOps-практик и прочего. Поэтому обязательно наладьте контакты с людьми, которые во всем этом разбираются, у себя в компании или вовне, ведь они сильно помогут и уберегут вас от ошибок.
Итак, что вам примерно предстоит:
- Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
- Самое трудоемкое — это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
Дальнейшая накатка необходимого ПО, встраивание в сети и прочее — это все за DevOps-инженерами. - На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
В его настройке опять-таки помогают DevOps-инженеры. - Связка полученного сервиса с Test Runner.
Одна из задач Avito Runner — сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.
В ближайшее время мы планируем выпустить Avito Runner и статьи, которые помогут настроить инфраструктуру.
Остальное
Не забывайте про такие немаловажные моменты, как:
- вывод отчета по прогону тестов (Allure);
- внедрение/синхронизация с TMS;
- интеграция в CI/CD;
- обучение разработчиков и тестировщиков;
- процессы — кто, когда, сколько и какие автотесты пишет.
Про все это мы еще обязательно поговорим.
Заключение
Мы постарались описать основные части становления автотестирования под Android. Надеемся, что теперь у вас в головах сложится тот самый пазл, который позволит видеть картину целиком.
Нагрузочное, функциональное, системное и прочие типы тестирования программного обеспечения имеют важнейшее значение с точки зрения выпуска качественного продукта. И сегодня в этой области ключевую роль играет автоматизация. Применение инструментов автоматизации и автоматизированных тестов (автотестов) позволяет компаниям соответствовать тенденциям отрасли и достигать максимальных результатов. Давайте рассмотрим наиболее популярные и эффективные инструменты автоматизированного тестирования. В список инструментов для тестирования вошли как приложения с открытым исходным кодом, так и коммерческие средства автоматизации.
Преимущества автоматизации
Прежде чем приступить к рассмотрению инструментов для тестирования, следует перечислить основные плюсы, которые несет автоматизация: — экономия времени. Ручное тестирование — это долго и трудоемко. А сценарий автоматизации в идеале пишется лишь один раз. Профит от использования автоматизации и автотестов — и экономия человеческого ресурса, и ускорение написания отчетной документации и т. п.; — переиспользование. Этот плюс автоматизации плавно вытекает из предыдущего. Написанный инженером один раз тестовый сценарий (автотест) используется многократно при обновлениях продукта, что оптимизирует весь процесс; — нагрузочное тестирование. Автоматизация дает возможность сымитировать воздействие на систему множества пользователей — ручная работа без инструментов для тестирования этого достичь не позволяет.
Да, все автоматизировать невозможно, но и игнорировать автоматизацию, особенно в условиях современной конкуренции, тоже нельзя.
Selenium
Один из наиболее популярных фреймворков для автоматизации тестирования сайтов и веб-приложений. Имеет открытый исходный код и завоевал сердца многих инженеров, особенно тех, которые обладают продвинутыми навыками программирования и без проблем самостоятельно пишут скрипты. Selenium был разработан достаточно давно, однако последние десять лет он активно развивается.
Стоит добавить, что платформа имеет и преимущества, и недостатки. Среди плюсов — гибкость, возможность написания сложных скриптов для автоматизации. Среди минусов — достаточно высокая квалификация тестировщика. Специалист по автоматизации должен не только обладать повышенными знаниями в разработке программного обеспечения, но и быть готовым ко времязатратному написанию специальных библиотек и фреймов, обеспечивающих выполнение необходимых функций в процессе автоматизированного тестирования.
Unified Functional Testing (переводится как комплексное функциональное решение для тестирования) — это популярный коммерческий инструмент. По сути, UFT — это набор функций, предназначенных для тестирования веб-сервисов, сайтов, API, графического интерфейса мобильных, десктопных и веб-приложений практически на всех, существующих на сегодняшний день, платформах. Инструмент имеет расширенный функционал распознавания объектов на основе их изображений. Доступны многоразовые тестовые компоненты, а также документация по автоматизации.
Для работы инструмента используется Visual Basic Scripting Edition, благодаря чему вы можете управлять объектами или сохранять информацию о выполненном тестировании. Еще UFT интегрирован с Mercury Quality Center и Mercury Business Process Testing, плюс поддерживает CI посредством интеграции с такими CI-инструментами, как Jenkins.
Katalon Studio
Эффективный инструмент для автоматизирования процесса тестирования сайтов, веб-сервисов, мобильных приложений. Katalon Studio считают «потомком» таких фреймворков, как Appium и Selenium. Это связано с тем, что он перенял у них ряд плюсов, связанных с интегрированной автоматизацией тестирования программного обеспечения.
Чтобы комфортно работать с этим инструментом, можно обладать как начальными знаниями в тестировании, так и быть экспертом своего дела. На практике запуск собственного проекта по автоматизации тестирования не вызывает затруднений даже у людей, далёких от программирования. Это можно сделать с помощью функции Object Spy. А вот для программистов и более опытных тестировщиков Katalon Studio станет весьма полезным инструментальным средством в плане экономии времени как при написании новых библиотек, так и при поддержке уже существующих скриптов.
Katalon Studio без проблем интегрируется в CI/CD и во время тестирования ПО прекрасно работает с различными инструментами: JIRA, Jenkins, qTest, Git. Встроена функция Katalon Analytics, позволяющая пользователю получать полное представление о непосредственном процессе тестирования. Для этого на экран выводятся специальные отчёты, оформленные в виде графиков, метрик, диаграмм.
Watir
Инструмент для автоматизированного тестирования веб-приложений, использующий в своей работе библиотеки Ruby. Имеет открытый исходный код, есть возможность кроссбраузерной работы во многих современных браузерах: Opera, Firefox, IE, headless-браузерах. Watir поддерживает тестирование, управляемое данными. Также он интегрирован с инструментами BBD (Cucumber, RSpec, Test/Unit).
TestComplete
TestComplete является эффективным средством автоматизации тестирования мобильных, десктопных и веб-приложений. Он разработан компанией SmartBear и поддерживает VBScript, JavaScript, Python, C ++ Script. Так же, как и в случае с Katalon Studio, посредством TestComplete тестировщики смогут без проблем проводить управляемое данными тестирование, а также применять ключевые слова. Вдобавок ко всему, это средство автоматизации тестирования имеет удобную функцию записи процесса с возможностью последующего воспроизведения.
Если сравнивать TestComplete с UTF, то он схож с функцией распознавания объектов GUI. В результате производится автоматическое обнаружение и обновление элементов пользовательского интерфейса. Всё это позволяет избежать дополнительных забот по поддержанию тестовых скриптов при изменениях AUT. Ещё инструмент может интегрироваться с Jenkins во время CI-процесса.
IBM Rational Functional Tester
Эффективный инструмент для управляемого данными тестирования функциональности и регрессии программного обеспечения. Поддерживает разные языки программирования (Java, SAP, Net, Flex, Ajax).
Платформа IBM RFT имеет функцию Storyboard testing. Она позволяет записывать и в последующем визуализировать в виде последовательных изображений все действия, связанные с автоматическим тестированием (пользователь всегда может изучить скриншоты приложений на разных этапах тестирования).
Очередная интересная особенность — возможность интеграции платформы с системами управления жизненным циклом приложений IBM Jazz (Rational Quality Manager, IBM Rational Team Concert).
Tricentis Tosca
Модельно-ориентированный инструмент для автоматизированного тестирования. Представляет собой широкий набор опций для непрерывного тестирования, куда входит и проверка качества ПО с выведением, анализом и интеграцией данных. Это необходимо для поддержки гибких методик программирования, тех же методологий DevOps.
С помощью Tricentis Tosca пользователь легко оптимизирует использование ресурсов, нужных для выполнения повторного тестирования. Как и в случае с прочими инструментами для тестирования, благодаря Tricentis Tosca возможна проверка качества мобильных приложений, API, сайтов, веб-приложений. Также с помощью этого инструмента для тестирования можно управлять интеграцией, анализировать риски.
TestPlant eggPlant
Работа основана на анализе изображений, что позволяет тестировщикам успешно выполнять AUT. С точки зрения методики платформа отличается от традиционных инструментов. Дело в том, что здесь моделирование процессов происходит так, как будто бы тестированием занимается не инженер путём написания соответствующих тест-скриптов, а сам пользователь.
TestPlant eggPlant совместим с разными платформами, плюс есть возможность CI-интеграции и управления лабораторией.
Ranorex
Очередной платный инструмент для автоматизации. Характеризуются широкими возможностями, включая: - распознавание GUI; - запись и воспроизведения этапов проверки программного обеспечения; - применение многоразовых тестовых сценариев.
Очередной плюс — возможность создавать тестовые сценарии без написания кода. Платформа станет прекрасным помощником для тех специалистов, которые только начали свой путь в автоматизации, так как для работы не нужно иметь углубленные знания в программировании.
Дополнительно скажем, что поддерживается интеграция с Selenium. Те же результаты тестирований можно группировать, используя сетку Selenium. Для бизнес-клиентов действует система скидок.
Robot framework
Фреймворк с открытым исходным кодом, позволяющий решать множество задач по автоматизации. Имеющиеся возможности можно расширить путём внедрения дополнительных библиотек посредством Java и Python. К примеру, одной из популярных внешних библиотек, используемых в Robot Framework, является Selenium WebDriver.
Кроме автоматического тестирования сайтов и веб-приложений, Robot Framework подходит для проверки программ для Android и iOS. Инструмент покажется очень простым для тех специалистов, кто уже знаком с методом тестирования на основе ключевых слов.
Делаем выводы: вышеперечисленные инструменты для тестирования и другие средства автоматизации тестирования сайта и программного обеспечения существенно облегчают труд тестировщика, снижают его рабочую нагрузку. Если вы хотите освоить некоторые из вышеперечисленных платформ, записывайтесь на соответствующий курс в OTUS в Москве!
Читайте также: