Первые шаги с Fiddler Classic
Привет! После знакомства с Charles Proxy большинство из читателей захотело узнать больше про инструменты мониторинга и анализа HTTP/HTTPS трафика. Расскажем про популярный у многих тестировщиков Fiddler. Описать все возможности Fiddler в одной статье вряд ли получится, поэтому давайте рассмотрим базовые возможности, которыми мы пользуемся каждый день.
Fiddler это:
Кроссплатформенное приложение прокси-сервера для отладки HTTP. Он позволяет пользователю просматривать HTTP, HTTPS и активированный трафик TCP-порта, доступ к которому осуществляется с локального компьютера, на него или через него. Сюда входят запросы и ответы, включая HTTP-заголовки и метаданные (например, файлы cookie, кэширование и кодирование информации), с функциями, предназначенными для помощи разработчикам и тестировщикам в анализе соединений и обмене сообщениями.
Первые шаги
1. Установка и запуск
Для начала необходимо загрузить и установить приложение.
Если у вас операционная система MAC или Linux, то для этого Вам необходимо будет перейти в соответствующий раздел для загрузки специальной версии Fiddler Everywhere. В данной статье мы будем рассматривать работу с Fiddler Classic для ОС Windows.
2. Выбор браузера для сниффинга
3. Начинаем сниффить трафик
В открывшемся диалоговом окне нам необходимо выбрать вкладку HTTPS.
Далее необходимо выбрать чекбокс «Decrypt HTTPS traffic». Далее разрешить установку сертификата.
После того, как мы установили сертификат, давайте в браузере откроем, например, сайт Юлы. В разделе слева мы видим все запросы к хосту api.youla.io и не только. Среди запросов выберем нужный нам запрос, например на выдачу всех товаров: https://api.youla.io/api/v1/products
Для того, чтобы декодировать ответ, необходимо нажать на «Response body is incoded. Click to decode.».
4. Настройка прокси на Android
Далее необходимо выбрать чекбокс «Allow remote computers to connect» и «Capture FTP requests». Fiddler теперь прослушивает порт 8888 (это порт по умолчанию, вы можете изменить его из приведенной выше настройки). Для применения настроек, нажимаем «ОК» и перезапускаем Fiddler.
Теперь нам необходимо настроить наше Android устройство. Возьмите в руки телефон, откройте Свойства сети → Название сети WiFi → Прокси-сервер → Вручную → Имя хоста: *ваш IP* / Порт: *8888* → Сохраните измененные свойства сети (указывается IP адрес вашего ПК, на котором установлен Fiddler).
Перейдем по ссылке http://ipv4.fiddler:8888 и скачаем FiddlerRoot certificate, далее начнется автоматическая загрузка сертификата. Откройте его, задайте имя сертификата, и теперь у вас есть доступ к трафику Android-приложения.
5. Настройка прокси на iOS
Возьмите в руки iPhone, откройте Свойства сети → Название сети WiFi → Прокси-сервер → Вручную → Имя хоста: *Наш IP* / Порт: *8888* → Сохраните измененные свойства сети.
Далее перейдите в Настройки → Профиль загружен → Установить.
Затем перейдите в Настройки → Основные → Об этом устройстве → Доверие сертификатам → найдите установленный сертификат и сделайте его «Доверенным».
Операции над запросами
Справа, в окне, где находятся request и response, располагаются дополнительные инструменты:
Statistics — позволяет получать различные статистики как по одному запросу, так и по пачке выделенных;
Inspectors — дает возможность просматривать в различном виде заголовки и данные запроса;
Filters — позволяет следить за конкретными запросами;
Timeline — визуальное представление выполненных запросов на временной шкале.
Подмена данных в Fiddler Classic
Представим, что нам надо протестировать на клиенте верстку. Нужно проверить, как будет отображаться большое количество бонусов у пользователя. Один из вариантов, который многие предложат: изменить в БД количество бонусов и проверить на клиенте. Да, вы будете правы! Однако на сервере может быть кэш, и необходимо подождать какое-то время, пока количество бонусов не обновится, либо просто подключиться к самой базе и выполнить запрос — это занимает определенное время. Есть вариант проще: изменить ответ от сервера! В Fiddler Classic есть несколько вариантов подмены данных, рассмотрим некоторые из них:
1.1 Automatic Breakpoints
Выполним запрос на пользователя https://api.youla.io/api/v1/user/5e6222bbbedcc5975d2375f8 и после выполнения запроса с клиента, в нашем случае это android приложение Юла, request запроса отображается справа. Мы его можем отредактировать.
У нас имеется приложение и профиль пользователя, у которого сейчас 45 бонусов на счету:
Запрос, в котором приходит это количество бонусов: https://api.youla.io/api/v1/user/5e6222bbbedcc5975d2375f8
В левой части экрана мы видим ответ от сервера.
Найдите нужный параметр — «bonus_cnt»:45. Далее измените значение параметра bonus_cnt, например, на 1 000 000 бонусов, и нажмите «Run to Completion».
На клиенте отобразится новое количество бонусов. Мы богаты!
1.2 AutoResponder
AutoResponder — это некая точка остановки запроса. Когда обнаруживается запрос из заданного списка, он отображается справа и с ним можно взаимодействовать.
Выберем необходимый нам запрос и перетащим его в правую часть.
После перетаскивания будет выглядеть так:
Далее нам надо изменить правило, для этого изменим:
METHOD:PUT EXACT:https://api.youla.io/api/v1/user/5e6222bbbedcc5975d2375f8?adv_id=99d548bc-0ca0-434e-b016-24611313d9de&app_id=android%2F10777&uid=85c9a921c27fb0e8&usr_latitude=55.9332685&usr_longitude=37.5032966×tamp=1607977265
На:
REGEX:.+/user/5e6222bbbedcc5975d2375f8*
Нам не важна часть до «/user/5e6222bbbedcc5975d2375f8» и после, сохраним, нажав Save. Далее правой клавишей мыши по запросу –> Edit Response.
В открывшемся окне идем в RAW, изменяем ответ:
Изменим значение с «45» на «1000000» бонусов:
Сохраним измененный ответ, нажав «Save» и перезапрашиваем экран «Профиль пользователя». Мы богаты:
Моделирование скорости
if (m_SimulateModem) <
// Задержка отправки на 300 мсек на каждый загруженный КБ.
oSession [«просачивание-задержка»] = «300»;
// Задержка приема 150 мс на загруженный КБ.
oSession [«задержка-отклик»] = «150»;
>
Конструирование запросов
Представим, что нам нужно самостоятельно отправить запрос и посмотреть ответ. Для данной задачи есть инструмент Request Builder. С помощью данного инструмента можно самостоятельно конструировать HTTP-запросы. В качестве примера давайте запросим товары с экрана «Главная» в сервисе Юла.
Сначала выберем нужный нам метод, в нашем случае это GET запрос. Далее составим сам запрос: http://api.youla.io/api/v1/products
Следующим шагом — выполним наш запрос, нажав Execute. В левой части мы видим выполненный запрос на товары. Выберем данный запрос и через инструмент Inspectors посмотрим запрос и ответ:
Управление трафиком с использованием Fiddler
Автор: Ольга Еременко, QA Engineer
При тестировании сайтов или мобильных приложений иногда возникает необходимость не только отловить трафик между клиентом и сервером, но и модифицировать его, чтобы посмотреть, как это обработает бэкенд и что поменяется на UI.
В таких случаях можно использовать прокси-сервер Fiddler — промежуточное звено между клиентом (браузер, мобильное приложение и т. д.) и целевым сервером. Скорее всего, этот инструмент вам известен, но обычно говорят о нем вскользь. Мы по шагам разберем, как проверить с помощью Fiddler, что отобразится на UI при изменении запроса к серверу или возвращаемого ответа.
Предположим, есть сайт dataart.ru. На его главной странице выводится блок с будущими ивентами. Если никаких событий нет, то и секция, соответственно, не должна отображаться вместе с заголовком и вспомогательными иконками.
Но что делать, если контент есть, а проверить кейс с отсутствием будущих ивентов нужно? Один из вариантов — использовать Fiddler.
Итак, моделируем случай, когда на главной странице нет будущих ивентов:
1. Запускаем Fiddler. Чистим Web Sessions list слева.
2. Включаем Capturing в левом нижнем углу, чтобы отлавливать трафик.
3. Обновляем страницу dataart.ru в браузере и видим отправленные запросы в левой части окна Fiddler. Нас интересует запрос GET “/Umbraco/Api/Events/GetEventsForHomePage?tags=8”, который возвращает будущие события для нашей страницы. Если в ответе ничего не приходит, то блок с ивентами, заголовком и вспомогательными иконками не отображаются.
4. В этом случае можно модифицировать либо запрос перед отправкой на сервер, либо ответ на этот запрос перед тем, как его получит клиент.
В Fiddler это можно реализовать с помощью breakpoints. Вручную breakpoints могут задаваться через QuickExec консоль следующим образом:
bpu https://dataart.ru/Umbraco/Api/Events/GetEventsForHomePage?tags=8 — создаем breakpoint перед отправкой нужного запроса на сервер.
bpа https://dataart.ru/Umbraco/Api/Events/GetEventsForHomePage?tags=8 — создаем breakpoint перед возвращением ответа клиенту.
Давайте рассмотрим каждый вариант отдельно.
5. Чтобы изменить запрос перед отправкой на сервер, выполняем команду в QuickExec консоли:
bpu https://dataart.ru/Umbraco/Api/Events/GetEventsForHomePage?tags=8
Обновляем в браузере страницу dataart.ru (в это время Capturing должен быть включен для Fiddler) и видим, что выполнение нужного нам запроса приостановлено. На это указывают иконка красного цвета напротив запроса в интерфейсе Fiddler и отсутствие блока с ивентами на самой веб-странице.
Что можно сделать на этом этапе? Изменить/добавить/удалить заголовки, куки, параметры запроса и т. д. Чтобы в ответе ничего не пришло, нам достаточно, например, во вкладке WebForms указать такое значение параметра tags, которое не должно вернуть никаких результатов.
После необходимых изменений запроса все, что остается сделать — кликнуть на Run to Completion и посмотреть на результат в браузере.
Важный момент: чтобы отключить breakpoints, нужно ввести в QuickExec консоль команды “bpu “ или “bpa“ без аргумента. Перед тем как перейти к рассмотрению следующего варианта, желательно убрать созданный breakpoint для запроса через “bpu “ соответственно.
6. Чтобы изменить ответ на запрос перед возвращением его клиенту, выполняем команду в QuickExec консоли:
bpa https://dataart.ru/Umbraco/Api/Events/GetEventsForHomePage?tags=8
Обновляем в браузере страницу dataart.ru (в это время Capturing должен быть включен для Fiddler) и видим, что отправка клиенту нужного нам ответа приостановлена. На это указывают иконка красного цвета напротив запроса в интерфейсе Fiddler и отсутствие блока с ивентами на самой веб-странице.
Для нашей цели достаточно подменить тело ответа. Переходим во вкладку TextView и вместо всего содержимого вставляем ответ, который приходит в тех случаях, когда нет результатов — <«items»:[],«total»:0>. Но не забываем, что изменять можно разные данные (статус код, заголовки и т. д.).
Теперь все, что остается сделать — кликнуть на Run to Completion и посмотреть на результат в браузере.
Существуют и другие способы подключения breakpoints, об этом можно прочитать в небольшой статье Эрика Лоуренса, создателя Fiddler.
Fiddler-инструмент для анализа трафика мобильных приложений. Выявляем уязвимости
Разработчики большое внимание уделяют удобству и внешнему виду, однако вопросам безопасности не всегда уделяется должное внимание. Недостаточная защищенность приложения увеличивает репутационные риски для компании-разработчика, а утечка конфиденциальных пользовательских данных негативно сказывается на его деловой репутации.
Большинство современных мобильных приложений построены на клиент-серверной архитектуре. Как правило, клиент функционирует под управлением одной из популярных мобильных ОС – Android или iOS, и обменивается данными с сервером. Использование открытых незащищенных протоколов передачи данных многократно увеличивают риски компрометации передаваемого трафика. Но даже защищенные соединения не всегда дают 100% гарантию надежности сохранности данных.
В данной статье мы познакомимся с инструментом Fiddler, позволяющим перехватывать и анализировать весь трафик между клиентом и сервером. Данный инструмент может помочь выявить уязвимости в процессе клиент-серверного взаимодействия мобильного приложения.
(Если вы уже работали с этим инструментом, делитесь опытом в комментариях)
Для начала установите Fiddler на ПК или ноутбук. Убедитесь, что ПК/ноутбук и смартфон находятся в одной сети (например, подключив устройства к одному wifi-роутеру). Это условие является обязательным, т.к. устройства не увидят друг друга. Проверить связь между устройствами можно через команду ping.
Далее, убедитесь, что Fiddler может принимать входящие соединения:
Настройка устройства на базе Android
Убедитесь, что Fiddler запущен и брандмауэр Windows отключен, далее на Android-устройстве выполните шаги:
После нажатия на кнопку «Сохранить» весь трафик смартфона должен быть виден в окне Fiddler.
Настройка устройств на базе iOS
Убедитесь, что Fiddler запущен и брандмауэр Windows отключен, далее на iOS-устройстве выполните шаги:
После нажатия на кнопку «Сохранить» весь трафик смартфона должен быть виден в окне Fiddler.
С этими настройками возможен перехват только незащищенного HTTP-трафика. Для работы с защищенным HTTPS-трафиком потребуется установка корневого сертификата на устройствах, а также дополнительная настройка Fiddler.
Для Android: скачайте FiddlerRoot certificate, откройте его, установите и задайте имя.
Для iOS: скачайте FiddlerRoot certificate, откройте его, нажмите «разрешить», после чего перейдите в Настройки → Профиль загружен → Установить. Далее в Настройках → Основные → Об этом устройстве → Доверие сертификатам → найдите сертификат и сделайте его доверенным.
После этого вы сможете работать и анализировать защищенный HTTPS-трафик в Fiddler.
Fiddler-инструмент для анализа трафика мобильных приложений. Выявляем уязвимости
Согласно статистике, в 2020 году мобильные приложения были загружены пользователями более 240 млн раз, и это число продолжает расти.
Разработчики большое внимание уделяют удобству и внешнему виду, однако вопросам безопасности не всегда уделяется должное внимание. Недостаточная защищенность приложения увеличивает репутационные риски для компании-разработчика, а утечка конфиденциальных пользовательских данных негативно сказывается на его деловой репутации.
Большинство современных мобильных приложений построены на клиент-серверной архитектуре. Как правило, клиент функционирует под управлением одной из популярных мобильных ОС – Android или iOS, и обменивается данными с сервером. Использование открытых незащищенных протоколов передачи данных многократно увеличивают риски компрометации передаваемого трафика. Но даже защищенные соединения не всегда дают 100% гарантию надежности сохранности данных.
В данной статье мы познакомимся с инструментом Fiddler, позволяющим перехватывать и анализировать весь трафик между клиентом и сервером. Данный инструмент поможет аудитору выявить уязвимости в процессе клиент-серверного взаимодействия мобильного приложения.
Подготовительные шаги
Для начала установите Fiddler на ПК или ноутбук. Убедитесь, что ПК/ноутбук и смартфон находятся в одной сети (например, подключив устройства к одному wifi-роутеру). Это условие является обязательным, т.к. устройства не увидят друг друга. Проверить связь между устройствами можно через команду ping.
Настройка Fiddler
Далее, убедитесь, что Fiddler может принимать входящие соединения:
Настройка устройства на базе Android
Убедитесь, что Fiddler запущен и брандмауэр Windows отключен, далее на Android-устройстве выполните шаги:
После нажатия на кнопку «Сохранить» весь трафик смартфона должен быть виден в окне Fiddler.
Настройка устройств на базе iOS
Убедитесь, что Fiddler запущен и брандмауэр Windows отключен, далее на iOS-устройстве выполните шаги:
После нажатия на кнопку «Сохранить» весь трафик смартфона должен быть виден в окне Fiddler.
Перехват HTTPS-трафика
С этими настройками возможен перехват только незащищенного HTTP-трафика. Для работы с защищенным HTTPS-трафиком потребуется установка корневого сертификата на устройствах, а также дополнительная настройка Fiddler.
Для Android: скачайте FiddlerRoot certificate, откройте его, установите и задайте имя.
Для iOS: скачайте FiddlerRoot certificate, откройте его, нажмите «разрешить», после чего перейдите в Настройки → Профиль загружен → Установить. Далее в Настройках → Основные → Об этом устройстве → Доверие сертификатам → найдите сертификат и сделайте его доверенным.
3. В настройках Fiddler (Options→ HTTPS) установите флажок «Decrypt HTTPS traffic», после чего разрешите установку сертификата.
После этого вы сможете работать и анализировать защищенный HTTPS-трафик в Fiddler.
В данной статье я познакомил вас с инструментом Fiddler для анализа трафика мобильных приложений на базе Android/iOS. Аудиторам он может быть полезен для поиска уязвимостей.
Битва Charles и Fiddler: как тестировать с комфортом?
Всем привет! Меня зовут Ксения Мерзлозубова, и я тестирую мобильные приложения в компании ATI.SU.
Для тестирования большинства задач мобильному тестировщику необходим сниффер — инструмент для перехвата и анализа трафика. Сейчас существует множество снифферов, но самые популярные — это Charles и Fiddler. В этой статье я опишу их достоинства и недостатки, обращу внимание на фичи, удобство использования, дизайн и еще некоторые нюансы. Снифферы всегда помогают мне при ручном тестировании, поэтому надеюсь, что и вы сможете выбрать один из них или будете использовать все.
Добавлю, что у Fiddler существует 2 версии: Classic и Everywhere. Расскажу про обе.
Charles
Тестировщики обычно называют его «Чарльз» или ласково «Чарлик». Для начала обсудим основные плюсы этого сниффера.
Плюсы
Кроссплатформенность. Есть версии на Mac OS, Windows и Linux. Это очевидное преимущество, если каждый из ваших коллег выбрал себе рабочую ОС по душе, и нужен общий инструмент для тестирования.
Удобная панель инструментов с такими функциями как очищение сессии, редактирование и перевыполнение запроса, остановкой перехвата трафика и другими.
Панель инструментов
Классификация запросов по хостам. У сниффера есть экраны Structure и Sequence. На экране Sequence перехваченные запросы отображаются последовательно, а на экране Structure еще и с группировкой по хостам. Для удобства можно настроить фокус на определенный хост. Тогда остальные запросы попадут в группу Other hosts. Этот вариант подойдет, если вы тестируете небольшую группу запросов к одному хосту, а остальные в текущий момент не важны.
Возможность экспортировать настройки. Например, можно попросить коллегу экспортировать настройки Charles и загрузить их себе, чтобы не настраивать все опции вручную. Настройки экспортируются в формате xml.
Возможность просматривать несколько сессий в соседних закладках. Здесь под «сессией» я подразумеваю один сеанс перехвата трафика. Например, вы воспроизводите сложный баг, и вам нужно повторить его дважды, чтобы сравнить траффик. Тогда можете использовать для каждого повтора отдельную сессию, а затем переключаться между ними.
Современный интерфейс. В отличие от Fiddler Classic, у которого интерфейс напоминает десктопные приложения из 2000-х, Charles выглядит актуальнее.
Минусы
Нет возможности наложить таймаут на запрос. При тестировании часто требуется проверить, как поведет себя конкретный запрос при задержке ответа и нестабильном интернете. К сожалению, Charles позволяет создать такую задержку только для хоста. Настройка влияет на все запросы указанного хоста, а их может быть очень и очень много. Найти настройку можно так: Proxy — Trottle Settings.
Trottle Settings
Нет возможности экспортировать сессию в формате txt или json. Теперь под «сессией» я подразумеваю запрос и ответ вместе, одним файлом. Charles предлагает форматы chls, csv, trace, har и другие.
Форматы экспорта сессии
Документация без скриншотов и видео. У этого сниффера есть документация на официальном сайте, и она целиком состоит из текста. На мой взгляд, документация платного инструмента должна быть как минимум дополнена поясняющими скриншотами, а еще лучше видео.
Это платный инструмент. В отличие от Fiddler Classic, у Charles бесплатный только триальный период в 30 дней. Однако, этот минус сомнительный, т.к. хороший инструмент и должен быть платным.
Fiddler Classic
Этот инструмент долгое время был моим любимчиком, так как с него я начинала изучение снифферов.
Плюсы
Удобная подмена ответов. Чтобы подменить ответ, в Fiddler Classic достаточно перетащить запрос на закладку AutoResponder. Далее можно выбрать вариант ответа в Rule Editor или нажать Edit Response и дать волю фантазии.
AutoResponder в Fiddler Classic
Для сравнения, чтобы подменить ответ в Charles, придется:
Копировать url; Добавить настройку подмены (Rewrite).
Вставить скопированный url.
Создать новое правило подмены (Rewrite rule) для url.
Выбрать тип подмены. Например, Body или Status.
Выбрать, в запросе или в ответе сделать подмену.
Допустим, вы подменяете тело ответа (Body). Тогда нужно заготовить измененное тело заранее и вставить в поле Value.
Rewrite в Charles
На самом деле шаги не сложные, но путь к подмене ответа длиннее, чем в Fiddler. В качестве альтернативы в обоих снифферах есть возможность подменять ответ на файл.
Много функций вынесены на панель инструментов. На мой взгляд, панель инструментов Fiddler Classic менее удобная, чем у Charles, но разработчики постарались вынести на нее большое количество опций.
Возможность цветового выделения запросов. Для наглядности, можно выделить запрос другим цветом. В Charles я не нашла подобной функции.
Бесплатный инструмент. Из трех инструментов, которые я сравниваю, только Fiddler Classic абсолютно бесплатно можно скачать с официального сайта.
Два способа редактирования запросов. В Fiddler и Charles есть аналогичные способы редактирования запросов. Они позволяют менять любую часть запроса. Покажу их на скриншотах ниже.
Редактирование запроса в Fiddler Classic Редактирование запроса в Charles
Однако в Fiddler есть и второй способ: использование редактора запросов Composer. Основное преимущество этого способа в том, что в Composer есть лог измененных и выполненных запросов. В нем очень просто найти запрос, который вы меняли ранее и вернуться к его редактированию.
Документация. Просто почитайте ее на официальном сайте.
Минусы
Только под Windows. Для других ОС на официальном сайте Fiddler предлагается скачать Fiddler Everywhere, о котором я расскажу позже в этой статье.
Устаревший дизайн интерфейса. Этот пункт выглядит очень субъективно, но с ним согласны большинство моих коллег.
Редактирование ответа только в текстовом формате. В AutoResponder есть встроенный редактор ответа. Если ответ содержит множество вложенных структур и полей, то читать его в текстовом виде крайне неудобно, а редактирование в формате json отсутствует. Также нет поиска по тексту в редакторе, поэтому быстро найти нужное поле не получится. Однако, выход есть — можно использовать отдельный текстовый файл для подмены ответа.
Fiddler Everywhere
Перейдем к новому Fiddler. Судя по списку релизов на официальном сайте, этот сниффер появился в 2018 году.
Плюсы
Кроссплатформенность. В отличие от предшественника, у Fiddler Everywhere есть версии под Mac OS, Windows и Linux.
Удобные фильтры запросов. Перехваченные запросы отображаются на закладке Life Traffic. Там можно настроить, какие столбцы показывать, а какие скрывать. Также есть фильтры по каждому столбцу. Если использовать фильтры по нескольким столбцам, то они применяются вместе.
Life Traffic
Сохранение сессий внутри инструмента — это преимущество по сравнению с Charles и Fiddler Classic, где сессии нужно экспортировать в файл для сохранения.
Отправка сессий другим пользователям. В Fiddler Everywhere можно поделиться сессией с коллегой, указав его email, если он тоже пользуется этим инструментом. Тут «сессия» — это один или несколько запросов.
Современный интерфейс. В отличие от Fiddler Classic, этот сниффер может похвастаться более актуальным интерфейсом, который напоминает привычный многим тестировщикам Postman.
Улучшенный Composer. В Fiddler Everywhere редактор запросов Composer получил функционал и дизайн, аналогичный Postman, за исключением некоторых функций. Например, нет возможности использовать переменные, писать скрипты или использовать раннер для запуска коллекций.
Сохранение коллекций. В отличие от Charles и Fiddler Classic в этом сниффере можно сохранять запросы в коллекции и давать им названия.
Документация. У Fiddler Everywhere есть подробная документация на официальном сайте.
Минусы
Нет брейкпоинтов. Брейкпоинты позволяют останавливать выполнение запроса и на ходу изменять его. Многие тестировщики привыкли к ним в Charles и Fiddler Classic. На текущий момент есть просьбы пользователей сделать breakpoints к команде разработчиков Progress Telerik. Вот еще пример. Судя по ответам, этот функционал есть в планах на будущее.
Платный инструмент. У сниффера есть бесплатный триальный период в 30 дней, а далее можно выбрать тарифный план.
Дополнительно
Добавлю, что большая часть функционала описанных снифферов совпадает. Они все отлично справляются с редактированием запросов, экспортом и импортом сессий, поиском по части запроса, поэтому на этих функциях я не останавливалась в статье.
В зависимости от проекта и задачи, тестировщику может потребоваться разный функционал сниффера. Если вам приглянулся какой-то инструмент, рекомендую попробовать его на практике, так как ваши рабочие потребности могут отличаться от моих.
Если у вас есть, что сказать по теме статьи, буду рада комментариям!