Блог
Теория и инструменты тестирования

Прерывания, сенсоры и геолокация в мобильном тестировании

Телефон живёт в потоке звонков, пуш-уведомлений, разряжающейся батареи и постоянно меняющейся геолокации — совсем не похоже на изолированное приложение на белом фоне. Мобильные приложения интегрированы в реальность гораздо плотнее, чем веб-страницы, а значит и багов, связанных с этим взаимодействием, можно придумать заметно больше. В этой статье разбираем вторую половину особенностей мобильного тестирования: связь, прерывания, сенсоры, геолокацию, гайдлайны платформ и жизненный цикл приложения.

Тестирование связи

Мобильное устройство переключается между типами соединения постоянно: Wi-Fi, сотовая связь от 2G до 5G, иногда спутниковая. Каждое такое переключение — потенциальный источник бага, и тестировщику стоит системно проверить набор сценариев:
— что происходит, если интернета нет вообще — краш, заглушка или корректный офлайн-режим;
— что будет, если сотовая сеть пропадает прямо во время передачи данных — сработает ли retry, сохранится ли состояние;
— то же самое при отключении Wi-Fi в процессе передачи;
— ситуация, когда Wi-Fi подключён, но интернета фактически нет — как обрабатывается timeout;
— переключение 3G → 4G → 5G — происходит ли реконнект без потери данных;
— переключение между сотовой сетью и Wi-Fi — сохраняется ли пользовательская сессия;
— разное покрытие у разных операторов связи.
На практике именно на этих сценариях находится значительная часть багов мобильных приложений — переключение сетей редко тестируют вдумчиво, потому что оно не бросается в глаза при обычной проверке функциональности.

Прерывания (Interruption Testing)

Тестирование прерываний проверяет, как приложение реагирует на внешние помехи — представьте, что вы работаете за компьютером, и коллега отвлекает вопросом: вы переключаетесь, а потом возвращаетесь к задаче. С мобильным приложением происходит то же самое, только помех гораздо больше:
— низкий заряд батареи и уведомления об этом;
— переход устройства в спящий режим;
— входящие SMS и звонки во время использования приложения;
— push-уведомления от других приложений;
— многозадачность — несколько открытых приложений конкурируют за память устройства;
— конфликт аудиоканалов — например, пользователь слушает аудиокнигу и параллельно запускает видео со звуком: должен ли звук книги остановиться, или каналы будут работать одновременно;
— подключение и отключение зарядки;
— полное выключение устройства — сохранились ли данные приложения при следующем включении.
Каждый из этих сценариев стоит проверить отдельно и целенаправленно — именно на прерываниях приложения чаще всего теряют несохранённые данные пользователя.

Сенсоры и датчики

Современный смартфон напичкан датчиками: акселерометр отслеживает положение в пространстве, гироскоп — угол наклона, магнитометр работает как компас, датчик приближения гасит экран у уха во время звонка, есть датчики давления и температуры, сканеры отпечатков пальцев и Face ID, motion-датчики для встряхивания и, конечно, камеры.
Для тестирования датчик может выступать в двух ролях. Первая — часть функционала: например, в приложении для трекинга спорта датчики измеряют давление, пульс, уровень кислорода, положение тела и прыжки, а в гоночной игре акселерометр управляет поворотами. Вторая роль — источник прерывания: телефон повернули — как отреагировал интерфейс, приложение потрясли — не произошёл ли краш. Базовый набор проверок для датчиков — включать, отключать, переключать и трясти устройство, наблюдая за реакцией приложения.

Геолокация

Множество мобильных приложений построено вокруг геолокации: доставки, трекеры скорости, карты, приложения для бега. Определение местоположения работает через три канала — Wi-Fi (по точкам доступа), сотовые вышки и GPS-спутники, — и на точность влияют страна (спутники расположены неравномерно), плотность застройки (в городе сигнал хуже, чем в поле) и скорость перемещения пользователя.
Показательный реальный кейс: спортивное приложение измеряло скорость бега пользователя. Тестировщик сел на велосипед вместо того чтобы бежать, разогнался выше ожидаемого лимита — и приложение упало. Такой баг невозможно найти, тестируя только «стандартный» сценарий использования: нужно намеренно выходить за рамки предполагаемого поведения пользователя. Мобильные приложения дают гораздо больше простора для подобной фантазии, чем веб — можно представить телефон под водой, на морозе −40 или на жаре +40, и в каждом случае найдётся своя причина для краша.

Гайдлайны платформ и жизненный цикл приложения

У Android и iOS разная философия интерфейса, зафиксированная в официальных гайдлайнах. Material Design для Android строится на иерархии элементов через слои и тени, типографике по принципам печатного дизайна и анимации, подчинённой законам физики — поверхности двигаются в трёх измерениях как в реальном мире. Human Interface Guidelines для iOS делает акцент на лаконичности и воздушности, управлении жестами (свайпы, смахивания) вместо кнопок и анимации, которая не отвлекает от основного взаимодействия — символ этого подхода — экран без физической кнопки «домой», где вся навигация ушла в жесты снизу.
Отдельная тема — жизненный цикл экрана приложения, в Android это называется Activity. Экран проходит через состояния Created (создан, но взаимодействовать нельзя), Started (виден, но ещё не интерактивен), Resumed (полностью доступен для взаимодействия), Paused (частично виден — например, поверх открылось модальное окно), Stopped (не виден, но всё ещё занимает память) и Destroyed (уничтожен). Именно в состоянии Stopped чаще всего возникают баги: приложение выглядит свёрнутым, но продолжает расходовать память как в активном режиме, что приводит к неожиданным крашам.

Удалённая отладка мобильного сайта через Chrome DevTools

Отдельный практический навык — что делать, если баг воспроизводится только на реальном телефоне, а на компьютере в эмуляции DevTools всё работает штатно. Причина в том, что эмуляция экрана в DevTools — это лишь имитация размеров экрана, без полноценного движка реального мобильного браузера.
Решение — подключить Android-устройство к компьютеру по USB и открыть удалённую отладку: включить режим разработчика на телефоне, в Chrome на компьютере перейти по адресу chrome://inspect, подтвердить соединение через USB-Debugging — и в списке появятся все вкладки, открытые в мобильном браузере. Выбрав нужную и нажав Inspect, тестировщик получает полноценный DevTools с трансляцией экрана телефона: можно скроллить, кликать и печатать прямо с компьютера, а также пользоваться Console, Network и Elements так, будто это обычная вкладка десктопного браузера. Для iOS аналогичная отладка работает только через Safari и только на macOS.
Прерывания, сенсоры и геолокация — это ровно тот класс багов, который не поймать без системного подхода и практики на реальных устройствах. На курсе «Инженер по ручному тестированию» в Quality Academy этому посвящён отдельный спринт с практическими домашними заданиями, включая подключение мобильного устройства к DevTools.
-------

Полезные ссылки школы

Сайт Quality Academy:
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena