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