Home

Оригинальная статья: http://www.testdetective.com/2018/05/performance-testing-tutorial-starting.html

Перевод: Анна Радионова

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

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

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

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

Цель тестирования производительности - выявить “узкие места” в системе или архитектуре. Существует выражение, что наша система является настолько быстрой, насколько быстр наш самый медленный сервис. Представим, что система состоит из различных микросервисов. У каждого существует свое время ответа или расчетная (предполагаемая) нагрузка. В таком уравнении существует даже больше переменных как, например, тип базы данных, серверов или местоположение центра обработки данных. Пользователям приложения нужны две вещи: быстрое время ответа и высокая отказоустойчивость. С помощью тестирования производительности мы можем выявлять эти узкие места в архитектуре и масштабировать, конфигурировать и  регулировать сервисы независимо для достижения такого быстродействия конечными пользователями.

А что насчет высокой отказоустойчивости? Эта характеристика как раз на стороне нагрузочного тестирования. Проще говоря, нагрузочное тестирование - это проверка нашей системы с помощью огромного количества одновременных пользователей или подключений, которые и являются нашей нагрузкой. Это количество мы постоянно увеличиваем для достижения максимального количества задач, с которыми система может справиться. Нагрузочное испытание наиболее актуально при релизе нового сервиса, когда нужно проверить, выдержит ли он ожидаемый поток трафика. Цель такого испытания - проверка работоспособности всей системы, а не производительность ее отдельных сервисов. И хотя методы проведения нагрузочного тестирования и тестирования производительности кажутся схожими с точки зрения инструментария и техник, различия становятся более явными при анализировании результатов и определении способов реагирования.

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

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

• Время задержки (Latency) - временной интервал между запросом и ответом. Например, у вашего сервиса время задержки составляет 100ms, что означает, что такому сервису потребуется 100 миллисекунд на обработку запроса и генерирование ответа. Как правило, чем ниже время задержки, тем лучше клиентский опыт.
• Пропускная способность (Throughput)  - фактическое количество запросов (или пользователей), которое может обработать система за определенное время. В то время как время задержки говорит вам только о времени, метрика пропускной способности информирует об объеме данных, полученных и обработанных в момент времени. Важно не отделять показатели времени задержки от пропускной способности, т.к. высокий показатель времени задержки часто прямо связан с увеличением показателей метрики пропускной способности. Пропускная способность обычно измеряется в rps – (кол-во) запросов в секунду (requests per second).
• Ширина пропускания канала (Bandwidth) - максимальное число запросов (или пользователей), которое может обработать система. В отличие от пропускной способности ширина пропускания канала измеряет максимальный объем, который может обработать приложение.

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

Процентили

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

Частота появления ошибок

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

Заключение

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

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