Тестування роботи мобільного додатку при нестабільному інтернеті

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1735 послуг
Тестування роботи мобільного додатку при нестабільному інтернеті
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    792
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    671
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1097
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    969
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    914
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    495

Тестування роботи мобільного додатку при нестабільному інтернеті

Мобільна мережа — не стабільний канал. Користувач їде у метро: мережа есть, пакеты теряються у 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 дні — налаштування інструментів симуляції, тестування по чеклисту сценаріїв, звіт з находками. Вартість розраховується індивідуально.