Charles proxy ошибки

Charles crashes

Crashes are fortunately unusual! There are a few things that might be causing it, or will help me diagnose and hopefully fix the problem…

Known Problems

Below is a list of problems that I know about with Charles that you might be having, and the recommended solution:

NOD32 IMON

If you’re running the NOD32 antivirus package and have its IMON service running, you are likely to encounter crashes in Charles – one moment Charles will be running normally and the next it will have just disappeared, leaving your browser broken as it hasn’t corrected your proxy settings (fortunately restarting Charles will remedy that).

There is no fix from NOD32 at this time, so you need to either disable IMON or exclude Charles from it. The later being the preferred option as you continue to benefit from IMON – although you may also find that it interferes with other applications.

Excluding Charles from IMON
We need to add Charles to the exclusions list in order to exclude Charles. Charles is a Java application, so adding the Charles.exe application to the exclusions won’t help: instead you need to add the Charles.exe inside the launch4j-tmp directory in your JRE directory.

Open the NOD32 Control Centre, click on IMON, click on the Setup button to enter IMON Setup.

Go to the Miscellaneous tab and look for the Exclusion panel. Click the Edit… button in the Exclusion panel. The Exclude applications dialog will appear.

Click the Add… button. Find your Java installation. This is probably in C:Program FilesJavajre* where the * is a version number. If you have multiple JREs installed check which version Charles is using (use About Java in the Help menu). Inside the JRE folder will be a launch4j-tmp folder, in which will be the Charles.exe that you need to exclude.

Reporting A Crash

If your problem isn’t described above then please report it to me. What will be a great starting point is if you can send:

• Your OS name and version (eg. Windows XP SP2)
• The version of Java that you’re running Charles in, as reported by the About Java option in the Help Menu
• Look for any Java crash logs that have been created in the Charles directory (eg. C:Program FilesCharles), they will be named hs_err_pid###.log. Please copy and paste one of these into the email.

Finally send all of that to me using the Contact page.

I am trying to get a Charles Log from an android device, and it is not working. The android device’s browser will not connect to the internet after I set up the Wifi with the Proxy.
I have listed the steps I did to set up Charles Proxy on my computer and configuring the android device to use charles proxy.

I am totally grateful for any help, but I just want to point out a couple of things:

*I have the correct the Wifi network & IP address for the Android device proxy settings ( see Step 18 below).

*As far as I know I do not use a VPN or a Firewall on the android device. How can I double check this?

*I have tried the steps below with 2 versions of Charles Proxy.
charles Proxy: 4.2.7
charles Proxy: 3.12.3
I removed and reinstalled the program each time.

*Chrome and Firefox on the android device will not connect to the internet with the proxy set up.

See the list below for the step and Thank you so much!!!

---

System:
MacOS 10.10.5
Android: 6.0.1

1. Menu: Proxy: ticked Mac OS proxy
2. Menu: Help > SSL proxying > Install Certificate
3. In Keychain > found certificate > clicked Always Trust (entered password)
4. In Charles Proxy, clicked Proxy menu
5. Menu > Proxy > SSL Proxying settings
6. Ticked Enable SSL Proxying
7. Clicked Add
8. Host * Port 443.
9. Menu: Proxy > Proxy Settings
10. Clicked Proxies Tab: Http Proxy Port: 8888
11. Ticked: Enable Transparent HTTP proxying
12. Clicked MacOSX tab
13. Ticked: Enable Mac OS Proxy, Use HTTP proxy, Enable MacOS proxy at start up
14. Clicked Mozilla Firefox tab: Enable Mozilla Firefox Proxy, Use HTTP proxy, Enable Mozilla Firefox proxy at startup.
15. Menu: Proxy > Access Control settings
16. Clicked add, set IP Range 0.0.0.0/0
17. Ticked: Prompt to allow unauthorized connection.
18. Menu > Help > Local IP address — Wrote this IP address down and used this number to set up android device.

