Привет! Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.
Нефункциональные проверки играют ключевую роль в обеспечении качества, удобства использования и стабильности продукта. В сети можно найти множество чек-листов и статей на эту тему, но зачастую проверки, описанные в них, либо избыточны, либо устарели. Более того, редко где объясняется, зачем проводить те или иные тесты и какие процессы происходят «под капотом» приложения.
В этой статье я не только разберу основные нефункциональные проверки, но и расскажу, что происходит с приложением в моменты, когда, например, вы сворачиваете его или выключаете экран – не взаимодействуете с телефоном. Часть тестов применима к обеим платформам, а некоторые актуальны только для Android или iOS. Примеры всех багов взяты из личного опыта тестирования.
Нефункциональные проверки можно разделить на следующие категории:
● Обновление приложения
● Прерывания
● Сеть
● Интерфейс
● Прочее
Обновление приложения
Обновление через магазин приложений
После обновления через App Store или Google Play необходимо проверить:
● Сохранность настроек и пользовательских данных
● Непрерывность авторизационной сессии
Обновление через установочный файл (APK)
Для Android возможно распространение приложения через установочный файл (.apk).
Важно проверить:
● Корректность обновления через APK-файл
● Совпадение подписи установленного на телефоне приложения и APK-файла.Если подписи различаются, например, из-за ошибки разработчика, обновление не произойдет.
Обновление через несколько версий
Если пользователь обновляется, например, с версии 1.0 сразу до 4.0, могут возникнуть проблемы:
● Потеря данных или настроек
● Некорректная работа отдельных модулей
● Ошибки из-за архитектурных изменений или нарушения обратной совместимости
Примечание: Установка и удаление приложения контролируется операционной системой, поэтому отдельное тестирование не требуется.
Прерывания
Входящий звонок при работающем приложении
Когда приложение работает и поступает входящий звонок, необходимо проверить, что после его завершения оно возвращается в прежнее состояние без потери данных и продолжает работу с того экрана, на котором пользователь был до звонка.
Для понимания этой проверки нужно знать, что происходит с приложением в момент звонка, а для этого надо разобраться в понятии Activity и его жизненном цикле.
Activity — это основной компонент как в Android, так и в iOS-приложениях, который отвечает за экраны приложения и их состояния. Можно сказать, что Activity — это «экран» в приложении, который взаимодействует с пользователем. Каждый экран (или Activity) имеет свой жизненный цикл, то есть набор состояний, через которые он проходит во время работы приложения.
Жизненный цикл Activity:
● Android: Когда приложение активно и пользователь взаимодействует с ним, состояние Activity находится в onResume. Когда поступает входящий звонок, приложение переходит в состояние onStop, что фактически означает, что его экран перекрывается другим приложением (в данном случае экраном звонка). После завершения звонка приложение должно вернуться в состояние onResume, и пользователь должен быть возвращен на тот же экран, с которого приложение было приостановлено, без потери данных и с сохранением состояния.
● iOS: Система iOS работает по аналогичному принципу. Когда приложение активно, оно находится в состоянии active. При поступлении звонка оно переходит в состояние inactive. После завершения звонка приложение должно вернуться в активное состояние и продолжить работу с того места, где оно было приостановлено.
Важно отметить, что не имеет значения, какое приложение перекроет ваше, это не обязательно должен быть звонок. Однако проверка с входящим звонком дополнительно помогает тестировать передачу аудио фокуса.
Передача фокуса звука — это процесс, при котором приложение, воспроизводящее звук (например, музыку), передает управление звуком другому приложению, когда это необходимо.
Пример: вы слушаете музыку и приходит push. В этот момент музыка приглушается, вы слышите звук уведомления. Это и есть передача фокуса звука.
На Android передача аудио фокуса строго регулируется операционной системой, начиная с Android 12. До этой версии могут быть проблемы с передачей фокуса, например, два приложения могут одновременно воспроизводить звук, либо одно приложение может не передавать фокус звука другому, что приведет к отсутствию звука уведомлений, звонков и т.д. Поэтому, если ваше приложение связано с проигрыванием контента, эту проверку необходимо проводить
Полезные ссылки:
Жизненный цикл activity (android)
Официальная документация по аудиофокусу
Системное уведомление во время работы приложения
Во время работы приложения могут появляться системные уведомления, например, о низком заряде батареи, обновлениях системы или ошибках. Они частично перекрывают экран и их невозможно смахнуть. Важно проверить, как приложение себя ведет в такие моменты.
Когда появляется системное уведомление, фокус переключается с приложения на системный интерфейс, и Activity приложения переходит в состояние onPause в Android и inactive в iOS. Важно убедиться, что после закрытия уведомления приложение возвращается в прежнее состояние без потери данных и ошибок, и что пользователь может продолжить работу с того места, где он был до появления уведомления.
Эта проверка менее востребована, поскольку системные уведомления возникают сравнительно редко.
Переход в спящий режим при работающем приложении
Спящий режим — это специальный режим энергосбережения, существующий только на платформе Android. Он активируется через некоторое время после выключения экрана и накладывает строгие ограничения на работу приложений:
● Блокирует доступ в сеть и синхронизацию данных
● Запрещает выполнение фоновых задач и отправку уведомлений
● Ограничивает сканирование Wi-Fi сетей
● Блокирует механизмы принудительного включения экрана (WakeLock)
Кроме того, начиная с Android 9, приложения автоматически разбиваются на категории по частоте использования. В зависимости от категории на них накладываются ограничения разной степени жесткости. При этом вендоры (производители устройств) могут самостоятельно управлять этими ограничениями, что делает поведение режима сна непредсказуемым для разных моделей смартфонов.
Нужно ли тестировать спящий режим?
Так как на эти ограничения нельзя повлиять программно, полноценное тестирование режима сна обычно не требуется. Однако понимание его работы помогает в локализации багов:
● Пользователю перестали приходить push-уведомления — одной из причин может быть режим сна, который ограничивает работу приложения в фоновом режиме.
● В приложении не работает синхронизация данных, когда телефон долго находится в состоянии блокировки.
● Push-уведомления о новых сообщениях не приходят, если приложение редко используется.
В таких случаях проблемы могут быть обусловлены, в том числе, ограничениями режима сна и их можно решить, разрешив приложению работать в фоновом режиме. Такая настройка доступна в параметрах энергосбережения на большинстве Android-смартфонов.
Когда необходимо тестировать работу в спящем режиме?
Тестирование спящего режима становится важным, если приложение выполняет критические фоновые задачи, такие как:
● Звонки и VoIP-связь: приложения для звонков
● Воспроизведение музыки и аудио: медиаплееры, стриминговые сервисы
● Отслеживание геопозиции: навигационные и фитнес-приложения
Если приложение относится к одной из этих категорий, необходимо проверить, что в спящем режиме оно продолжает выполнять свои ключевые функции, так как данные процессы не блокируются режимом сна.
Пример бага: Музыкальный плеер после перехода телефона в спящий режим перестает воспроизводить музыку.
Полезные ссылки:
Таблица ограничений в спящем режиме в Android
Информация по работе режима сна и режима ожидания в Android
Переход в другое приложение и возврат
При сворачивании приложения кнопкой "Домой" или переключении на другое приложение через "Обзор приложений" необходимо убедиться, что после возвращения, приложение:
● Восстанавливает состояние без потери данных
● Возвращает пользователя на тот же экран
● Не вызывает ошибок или визуальных артефактов
При сворачивании, Activity приложения переходит в состояние onStop (Android) или inactive (iOS).
Эта проверка включает два ключевых аспекта:
а. Кратковременное сворачивание и возврат
Приложение сворачивается и разворачивается сразу или через небольшой промежуток времени. Здесь возможны абсолютно любые баги, вплоть до крашей.
Пример бага: при использовании камеры в приложении, после сворачивания и возврата видим черный экран вместо режима камеры.
Кратковременное сворачивание — один из самых распространенных сценариев использования, так как пользователи постоянно переключаются между приложениями, поэтому данная проверка крайне востребована.
б. Длительное пребывание в фоновом режиме
Через некоторое время после сворачивания приложения, операционная система может выгрузить его из памяти, чтобы освободить ресурсы.
В этом случае проверяем:
● Если приложение выгружено, оно должно корректно восстановить данные при повторном запуске
Важно помнить, что по умолчанию приложения не сохраняют свое состояние после выгрузки. Это должно быть реализовано разработчиками, поэтому перед тем как заводить баг, уточните, предусмотрена ли в приложении логика восстановления состояния после выгрузки.
Как ускорить тестирование?
● В Android можно включить настройку "Не сохранять Activity" в панели разработчика — тогда приложение будет сразу выгружаться при сворачивании.
● В iOS придется подождать некоторое время или открыть несколько других приложений, чтобы система быстрее выгрузила тестируемое приложение из памяти.
Навигация по приложению с помощью кнопки "Назад"
При нажатии кнопки "Назад" осуществляется переход на предыдущий экран с сохранением его состояния, а текущий экран выгружается из памяти без сохранения данных. Это стандартное поведение для обеих платформ — Android и iOS. Эта проверка особенно важна, если на экране, к которому мы возвращаемся, есть:
● Видео — может не возобновиться с нужного момента или не загрузиться
● Таймеры и индикаторы прогресса — могут сброситься или замереть
● Анимации — могут перестать воспроизводиться или зависнуть
Пример бага: пользователь просматривает список товаров, переходит в карточку конкретного товара и после нажатия "Назад" список загружается с самого начала, а не с той позиции, где находился пользователь.
Важно: Все тесты, связанные с изменением состояния Activity, необходимо проводить на каждом экране приложения.
Сеть
Попытка совершения запроса без интернета
При совершении запроса в приложении с отсутствующим интернетом необходимо проверить следующее:
● Отображается понятное уведомление о проблеме с сетью
● Приложение не зависает
● Если предусмотрен автоповтор запроса, он должен срабатывать корректно при восстановлении соединения
● Офлайн-данные должны отображаться без сбоев
Отключение сети во время загрузки
Проверка актуальна для стриминговых сервисов и приложений, загружающих контент. Она моделирует следующую ситуацию: во время загрузки контента теряется интернет-соединение, после восстановления сети необходимо проверить что:
● Воспроизведение или загрузка контента возобновляется
● Контент загружается полностью и без повреждений
Пример бага: музыкальный плеер при потере соединения не возобновляет загрузку плейлиста, а файлы оказываются не до конца загруженные (битые).
Работа при медленном интернете
Проверяем, что приложение отрисовывает интерфейс и выполняет функции, даже при низкой скорости соединения:
● Все элементы UI загружаются корректно.
● Кнопки и функции работают, даже если контент подгружается медленно.
Пример бага: в потоковом радио кнопка Play не работает, потому что загрузился UI, но скрипт его работы не успел подтянуться.
Данная проверка более актуальна для гибридных приложений или PWA, работающих через веб-технологии.
Обработка ошибок бэка (500, 400)
Проверяем, как приложение реагирует на ошибочные ответы сервера (можно имитировать через сниффер): корректные сообщения об ошибках и отсутствие крашей. Не стоит путать первую проверку с последней – они разные, так как первый случай подразумевает полное отсутствие ответа от сервера, второй – получение неожиданного ответа.
Проверка UI и взаимодействия с приложением
Работа со списками
● Быстрое пролистывание длинных списков не должно вызывать фризы и зависания
● Конец списка не уходит за границы экрана
● Элементы списка не накладываются друг на друга
Ввод данных и нажатия
● Экранная клавиатура не должна перекрывать поля ввода. Особенно важно учитывать нестандартные клавиатуры, например, с увеличенным размером.
● Множественный выбор не должен вызывать баги или краши. Приложение может неправильно обрабатывают одновременные касания.
● Повторные нажатия на кнопки, особенно отправляющие запросы на сервер, не должны приводить к дублированию запросов или падению приложения.
Изменение ориентации экрана
● Если приложение поддерживает работу в разных ориентациях, то при смене ориентации (портретная/альбомная) приложение сохраняет текущий экран и данные. Во время поворота экрана Activity проходит все стадии жизненного цикла, поэтому важно убедиться, что приложение не зависает, не теряет введенные данные и не выдает ошибки при смене ориентации.
Темная тема
● Если приложение поддерживает темную тему, при ее включении все элементы должны корректно адаптироваться. Переключение темы вызывает перезапуск Activity, что потенциально приводит к багам и крашам.
Масштабирование шрифтов
● Проверяем, как приложение реагирует на изменение размера шрифта в настройках ОС. Если приложение использует размер шрифта “как в системе”, текст не должен выходить за границы полей и оставаться читаемым.
Навигация и жесты
● В устройствах с жестовой навигацией важно проверить, что элементы приложения не конфликтуют с системными жестами (свайп "назад" не мешает перелистыванию каруселей).
● После смены типа навигации с кнопок на жесты интерфейс должен корректно адаптироваться — не должно быть пустого места на экране там, где были кнопки.
Адаптация верстки
● Интерфейс должен отображаться корректно на экранах разной ширины. Обе OS используют независимые пиксели (dp/sp), поэтому важно проверять, как приложение масштабируется на разных устройствах.
Подробнее о разных размерах экранов:
Поддержка разных размеров экранов в Android
Поддержка разной плотности пикселей в Android
Адаптивный дизайн в Android
Прочие проверки
Работа приложения при отсутствии разрешений
Если приложение не имеет доступа к камере, уведомлениям, хранилищу и другим системным ресурсам, должно появляться корректное уведомление с возможностью включения разрешений. Приложение не должно падать или зависать, если доступ к важным функциям ограничен.
Работа при нехватке памяти
Если на устройстве не хватает свободного места, приложение должно уведомлять пользователя о проблеме. Должны быть предусмотрены варианты действий, например, отмена загрузки контента или предложение освободить место.
Совместимость с разными версиями ОС
Некоторые функции могут не работать на старых или новых версиях ОС, приводя к багам и крашам. Обновления ОС могут изменять работу API, поэтому важно тестировать приложение на нескольких версиях Android и iOS.
Тестирование на оболочках разных вендоров
Производители мобильных устройств, такие как: Samsung, Xiaomi, Huawei и др., устанавливают свои оболочки (One UI, MIUI, EMUI и др.), которые могут изменять работу системных функций. Некоторые баги проявляются только на устройствах определенного бренда, поэтому важно проверять работу приложения на популярных моделях.
Вывод
Нефункциональное тестирование мобильных приложений — это важный этап обеспечения качества продукта, который напрямую влияет на удобство использования, стабильность и производительность приложения.
В статье были рассмотрены ключевые аспекты нефункциональных проверок, такие как обновление приложения, обработка прерываний, работа в условиях нестабильной сети, корректность интерфейса и адаптация к различным условиям эксплуатации. Регулярное проведение таких проверок позволяет создавать стабильные, удобные и надежные приложения, которые удовлетворяют потребностям пользователей и соответствуют современным стандартам качества.