Как подключал мобильные приложения к Filler

Подключение мобильных приложений к Fiddler для тестирования

Подключение мобильных приложений к Fiddler (или Charles Proxy, что является более распространённым инструментом для мобильного тестирования, но принципы схожи) — это стандартная практика для анализа, отладки и тестирования сетевого трафика. Я использую эту настройку для множества задач: перехвата и анализа HTTP/HTTPS запросов, модификации данных на лету, симуляции медленных сетей, тестирования API и отлова багов, связанных с сетевым взаимодействием.

Основные шаги настройки Fiddler для мобильных устройств

Процесс состоит из конфигурации как самого Fiddler на ПК, так и мобильного устройства.

1. Настройка Fiddler на компьютере:

• Разрешаем удалённые подключения: Tools > Options > Connections → ставим галочку Allow remote computers to connect.
• Запоминаем порт (обычно 8888).
• Важно отключить брандмауэры или добавить исключение для Fiddler.

2. Определение IP-адреса компьютера в локальной сети:

• Через командную строку:

ipconfig

• Нужен IPv4-адрес (например, 192.168.1.105).

3. Настройка мобильного устройства:

• Устройство и компьютер должны быть в одной Wi-Fi сети.
• В настройках Wi-Fi на устройстве для текущей сети указываем прокси-сервер вручную:

    *   Хост: IP-адрес ПК (`192.168.1.105`).
    *   Порт: порт Fiddler (`8888`).

4. Установка корневого сертификата Fiddler на устройство: Это критически важный шаг для расшифровки HTTPS-трафика.

• На устройстве открываем браузер и переходим по адресу http://IP_ПК:порт, например, http://192.168.1.105:8888.
• Скачиваем и устанавливаем сертификат FiddlerRoot.
• Для iOS необходимо дополнительно активировать доверие к сертификату в Настройки > Основные > Сертификаты.
• Для Android (особенно версий 7+) может потребоваться поместить сертификат в хранилище доверенных (User Credentials) или настроить сетевой security config в самом приложении для dev-сборки.

5. Запуск перехвата трафика:

• В Fiddler включаем захват (File > Capture Traffic).
• Запускаем мобильное приложение. Весь его сетевой трафик появится в списке сессий.

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

После настройки я активно использую эту связку для:

• Валидации запросов и ответов API: Убеждаюсь, что отправляемые JSON/XML-данные корректны, проверяю статус-коды, заголовки, структуру ответов.
• Модификации данных (Breakpoints): Устанавливаю точки останова на запросы или ответы, чтобы изменить параметры на лету. Это незаменимо для:

    *   Тестирования обработки ошибок (например, подменить успешный ответ `200 OK` на `500 Internal Server Error`).
    *   Проверки граничных значений (отправить неожиданно длинную строку или отрицательное число).
    *   Смены флагов функциональности (A/B-тесты).

• Тестирования производительности и слабых сетей: Использую функцию AutoResponder для симуляции медленных ответов сервера или правила Rules > Performance > Simulate Modem Speeds для ограничения пропускной способности. Это помогает проверить таймауты, спиннеры и общее поведение приложения.
• Mock-тестирования и изоляции: С помощью AutoResponder можно заменить ответ от реального сервера на заранее заготовленный файл (.json, .xml). Это позволяет тестировать фронтенд, когда бэкенд ещё не готов, или изолировать конкретный сценарий.
• Отлова ошибок безопасности: Проверяю, не передаётся ли в открытом виде чувствительная информация (токены, пароли), правильно ли используются заголовки безопасности.

Пример практического использования: тестирование обработки ошибки платежа

Задача: Проверить, что приложение корректно обрабатывает ошибку "Недостаточно средств" от платежного шлюза.

Действия в Fiddler:

1. В приложении инициирую платеж.
2. В Fiddler нахожу соответствующий POST-запрос к платежному API.
3. Устанавливаю на этот запрос Breakpoint before response (Rules > Automatic Breakpoints > Breakpoints on Responses).
4. В приложении подтверждаю платеж.
5. Когда запрос "заморозится" в Fiddler, изменяю тело ответа от сервера, подставляя статус "DECLINED" и код ошибки "INSUFFICIENT_FUNDS".
6. Разрешаю отправку модифицированного ответа на устройство.
7. Наблюдаю в приложении: должно появиться понятное сообщение об ошибке, а не краш или зависание.

Важные нюансы и проблемы

• HTTPS и доверенные сертификаты: Самая частая проблема. Для Android 7+ и iOS с строгими политиками безопасности часто необходимо использовать отладочные (debug) сборки приложения, которые доверяют пользовательским сертификатам. Для продакшн-сборок перехват HTTPS часто невозможен — и это правильно с точки зрения безопасности.
• Трафик других приложений: Будет виден трафик всех приложений на устройстве, использующих системный прокси. Важно фильтровать сессии по хосту (www.api.myapp.com) или процессу.
• Производительность: Включённый Fiddler добавляет задержки. Для тестов производительности его нужно отключать.

Этот подход является фундаментальным навыком современного QA-инженера, особенно в эпоху мобильных и гибридных приложений. Он превращает "чёрный ящик" сетевого взаимодействия в прозрачный и контролируемый процесс, значительно увеличивая глубину и эффективность тестирования.