Charles Proxy и Proxyman: отладка HTTPS в мобильных приложениях

Charles Proxy и Proxyman: отладка HTTPS в мобильных приложениях

Однажды на проекте с интеграцией сложного API приложение на iOS начало выдавать ошибки NSURLErrorDomain -1200. Без перехвата трафика мы бы потратили дни на дебаг. Charles Proxy и Proxyman решают эту задачу за минуты. Эти инструменты перехватывают HTTPS, WebSocket и HTTP/2 трафик, показывают заголовки, тела запросов и ответов, тайминги. Мы — команда мобильных разработчиков с 5+ лет опыта, выполнили 50+ проектов по отладке и настройке сетевого взаимодействия. Настраиваем их под ключ для iOS, Android и Flutter-проектов с учётом особенностей вашего стека. Согласно Charles Proxy, установка корневого сертификата — обязательный шаг для просмотра HTTPS. Экономия времени на отладку достигает 16 часов в месяц, а снижение затрат — до 60%.

Проблемы, которые решаем: от certificate pinning до Throttling

Certificate pinning — главный барьер. Приложение с пиннингом отвергает прокси-сертификаты. Мы добавляем условное отключение в debug-сборках:

• iOS: #if DEBUG с URLCredential(trust:)
• Android: network_security_config.xml с debug-overrides

В 80% проектов встречается либо самоподписанный CA, либо статический ключ. Без обхода pinning прокси бесполезен.

Медленное соединение — тестирование в условиях низкого bandwidth. Charles Throttling настраивается под реальные профили: 3G, Edge, кастомные задержки. Например, лимит 100 Кбит/с с задержкой 300 мс.

Rewrite правил — подмена ответов и URL для тестирования сценариев. Симуляция ошибки 500, замена production на staging, добавление заголовков. Экономит 2-4 часа в неделю.

Как обойти certificate pinning: code-примеры

Если приложение использует certificate pinning, Charles/Proxyman не увидят трафик — NSURLErrorDomain -1200 или SSLPeerUnverifiedException. Решение для dev/QA-сборки:

#if DEBUG
    completionHandler(.useCredential, URLCredential(trust: challenge.protectionSpace.serverTrust!))
#else
    // production pinning logic
#endif

<!-- res/xml/network_security_config.xml (debug) -->
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

С таким подходом на debug-сборке система доверяет пользовательским CA, на release — нет. Гарантируем, что production-логика не изменится.

Какой инструмент выбрать: Proxyman или Charles?

Для работы с WebSocket и HTTP/2 Proxyman удобнее, Charles надёжнее для legacy и больших команд.

Как настроить rewrite rules?

Rewrite rules позволяют подменять запросы и ответы без изменения кода. В Charles: Tools → Rewrite. Создайте правило: поле для замены (URL, header, body) и значения. В Proxyman: Scripts → Add Script с JavaScript. Пример: замена api.production.com на api.staging.com, добавление токена в заголовок. Типовая настройка — 2-3 правила на проект — занимает 1-2 часа.

Процесс работы

1. Анализ — изучаем стек проекта: сетевой слой (Alamofire, URLSession, Retrofit, OkHttp), наличие certificate pinning, необходимость WebSocket.
2. Настройка прокси — установка сертификата на все устройства (iOS, Android, эмуляторы), конфигурация Wi-Fi proxy, включение SSL Proxying для нужных доменов.
3. Обход pinning — подготовка debug-сборки с условным доверием. Если pinning на библиотеке (например, TrustKit), меняем конфигурацию.
4. Rewrite правила — настройка подмены URL, заголовков или ответов для тестирования specific сценариев.
5. Документация и обучение — фиксируем процесс для команды, проводим 1-часовой вебинар.

Что входит в работу?

• Полная документация по настройке прокси и обходу certificate pinning.
• Доступы к прокси-серверу (локальный или удалённый) с настроенными правилами.
• Обучение команды: 1-часовой вебинар с демонстрацией ключевых сценариев.
• Техническая поддержка в течение недели после настройки.

Типичные сценарии использования

• Проверка заголовков авторизации (Bearer token, API key) — 2-3 запроса.
• Отладка multipart/form-data загрузки файлов.
• Тестирование при медленном соединении (throttling в Charles: Proxy → Throttle Settings, профиль Edge).
• Проверка обработки ошибочных HTTP-ответов (Map Local → подставить 500 ответ).
• Отладка GraphQL запросов и WebSocket фреймов (в Proxyman — live view).

Это экономит до 40% времени QA-инженеров. На типовом проекте с 10 экранами и 5 API-запросами — 2-4 часа в неделю, до 16 часов в месяц. Закажите настройку — получите консультацию по выбору инструмента и интеграцию в ваш CI/CD.

Типичные проблемы и их решения

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

Тестирование мобильных приложений: XCTest, Espresso, Detox и Appium

Flaky-тест, падающий на CI раз в пять запусков без воспроизводимой причины, хуже его отсутствия. Команда перестаёт доверять инфраструктуре и отключает тесты — регрессии проскакивают в продакшн. Мы это видим каждый день и знаем, как выстроить надёжную систему тестирования, которая не требует постоянного внимания. Получите консультацию — оценим ваш проект и предложим архитектуру тестов под ваш стек.

Почему flaky-тесты опасны?

Одна нестабильная проверка может завалить пайплайн, заблокировав релиз. Разработчики тратят 15-20% рабочего времени на перезапуск и анализ ложнонегативных сбоев. Автоматизация без стабильности — не экономия, а потеря эффективности. Мы решаем эту проблему на уровне архитектуры: Gray Box-фреймворки (Detox, Patrol) синхронизируются с состоянием приложения, а native инструменты (XCUITest, Espresso) получают правильные IdlingResource и accessibilityIdentifier. Результат: стабильность >99% на CI.

Unit-тесты: что тестировать, а что нет

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

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

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 на этапе аудита.

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

Detox — E2E фреймворк для React Native, разработанный Wix. Работает на реальных устройствах и симуляторах через Gray Box подход: знает о состоянии JS thread и синхронизируется с ним. Это решает главный flakiness-источник — тест не нажимает кнопку, пока приложение занято. Настройка 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. Время прогона 200 UI-тестов с параллелизацией на 4 симулятора — с 40 минут до 12. На Android аналогично используем Firebase Test Lab с шардингом.

Типичные ошибки при настройке (и как их избежать)

Как мы это делаем: процесс работы

1. Аудит текущего кода и CI — оцениваем flakiness, покрытие, узкие места.
2. Проектирование тестовой архитектуры — выбираем фреймворк, селекторы, моки.
3. Настройка инфраструктуры — CI пайплайн, parallel execution, отчёты (Allure, Xcode Report).
4. Написание тестов — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Интеграция и стабилизация — прогон 200+ тестов, отлов flaky-кейсов.
6. Передача документации — архитектура, запуск, troubleshooting.

Что входит в работу (deliverables)

• Архитектурная документация тестового покрытия
• Настроенный CI-пайплайн с параллелизацией и отчётами
• Код тестов (unit, UI, E2E) с styleguide
• Обучение команды (2 часа воркшопа)
• Доступ к тестовым билдам и CI-логам
• Поддержка в течение месяца после сдачи (фикс flakiness, обновление под новые версии)

Сроки ориентировочно

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