Тестирование работы мобильного приложения при нестабильном интернете
Мобильная сеть — не стабильный канал. Пользователь едет в метро: сеть есть, пакеты теряются в 30%. Переходит с WiFi на LTE: 2–3 секунды полного обрыва. Заходит в лифт: соединение пропадает на минуту. Большинство приложений тестируют только на стабильном WiFi и выглядят катастрофически на реальном трафике.
Инструменты симуляции
iOS: Network Link Conditioner
На iOS стандартный инструмент — Network Link Conditioner из дополнительных инструментов Xcode (Additional Tools for Xcode). Устанавливается на симулятор и реальное устройство через Настройки → Разработчик.
Профили: 3G, Edge, 100% Loss, Very Bad Network (потеря 5%, задержка 500 мс). Можно создать кастомный: задать Downlink Bandwidth, Uplink Bandwidth, Delay, Packet Loss.
Программное управление для автоматизированных тестов — через XCTest и XCTNSURLSessionTaskMetrics. Метрики дают данные о реальных условиях соединения в тесте.
Android: tc и emulator network settings
На эмуляторе: Emulator Extended Controls → Cellular → Network type → Edge / GSM и Signal strength → Poor.
Программная симуляция через adb и tc (traffic control):
# Добавляем задержку 500ms и потерю пакетов 20%
adb shell tc qdisc add dev wlan0 root netem delay 500ms loss 20%
# Сбрасываем
adb shell tc qdisc del dev wlan0 root
tc netem работает на уровне сетевого интерфейса эмулятора. На реальном устройстве нужен root — для тестирования используем эмулятор или тестируем в зонах реального плохого покрытия.
Кросс-платформа: Charles Proxy и Proxyman
Charles Proxy (macOS/Windows) и Proxyman (macOS) работают как man-in-the-middle прокси. Приложение настраивается на использование прокси, и уже там применяем throttling:
Charles → Proxy → Throttle Settings: выбираем профиль GPRS / 3G / Custom. Все запросы приложения проходят через прокси с симулированной задержкой и ограниченной полосой.
Дополнительно — Breakpoints: перехватываем запрос, задерживаем его на 10 секунд вручную, имитируем timeout. Полезно для проверки UI в состоянии ожидания.
Что проверяем
Timeout и retry-логика. Запрос завис на 30 секунд — что видит пользователь? Крутящийся spinner без возможности отменить — плохо. Кнопка «Отмена» + таймаут + понятное сообщение об ошибке — хорошо. Проверяем каждый тип запроса: загрузка ленты, отправка формы, загрузка файла.
Переключение сетей. Переход WiFi→LTE прерывает TCP-соединения. Правильное поведение: приложение определяет смену через NWPathMonitor (iOS) / ConnectivityManager.NetworkCallback (Android) и переподключается. Неправильное: бесконечный спиннер, потому что старый URLSession-таск завис.
// iOS: мониторинг смены сети
let monitor = NWPathMonitor()
monitor.pathUpdateHandler = { path in
if path.status == .satisfied {
// есть соединение — повторяем незавершённые запросы
self.retryPendingRequests()
}
}
monitor.start(queue: DispatchQueue.global(qos: .background))
Потеря пакетов. При 15–20% потере пакетов HTTP-запрос может завершиться, может зависнуть. Проверяем: каждый запрос имеет timeout, таймаут разумный (5–15 секунд для данных, 30–60 для загрузки файлов), retry реализован с экспоненциальной задержкой.
Частичная загрузка. Данные приходят порциями при медленном соединении. Если приложение показывает контент только после получения всего ответа — пользователь видит белый экран 10 секунд. Streaming или прогрессивная загрузка улучшает восприятие.
Типичные находки при тестировании
Незакрытые соединения. URLSession с задачами, которые не отменяются при исчезновении контроллера. Следствие: memory leak + запрос приходит через 30 секунд, когда экран уже закрыт, и приложение падает с EXC_BAD_ACCESS.
Дублирование запросов при retry. Кнопка «Повторить» вызывает тот же метод, который уже выполняется. В итоге два одновременных запроса, два ответа, состояние гонки. Исправление: флаг isLoading, дизэйблим кнопку во время запроса.
Потеря данных при прерывании. Пользователь заполнил форму, нажал «Сохранить», соединение упало. Данные не сохранились — и потерялись. Правильное решение: локальное сохранение черновика до отправки, автоматическая повторная отправка при восстановлении сети.
Сроки
2–3 дня — настройка инструментов симуляции, тестирование по чеклисту сценариев, отчёт с находками. Стоимость рассчитывается индивидуально.