Мобильное приложение живёт в гораздо более хаотичной среде, чем сайт. Сотни моделей устройств, разные версии операционных систем, нестабильная связь, входящие звонки, переключение между приложениями, разряжающаяся батарея, крупный шрифт в настройках — всё это влияет на то, как приложение работает у реального пользователя. Ошибка, которую не заметили при тестировании, превращается в гневный отзыв с одной звездой, а исправление требует нового релиза и, возможно, повторной модерации.
В этой статье расскажем, что именно мы проверяем перед выпуском приложения, как устроен процесс тестирования и как выстроить его так, чтобы релизы проходили спокойно.
Почему тестирование мобильных приложений сложнее
Есть несколько особенностей, которые отличают мобильное тестирование от веб-тестирования:
- Фрагментация устройств. Особенно на Android: разные производители, размеры экранов, объём памяти, системные надстройки, агрессивные режимы энергосбережения.
- Медленное исправление ошибок. Сайт можно обновить за минуты, а приложение — только через новую сборку, модерацию и обновление у пользователя. Часть людей годами не обновляет приложения.
- Взаимодействие с системой. Разрешения, уведомления, фоновые задачи, прерывания — всё это нужно проверять отдельно.
- Нестабильная сеть. Пользователь может потерять связь в любой момент, и приложение должно корректно это обрабатывать.
- Требования магазинов. Помимо собственного качества, приложение должно соответствовать правилам App Store, Google Play и RuStore.
Функциональное тестирование
Основа всего — проверка того, что приложение делает то, что должно, по требованиям и пользовательским сценариям.
Что проверяем:
- Основные пользовательские сценарии от начала до конца: регистрация, авторизация, поиск, оформление заказа, оплата, запись, отмена.
- Граничные случаи: пустые поля, слишком длинный текст, спецсимволы, нулевые и отрицательные значения, отсутствие данных на сервере.
- Обработку ошибок: что видит пользователь, если сервер вернул ошибку, истекла сессия, платёж не прошёл.
- Права и роли: если в приложении есть разные типы пользователей, каждый видит только то, что ему положено.
- Глубокие ссылки и уведомления: нажатие на push или ссылку открывает нужный экран, в том числе когда приложение было закрыто.
- Восстановление пароля, смену данных, удаление аккаунта.
Для каждого релиза составляется набор тест-кейсов. Новые функции проверяются детально, а для ранее работавших проводится регрессионное тестирование — чтобы убедиться, что изменения ничего не сломали.
Тестирование на устройствах
Проверить приложение на всех существующих устройствах невозможно, поэтому формируется матрица — набор устройств, который покрывает основные варианты у вашей аудитории.
При составлении матрицы учитываем:
- Версии ОС. Минимальная поддерживаемая, самая распространённая у ваших пользователей и самая новая.
- Размеры экранов. Компактные телефоны, большие экраны, планшеты (если поддерживаются), устройства с вырезами и закруглёнными углами.
- Производители Android. Самые популярные у вашей аудитории бренды — их надстройки по-разному работают с уведомлениями, фоновыми задачами и разрешениями.
- Производительность. Обязательно хотя бы одно бюджетное устройство с небольшим объёмом памяти: на флагманах многие проблемы просто не проявляются.
Комбинируем реальные устройства, эмуляторы и облачные фермы устройств. Эмуляторы удобны для быстрых проверок, но окончательная проверка критичных сценариев всегда проводится на реальных телефонах.
Если ваши пользователи — курьеры или водители с недорогими смартфонами, тестировать только на флагманах бессмысленно. Матрица устройств должна отражать реальную аудиторию.
Тестирование интерфейса и доступности
- Соответствие макетам: отступы, шрифты, цвета, состояния элементов.
- Адаптивность: интерфейс не ломается на маленьких и больших экранах, в горизонтальной ориентации (если она поддерживается).
- Крупный шрифт: многие пользователи увеличивают размер текста в системе. Тексты не должны обрезаться или наезжать друг на друга.
- Тёмная тема: если поддерживается, все экраны должны выглядеть корректно, без нечитаемых элементов.
- Экранные чтецы: кнопки и элементы должны иметь понятные подписи для VoiceOver и TalkBack.
- Локализация: если приложение многоязычное, проверяем длину строк, форматы чисел и валют.
Тестирование в разных условиях сети
Сеть — один из главных источников проблем. Проверяем:
- работу без интернета: приложение не падает, показывает понятное сообщение, если предусмотрен офлайн-режим — корректно сохраняет данные;
- медленную сеть: есть индикаторы загрузки, запросы не дублируются при повторных нажатиях, таймауты обрабатываются;
- обрыв связи во время операции: например, при отправке заказа или оплате — нет дублирования и потери данных;
- переключение между Wi-Fi и мобильной сетью;
- восстановление связи: несинхронизированные данные отправляются автоматически.
Для этого используются инструменты эмуляции плохой сети и, конечно, реальные проверки — в лифте, в метро, на парковке.
Прерывания и жизненный цикл
Мобильное приложение постоянно прерывается, и это нужно проверять:
- входящий звонок во время заполнения формы или оплаты;
- сворачивание и возврат в приложение — данные не теряются, экран не сбрасывается;
- выгрузка приложения системой из памяти при нехватке ресурсов и последующее восстановление;
- блокировка экрана и разблокировка;
- изменение системных настроек во время работы: отзыв разрешения, смена языка, включение режима энергосбережения;
- низкий заряд батареи и отсутствие свободного места на устройстве.
Производительность
Медленное приложение раздражает не меньше, чем падающее. Что измеряем:
- Время запуска — холодный и тёплый старт.
- Плавность интерфейса — отсутствие подтормаживаний при прокрутке списков и анимациях.
- Потребление памяти — особенно на длинных списках и экранах с изображениями.
- Расход батареи — фоновые задачи, геолокация, частые сетевые запросы.
- Объём трафика — приложение не должно загружать лишнее, изображения должны быть оптимизированы.
- Размер приложения — слишком большой размер снижает количество установок.
Безопасность
Базовые проверки безопасности, которые обязательны для любого приложения с пользовательскими данными:
- данные передаются только по защищённому соединению;
- токены и пароли хранятся в защищённом хранилище системы, а не в открытом виде;
- после выхода из аккаунта данные пользователя удаляются с устройства;
- сессия корректно истекает, а повторная авторизация работает;
- в логах и отчётах о сбоях нет персональных данных и токенов;
- в сборке нет тестовых ключей, адресов тестовых серверов и отладочных функций;
- сервер проверяет права доступа, а не полагается на то, что приложение «не покажет» лишнее.
Для приложений, работающих с платежами, медицинскими или финансовыми данными, проводится расширенное тестирование безопасности.
Автоматизация тестирования
Ручное тестирование незаменимо для новых функций и проверки удобства, но регрессионные проверки выгодно автоматизировать:
- Модульные тесты проверяют бизнес-логику: расчёты, валидацию, преобразование данных.
- Интеграционные тесты проверяют взаимодействие с сервером и базой данных.
- UI-тесты проходят основные сценарии через интерфейс, как пользователь.
- Скриншот-тесты выявляют непреднамеренные изменения внешнего вида.
Автотесты запускаются в системе непрерывной интеграции при каждом изменении кода. Это позволяет находить ошибки сразу, а не перед релизом, и выпускать обновления чаще без страха что-то сломать.
Проверка требований магазинов
Перед отправкой на модерацию проверяем отдельный список:
- все разрешения сопровождаются понятными объяснениями и действительно используются;
- есть функция удаления аккаунта;
- политика конфиденциальности доступна и соответствует реальному сбору данных;
- для проверяющих подготовлен рабочий тестовый аккаунт;
- в приложении нет заглушек, тестового контента и неработающих разделов;
- скриншоты и описание соответствуют текущей версии.
Бета-тестирование и поэтапный релиз
Финальный этап — проверка на реальных пользователях до полного релиза:
- Внутреннее тестирование — команда и заказчик через TestFlight и внутренние треки Google Play.
- Закрытая бета — ограниченная группа лояльных пользователей или сотрудников.
- Поэтапный релиз — обновление получают сначала несколько процентов пользователей. Мониторим сбои и отзывы и только потом раскатываем на всех.
После релиза подключённые системы отчётов о сбоях и аналитики позволяют быстро увидеть проблемы, которые проявляются только на реальных устройствах.
Вывод
Тестирование мобильного приложения — это не одна проверка перед релизом, а набор практик на всех этапах разработки: функциональные проверки, матрица устройств, сеть, прерывания, производительность, безопасность и требования магазинов. Чем раньше ошибка найдена, тем дешевле её исправить.
Хорошее тестирование — это не поиск всех ошибок, а уверенность в том, что ключевые сценарии работают у реальных пользователей на их устройствах.
Тестирование входит в каждый наш проект — от первой сборки до поддержки после релиза. Подробнее о том, как мы работаем, — на странице мобильной разработки, а о сопровождении уже запущенных приложений — в разделе поддержка и развитие.