Тестирование мобильных приложений: с чего начать и что проверять
Мобильное приложение ломается не там, где веб. Логика может быть безупречной, но приложение упадёт от входящего звонка или потеряет данные при сворачивании.
Чем мобильное отличается от веба
Функциональная часть похожа: те же формы, те же сценарии, те же требования. Разница в среде, в которой всё это живёт.
| Веб | Мобильное |
|---|---|
| Вкладка открыта, пока не закроют | Система может выгрузить приложение из памяти в любой момент |
| Сеть обычно стабильна | Обрывы, переключение Wi-Fi и мобильного, туннели, лифты |
| Прерываний почти нет | Звонки, уведомления, будильники, блокировка экрана |
| Разрешений не спрашивают | Камера, геолокация, контакты — и отказ надо обработать |
| Обновление незаметно | Обновление через магазин, старые версии живут годами |
| Экраны разные, но предсказуемые | Сотни устройств, вырезы, жесты, оболочки |
Прерывания — главный источник дефектов
Если проверять только один класс вещей, проверяйте этот. Приложение живёт в среде, где его постоянно отвлекают.
- Входящий звонок во время работы и особенно во время оплаты.
- Push-уведомление поверх экрана.
- Сворачивание и возврат: состояние и введённые данные сохраняются.
- Долгое пребывание в фоне — сессия жива или корректно просит войти заново.
- Приложение выгружено системой из-за нехватки памяти и запущено снова.
- Блокировка экрана во время загрузки или отправки.
- Разряд батареи и переход в режим энергосбережения.
Свернуть приложение на пятнадцать минут и вернуться. Половина дефектов состояния живёт именно здесь: потерянная сессия, пустой экран, сброшенная форма, зависший индикатор загрузки.
Сеть и разрешения
Два блока, которые в вебе почти не проверяют, а в мобильном они обязательны.
Сеть: работа без интернета с понятным сообщением, медленное соединение, обрыв в середине операции, переключение Wi-Fi и мобильного на лету, режим полёта, включённая экономия трафика.
Разрешения: запрос приходит в момент использования и объясняет, зачем; отказ не роняет приложение, а даёт понятный сценарий; отзыв разрешения в системных настройках во время работы обрабатывается. Проверять нужно каждое: камеру, галерею, геолокацию, микрофон, контакты, уведомления.
Особенности платформ
| iOS | Android |
|---|---|
| Свайп от левого края — «назад» | Системная кнопка «назад» обязана работать на каждом экране |
| Устройств меньше, важнее версии ОС | Огромный парк устройств и оболочек |
| Разрешение спрашивают один раз, отказ окончателен | Можно спрашивать повторно, есть «только в этот раз» |
| Строгая модерация App Store | Разные магазины, поддержка старых версий |
Практический вывод: набор устройств для проверки берут не наугад, а по аналитике продукта — какие модели и версии реально у ваших пользователей. Гнаться за полным покрытием бессмысленно.
Инструменты
- Эмулятор и симулятор. Android Studio и Xcode дают виртуальные устройства — годятся для функциональных проверок, но не для жестов, камеры и производительности.
- Реальные устройства. Обязательны для финальной проверки. Одно-два своих плюс облачные фермы, если нужен широкий парк.
- adb logcat — логи Android прямо с устройства. Основной инструмент разбора падений.
- Прокси (Charles, Proxyman) — увидеть запросы приложения так же, как во вкладке Network у веба.
- Отчёты о падениях в системе аналитики — там стек, версия и устройство.
Прокси стоит освоить сразу: как только вы видите трафик приложения, все навыки из веб-тестирования начинают работать — коды ответов, тела запросов, авторизация. Про сами коды — в шпаргалке по HTTP.
Установка и обновление
Отдельный сценарий, который забывают проверять чаще остальных. Обновление устанавливается поверх предыдущей версии, а не на чистое устройство, — и именно там всплывают потерянные данные.
- Установка на чистое устройство проходит без ошибок.
- Обновление поверх старой версии сохраняет данные и авторизацию.
- После обновления не повторяется онбординг и не сбрасываются настройки.
- Миграция данных при смене формата хранения прошла корректно.
- Удаление приложения убирает данные, повторная установка не тянет мусор.
Производительность и ресурсы
В вебе на это смотрят выборочно, в мобильном — всегда: телефон замечает всё сразу, и пользователь тоже.
- Холодный старт не дольше двух-трёх секунд: первый экран важнее всего остального.
- Плавность списков на длинных данных: рывки при прокрутке заметны мгновенно.
- Утечки памяти: переходите между экранами двадцать раз подряд и смотрите, растёт ли потребление.
- Нагрев и батарея: приложение не должно греть телефон в фоне.
- Трафик: картинки в ленте не должны тянуться в полном разрешении.
Отдельно — размер самого приложения и то, как быстро растёт кэш. Приложение, занявшее через месяц два гигабайта, удаляют первым при нехватке места.
С чего начать, если опыта нет
- Возьмите любое приложение на своём телефоне и пройдите по списку прерываний — звонок, сворачивание, обрыв сети. Вы удивитесь, сколько найдётся.
- Установите Android Studio и поработайте с эмулятором: научитесь ставить сборку и смотреть логи.
- Освойте
adb logcat— хотя бы фильтрацию по имени приложения. - Настройте прокси и посмотрите на трафик приложения: это мостик от веб-тестирования к мобильному.
- Оформите найденное по шаблону — получится первый блок мобильного портфолио.
Полный список проверок, который можно распечатать, — в чек-листе мобильного приложения.
Нужен ли iPhone для тестирования iOS?
Для полноценной проверки — да, симулятор не воспроизводит жесты, камеру и производительность. На старте можно обойтись симулятором на Mac или облачной фермой устройств.
Мобильное тестирование сложнее веба?
Не сложнее, но шире: добавляются среда, платформы и устройства. База при этом та же — техники проверки, работа с API и данными.
Берут ли новичков сразу на мобильное направление?
Да, но чаще ждут понимания веба и API — они всё равно под капотом. Мобильную специфику добирают уже на месте.