On Android device:

1. Connect Android to Mac with USB cable. Port USB 2.0
2. Settings > Network & Internet > Wi-Fi
3. long-tapped active wifi connection, selected: Modify network
4. Expand the Advanced options, tapped at None below Proxy and selected Manual
5. Entered IP address from step 18 in the Proxy hostname field .
6. Entered 8888 into the Proxy portfield
7. Clicked Save.
8. Open Chrome
9. type http://charlesproxy.com/getssl/ or short version chls.pro/ssl
10. Get error message: “err_proxy_connection_failed” or «err_connection_timed_out»
    Please note: No dialog box appears on Charles Proxy on Mac about the Android device.
11. As far as I know I do not use VPN and I do not use a Firewall on the android device. How can I check this?

To manually add the security certificate to the Android device:
30: On Mac desktop – Charles Proxy > Menu Help > SSL Proxying > Save Certificate
31. Saved certificate to desktop.
32. Copied certificate to android device / downloads folder (not on SD card) via USB cable.

On android device:
33. Found charles proxy certificate file, long clicked.

1. In dialog box: renamed certificate Charles Proxy Certificate

2. Clicked VPN & Apps

3. Clicked save.

4. NB: Here I am not asked to re-enter my device PIN

5. Open Chrome App. Get the error message “err_proxy_connection_failed” or «err_connection_timed_out»

6. Android Device: notification that a third party might be watching.

7. I check if the certificate is installed: Settings > Security > Trusted Credentials > User > the XYZ Charles Proxy security certificate is installed.

I have also done Steps 30 to 38 with the certificate with a crt and a pem suffix.

I have tried the following variations:
*Setting up the Proxy on Android device without USB connection to mac
*Setting up the Proxy on Android device while connected to mac via USB
*Setting up the proxy on Android device before opening Charles Proxy and after.

I have no idea what to try next! Hope you can help and thank you for reading this far.

High level steps

1. Go to Charles Proxy on your Mac. Help >> SSL Proxying >> Install Charles Root Certificate on Mobile device
2. Configure the IP given your WiFi settings — HTTP Proxy Settings
3. Hit Allow on your Mac
4. Go to chls.pro/ssl on your iPhone
5. Download the profile
6. Find the profile on your iPhone Settings
7. Install the profile into your iPhone
8. Trust the cert in your iPhone Settings >> About

Detail steps

The instructions for getting it working for the iOS couldn’t be any worse.

So in case you needed to configure CharlesProxy for your iPhone connected to your Mac, then the steps are as followed:

Assuming your Mac’s browser IP address is 192.168.1.5 then you should NOT put that IP Address into your iPhone’s browser.

Where should you put it? Inside the wifi settings. But where? In the IPV4 ADDRESS settings? AGAIN NO!

You should go SCROLL DOWN and put the IP + port number in HTTP PROXY.

Then the rest of the steps are easy to follow. Just open Safari on your iPhone and open chls.pro/ssl and that should prompt your Mac. Hit Allow.

Then on your iPhone you should get a prompt for downloading a cert. Download it.

Go to Settings app. Find the Profile you downloaded. Click it.

Install it:

Trust it:
Go to Settings app >> About. Scroll all the way to the bottom. >> Certificate Trust Settings >> Trust the cert.

IMPORTANT

Once you’re done, then you need to set the HTTP proxy back to Automatic. Otherwise your iPhone will think it needs to do manual proxy and things won’t work

Also note: VPN should be turned off at all times (during initial setup and usage). Otherwise instead of routing the traffic through Charles it will get routed through your VPN.

I ended up deleting my VPN app just to be safe.

Время на прочтение
11 мин

Количество просмотров 37K

Привет, Хабр! Статья была ранее опубликована в блоге компании, который сейчас удален. Перевыкладываю, так как считаю, что статья не потеряла актуальность на текущий момент времени.

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

