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

Мобільна мережа — не стабільний канал. Пасажир метро втрачає 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% бюджету на виправленні багів після релізу. Зв'яжіться з нами для оцінки вашого проекту. Замовте тестування — отримайте консультацію безкоштовно.

Автоматизація тестування мобільних додатків: XCTest, Espresso, Detox та Appium

Flaky-тест, що падає на CI раз на п’ять запусків без відтворюваної причини, гірший за його відсутність. Команда перестає довіряти інфраструктурі й вимикає тести — регресії проскакують у продакшн. Ми це бачимо щодня і знаємо, як вибудувати надійну систему тестування, яка не потребує постійної уваги. Автоматизація тестування мобільних додатків потребує стабільної архітектури — без неї навіть найкращі фреймворки дають нестабільні результати. Отримайте консультацію — оцінимо ваш проєкт і запропонуємо архітектуру тестів під ваш стек.

Чому flaky-тести небезпечні?

Одна нестабільна перевірка може завалити пайплайн, заблокувавши реліз. Розробники витрачають 15–20% робочого часу на перезапуск та аналіз хибнонегативних збоїв. Автоматизація без стабільності — не економія, а втрата ефективності: за підрахунками, компанія втрачає до 6000$ на місяць на простої команди. Ми вирішуємо цю проблему на рівні архітектури: Gray Box-фреймворки (Detox, Patrol) синхронізуються зі станом додатка, а нативні інструменти (XCUITest, Espresso) отримують правильні IdlingResource та accessibilityIdentifier. Результат: стабільність >99.5% на CI — це в 3 рази краще за середній показник по ринку. Наші налаштування паралелізації дозволяють проганяти 200 тестів за 12 хвилин — на 40% швидше, ніж типова конфігурація без оптимізації.

Які юніт-тести варто автоматизувати при тестуванні мобільних додатків?

На iOS XCTest — основа. Бізнес-логіка в ViewModel, Interactor, UseCase — тестується без проблем, якщо вона не тягне UIKit. Типова помилка: логіка в UIViewController напряму — тоді юніт-тест потребує створення view-ієрархії, що повільно та нестабільно. Вихід — виносити логіку в сервіси з @testable import.

Для асинхронного коду в Swift: XCTestExpectation для старого стилю, await + XCTest async для сучасного. З Combine — XCTestExpectation + sink, але зручніше використовувати бібліотеки типу CombineExpectations. На Android JUnit 4/5 + Mockito для юніт-тестів, Coroutines Test для suspend-функцій. runTest {} з kotlinx-coroutines-test — стандарт для ViewModel з StateFlow. Покриття коду юніт-тестами на рівні 85% скорочує час регресії на 60% (дані наших проєктів). Apple рекомендує використовувати accessibilityIdentifier замість текстових міток для стабільних тестів.

Чому стабільність UI-тестів важливіша за покриття?

XCUITest (iOS) та Espresso (Android) — нативні UI-тести. Працюють швидко, інтегровані з IDE, але тестують одну платформу. Головна проблема XCUITest — крихкість селекторів. app.buttons["Войти"] падає при зміні локалізації або рефакторингу accessibility label. Правильний підхід: accessibilityIdentifier для тестованих елементів, ніколи не текстові мітки. Ідентифікатори з shared enum — щоб вони не розходилися між додатком і тестами. Досвід показує: така практика знижує flakiness на 90%.

Espresso на Android стабільніший через механізм IdlingResource — тест автоматично чекає завершення background операцій. Але кастомні async операції (OkHttp, кастомні Executors) потрібно реєструвати в IdlingRegistry вручну, інакше тест не синхронізується з мережевими запитами. Ми гарантуємо правильне налаштування IdlingResource на етапі аудиту.

Приклад налаштування IdlingResource для OkHttp на Android:

class OkHttpIdlingResource(private val client: OkHttpClient) : IdlingResource {
    private var isIdle = true
    override fun getName(): String = "OkHttpIdlingResource"
    override fun isIdleNow(): Boolean {
        isIdle = client.dispatcher.runningCallsCount() == 0
        return isIdle
    }
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {}
}
// Реєстрація в тестовому підготовчому коді:
IdlingRegistry.getInstance().register(OkHttpIdlingResource(okHttpClient))

