Home

Автор: Владимир Иванов

Оригинальная публикация: http://www.performance-lab.ru/blog/load-testing/mobile-app-load-testing_traffic-recording

Эта статья описывает процесс записи трафика и создание скрипта для jMeter с целью провести нагрузочное тестирование мобильного приложения для iOS и Android.

Введение

Мобильный рынок — один из самых быстрорастущих во всем направлениям: от рекламы до использования в бизнес-сфере.

Использование мобильных устройств в некоторых задачах еще в 2014 году пришло к показателям ПК, поэтому необходимость в тестировании мобильных приложений становится важной пропорционально росту рынка.

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

Сразу стоит уточнить, что встречается разделение на Protocol-Level Load Generation (протокольный) и Device (User Interface) level Load Generation (нагрузка с помощью мобильного клиента).
Первый вариант – стандартная генерация HTTP-трафика с помощью нагрузочного инструмента.
Второй вариант подразумевает наличие реальных устройств, которые создают нагрузку с помощью клиента.
Также есть разделение на производительность непосредственно приложения (в том числе потребление ресурсов “железа” и расход батареи), производительность сервера и производительность сети.

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

Для этого используются те же инструменты, что и для работы с веб-приложениями: Fiddler, jMeter, LoadRunner и т.д.
В данном случае мы используем только бесплатные инструменты.

Дальнейшие шаги делались на устройствах iPhone и iPad, так же данный метод был проверен на устройствах с Android на борту.

Запись трафика

Общая схема записи трафика выглядит следующим образом:

1. Выбор устройства с приложением, работу которого требуется эмулировать.
2. Настройка прокси-сервера, который будет записывать и перенаправлять запросы клиента на сервер (и ответы от сервера клиенту).
3. Подключение устройства к прокси-серверу.
4. На мобильном устройстве выполняются бизнес-операции, которые необходимо записать.

Для этого нам сойдет любая из программ, у которой есть такая функция. В примере ниже используется Fiddler 4, но возможно использовать и Jmeter.

Первым делом нужно установить на устройство сертификат безопасности нашего proxy — SSL сертификат, который позволит нам пропустить и расшифровать HTTPS-трафик через Fiddler.

В Fiddler нужно проставить настройки на расшифровку HTTP(S) трафика и подключение удаленных компьютеров:

Кликните на картинку, чтобы увеличить изображение

Кликните на картинку, чтобы увеличить изображение

Далее нужно вручную настроить прокси подключение на устройстве:

Сертификат находится по адресу http://ipv4.fiddler:номер_порта/.
Скачиваем его через браузер и устанавливаем. На Samsung Galaxy S7 (Android7.0.1) было недостаточно просто кликнуть по сертификату, несмотря на сообщение об успехе, сертификат отсутствовал в системе. Решилось установкой сертификата через параметры безопасности.

Ту же операцию можно проделать с jMeter HTTP(S) Proxy Recorder.

Создание скрипта

Запускаем приложение и делаем все необходимые операции, которые потребуются для скрипта.

После того, как создан тест-план, коррелируем значения и проверяем, правильно ли выполняется скрипт.

На данном этапе процесс идентичен стандартной отладке скрипта.

Если запрос (особенно POST с загрузкой файла) возвращается с ошибкой, его имеет смысл повторно перехватить с помощью другой программы (т.е. ловили трафик в Fiddler, значит теперь сделаем через jMeter, и наоборот) и сравнить, в чем разница.

На практике с приложением

