Мобильная сеть — не стабильный канал. Пассажир метро теряет 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, инструмент позволяет точно эмулировать разные типы сетей.
| Профиль | Bandwidth (Down/Up) | Delay | Packet Loss |
|---|---|---|---|
| 3G | 1 Мбит/с / 512 Кбит/с | 200ms | 0% |
| Edge | 200 Кбит/с / 100 Кбит/с | 300ms | 1% |
| Very Bad Network | 500 Кбит/с / 250 Кбит/с | 500ms | 5% |
Программное управление для автоматизированных тестов — через 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 |
Высокая (системный) | Средняя | Низкая |
Android tc |
Высокая (реальная задержка) | Высокая | Средняя |
Charles Proxy |
Средняя (зависит от сети) | Высокая | Средняя |
Proxyman |
Средняя | Высокая | Средняя |
Network Link Conditioner лучший для быстрых тестов на iOS, Charles Proxy позволяет эмулировать сложные сценарии с breakpoints. Для Android tc незаменим для точной настройки.
Что входит в работу
- Документация: описание всех протестированных сценариев и условий.
- Видеофиксация: каждый баг записан на видео с аннотацией.
- Отчет: подробный анализ с рекомендациями по исправлению.
- Обучение: консультация команды разработки по найденным проблемам.
Процесс работы
- Анализ — изучаем архитектуру приложения, определяем критические запросы.
- Настройка — выбираем и конфигурируем инструменты симуляции.
- Тестирование — проходим по чеклисту из 25+ сценариев: потеря пакетов, задержки, переключение сетей, timeout.
- Фиксация багов — записываем видео, логи, скриншоты.
- Отчет — предоставляем подробный отчет с рекомендациями.
- Консультация — обсуждаем результаты с командой разработки.
Сроки и стоимость
Тестирование занимает от 2 до 3 дней в зависимости от объёма приложения. Стоимость рассчитывается индивидуально и зависит от количества сценариев и сложности архитектуры. В среднем наши клиенты экономят до 40% бюджета на исправлении багов после релиза. Свяжитесь с нами для оценки вашего проекта. Закажите тестирование — получите консультацию бесплатно.