Сетевые условия оказывают глубокое влияние на пользовательский опыт так, как среды разработки никогда не воспроизводят. По данным исследования Google, 53% пользователей мобильных устройств покидают сайты, загружающиеся дольше 3 секунд. По данным Akamai, страницы с даже кратковременными сетевыми перебоями имеют на 40% более высокий показатель отказов. Тестирование в реалистичных сетевых условиях необходимо для команд, ориентированных на глобальные рынки: нужно проверять поведение приложения при разной пропускной способности (2G, 3G, 4G, WiFi), задержках и потере пакетов. Это руководство охватывает инструменты симуляции сетевых условий.

TL;DR: Тестирование сетевых условий симулирует реальную связь для веб и мобильных приложений. Используй Chrome DevTools для браузерного тестирования, tc netem (Linux) для симуляции на уровне ОС и Charles Proxy/Proxyman для мобильного трафика. Тестируй минимально: Fast 3G, Slow 3G и 2G профили.

Android Симуляция Сети

Используя OkHttp Interceptors 

class NetworkConditionInterceptor(
    private val delayMs: Long = 0,
    private val packetLossRate: Double = 0.0,
    private val bandwidthBytesPerSecond: Long = Long.MAX_VALUE
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        // Симулировать задержку
        if (delayMs > 0) {
            Thread.sleep(delayMs)
        }

        // Симулировать потерю пакетов
        if (Random.nextDouble() < packetLossRate) {
            throw SocketTimeoutException("Симулированная потеря пакетов")
        }

        return chain.proceed(chain.request())
    }
}

// Использование
val client = OkHttpClient.Builder()
    .addInterceptor(
        NetworkConditionInterceptor(
            delayMs = 500,
            packetLossRate = 0.1,
            bandwidthBytesPerSecond = 128_000
        )
    )
    .build()

Тестирование Различных Условий 

@Test
fun testSlowConnection() = runTest {
    val slowClient = OkHttpClient.Builder()
        .addInterceptor(NetworkConditionInterceptor(
            delayMs = 2000,
            bandwidthBytesPerSecond = 50_000
        ))
        .build()

    val startTime = System.currentTimeMillis()
    val response = apiService.getUsers()
    val duration = System.currentTimeMillis() - startTime

    assertTrue(duration >= 2000)
}

@Test
fun testPacketLoss() = runTest {
    val unreliableClient = OkHttpClient.Builder()
        .addInterceptor(NetworkConditionInterceptor(
            packetLossRate = 0.5
        ))
        .build()

    var failureCount = 0

    repeat(100) {
        try {
            apiService.getUsers()
        } catch (e: SocketTimeoutException) {
            failureCount++
        }
    }

    assertTrue(failureCount in 40..60)
}

“Most teams test their apps on localhost with perfect network conditions and wonder why mobile users complain. Network simulation is not optional — it’s the only way to know how your app actually performs in the real world.” — Yuri Kan, Senior QA Lead

Тестирование Offline Режима

Тестирование сетевых условий критически важно для мобильного тестирования в 2025, где iOS и Android приложения сталкиваются с разнообразными сценариями подключения.

@Test
fun testOfflineDataAccess() = runTest {
    val offlineClient = OkHttpClient.Builder()
        .addInterceptor { chain ->
            throw UnknownHostException("Нет доступной сети")
        }
        .build()

    val repository = UserRepository(offlineClient)
    val users = repository.getUsers()

    assertNotNull(users)
    verify { localDatabase.getUsers() }
}

@Test
fun testOfflineWriteQueueing() = runTest {
    syncManager.setNetworkAvailable(false)

    val newUser = User(id = "123", name = "Тестовый Пользователь")
    syncManager.queueCreateUser(newUser)

    val pending = syncManager.getPendingOperations()
    assertEquals(1, pending.size)

    syncManager.setNetworkAvailable(true)
    delay(1000)

    assertEquals(0, syncManager.getPendingOperations().size)
}

Реализация offline-first паттернов требует стратегии кэширования API для мобильных приложений, обеспечивая доступность данных независимо от сетевого состояния.

Логика Повторов

Тестирование механизмов повторов при плохих сетевых условиях необходимо для тестирования производительности API, обеспечивая устойчивость к временным сбоям.

class RetryInterceptor(
    private val maxRetries: Int = 3,
    private val initialDelay: Long = 1000
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        var attempt = 0
        var delay = initialDelay

        while (attempt <= maxRetries) {
            try {
                return chain.proceed(chain.request())
            } catch (e: IOException) {
                attempt++
                if (attempt > maxRetries) throw e
                Thread.sleep(delay)
                delay *= 2
            }
        }

        throw IOException("Превышено максимальное число повторов")
    }
}

@Test
fun testRetryLogic() = runTest {
    var attemptCount = 0

    val client = OkHttpClient.Builder()
        .addInterceptor { chain ->
            attemptCount++
            if (attemptCount < 3) {
                throw SocketTimeoutException("Симулированный сбой")
            }
            chain.proceed(chain.request())
        }
        .addInterceptor(RetryInterceptor(maxRetries = 3))
        .build()

    val response = client.newCall(request).execute()

    assertEquals(3, attemptCount)
    assertTrue(response.isSuccessful)
}

Лучшие Практики

  1. Тестируйте с реалистичными сетевыми профилями - 3G, 4G, WiFi
  2. Реализуйте retry логику с экспоненциальным backoff - Обработка временных сбоев
  3. Используйте offline-first архитектуру - Кэшируйте данные локально
  4. Тестируйте сетевые переходы - WiFi ↔ cellular, online ↔ offline
  5. Мониторьте производительность сети - Отслеживайте latency, throughput

Заключение

Тестирование сетевых условий обеспечивает:

  • Graceful деградацию на медленных сетях
  • Offline функциональность
  • Правильные механизмы retry
  • Согласованность данных в сетевых состояниях

Тестирование различных сетевых условий предотвращает плохой пользовательский опыт и потерю данных.

Смотрите также

Официальные ресурсы

FAQ

Какие сетевые профили мне следует тестировать?

Стандартные профили: WiFi (50+ Мбит/с, 5мс задержка), Fast 4G/LTE (10 Мбит/с, 20мс), Regular 4G (4 Мбит/с, 30мс), Fast 3G (1,5 Мбит/с, 40мс), Slow 3G (400 Кбит/с, 400мс), 2G (250 Кбит/с, 750мс) и Offline. Приоритизируй профили, соответствующие демографии пользователей.

Как симулировать сетевые условия для мобильного тестирования?

Для iOS: используй Xcode Network Link Conditioner. Для Android: используй настройки разработчика > Симуляция сетевых условий, или tc netem через adb на рутованных устройствах. Для обеих платформ: используй прокси-инструмент типа Charles Proxy для ограничения всего трафика.

Как тестировать оффлайн-режим и деградацию?

Тестируй: полное отсутствие сети, переход с онлайн на оффлайн во время операции, частичное подключение (периодическая потеря пакетов) и сбои DNS. Проверяй: кэшированные данные отдаются в оффлайне, ожидающие операции ставятся в очередь и возобновляются при подключении.

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

Linux tc netem: ’tc qdisc add dev eth0 root netem loss 5%’ симулирует 5% потерю. Chrome DevTools Custom profile поддерживает симуляцию потери пакетов. Charles Proxy включает настройки потери. Потеря пакетов критична для тестирования надёжности функций реального времени.

See Also