testengineer.ru

Домой Обучение Автоматизированное тестирование Тестирование производительности в Postman

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

Автор

Дата

Категория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Постоянная спешка

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

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

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! Вообще всегда стоит пробовать простые и удобные решения, прежде чем перейти к более громоздким и затратным по времени. Возможно, именно простое решение прекрасно подойдет для ваших нужд!

1 КОММЕНТАРИЙ

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

ОСТАВЬТЕ ОТВЕТ

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

Последние публикации

Последние комментарии