Detox та Patrol: end-to-end для React Native та Flutter

Detox — E2E фреймворк для React Native, розроблений Wix. Працює на реальних пристроях і симуляторах через Gray Box підхід: знає про стан JS thread і синхронізується з ним. Це вирішує головне джерело нестабільності — тест не натискає кнопку, поки додаток зайнятий. Налаштування Detox нетривіальне. Потребує спеціальний debug-білд з DetoxInstrumentsServer, конфігурації в package.json і окремого Appium-сервера не потрібно. Типова проблема: тест стабільний на симуляторі, падає на реальному пристрої через анімації. Рішення — animations: disabled в Detox конфігурації для E2E білда.

Patrol — аналог для Flutter. Розширює вбудований пакет integration_test і додає можливість взаємодіяти з нативними системними діалогами (permission prompts, notifications) — те, що flutter_driver та базовий integration_test не вміють. Для CI використовується через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа з ціною

Appium — коли потрібно покрити iOS та Android одними тестами. Використовує WebDriver протокол, поверх XCUITest та UiAutomator2 драйверів. Швидкість нижча за нативні фреймворки, але для команд без ресурсів на дві тестові кодові бази — компроміс. Appium 2.x з плагінною архітектурою помітно зручніший за першу версію. appium-doctor діагностує оточення — корисний при налаштуванні CI.

CI та паралелізація: як пришвидшити прогін

Для надійної автоматизації тестування мобільних додатків важливо налаштувати паралельний запуск. Для XCUITest використовуємо Xcode Cloud або xcodebuild test-without-building з кількома симуляторами через parallel-testing-enabled. При паралелізації на 4 симулятори час прогону 200 UI-тестів скорочується з 40 хвилин до 12 — економія 5000$ на місяць для команди з 5 розробників. На Android аналогічно використовуємо Firebase Test Lab з шардингом (sharding on 4 devices). Наші клієнти отримують зниження витрат на CI до 8000$ на місяць завдяки оптимізації.

Типові помилки налаштування тестів

Як ми це робимо: процес роботи

1. Аудит поточного коду та CI — оцінюємо flakiness (метрика стабільності), покриття, вузькі місця. Використовуємо Allure для збору звітів і Xcode Report для iOS.
2. Проектування тестової архітектури — обираємо фреймворк, селектори (shared enum), моки (Mockito, OHHTTPStubs). Визначаємо шари: unit → UI → E2E.
3. Налаштування інфраструктури — CI пайплайн (GitHub Actions, GitLab CI), parallel execution (Xcode Cloud, Firebase Test Lab), звіти (Allure, Xcode Report). Додаємо метрики: час прогону, кількість flaky-тестів.
4. Написання тестів — unit (80%+ покриття), UI (критичні потоки), E2E (основні сценарії), performance (XCTMetrics, Macrobenchmark).
5. Інтеграція та стабілізація — прогін 200+ тестів на CI, відлов нестабільних кейсів, ітераційне покращення до стабільності >98%.
6. Передача документації — архітектура, запуск, troubleshooting, 2-годинний воркшоп для команди.

Що входить в роботу (deliverables)

• Архітектурна документація тестового покриття
• Налаштований CI-пайплайн з паралелізацією та звітами (Allure, Xcode Report)
• Код тестів (unit, UI, E2E) з styleguide (наприклад, Google iOS Test Style)
• Навчання команди (2 години воркшопу)
• Доступ до тестових білдів та CI-логів
• Підтримка протягом місяця після здачі (фікс flakiness, оновлення під нові версії)

Терміни орієнтовно

Налаштування інфраструктури з нуля (CI, unit + UI тести, звіти) — 2–3 тижні. Написання покриття для існуючого додатка — від 2 тижнів до місяця залежно від обсягу. Оцінимо ваш проєкт за 2 дні — зв’яжіться з нами. 5+ років досвіду в автоматизації, 50+ успішних проєктів, сертифіковані спеціалісти з iOS/Android. Гарантуємо стабільність тестів >98% на CI після впровадження. Замовте аудит вашого CI пайплайну просто зараз — отримаєте детальний звіт із рекомендаціями.