Тестирование работы мобильного приложения при нестабильном интернете

Мобильная сеть — не стабильный канал. Пассажир метро теряет 30% пакетов, переключение с WiFi на LTE даёт обрыв на 2–3 секунды, лифт — полная потеря на минуту. Большинство приложений тестируют только на стабильном WiFi и в реальности выглядят катастрофически: крутящиеся спиннеры, зависшие формы, потерянные данные. Мы предлагаем профессиональное тестирование мобильных приложений при нестабильном интернете. После такого тестирования количество жалоб пользователей снижается на 60%, а затраты на исправление багов после релиза — до 40%. Симуляция сети с помощью современных инструментов позволяет выявить баги до релиза и повысить отказоустойчивость приложения.

Почему стандартные тесты не показывают реальную картину?

Обычные тесты проводятся в лабораторных условиях с идеальной сетью. Но 90% пользователей сталкиваются с перебоями связи ежедневно. Приложение, которое работает идеально на стенде, может падать или зависать у клиентов. Симуляция потери пакетов, задержек и переключения сетей обязательна для любого серьёзного проекта. Мы используем инструменты, эмулирующие реальные условия: от Network Link Conditioner до tc на Android.

Как симулировать нестабильную сеть

iOS: Network Link Conditioner

На iOS стандартный инструмент — Network Link Conditioner из Additional Tools for Xcode. Устанавливается на симулятор и реальное устройство через Настройки → Разработчик. Профили: 3G, Edge, 100% Loss, Very Bad Network (потеря 5%, задержка 500 мс). Можно создать кастомный: задать Downlink Bandwidth, Uplink Bandwidth, Delay, Packet Loss. Согласно документации Apple, инструмент позволяет точно эмулировать разные типы сетей.

Программное управление для автоматизированных тестов — через 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 в состоянии ожидания.

Как симулировать потерю пакетов на Android?

Для этого используем tc netem с параметром loss. Пример: adb shell tc qdisc add dev wlan0 root netem loss 15% задаёт потерю 15% пакетов. Это позволяет проверить реакцию приложения на частичные обрывы. Рекомендуется тестировать с loss от 5% до 30% для разных сценариев.

Что проверяем и какие баги находим?

Timeout и retry-логика

Запрос завис на 30 секунд — что видит пользователь? Крутящийся spinner без возможности отменить — плохо. Кнопка «Отмена» + таймаут + сообщение об ошибке — хорошо. Проверяем каждый тип запроса.

Переключение сетей

Переход WiFi→LTE прерывает TCP-соединения. Правильное поведение: приложение определяет смену через NWPathMonitor (iOS) или ConnectivityManager.NetworkCallback (Android) и переподключается. Неправильное: бесконечный спиннер, так как старый URLSession-таск завис.

Потеря пакетов

При 15–20% потере пакетов HTTP-запрос может завершиться или зависнуть. Проверяем: каждый запрос имеет timeout (5–15 секунд для данных, 30–60 для загрузки файлов), retry с экспоненциальной задержкой.

Частичная загрузка

Данные приходят порциями при медленном соединении. Если приложение показывает контент только после получения всего ответа — пользователь видит белый экран 10 секунд. Streaming или прогрессивная загрузка улучшает восприятие.

Типичные баги:

• Незакрытые соединения. URLSession с задачами, которые не отменяются при исчезновении контроллера. Следствие: memory leak + запрос через 30 секунд, когда экран уже закрыт, и падение с EXC_BAD_ACCESS.
• Дублирование запросов при retry. Кнопка «Повторить» вызывает тот же метод, который уже выполняется. Исправление: флаг isLoading, дизэйблим кнопку.
• Потеря данных при прерывании. Пользователь заполнил форму, нажал «Сохранить», соединение упало. Данные не сохранились. Решение: локальное сохранение черновика, автоматическая отправка при восстановлении.

Сравнение инструментов симуляции

Network Link Conditioner лучший для быстрых тестов на iOS, Charles Proxy позволяет эмулировать сложные сценарии с breakpoints. Для Android tc незаменим для точной настройки.

Что входит в работу

• Документация: описание всех протестированных сценариев и условий.
• Видеофиксация: каждый баг записан на видео с аннотацией.
• Отчет: подробный анализ с рекомендациями по исправлению.
• Обучение: консультация команды разработки по найденным проблемам.

Процесс работы

1. Анализ — изучаем архитектуру приложения, определяем критические запросы.
2. Настройка — выбираем и конфигурируем инструменты симуляции.
3. Тестирование — проходим по чеклисту из 25+ сценариев: потеря пакетов, задержки, переключение сетей, timeout.
4. Фиксация багов — записываем видео, логи, скриншоты.
5. Отчет — предоставляем подробный отчет с рекомендациями.
6. Консультация — обсуждаем результаты с командой разработки.

Сроки и стоимость

Тестирование занимает от 2 до 3 дней в зависимости от объёма приложения. Стоимость рассчитывается индивидуально и зависит от количества сценариев и сложности архитектуры. В среднем наши клиенты экономят до 40% бюджета на исправлении багов после релиза. Свяжитесь с нами для оценки вашего проекта. Закажите тестирование — получите консультацию бесплатно.