Если повезло, то кандидат знает о необходимости проверки сетевого взаимодействия, но, за редким исключением, его знания ограничены Rewrite или Breakpoints.

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

Случай из жизни

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

Ситуация 1: тестировщик пропускает баг вёрстки счётчика подписчиков для пользователя, у которого больше миллиона фолловеров. Неприятно, но на ценности продукта для пользователя сильно не скажется.

Ситуация 2: в приложение добавлена настройка получения push-уведомлений. Проверяя их отключение, тестировщик увидел подтверждение и посчитал сценарий пройденным. После релиза посыпались жалобы пользователей на слишком большое количество уведомлений, им приходилось отключать их на уровне ОС или удалять приложение. Для бизнеса такая ситуация критична: метрики искажаются, а пользователи утекают.

Почему так произошло? На бэкенде раскатили неудачный коммит, и на запрос отключения уведомлений возвращалась ошибка сервера. Мобильный клиент не обрабатывал получение кода 500, но тестировщик и пользователь видели попап отписки, хотя она не происходила. Если бы тестировщик обратил внимание на нестандартный код ответа API, то проблему быстро бы обнаружили и решили. Правда, в этот случай ещё вмешался сломанный мониторинг и отсутствие тестов на бэкенд, но всегда помните, что вы можете оказаться единственным тестировщиком на задаче или продукте и перепроверить будет некому.

К чему это всё? К тому, что использование сниффера может избавить вас от таких ошибок.

Что мы используем?

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

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

Задача 1. Слушаем, смотрим, анализируем

Подготовка

Если знаете, как установить Charles в связке с мобильным устройством, можете смело пропускать эту часть.

1. Устанавливаем и запускаем Charles Proxy.
2. Для расшифровки SSL-соединений потребуется установка сертификата. Переходим по ссылке chls.pro/ssl на тестовом устройстве.
3. Для iOS необходимо дополнительно подтвердить доверие сертификату в настройках: General -> About -> Trust Certificates. Для Android 7.0 и выше в код приложения должен быть добавлен network_security_config. Подробно описывается здесь.
4. Настраиваем проксирование через Charles:
   • если ПК c Charles и тестовое устройство принадлежат одной Wi-Fi сети, переходим в настройки Wi-Fi тестового девайса, прописываем настройки прокси-сервера: IP-адрес устройства, на котором запущен Charles, в поле Server (Hostname), порт 8888;
   • если ПК с Charles подключен к проводной сети, но с него можно раздать Wi-Fi, то делаем это;
   • если ПК с Charles подключен к проводной сети и раздать интернет с него нельзя, нам понадобится дополнительное устройство, способное раздавать беспроводной интернет (роутер), на нём настраиваем Port Forwarding на адрес нашего ПК. Ищем «проброс портов <модель роутера>».
5. После того как мы связали тестовое устройство и ПК со сниффером, в Charles появится запрос на разрешение подключиться мобильному устройству.
6. Включаем SSL Proxying Settings на нужных хостах.

Результат шага: мы запустили Charles, отображается трафик приложения, а также соединения рекламных и системных сервисов.

Примечание 1: по дефолту трафик ПК будет также проходить через Charles. Чтобы в сниффере отображался только трафик подключенных устройств, снимаем галку в настройках проксирования.

Примечание 2: мы не включаем расшифровку сетевых соединений на все хосты сразу, т.к. это помешает проверке сценариев интеграции со сторонними сервисами (Twitter, Facebook, и т.д), покупки и прочего — самоподписанный сертификат Charles не вызовет доверия.

Фильтрация информации

Найти интересующую тестировщика информацию можно несколькими способами.

Structure view + Focus Mode

Представление Structure view удобно, если хотим узнать, к каким ручкам выполняется обращение. Список проксируемых ручек отображается слева. Выберем конкретный запрос и в правой части увидим информацию о нём. Во вкладке Overview будет техническая информация по статусу соединения, коду ответа, времени отправки запроса и времени получения ответа и так далее, во вкладке Contents можно выбрать формат и заглянуть в тело запроса или ответа, а также посмотреть заголовки.

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

