Особенности тестирования мобильных приложений

Виды мобильных приложений, их плюсы и минусы

Web приложения

Веб-приложения представляют собой адаптированные веб-сайты, которые открываются через браузеры.

Пользователь не скачивает приложение и не хранит его на своем устройстве. Если его «скачивают», скорее всего, речь идет о том, что оно добавляется в закладки браузера.

Одним из самых распространенных подвидов считают PWA — прогрессивные веб-приложения, которые, по сути, являются нативными приложениями внутри браузера.

Сложно выделить примеры, чтобы не ошибиться. Разные источники приводят в пример Google Maps, программы Microsoft Office.

Плюсы

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

Минусы

• Веб-приложения зависят от браузера. И функции, которые доступны в одном браузере, могут не поддерживаться в другом. Это означает, что пользовательский опыт будет отличаться.
• Веб-приложения не работают без подключения к интернету.
• Не имеют доступа к ресурсам мобильного устройства, в связи с этим имеют ограниченную функциональность.

Нативные приложения

Нативные мобильные приложения — самый распространенный и дорогой в разработке вид, так как создается отдельно для каждой ОС (iOS, Android или другие).

Когда мы говорим о мобильных приложениях, чаще всего имеем в виду именно нативные. Pokemon Go, Spotify и многие другие являются именно нативными приложениями.

Плюсы

• Высокая производительность (скорость работы и надежность). Это связано с тем, что приложение создается для каждого ОС с учетом его особенностей. В итоге это обеспечивает пользователю позитивный опыт взаимодействия.
• Доступ к аппаратной части устройства (геолокации, камере, микрофону, акселерометру, датчикам освещенности, календарю, push-уведомлениям) и широкий функционал за счет этого; Это тоже упрощает и улучшает пользовательский опыт.
• Adjust упоминает, что нативные приложения еще и более безопасны с точки зрения защиты данных пользователя.
• Нет ограничения функционала скоростью и качеством Интернет-соединения, приложение может работать без выхода в сеть;
• Можно распространять через магазин проложений.

Минусы

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

Гибридные приложения

Название говорит само за себя: это веб-приложения, которые выглядят как нативные и имеют их признаки.

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

Среди гибридных приложений выделяют Uber, Evernote. Некоторые источники относят к гибридам и Instagram.

Плюсы

• Более бюджетная и быстрая разработка по сравнению с нативными.
• Более быстрая загрузка — это хорошее преимущество для пользователя и возможность улучшения пользовательского опыта.
• Возможность взаимодействия с ОС устройства.
• Есть встроенный браузер.
• Можно распространять через магазин прилодений.
• Мультиплатформенные.

Минусы

• Все равно не такая хорошая производительность, как у нативных приложений.
• Ограниченный доступ к ресурсам мобильного устройства.
• Не полностью автономны, нужно подключение к интернету.

Отличия web и mobile тестирования

1. Мобильные устройства можно переносить, в связи с этим появляются свои особенности, меняется геолокация и т.д.
2. У мобильных устройств высокая фрагментация (много устройств на которых можно использовать приложение) и больше пользователей
3. Мобильные прилодения имеют ограничения в ресурсах (оперативной и постоянной памяти)
4. Разное взаимодействие в отлечие от web'a (tap, swipe и т.д.)
5. Разное поведение с подкючением к интернету и без подключения.

Тестирование mobile приложений

1. Выбор устройств. Из всего зоопарка устройств нужно выбратьустройства для тестирования. Для этого можно обратиться к статистике и аналитике по использованию вашего приложения, если такой статистики нет то моно обратиться к статистике google илии apple.

2. Размеры экрана и touch интерфейс

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

3. Ресурсы устройства

• кейсы с утечкой памяти;
  • можно проверить с помощью программы Instruments (стандартное приложение MacOS). Может быть не более 30мб на 2г айфон/айпод, примерно 70мб для всех девайсов до 2-го айпада
  • уделить внимание окнам с большим количеством информации, при длительном пребывании пользователя в приложении
• кейсы, когда не хватает памяти для установки и работы приложения;
• кейсы, когда не хватает памяти для обновления и работы приложения;
• кейсы, когда переносим или устанавливает приложение на sd карту;

4. Разрешения экрана и версии ОС

• можно столкнуться с ошибками верстки;
• на разных разрешениях приложение зачастую выглядит по разному;
• кейсы с портретной и альбомной ориентацией устройства;

Если приложение работает с разными форматами файлов то нужно проверять все эти форматы, чтобы приложеине корректно работало с каждым.

5. Реакция на внешнее прерывание Внешние прерывания:

• входящие/исходящие звонки/сообщения/смс/ммс/напоминание/нотификацию ;
• уведомления от других приложений;
• разрядка устройства, переход устройства в энергосберегающий режим, переход устройства в режим ожидания, смена ориентации в режиме ожидания;
• кейсы с разными подключениями (с разными сетями: wi-fi, 3G);
• при включенной/отключенной функции bluetooth, геопозиция, режим полета, функции где используется камера;
• кейсы с потерей связи;
• кейсы с зарядкой устройства(разряд/изъятие батареи);
• с извлечением/подключением sd карты/кабеля/зарядки;
• закрыть приложение для того, чтобы открыть какое-то другое на некоторое время и вернуться к вашему приложению позже;
• послать девайс в сон на некоторое время.