Тестируемое приложение Gloopt – сервис по созданию канала с возможностью делится своими видеороликами длительностью до 1 минуты.
Трафик мы записали через Fiddler, так как jMeter не позволил нам воспроизвести видеоролик и загрузить клип на сервер.
Для конвертирования запросов в скрипт jMeter’а мы использовали плагин авторства нашего коллеги, Дениса Скорнякова (https://git.performance-lab.ru/d.skornyakov/FiddlerJmxCreator) – он сохраняет сессию в .jmx файл. Предварительно прямо из Fiddler можно коррелировать значения.

Если создавать тест-план с помощью плагина, а не вручную, сессию Fiddler лучше сохранить, потому что не все заголовки могут быть перенесены корректно.

Обмен сообщениями между клиентским приложением и сервером выглядит примерно так:

1. Сначала запрашивается информация о файле, из респонза мы узнаем его размер в байтах.

2. Далее приложение посылает запрос на некий отрезок файла, например, от нуля.

Выглядит как “Content-range: bytes был = 0-“, сервер возвращает уже конкретный отрезок, “ Content-range: bytes был = 0-37895”.

Следующий запрос клиента запрашивает часть от 37896 и так далее, пока не дойдем до конца.

В Fiddler, кстати, реквесты со стороны клиента уходили с определенным диапазоном. Поначалу было непонятно, каким образом приложение формирует запрос.
Зато в деббагере Chrome можно было увидеть, что запрашиваемый диапазон зависит от респонза сервера.
Соответственно, получая длину контента, делим его на n частей и через While симулируем просмотр видео.

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

Эту транзакцию не удалось выполнить из jMeter после конвертации – то ли Fiddler специфично воспринимает подобную операцию, то ли в jMeter приходится выкручиваться по-особому.
В итоге пришлось именно эту часть записать помощью jMeter, чтобы были правильно проставлены параметры сэмплера.

В частности, для загрузки видео надо было удалить Content-Type из header’a, прописать MIME Type у отправляемого файла, поставить галочки у “Use multipart/form data for POST” и “Browser-compatible headers”, что не было сделано при конвертации запроса из Fiddler (там сам запрос построен немного по-другому).

Альтернативный вариант записи трафика для Android

Кликните на картинку, чтобы увеличить изображение

В случае, если тестируемое приложение работает под Android, есть альтернативный вариант записи трафика. Для его использования понадобится устройство и приложение Packet Capture. Данное приложение не требует Root-привилегий, может расшифровывать HTTPS трафик и почти полностью автоматически позволяет создать сертификат для расшифровки такого трафика. От пользователя необходимо лишь согласиться с установкой сертификата.

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

По окончанию записи (останавливать запись не обязательно) можно вновь переключиться на Pocket Capture и посмотреть записанные запросы и ответы к ним. На главном экране отображаются все сессии записи. Для просмотра запросов, нужно выбрать текущую сессию (или одну из предыдущих, для просмотра старых записей). Будет отображен список подключений каждого приложения, выходящего в Internet.

Выбираем нужное приложение и видим записанный трафик.

Кликните на картинку, чтобы увеличить изображение

Можно дешифровать его, если нажать соответствующую кнопку. Возможно сохранение отдельных соединений (к сожалению, нет пакетной обработки, т.е. невозможно сохранить всю сессию записи или все запросы приложения).

Кликните на картинку, чтобы увеличить изображение

Запись трафика банковских приложений

К сожалению, при попытке записать трафик мобильных банковских приложений под платформой Android обоими перечисленными вариантами, приложения отказывались работать, ссылаясь на проблемы с подключением. Вероятно, приложения используют ssl-pinning. Однако, и данное затруднение можно обойти.

Можно попытаться использовать Interceptor-NG, Zaproxy, Mallory Proxy, MITMPROXY, WebScarab, Burp Proxy или SSLSplit для SSL MiTM. Для Android можно попытаться использовать модуль SSL unpinning для Xposed, который позволяет перехватывать стандартные вызовы на проверку сертификатов и отвязывать их, или попытаться пропатчить приложение вручную. Важно помнить, что не существует идеальной технологии, и к задаче нужно подходить творчески.

Заключение

Итак, мы перехватили трафик мобильного приложения и превратили его в скрипт для jMeter. Дальнейшие шаги ничем не отличаются от нагрузочного тестирования WEB приложений — корреляция, подготовка тестовых данных, запуск тестов и т.д.

Таким образом можно сказать, что проведение нагрузочного тестирования мобильного приложения мало отличается от того, с чем мы обычно имеем дело.

А если по тем или иным причинам у вас не получилось, то не расстраивайтесь, а обратитесь к нам, мы поможем,  и сможем провести тестирование даже в самом сложном случае.

Обсудить в форуме