Теперь ручки, для которых выбран Focus, будут закреплены в верхней части списка. Остальные сгруппированы в Other Hosts.

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

Да, стало проще искать информацию о конкретных пакетах. Ещё хотелось бы видеть на одном экране техническую информацию о пакете и тело. Кроме того, в этом представлении не видно, насколько позже или раньше уходит один запрос относительно другого. В этом нам поможет Sequence view.

Sequence view

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

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

Можно создать кастомную колонку по любому полю заголовков запроса/ответа. Например, рекламные SDK часто передают полезную информацию в заголовках ответа.
Для настройки нажимаем на заголовок таблицы ПКМ и выбираем New Custom Header Column. Указываем название заголовка.

Ставим галочку Focused и видим только те ручки, что ранее выбрали через Structure view.

Ещё одна классная фича — возможность обходиться без галочки Focused и делать фильтрацию с помощью регулярок. Для этого нужно нажать на Settings справа от строки фильтрации и поставить галочку тут:

Теперь, составив, например, такой фильтр, увидим тот же результат, как при использовании галочки Focused.

Анализируем результаты

Ещё раз зафиксируем, на что в общем случае стоит обратить внимание:

1. При выполнении действия на клиенте с него уходит запрос по нужному URL.
2. Время между действием и отправкой запроса.
3. Соответствует ли метод запроса ожидаемому.
4. В каком формате переданы данные серверу, не пусты ли значения.
5. Не дублируется ли запрос.
6. Вернулся ли ответ сервера за допустимое время, соответствуют ли код и тело ответа ожиданиям.
7. Блокирующий ли запрос (важно для запросов на старте приложения).
8. Отобразились ли полученные данные на клиенте (если применимо) за допустимое время.

В каких случаях стоит насторожиться и бежать к бэкендерам:

• запрос не завершается;
• возвращается неожиданный код ответа бэкенда;
• в ответе бэкенда возвращается 200 ОК, но в теле содержится ошибка;
• возвращается ошибочный код ответа от бэкенда (например, 500), но в теле ошибка отсутствует;
• мы не понимаем, что происходит.

Задача 2. Меняем API

Случается, что мобильным тестировщикам приходится проверять фичу на тестовом API, которое пока не задеплоено на продакшен. Можно попросить разработчиков добавить developer mode, в котором будет возможность изменить ручку API, но можно это сделать и без внесения изменений в код.

Итак, у нас есть URL тестовой среды, на которой можно протестировать фичу — https://api-1111.ifunny.mobi, и URL продового API — https://api.ifunny.mobi.
Charles позволяет решить эту задачу следующими способами.

Map Remote

С помощью Map Remote можно без СМС и регистрации выполнить переадресацию запросов с некоторого URL (Map From) на другой (Map To). Подменяем только хост, путь целиком или только параметры (в зависимости от задачи).
Настраиваем Map Remote для решения текущей задачи. Чтобы перейти в настройки Map Remote, выбираем Tools: Map Remote или для macOS (⌘⌥M). Шорткаты ускорят работу в Charles.

Примечание: Charles автоматически распарсит части URL при копировании и вставке. Вставляем URL в строку Host, нажимаем Tab. Protocol, Port, Path, Query заполнятся сами.

Rewrite

Rewrite — самый мощный механизм Charles. В коллекциях на текущем проекте порядка 30 наборов рерайтов (Rewrite sets) с десятками вложенных правил (Rewrite rules).

Для создания Rewrite нужно перейти в Tools -> Rewrite (или для macOS нажать — ⌘⌥R). Для добавления Rewrite set жмём на (1), ему можно задать название в поле (2). Rewrite sets могут быть ограничены набором хостов, на которых применяются правила. Если область действия правил (Location) не задать, то они будут применяться ко всем хостам. Для задания Location жмём на (3).

Чтобы добавить первое правило, нажимаем на (4). Появляется скромное окошко, обладающее большими возможностями.

Rewrite — это подмены: в заголовках (header rules), в пути (URL), в параметрах (query parameter rules) и в теле запроса или ответа (body rules).

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

Для правила требуется указать область действия: запросы клиента (Request), ответы сервера (Response) или и те, и другие. Устанавливаем соответствующие чек-боксы.

Рассмотрим алгоритм применения Rewrite. Если указать маркер применения правила через блок Match, выполнится поиск этого значения в пакете, а затем замена на значение из блока Replace. Здесь и в некоторых других местах полезно использовать регулярные выражения, при необходимости — соответствующий чек-бокс. При пустом блоке Match замена применится везде, где можно. Заменится весь хост при типе Host или всё тело пакета при типе Body.
Ещё можно выбрать опцию «Подменить один раз» (Replace First), тогда Rewrite будет применён только по первому совпадению. Заполнение полей может оказаться недоступным для некоторых типов правил.

Для смены API подойдёт Type: Host. Нужное правило выглядит так:

Можно не прописывать Match, потому что указан Location, к другим хостам правило не применится, но Value пришлось бы указать целиком.

Задача 3. Проверяем нестандартные коды ответа

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

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

• какие коды ошибок возвращает бэкенд;
• какая обработка ожидается при ошибке сервера: 500, 503;
• какая обработка ожидается при ошибках клиента: 403, 404;
• требуется ли повторить отправку запроса при получении ответа с ошибкой;
• должны ли уходить следующие запросы, пока не получен успешный ответ.

Варианты решения:

1. Сделать редирект на URL, который отдаст нужную нам ошибку, но надо иметь список соответствующих URL.
2. Универсальный способ решения этой задачи — через Rewrite с типом Response Status.
   Создаём правило. Указываем в Replace нужный код ответа:
   
3. Для возвращения ошибок типа 403 можно использовать механизмы Block list (для macOS — ⌘⌥B), Allow list (для macOS — ⌘⌥W).

Block Lists, Allow Lists

Block List позволяет добавить URL, запросы к которым будут заблокированы путем разрыва соединения или возврата 403 кода ответа. Включаем так:

Allow list работает по обратной логике: указываем те URL, обращения к которым разрешены. Остальные соединения сбрасываются или возвращается 403 ошибка.

Задача 4. Безопасный способ подменить тело

Представьте, вы нашли баг: приложение падает при получении рекламного креатива. Сниффер включён, сессия сохранена.

Через время разработчику требуется воспроизвести ситуацию у себя, а рекламодатель не спешит возвращать ту же рекламу, что привела к ошибке. Что делать? Открываем сохраненную сессию и находим креатив.

Map Local

Для подмены ответа сервера целиком можно использовать Map Local (⌘⌥L). Это удобный инструмент, который позволяет заменить удалённый файл на тот, что хранится локально на машине. Указываем ручки, ответы к которым надо подменить, и выбираем файлы у себя в системе, предварительно сохранив их в нужном расширении/формате (json, xml и т.п., поддерживаются медиа и другие менее популярные форматы). В контексте представленного кейса нам надо откопать приводящий к проблеме креатив из сохранённой сессии, положить себе в папку и включить на него Map Local.

Здесь можно также воспользоваться Rewrite. Выбираем Type: Body, поле Match остаётся незаполненным, если заменяем тело целиком. Вставляем простыню с телом ответа в поле Value блока Replace, применяем.

Заменить определённую часть запроса/ответа через Rewrite также не представляет сложности.
Это полезно, когда мы хотим получить на клиенте какие-то значения, которые трудно сгенерировать на тестовой или продакшен-среде. Для этого в поле Match указываем, какую пару «ключ-значение» ответа API мы ищем, а в Replace — на какую пару подменяем.

Задача 5. Таймауты и троттлинг.

