Такие термины, как тестирование производительности, нагрузочное и стресс-тестирование часто используются как синонимы. Однако замер скорости работы сервиса и измерение возможной нагрузки на него – это не одно и то же, а подтверждение способности сервиса справиться с нормальным уровнем нагрузки не означает, что он так же среагирует на очень высокую. Как же создавать высокоэффективные тесты производительности, не налепив распространенных ошибок?
Вначале определитесь, чего вы ожидаете от сервиса, и что именно вы хотите проверить. Ваше приложение – "заяц", обязанный максимально быстро отвечать на вопросы? А может, это "черепаха", которая выигрывает гонку благодаря постоянно поддерживаемой скорости?
В реальной жизни веб-сервисы имеют как качества зайца, так и качества черепахи, и эти качества должны быть сбалансированы. Они проверяются по-разному в зависимости от природы вашего теста. Без глубокого понимания сервиса, его применения пользователями, пользовательской базы и целей теста вы потратите много времени, гоняясь за несуществующими проблемами, в то время как реальные риски утекут у вас сквозь пальцы.
Все, кто когда-либо сталкивался с тестированием производительности, прекрасно знают, как сложно сделать отчеты понятными, хорошо визуализированными и прозрачными для заказчика. Очень важно выбрать "правильные" метрики и разработать нужные профили нагрузки, но если в результате заказчик увидит скучные и непонятные кривые на белом фоне, он вполне может отказаться от тестирования производительности как такового, поскольку результат будет не вполне прозрачен. Давайте посмотрим, как можно улучшить впечатление от результатов тестирования производительности, на примере интеграции JMeter с мощным инструментом визуализации - Grafana.
Я заметил, что тема тестирования производительности все еще остается не до конца понятной для большинства тест-инженеров. Мы стремимся сфокусировать внимание на функциональном аспекте тестирования, оставляя производительность, масштабирование и настройку на усмотрение разработчиков. Разве не является стабильность существенной составляющей качества программного продукта? Особенно во времена распределенной обработки данных, когда мы масштабируем приложения независимо друг от друга и всецело рассчитываем на внедрение интеграций по HTTP протоколу. Другим существенным фактором является возможность расширения систем. Для того, чтобы справиться с увеличением трафика, мы должны быть осведомлены об ограничениях пропускной способности.
Существует несколько хорошо известных тестировщикам инструментов, таких как JMeter, Gatling, Tsung и т.д. И хотя они довольно просты в использовании, анализ полученных результатов и выводы на их основании представляют для тестировщиков сложность. Во время проведения собеседований на позицию QA инженера я часто встречаю кандидатов, утверждающих, что у них есть опыт в области тестирования производительности, но, по факту, не обладающих знаниями метрик и основных понятий с ним связанным. Поскольку основной задачей тестирования производительности является не знание инструментария, а данные, полученные с его помощью, цель этой статьи - рассмотреть основные аспекты этой сферы тестирования.
Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда A1QA с опорой на реальные кейсы расскажет, в какой последовательности проводится тестирование и что измеряется на каждом из этапов.
Первым в череде тестов проводится стресс-тест (StressTest), цель которого – установить предельный уровень производительности продукта. Стресс-тест позволяет проанализировать зависимость ключевых характеристик системы (времени отклика самых важных бизнес-транзакций, количества запросов в секунду, количества транзакций в секунду) от количества одновременно работающих пользователей.
Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, п
Оригинал статьи: 
Оригинальная статья: 
Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда