83 подписчика

Тестирование мобильных приложений

6 апреля 20256 апр 2025

4 мин

В разработке и QA часто приходится сталкиваться с тестированием мобильных приложений. Как правило, задача не самая очевидная и сложнее, чем тестирование веб-интерфейсов, где можно просто вызвать консоль разработчика и посмотреть, какие данные приходят и уходят. Дело в том, что мобильное приложение по сути представляет собой «чёрный ящик»: непонятно, что происходит «под капотом», куда обращается приложение, какие данные передаёт и что получает. Иногда бывает, что в процессе разработки не предусмотрели способ тестирования самого приложения, а локализовать проблему необходимо. В таком случае подключают мобильного разработчика, который смотрит, какие данные приходят и уходят, и в целом локализует проблему. Разумеется, это отнимает время, тогда как специалисты QA могли бы сделать это самостоятельно. Давайте попробуем решить этот кейс и разобраться, какими данными обменивается приложение, чтобы QA-специалисты могли локализовать проблему на стороне бэкенда или устройства. Как правило, существ

Оглавление

Тестирование Android приложений с Charles Proxy и Android эмулятором
Что потребуется для работы:
Шаги настройки:

Иногда бывает, что в процессе разработки не предусмотрели способ тестирования самого приложения, а локализовать проблему необходимо. В таком случае подключают мобильного разработчика, который смотрит, какие данные приходят и уходят, и в целом локализует проблему. Разумеется, это отнимает время, тогда как специалисты QA могли бы сделать это самостоятельно.

Давайте попробуем решить этот кейс и разобраться, какими данными обменивается приложение, чтобы QA-специалисты могли локализовать проблему на стороне бэкенда или устройства.

Как правило, существует несколько способов решения этой задачи, например:

Добавление логгера, который выводит все уходящие и приходящие запросы.
Минусы:
- Нужно прятать логгер под какими-то флагами.
-Решать, выводить его в продакшн-версии приложения или нет (например, для воспроизведения проблем на проде).
Проксирование запросов в приложении и перенаправление трафика через прокси.
Добавляется скрытая настройка, позволяющая указывать, через какой прокси отправлять данные.
Минусы:
-Нужно решать, передавать ли данные в открытом виде через HTTP или настраивать сквозное проксирование через промежуточный HTTP-хост, который уже перенаправляет трафик на нужный адрес.

Оба способа подходят для Android и iOS, но для этого необходимо, чтобы мобильное приложение поддерживало соответствующий функционал.

Тестирование Android приложений с Charles Proxy и Android эмулятором

В этом решении мы просто устанавливаем приложение на эмулятор и работаем с ним как с обычным приложением.

Что потребуется для работы:

Android Studio — https://developer.android.com/studio?hl=ru
Charles Proxy — https://www.charlesproxy.com/
ADB Tools (должен идти в комплекте с Android Studio) — https://developer.android.com/tools/adb

Рабочие директории (для Windows):

C:\Users\Default\Android\Sdk\emulator\emulator.exe
C:\Users\Default\Android\Sdk\platform-tools\adb.exe

Оптимально добавить их в переменную окружения Path для удобства. Далее примеры будут приведены с учётом этой настройки, но можно запускать файлы и напрямую из их директорий.

Примечание: пример рассмотрен для Windows, но на Unix-системах механизм будет аналогичным.

Шаги настройки:

1. Создаём Android-эмулятор в Android Studio.
Если ранее не использовали, скачиваем образы.
Важно: выбираем версию без Google Play! Иначе не получится запустить эмулятор с root-доступом.
Например: Android 12.0 (Google APIs).
Максимальная версия, на которой у меня запускалось — Android API 31. Рекомендую использовать её.
На самых свежих версиях, насколько я знаю, есть проблемы с таким запуском.

2. Открываем cmd от имени администратора.

3. Получаем список доступных эмуляторов:

emulator -list-avds

Должен появиться созданный вами эмулятор, например: Pixel_2_API_34

4. Запускаем эмулятор с правами записи в систему:

emulator -avd Pixel_2_API_34 -writable-system

При первом запуске нового образа нужно подождать, пока он развернётся.
В результате должен запуститься эмулятор с мобильным устройством.

5. Открываем второй терминал cmd от имени администратора и получаем root-права:

adb root

6. Перемонтируем диск на эмуляторе:

adb remount

Потребуется перезагрузка:

adb reboot

После перезагрузки снова выполняем:

adb root
adb remount

Не спешите все копировать сразу, часть команд на скриншоте выполняется ниже

7. Настраиваем Charles Proxy:
Запускаем Charles. Сохраняем сертификат.

Сохраняем сертификат Charles для дальнейшего использования

8. Переименовываем сертификат в его хеш.
Для получения хеша понадобится openssl (можно выполнить в Git Bash или на сервере):

openssl x509 -inform PEM -subject_hash_old -in charles.pem | head -1
Пример вывода:

6031e357

Переименовываем файл сертификата в полученный хеш с добавлением ".0".
В примере это будет "6031e357.0". Важно: у вас хеш может отличаться.

9. Копируем сертификат в эмулятор:

adb push 6031e357.0 /system/etc/security/cacerts/6031e357.0

10. Выставляем права:

adb shell chmod 644 /system/etc/security/cacerts/6031e357.0

11. Перезагружаем эмулятор:

adb reboot

12. Проверяем настройки Charles Proxy:
Убеждаемся, что Charles слушает порт 8888.
Включена галочка SSL Proxy Settings → Enable SSL Proxying.
Можно отключить Windows Proxy, чтобы Charles не перехватывал трафик основной системы.