Какие знаешь кейсы реконнекты мобильного тестирования?

Кейсы реконнектов в мобильном тестировании

Реконнект (восстановление соединения) — это критически важный аспект тестирования мобильных приложений, учитывая нестабильность сетевых условий (переключение между Wi-Fi/4G/5G, зоны слабого сигнала, режим полёта). Успешная обработка реконнекта напрямую влияет на пользовательский опыт (UX) и целостность данных. Вот ключевые кейсы, которые я рассматриваю на проектах.

1. Смена типа сети

Это базовый и наиболее частый сценарий. Приложение должно корректно реагировать на переключение между разными источниками связи.

• Кейс: Активное потоковое аудио/видео при переключении с Wi-Fi на мобильную сеть (и обратно). Ожидаемое поведение: пауза или незначительный буфер (1-3 сек.) без падения приложения.
• Что проверять:

    *   Корректность работы **экспоненциальной задержки (exponential backoff)** при повторных попытках запроса.
    *   Обновление **индикатора сетевого статуса** (иконка в статус-баре или внутри UI).
    *   Сохранение состояния сессии/авторизации.

2. Полная потеря и последующее восстановление связи

Имитация "провала" в сеть (туннель, лифт) с последующим возвращением.

• Кейс: Форма для заполнения с последующей отправкой. Пользователь теряет сеть при нажатии "Отправить", получает визуальный тост "Нет соединения", позже сеть возвращается.
• Ожидаемое поведение:

    *   Данные формы **не теряются** локально.
    *   При восстановлении связи появляется опция для **повторной отправки (retry logic)** или отправка происходит **автоматически** (если это допустимо по бизнес-логике).
    *   Пользователь получает чёткий фидбэк о статусе операции.

// Пример логики проверки состояния сети в Android (Kotlin)
val connectivityManager = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val networkCallback = object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network: Network) {
        // Сеть доступна: можно возобновить отправку данных из очереди
        resumePendingOperations()
    }
    override fun onLost(network: Network) {
        // Сеть потеряна: показать уведомление пользователю
        showSnackbar("Connection lost. Data will be sent when restored.")
    }
}
connectivityManager.registerDefaultNetworkCallback(networkCallback)

3. Режим "В самолёте" (Airplane Mode)

Жёсткий сценарий полного отключения всех беспроводных интерфейсов.

• Кейс: Включение режима полёта во время загрузки ленты новостей. После выключения режима:

    *   Приложение должно либо **автоматически до-подгрузить** недостающий контент, либо
    *   Предоставить пользователю явный **UI-элемент ("Повторить")** для ручного обновления.

• Важно: Проверить работу кеширования. При отсутствии сети должен показываться актуальный кеш, если он есть, а не "пустышка" или ошибка.

4. Прерывание и восстановление при фоновой работе (Background/Foreground)

• Кейс:

    1.  Приложение в фоне загружает большой файл.
    2.  Сеть пропадает на несколько минут.
    3.  Пользователь возвращает приложение на передний план (foreground).

• Ожидание: Задача загрузки должна быть либо приостановлена с возможностью возобновления (resumable downloads), либо перезапущена с корректной точки. Не должно быть бесконечных попыток или краша.

5. Работа с сокетами (WebSocket, долгоживущие соединения)

Для мессенджеров, финансовых тикеров, онлайн-игр.

• Кейс: Разрыв WebSocket-соединения из-за смены сети.
• Что проверять:

    *   Наличие и эффективность **механизма heartbeat/ping-pong** для быстрого обнаружения разрыва.
    *   **Автоматический переподключение** с корректеной повторной авторизацией, если требуется.
    *   **Синхронизация состояния** после реконнекта (не должны теряться непрочитанные сообщения, должен приходить актуальный баланс).

6. Взаимодействие с push-уведомлениями (FCM/APNs)

• Кейс: Устройство долго находится оффлайн, получает несколько push. После подключения к сети все уведомления должны быть доставлены и обработаны. Важно проверить логику collapse_key в FCM, чтобы не показывать пользователю дублирующие нотификации.

7. Восстановление после долгого отсутствия сети

Проверка на "забытые" запросы и таймауты.

• Кейс: Приложение неделю работает в офлайне (например, в роуминге). При подключении к стабильному Wi-Fi оно не должно "захлебнуться", пытаясь мгновенно синхронизировать гигабайты данных. Должна работать приоритизация запросов (сначала критичные для работы, потом фоновые) и дросселирование (throttling).

Общая стратегия тестирования:

• Инструменты: Использую Charles Proxy или Fiddler для симуляции Network Throttling и Breakpoints. В Android Studio — Network Emulator, на реальных устройствах — режим разработчика.
• Автоматизация: Пишу сценарии, используя Appium или Espresso/XCUITest с моками сервера (например, WireMock), чтобы эмулировать различные сетевые сценарии (задержка 5000мс, отказ 503) в CI/CD пайплайне.
• Мониторинг: Обращаю внимание на потребление батареи при активных попытках реконнекта. Неудачная политика повторных попыток может быстро разряжать устройство.

Итог: Комплексное тестирование реконнекта — это не просто проверка "работает/не работает". Это валидация отказоустойчивости (resilience), консистентности данных и прозрачной коммуникации с пользователем в условиях неидеальной сети, что является нормой для мобильной среды.