Плох тот тестировщик, который тестирует свое приложение только в условиях мощного офисного WiFi, находясь в одной сети с серверами. Как можно выяснить, что потери и задержки не нарушают usability для пользователя, или обнаружить, что при получении таймаута приложение не может восстановиться?

Настройки троттлинга (⇧⌘T) в Charles выглядят так :

Подбираем те, которые превратят любимое приложение в тыкву, а для тестирования таймаутов используем Breakpoints (⇧⌘K).
Примечание: Пользуйтесь возможностью включить троттлинг только на определённых хостах.

Брейкпоинты в Charles — это очень крутая штука. Информация о них будет в первых результатах поисковой выдачи по запросу «как подменить ХХХ в Charles». Их действительно можно использовать вместе или вместо Rewrite, но для подмен они не очень подходят.

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

Из неочевидного

Оптимизируем Rewrite

Что ещё здесь интересного? Активных правил в наборе может быть несколько, они применяются последовательно, сверху вниз. Значит, одно и то же место может изменяться несколько раз подряд.
Если есть какая-то структура, которая должна принимать несколько вариантов значений в зависимости от необходимости, то можно сделать следующее:

1. Берём структуру, которую хотим подменить.
2. Выносим её в переменную.
3. Создаём набор правил по замене этой переменной на нужные тестовые структуры.

Например, приложение использует некоторое количество ID для получения рекламы. Мы хотим их все подменять то на один тестовый ID, то на другой. Здесь сначала все ID будут заменены на your_var, а your_var будет следом заменено в зависимости от простановки чек-боксов.

Если включить оба чек-бокса из примера одновременно, то вторая подмена уже не применится.

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

Примечание 2: «Я всё делаю правильно, но Rewrite не работает».

• Проверяем, что Rewrite был применён к выбранному пакету, информация об этом в явном виде есть во вкладке Overview и Notes:

  

• Включаем логи в Charles в окне Rewrite:

  

  Window -> Error Log может содержать полезную информацию. Например, как ниже: проверяю правило, найден матч, выполнен Rewrite.

  

• Убедимся, что другие наборы Rewrite не переписывают поверх наше правило. Отмеченные чек-боксами наборы также применяются друг за другом, сверху вниз, как и правила внутри набора.

• Проверяем Location.

• Убедимся, что все чек-боксы на своих местах.

• Убедимся, что не произошло ошибки при копировании-вставке. Известный баг Charles на macOS: при копировании в буфер обмена при раскладке клавиатуры, отличной от английской, данные в буфере задваиваются и вставляется два значения вместо одного.

Auto save

Один из недостатков Charles — утечки памяти, возникающие при продолжительной записи сессии. Чтобы избежать утечек, необходимо регулярно очищать активную сессию. Из-за этого возникают ситуации, когда вы случайно очистили нужную сессию. Чтобы защититься, автоматизируем сохранение сессий.

Перейдём в Tools -> Auto Save (⌘⌥A), выберем интервал сохранения сессий и путь для сохранения chls-файлов. Теперь через каждую минуту сессия будет сохраняться локально, а затем очищаться в Charles без дополнительных действий с вашей стороны.

Mirror

Еще одна не самая очевидно полезная функция — Mirror (⌘⌥I). Эта фича позволяет автоматически сохранять все ответы, возвращаемые в Charles. Они раскладываются локально в такой же иерархии, как на сервере. Если внезапно случился даунтайм на бэкенде, отвалилась тестовая среда и так далее, у вас есть готовые моки для Map Local.

На этом всё. Я постаралась раскрыть возможности Charles Proxy для тестировщиков мобильных (и не только) приложений в разрезе тех задач, которые мы решаем в FunСorp. Если какие-то функции, которые вы используете, остались за бортом, пожалуйста, напишите об этом в комментариях.

И помните: хороший тестировщик клиент-серверных приложений всегда прикладывает к багу сессию из любимого сниффера.