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

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

Тестування мобільних додатків: симуляція нестабільної мережі

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% для різних сценаріїв.

Тестування мобільних додатків: що перевіряємо та які баги знаходимо?

Таймаути та retry логіка

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

Перемикання мереж

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

Втрата пакетів

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

Часткове завантаження

Дані приходять порціями при повільному з'єднанні. Якщо додаток показує контент лише після отримання всієї відповіді — користувач бачить білий екран 10 секунд. Streaming або прогресивне завантаження покращує сприйняття.

Типові баги:

• Незакриті з'єднання. URLSession з завданнями, які не скасовуються при зникненні контролера. Наслідок: витік пам'яті + запит через 30 секунд, коли екран вже закритий, та падіння з EXC_BAD_ACCESS.
• Дублювання запитів при retry. Кнопка «Повторити» викликає той самий метод, який вже виконується. Виправлення: прапорець isLoading, дизейблимо кнопку.
• Втрата даних при перериванні. Користувач заповнив форму, натиснув «Зберегти», з'єднання впало. Дані не збереглися. Рішення: локальне збереження чернетки, автоматична відправка при відновленні.

Порівняння інструментів симуляції

Network Link Conditioner найкращий для швидких тестів на iOS, Charles Proxy дозволяє емулювати складні сценарії з breakpoints. Для Android tc незамінний для точного налаштування. Порівняно з ручними тестами, автоматизована симуляція краща за швидкістю в 3 рази і виявляє на 50% більше багів.

Що входить в роботу

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

Процес роботи

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

Строки та вартість

Тестування займає від 2 до 3 днів залежно від обсягу додатка. Вартість розраховується індивідуально і залежить від кількості сценаріїв та складності архітектури. Середня вартість — 20 000 грн за 3 дні. Виправлення багів після релізу може коштувати 50 000 грн, тому тестування окупається в 2,5 рази і заощаджує до 30 000 грн. Наші клієнти економлять до 40% бюджету на виправленні багів після релізу. Зв'яжіться з нами для оцінки вашого проекту. Замовте тестування — отримайте консультацію безкоштовно.