6. Доступ к связи

• позитивный кейс (наличие отличной постоянной связи);
• наличие постоянной неотличной связи;
• отсутствие связи;
• потеря связи;

7. Постоянная мобильность

• Крэш в приложении при попытке восстановить приложение из бэкграунда с предварительной сменой ориентации экрана;
• Крэш в приложении при “потряхивании” девайса в момент совершения этим девайсом фотосъёмки (приложение изначально создавалось для создания фото);

8. Проверка работы приложений на ретина экранах и различных версия OS

• корректное отображение различных элементов на экранах ретина/не ретина
• установка приложения на корректную версию OS
• проверить установку на все возможные девайсы
• различные функции на девайсах: отсутствие/наличие камеры(ipad) (автофокуса), отсутствие/наличие GPS

9. Проверка типа покупок (восстанавливаемые, не восстанавливаемые)

• проверка соответствия фактической/заявленной стоимости приложения
• проверка восстановления покупки независимо от девайса, а с привязкой к учетной записи

10. Проверка работы обратной связи

• сообщения при загрузке контента/прогресс
• сообщения при ошибке доступа к сети
• наличие сообщений при попытке удалить важную информацию
• наличие экрана/сообщения при окончании процесса/игры (экран Game over)

11. Проверка работы обновлений

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

12. Реклама в мобильном приложении

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

13. Проверка локализации

• на другом языке на экране должно хватить места для текста
• даты должны соответствовать формату установленного региона
• временные настройки должны быть соблюдены

14. Проверка энергопотребления

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

Жизненный цикл приложения

Когда мы тестируем кейсы на прерывание мы проверяем как правильно приложение работает с жизненным циклом.

Обратная связь с пользователем

У всех элементов нажатых пользователем должно быть соответсвующее состояние благодаря этому пользователь видит действительно ли нажатие случилось или нет.

Также нужно смотреть на отклик(реакция на нажатие), есть ли какая то скорость отклика она не должна быть достаточно быстрой и не должна быть достаточно медленной. При таком тестировании желательно использовать не самые топовые устройства(девайсы).

Когда загружаем какой нибудь контент нужно использовать прогресс бар чтобы пользователь видел что идет загрузка.

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

Должны быть четкие и понятные сообщения об ошибках. Чтобы пользователь понимал чтоо ему нажимать, вдруг он удаляет какую то важную информацию. Текст сообщения должен быть крайне понятным и простым.

Также если используются уведомления на экране, например о покупках, можно использовать звуки и вибрацию. Звуки, вибрация и уведомления должны быть синхронизированы между собой, такой кейс тоже надо проверять.

Настройки разработчика в Android

В Android и iOS есть специальный режим разработчика, это список настроек/параметров которые мы можем использовать при тестировании.

Например:

• Профиль обработки GPU - показывает насколько быстро рисуется интерфейс нашего приложения. Если будет выше зеленой линии значит не все так гладко с интерфейсом.

• Показывать ограничения макета - показывает как все элементы расположены относительно друг друга. Если мы тестируем верстку можно включить этот режим и сравнить с макетом.

• Параметр "Отладка" - используется при дебаге.

• Параметр "Конфигурация USB" - как подключаться для отадки, для зарядки, для передачи файлов.

• Параметр "Не сохранять операции"("Do not keep activities") - используется для тестирования жизненого цикла. При включении этого параметра при навигации в новый экран предыдущий экран уничтожается, если мы снавигируемся назад то приложение падает.

для iOS есть такой же режим:

• Параметр "Network Link Conditioner" - для тестирования с разным качеством связи(3G, LTE и т.д.) и с возможностью задавать собственные профайлы, кастомные со своими параметрами какая нам сеть нужна.

Помощь при релизах

Beta версии

iOS

Перед релизами можно использовать beta версии. Для iOS для этих целей можно использовать TestFlight, релиз выкладываетя и пояляется в TestFlight и далее смотрится как поведет себя приложение.

Android

Нечто похожее также имеется и на Android. Также используется Beta testing версии для внутреннего тестирования.

Выпуск автоматических обновлений

iOS

Также в iOS есть функция поэтапного выпуска автоматических обновлений. Если включается этот параметр то в течение недели наше обновление будет выкатываться с 1% пользователей до 100%, каждый день постепенно увеличиваясь.

Android

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

Если мы желаем поэтапный релиз для iOS то мы можем его только остановить но не поменять проценты или другие настройки, в Google Play можно указать процент - сколько пользователей нужно от общего количества, в любой момент остановить и в любой момент продолжить, в любой момент поменять этот процент.

Отчеты о тестировании

Также в Google Play есть отчеты о тестировании. Когда вы загружаете свой apk файл и публикуете, через некоторое время там появится отчет о тестировании этой версии.

Google на своей фабрике устройств тестирует нашу apk, в течении ~ 10 минут и в итоге выдает отчет по разным параметрам: по безопасности, будут видны краши если они были, видно на каких устройствах тестировалось, видно скриншоты и запись видео в том случае если что то пошло не так.

Чек-лист тестирования мобильных приложений:

• Геолокация.
• Работа приложения в разных режимах: 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.

Источник:

1. ❗ «Особенности тестирования мобильных приложений», Игорь Плотников
2. ❗ Мобильное тестирование, автоматизация и тестирование API: С чем нужно уметь работать тестировщику в 2021 году