Тестирование производительности в Postman

Тестирование производительности — отличный способ выяснить, насколько наше приложение (или сайт) надежное и быстрое. Оценка адаптивности, определение возможных узких мест и проверка, как приложение справляется с ожидаемыми (и, что более важно — неожиданными) ошибками — это неотъемлемая часть тестирования. 

Когда заходит речь о тестировании производительности, часто упоминают такие инструменты, как Jmeter, LoadNinja, Gatling и т. п. Все они по-своему хороши. Наш подробный материал о тестировании производительности можно прочитать по ссылке.

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

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

Тестирование производительности — теория и типы тестирования

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

Допустим, наш сайт имеет какой-нибудь лимит. Например, число пользователей, которые могут пользоваться сайтом  одновременно, ограничено. Мы хотим проверить, как система будет справляться с нагрузкой при достижении этого лимита. Это называется нагрузочным тестированием (load testing)

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

Модифицированная версия нагрузочного тестирования — тестирование стабильности (endurance testing). Суть его в том, что мы достигаем определенного лимита и наблюдаем, как долго наша система сможет работать в таких условиях. 

Другой подход к тестированию производительности — стресс-тестирование (stress testing). При нем мы постепенно увеличиваем нагрузку, пока не достигнем предела, за которым, как мы знаем, приложение не сможет работать. 

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

Spike-тестирование — это подтип стресс-тестирования. В нем фокус смещен на производительность приложения под огромными нагрузками в течение коротких периодов времени. Такие перепады создаются либо между периодами обычной нагрузки приложения в продакшене (продакшен-среда имитируется), либо вообще без «фоновой» нагрузки.

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

типы тестирования производительности

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

Тестирование в Postman

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

Postman — это простая, легковесная и удобная платформа, в целом предназначенная для тестирования и разработки API. Но если у вас есть уже созданные и ежедневно обновляемые коллекции запросов, при помощи Postman можно запускать базовые тесты производительности буквально за пару минут.

1. Настройка

Создайте коллекцию и добавьте вызовы API, которые хотите протестировать. В нашем примере мы используем главную страницу сайта brightinventions.pl. Устанавливаем HTTP-метод как GET, вводим URL и нажимаем «Send». Ответ показывает HTML-структуру тестируемой страницы, а Postman позволяет визуализировать ее.

postman

2. Рендомные данные

Бывает, что нужно добавить случайные данные в наш URL или тело запроса. Чтобы избежать спамминга одинаковыми вызовами, их можно рандомизировать при помощи динамических переменных, предоставляемых Postman (например,  {{$randomAlphaNumeric}}).

Или можно загружать данные из  JSON или CSV-файла, в каждой итерации создавая переменную на основе следующего массива/строки. Но в нашем примере этот шаг не нужен.

3. Критерии приемки

Для тестирования нужно создать условие проверки ответа после каждого вызова (assertion). Чтобы это сделать, перейдите во вкладку Tests в окне редактирования запроса. 

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

postman

В первом тесте код состояния должен быть всегда равен 200, поскольку наша страница должна быть  доступна все время. 

Второй тест проверяет, получаем ли мы ответ на запрос в пределах 400 мс.

В третьем тесте проверяется, содержит ли HTML, полученный в ответе, текст «Software Development Company | Bright Inventions».

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

4. Открываем Test Runner

Как превратить простую проверку одного ответа в тест на производительность? Просто выберите опцию «Run collection». Вы можете выбрать количество итераций, задержку между итерациями, а также импортировать файл с данными при необходимости. 

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

postman

5. Run, Forrest!

А теперь мы ждем… Мы установили количество итераций равным 100, так что долго ждать не придется. Меньше чем за минуту мы получаем наши результаты:

postman

6. Анализ результатов

Мы видим, что в числе 300 тестов были и неудачные. Все провалившиеся тесты касались времени ответа. Заметно, что с течением времени ответ все больше задерживался, а ведь у нас было всего 100 итераций!

График, представленный ниже, составлен на основе экспортированных результатов теста. Он показывает, что со временем превышение лимита в 400 мс происходило все чаще. Также были отдельные случаи, когда ответ приходил спустя 500-600 мс.

тестирование производительности результаты

Итоги

Конечно, возможности Postman в тестировании производительности ограничены. Но то, что за считанные минуты можно создать тест с нуля, впечатляет. 

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

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

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

3 КОММЕНТАРИИ

Подписаться
Уведомить о
guest

3 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
murr
murr
2 лет назад

Синоптики объявили неделю тестирования производительности, количество статей по performance тестированию на testengineer.ru увеличилось))

rew
rew
2 лет назад

Иронично то, что на сайте посвящено столько материала по тестированию — но картинки в статьях увеличить нельзя.

Johnny
Johnny
1 год назад

Как произведён анализ результатов? Как их преобразовали в график? Что за инструмент? У меня только json с результатами прогона а дальше как?

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас