Как протестировать android приложение
Тестирование Android приложений
Взрывной рост использования мобильных смартфонов и разработки мобильных приложений делает автоматизацию тестирования ключевым требованием успешной и быстрой поставки качественных мобильных приложений. Автоматизированное функциональное тестирование помогает обеспечить необходимую функциональность мобильного приложения и надлежащую работу пользовательского интерфейса. Однако существует необходимость выйти за рамки функционального тестирования мобильных приложений. Существует множество аспектов производительности мобильных приложений, которые нужно измерять и улучшать. Есть прямая взаимосвязь между производительностью и удобством использования мобильных приложений.
Тестирование является важной частью процесса разработки мобильных приложений. Для Android оно имеет особенную важность, поскольку используемые устройства довольно сильно отличаются друг от друга по следующим параметрам:
Процесс тестирования приложений может включать тесты различных типов. Можно регулярно проводить автоматическое тестирование функциональности без дополнительных затрат. Например, можно на ночь запускать тестирование сборки на всех устройствах, а утром анализировать результаты и исправлять ошибки.
Автоматическое тестирование приложений для Android
Рассмотрим несколько средств для автоматического тестирования функциональности, которые входят в состав Android SDK или распространяются с открытым исходным кодом.
Принцип автоматического тестирования приложений
Наша задача — с наибольшей точностью автоматизировать действия, выполняемые вручную. Рассмотрим эти действия. Будем использовать несколько приложений и несколько устройств с Android. Для каждого приложения и каждого устройства нужно выполнить следующие действия:
Прежде всего необходимо выбрать компьютер, который будет использоваться для запуска автоматических тестов, и установить на нем Android SDK. В данном примере мы используем настольный компьютер с операционной системой Linux*. На каждом устройстве необходимо отключить экран блокировки и увеличить «время перед переходом в спящий режим» до максимального значения. Для некоторых методик тестирования также нужно отключить изменение ориентации экрана. В составе Android SDK предусмотрено две программы для управления устройствами с Android: ADB и monkeyrunner* ADB (Android Debug Bridge) — это программа командной строки для управления устройствами с Android.
Методы автоматического тестирования Android
Тестирование с помощью Monkey*
Предположим, что тестируемое устройство попало в лапы крайне любопытной и деятельной обезьяны: программа Monkey имитирует именно такую ситуацию. Программа Monkey, входящая в состав Android SDK, отправляет поток случайных действий пользователя. В командной строке можно указать количество действий пользователя, долю действий каждого типа и имя пакета (чтобы программа Monkey не вышла за пределы тестируемого приложения и не начала, к примеру, рассылать SMS-сообщения всем контактам из адресной книги).
Основное преимущество Monkey в отсутствии затрат на обслуживание. К тому же нагрузочное тестирование может выявлять сложные и малозаметные ошибки.
Недостатки тестирования с помощью Monkey:
Автоматическое тестирование с помощью Monkey можно считать неплохой начальной проверкой для любого приложения. Этот метод может дать достаточно полезные результаты для определенного приложения. Но при низком качестве тестирования следует использовать другие методы.
Тестирование с помощью MonkeyRunner
MonkeyRunner позволяет не только создавать сценарии для управления устройствами с Android, но и создавать сценарии для тестирования приложения на определенном устройстве. Основное преимущество – гибкость, а недостаток в сложности написания скриптов, даже в простых случаях. Создание скриптов monkeyrunner занимает немало времени, поэтому обычно этот метод использовать нецелесообразно. Но в некоторых случаях его применение может оказаться весьма полезным.
Тестирование с помощью getevent и sendevent
Программы getevent и sendevent позволяют пользователю записывать последовательность действий и затем воспроизводить ее. Для запуска этих программ не требуются права доступа root.
Тестирование с помощью Robotium
Robotium не входит в состав Android SDK, эта программа распространяется с открытым исходным кодом. Сценарии Robotium определяют действия на уровне пользовательского интерфейса приложений, а не на уровне устройства ввода. Например, в сценарии требуется коснуться кнопки «ОК». В этом случае скрипт monkeyrunner будет построен следующим образом: «имитировать касание экрана в точке с координатами (x0, y0)». Скрипт Robotium будет построен иначе: «нажать кнопку с текстом «ОК».
Описание действий на уровне интерфейса позволяет сделать тестовый скрипт независимым от расположения и размеров элементов интерфейса, разрешения и ориентации экрана. Кроме того, в Robotium можно проверять реакцию приложения на действия. Например, предположим, что после нажатия кнопки «ОК» должен появиться список с элементом «Элемент 1». В Robotium можно проверять имена элементов списков. Проверка состояния приложения после каждого шага позволяет с легкостью находить шаг, на котором произошла ошибка.
В целом, Robotium позволяет создавать тестовые сценарии высшего качества с разумными затратами.
Сравнение методов тестирования мобильных приложений
| Метод тестирования | Преимущества | Недостатки |
| Monkey — поток случайных действий пользователей | Затраты на обслуживание отсутствуют. |
Независимость от устройства.
Нагрузочное тестирование может выявлять сложные и малозаметные ошибки.
Сложно воспроизводить последовательность действий, вызвавших ошибку, в отчетах об ошибках.
Monkey не проверяет состояние приложения во время тестирования.
При смене интерфейса приложения необходимо переделывать последовательность событий.
Этот метод не проверяет состояние приложения во время тестирования.
Скрипт может не зависеть от разрешения и ориентации экрана.
Скрипт может проверять состояние приложения после действий.
При изменении интерфейса приложения необходимо переделывать скрипт.
Автоматическое тестирование не заменяет другие типы тестирования. Продуманный процесс тестирования, сочетающий различные методы, в том числе и автоматическое тестирование, является важнейшей частью процесса разработки высококачественных приложений.
Ручное тестирование Android приложений
Рассмотрим ручное функциональное тестирование. Тестировщик устанавливает на устройство приложение, вдумчиво проверяет всю функциональность, затем возвращает устройство в первоначальное состояние. И так для каждого приложения и каждого устройства. Очевидный недостаток такого способа – большие затраты времени для регулярного тестирования.
Тестирование мобильных приложений существенно отличается от тестирования приложений, предназначенных для использования на персональных компьютерах. Приведем ряд основных моментов, которые нужно протестировать:
Как показывает практика тестирования мобильных приложений, наиболее корректной работы приложения можно добиться при ручном тестировании на реальных мобильных устройствах.
Особенности альфа/бета тестирования в консоли разработчика Google Play
В консоли разработчика Google Play можно выбирать группы пользователей для альфа- и бета-тестирования различных версий приложения, после чего поэтапно внедрять обновления.
Что нужно знать перед началом тестирования
В аккаунте разработчика доступны инструменты для альфа- и бета-тестирования различных версий вашего приложения. Тестирование приложения возможно без публикации рабочей версии APK-файла. Обратите внимание на следующую информацию:
Мы рекомендуем начать с маленькой группы альфа-тестировщиков, а затем перейти к бета-тестированию с участием большего количества пользователей. Файлы дополнений можно тестировать с помощью альфа-канала распространения в консоли разработчика. Для тестирования нельзя использовать черновики, то есть файл APK должен быть опубликован как альфа-, бета- или рабочая версия. Файлы дополнений нельзя добавлять для первого загруженного файла APK нового приложения.
Компания GETBUG помогаеn обеспечить корректную и стабильную работу мобильного приложения на целевых устройствах, сделать его удобным для пользователя и оптимизировать производительность как самого мобильного приложения, так и мобильного решения в целом.
Тестирование приложений с Android Studio: режим разработки и виртуальная машина
Android Студия является наиболее полной IDE программирования для разработки приложений для операционной системы Google. В нем мы можем найти все библиотеки, полную помощь для создания кода и даже всевозможные инструменты, такие как отладка или компиляция, которые помогут нам внести последние штрихи в наши программы. Перед публикацией заявки в Гугл игры Store, необходимо проверить, что он работает правильно. И вот как мы можем это сделать благодаря этой IDE.
Что нам нужно для тестирования приложения для Android
Если мы собираемся протестировать это на физическое устройство Android (мобильный телефон, планшет и т. д.) очень важно, чтобы он был относительно новым (поскольку, если он старый и не обновленный, он может не работать в зависимости от настроенного нами SDK) и обновлен до современного версия Android. Наверняка у многих из нас есть дома мобильный телефон с Android Ginger или Ice Cream. Это, конечно, совсем не рекомендуется. Нам также понадобится USB-кабель для подключения телефона к компьютеру и в настройках разработчика включить «USB-отладку». Для работы может потребоваться установка OEM-драйверов производителя.
Тестируйте и отлаживайте приложения с помощью Android Studio
Далее мы увидим, как мы можем тестировать приложения Android из Android Studio как на реальном мобильном устройстве, так и на виртуальной машине, которую мы можем создать благодаря включенному в нее эмулятору.
Скомпилируйте приложение прямо на смартфоне
Если у нас есть новый мобильный телефон, это лучший метод отладки, который мы можем выбрать. Благодаря ему мы можем получить очень точное представление о том, как приложение будет работать на реальном смартфоне, что трудно понять в виртуальных машинах, которые мы можем создать.
Если беспроводное соединение доставляет нам проблемы, то лучше использовать отладку по USB.
Создайте виртуальную машину с эмулятором Android Studio
Эмулятор Android Studio, который по умолчанию включен в IDE, позволит нам тестировать наши приложения на многих устройствах и версиях Android одновременно. Вместо того, чтобы иметь много телефонов дома или в офисе, каждый из которых настроен по-своему, мы можем делать все это благодаря этим виртуальным машинам.
Если у нас есть виртуальные машины, они появятся в новом открывшемся окне. В противном случае мы увидим кнопку для запуска мастера для создания новой виртуальной машины Android.
Мы можем выбрать любой из уже созданных в стандартной комплектации смартфонов с собственными характеристиками (размер, экран, память и т. Д.) Или создать собственный смартфон с теми характеристиками, которые нам нужны.
На следующем шаге мы можем выбрать версия Android что мы хотим, чтобы наша виртуальная машина была. Помимо имени и версии, которой оно соответствует, мы также можем увидеть уровень API, которому он соответствует. Это важно, поскольку приложение с API 30 (например) не будет работать в версиях до Android 11. Но, наоборот, будет. Если у нас нет загруженного образа Android, мы можем загрузить его на этом же этапе.
Даем имя, которое хотим ВМ, проверяем правильность настроек и все. Нажав на «Готово», вы создадите виртуальную машину.
Наш виртуальный мобильный телефон уже отображается в списке AVD Manager. И чтобы запустить виртуальную машину, нам просто нужно нажать кнопку «Воспроизвести», которая появляется справа от нее. Через несколько секунд Android будет запущен.
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Тестируем Android-приложение правильно
Меня зовут Андрей Рыжкин, я CTO AGIMA.
Сегодня я расскажу о том, как мы тестируем приложения на Android, а также поделюсь нашим чек-листом.
Чек-лист от команды AGIMA
В 2020 году количество приложений для Android вплотную приблизилось к трём миллионам (по данным Appbrain на 28 марта). И это число продолжает расти – каждый день появляются сотни новых программ для этой операционной системы. В том числе благодаря AGIMA. Мы создаем самые разные приложения для Android – простые и сложные, узкоспециализированные и «для всех». И можем немало рассказать о нюансах их разработки.
Конечно, главное в Android-приложении – его функционал. Недочеты вёрстки редко бросаются в глаза, но качество любого продукта – в мелочах. Поэтому мы всегда тщательно тестируем приложения перед запуском. А для того, чтобы тестирование занимало минимум времени и приносило максимум пользы, мы разработали специальный чек-лист, которым рады поделиться с вами!
Но сначала перечислим шесть наиболее распространенных проблем вёрстки, избежать которых поможет наш чек-лист.
1. Сдвиг элемента страницы
При вёрстке страницы можно применить три вида выравнивания по вертикали (Align Top, Align Middle и Align Bottom) и три – по горизонтали (Align Left, Align Center, Align Right). Но если использовать их несогласованно, отдельные элементы страницы начинают «съезжать» со своих мест.
На рисунке слева всё хорошо, но стоит изменить разрешение – и заголовок сдвигается вправо.
2. Обрезка текста
Проблема появляется, когда компоненты GUI пытаются сжать, чтобы «втиснуть» в маленький экран.
Слева всё в порядке, справа часть текста обрезана из-за изменения ориентации устройства.
3. Отсутствие элемента страницы
При снижении разрешения экрана элементы увеличиваются в размере. И при неправильной вёрстке некоторые из них могут просто «исчезнуть».
4. Пересечение элементов
Иногда, также при снижении разрешения или уменьшении размера экрана, компоненты GUI «наезжают» друг на друга. В итоге на странице воцаряется полный хаос.
5. Выход элементов за границы экрана
Причина всё та же – при изменении разрешения элементы страницы увеличиваются, и экрана банально «не хватает» для их отображения. В итоге страница ужасно выглядит (и это в лучшем случае, в худшем ей становится просто невозможно пользоваться).
6. Артефакты адаптивного дизайна
При увеличении разрешения экрана может возникнуть «обратная» ситуация – компоненты GUI и текстовые символы могут уменьшиться до абсолютно нечитабельных размеров.
Согласно Material Design, размер любого элемента, с которым взаимодействует пользователь, будь то кнопка, чекбокс или радиобаттон, не должен составлять меньше 48 пикселей по любому измерению.
Гайдлайн не дает четких рекомендаций по размеру текста, однако по результатам исследования комфортным считается шрифт в 16 пикселей высотой, а приемлемым для чтения – 12-14 пикселей.
Перечисленные проблемы часто «наслаиваются» друг на друга – как известно, беда не приходит одна. И результаты таких сочетаний могут быть самыми непредсказуемыми. Но это – тема для отдельной статьи.
А теперь – обещанный чек-лист. Используйте его во время тестирования Android-приложения – и от вас не «ускользнет» ни одна ошибка!
Чек-лист
Запуск и выход из приложения:
Вёрстка (на всех заявленных в ограничениях устройствах и разрешениях):
И напоследок важный вопрос для всех читателей. Какие пункты вы добавили бы к нашему чек-листу? Будем рады вашим идеям!
Статья написана с ex-head QA AGIMA Рамилем Усмановым.