Home

Оригинал статьи: http://testdetective.com/performance-testing-tutorial/

Автор: Лукас Розуонек (Łukasz Rosłonek)

Перевод: Ольга Алифанова

Я заметил, что большинство тестировщиков слабо знакомо с такой областью, как тестирование производительности. В основном мы концентрируем усилия на функциональных аспектах тестирования, оставляя тестирование производительности, масштабируемости и настройки на откуп разработчикам. Но ведь стабильность – важная часть качества продукта, особенно в эпоху распределенных сетей, когда приложения масштабируются независимо и опираются на интеграцию через HTTP-протоколы. Другой аспект качества – способность увеличивать масштаб наших систем. Для того, чтобы справиться с ростом трафика, нужно знать пропускную способность ПО.

Инженеры хорошо знакомы с такими инструментами, как JMeter, Gatling, Tsung. Они относительно просты в использовании, но люди зачастую плохо разбираются в анализе выданных ими результатов, и не умеют делать выводы на их основании. Собеседуя кандидатов на должность тест-инженера, я часто встречаю людей, утверждающих, что они имеют опыт тестирования производительности, но не владеющих знаниями о метриках этого вида тестирования, а также о его элементарных положениях. Основная цель нагрузочного тестирования и тестирования производительности – не умение обращаться с соответствующими инструментами, а знания, полученные в результате их использования. Цель этой статьи – осветить основные аспекты этой области.

Тестирование производительности и нагрузочное тестирование

Люди зачастую путают нагрузочное тестирование и тестирование производительности. Два этих термина часто используются, как взаимозаменяемые, но это вовсе не так.

Цель тестирования производительности – это поиск "бутылочных горлышек" системы или архитектуры. Как говорится, скорость нашей системы – это скорость самого медленного ее компонента. Предположим, что система состоит из нескольких различных микросервисов. У каждого из них есть собственное время отклика и устойчивость к нагрузке. Добавим сюда такие факторы, как тип базы данных, сервера или местоположение дата-центра. Пользователям приложения нужен быстрый отклик системы и ее высокая доступность. Тестируя производительность, мы ищем узкие места в нашей архитектуре и независимо масштабируем и настраиваем микросервисы, чтобы добиться вышеупомянутого быстрого отклика системы целиком.

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

Время ожидания, пропускная способность и ширина канала

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

• Время ожидания – это временной интервал между запросом и ответом на него. К примеру, если время ожидания вашего сервиса равна 100 мс, это означает, что вашему сервису требуется 100 миллисекунд для обработки запроса и генерации ответа. Как правило, чем ниже время ожидания, тем лучше для пользователя.
• Пропускная способность – это реальное количество запросов или пользователей, которые ваша система способна обработать за определенное время. Время ожидания дает вам информацию только о временном интервале, а пропускная способность – об объеме данных, которые система получает и обрабатывает. Очень важно не разделять эти метрики, потому что высокое время ожидания может быть напрямую связано с падением пропускной способности. Обычно она измеряется в количестве запросов в секунду.
• Ширина канала – это максимальное количество запросов или пользователей, которые могут быть обработаны. В отличие от пропускной способности, ширина канала замеряет максимальный объем данных, которые ваше приложение способно выдержать.

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

Перцентили

При измерении времени ожидания одним из первых приходящих в голову сценариев будет расчет среднего времени ожидания за определенное время. Первым измеряемым показателем будет арифметическое среднее, однако здесь есть некоторая проблема: арифметическое среднее очень чувствительно к большому среднеквадратичному отклонению. Так как графики времени ожидания обычно довольно равномерны с небольшими экстремумами, лучше использовать перцентили. Если вы хотите замерить среднее время ожидания вашего сервиса, то можно использовать медиану – 50-й перцентиль (p50). Однако следует помнить, что p50 тоже чувствительно к статистическим флуктуациям. Наиболее распространенная метрика для замера среднего времени ожидания – это 90-й и 99-й перцентили (p90 и p99). К примеру, если время ожидания для p90 составляет 1 мс, то это означает, что в 90% случаев ваш сервис отвечает спустя 1 мс.

Частота ошибок

Как уже говорилось, мы можем измерить объем полученного трафика, замеряя пропускную способность, однако что насчет исходящего трафика – ответов приложения? Важно знать, какими HTTP-кодами мы отвечаем на запросы – 2хх, 4хх или 5хх. И тут в игру вступает измерение частоты ошибок. Цель этого измерения – узнать, сколько (какой процент) наших ответов успешны, и тому подобные вещи. Какая-то часть исходящего трафика всегда будет с ошибкой (в том числе из-за валидации клиентами – коды 4хх). Однако если в частотности ошибок возникают внезапные пики, это может означать, что в приложении проблемы. Пример графика частоты ошибок приведен на изображении выше.

Заключение

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

Обсудить в форуме.