Нагрузочное тестирование с locust / блог компании инфопульс украина / хабр

Основные понятия

Для начала нужно ознакомиться с базовыми терминами и понятиями.

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

Тестовые потоки

Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:

Изолированное тестирование запросов — выполнение одного запроса API и соответствующая проверка ответа. Такие базовые тесты — это минимальные строительные блоки, с которых мы должны начинать. И нет смысла продолжать тестирование, если эти тесты упадут.
Многоступенчатый рабочий поток с несколькими запросами — тестирование серии запросов, которые являются обычными действиями пользователя, поскольку одни запросы могут зависеть от других. Например, мы выполняем запрос POST, который создает ресурс и возвращает автоматически сгенерированный идентификатор в своем ответе. Затем мы используем этот идентификатор, чтобы проверить, присутствует ли этот ресурс в списке элементов, полученных запросом GET. Затем мы используем PATCH для обновления новых данных и снова вызываем запрос GET для проверки этого обновления. И в завершении, мы УДАЛЯЕМ этот ресурс и снова используем GET, чтобы убедиться, что записи больше нет.
Комбинированные тесты API и тесты веб-интерфейса — это в основном относится к ручному тестированию, при котором мы хотим обеспечить целостность данных и согласованность между пользовательским интерфейсом и API.

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

Основы нагрузочного тестирования

Нагрузочное тестирование – это технология измерения производительности сервера, которая заключается в отправке имитируемого HTTP-трафика на сервер. Это позволяет найти ответы на такие вопросы:

Достаточно ли у сервера ресурсов (памяти, CPU и т. п.), чтобы обработать ожидаемый трафик?
Достаточно ли быстро реагирует сервер, чтобы обеспечить хороший пользовательский опыт?
Эффективно ли работает приложение?
Нужно ли серверу вертикальное или горизонтальное масштабирование?
Есть ли особо ресурсозатратные страницы или вызовы API?

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

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

Общая тенденция такова: чем выше нагрузка (чем больше запросов в секунду), тем выше задержка. Чтобы получить более реальную картину о задержке сервера при заданной нагрузке, нужно будет протестировать его несколько раз с разным количеством запросов. Не все приложения для тестирования нагрузки способны на это, но немного позже мы ознакомимся с wrk2 (это средство командной строки для тестирования нагрузки, которое может выполнить эту функцию).

Как определить разумный показатель задержки?

Время загрузки веб-сайта в диапазоне 2-5 секунд – обычное дело, но часть времени, связанная с задержкой веб-сервера, обычно составляет около 50-200 миллисекунд. Идеальный показатель задержки индивидуален для каждого сайта. Он зависит от большого количества факторов (аудитории, рынка, целей сайта, наличия пользовательского интерфейса или API и т. д.). Имейте в виду: большинство исследований показывают, что в производительности учитывается каждый маленький бит скорости, и даже совсем незаметные улучшения приводят к улучшению результатов в целом.

Планирование нагрузочного тестирования

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

Модели нагрузки

Gatling поддерживает различные модели нагрузки. Эти модели отвечают за «подъем» пользователей и генерируемую интенсивность.

nothingFor(duration) — указывается длительность паузы duration перед стартом нагрузки

atOnceUsers(nbUsers) — виртуальные пользователи в количестве будут “подниматься” сразу (по готовности).

rampUsers(nbUsers) over(duration) — в течение времени будут «подниматься» виртуальные пользователи в количестве nbUsers через равные временные интервалы.

constantUsersPerSec(rate) during(duration) — указывается частота “поднятия” виртуальных пользователей (вирт. польз. в секунду) и временной интервал . В течении количество виртуальных пользователей будет увеличиваться на rate каждую секунду.

constantUsersPerSec(rate) during(duration) randomized — аналогично верхней конструкции только временные интервалы между «поднятием» виртуальных пользователей будут случайными.

rampUsersPerSec(rate1) to (rate2) during(duration) — в течение времени виртуальные пользователи будут увеличиваться с частоты до частоты .

rampUsersPerSec(rate1) to(rate2) during(duration) randomized — аналогично верхней конструкции только временные интервалы между «поднятиями» виртуальных пользователей будут случайными.

splitUsers(nbUsers) into(injectionStep) separatedBy(duration) — через каждый временной интервал будут добавляться виртуальные пользователи по модели , пока их количество не достигнет . В можно указать модели описанные выше.

splitUsers(nbUsers) into(injectionStep1) separatedBy(injectionStep2) — аналогично верхней конструкции только разделителем модель .

heavisideUsers(nbUsers) over(duration) — виртуальные пользователи в количестве nbUsers будут подниматься ступенями за время .

Цели и процессы нагрузочного тестирования

Как и в любом тестировании, цели и процесс НТ вытекают из требований к тестируемой системе и зависят от организации разработки.

Примеры целей НТ:

определение максимальной производительности на имеющемся оборудовании (в частности, позволяет понять, сколько пользователей сможет обслуживать разрабатываемая система);
проверка стабильности (например, отсутствие утечек памяти на сервере и его стабильная работа в течение длительного времени, что особенно важно для систем 24/7);
проверка масштабируемости (к примеру, после добавления еще одного сервера или оперативной памяти система сможет обслуживать большее число пользователей, когда вырастет количество клиентов);
проверка стрессоустойчивости (если система сама восстанавливает свою работоспособность даже после сверхвысокой нагрузки, например, при наплыве клиентов в «черную пятницу»).

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

Различные варианты процессов НТ можно условно свести к двум:

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

В зависимости от варианта процесса меняется организация работ и взаимодействие в команде, формат документации, но при этом основные этапы сохраняются:

Анализ системы (или внесенных в нее изменений).
Подготовка или актуализация модели нагрузки и методики НТ (основополагающего документа в процессе).
Подготовка или обновление стенда НТ.
Разработка или актуализация скриптов НТ, «заглушек», скриптов генерации тестовых данных.
Настройка мониторинга на стенде НТ.
Сборка и отладка всего, что разработали, на стенде НТ.
Проведение необходимых тестов.
Анализ результатов тестов.
Подготовка отчетности.

И на каждом из перечисленных этапов требуются те или иные навыки специалиста по НТ.

Акт выполненных работ по нагрузочному тестированию

Результаты нагрузочного тестирования обобщаются в акте выполненных работ. Этот документ имеет следующую структуру:

Титульный лист «Акт выполненных работ по нагрузочному тестированию» с указанием:

Тестируемое приложение указываем официальное название приложения.

Тестирование проводилуказываем инженеров, участвующих в тестировании.

Дата и время тестирования.

Этап тестированиянапример, 1, 2, 3 этапы означают, какой по счёту раз проводится тестирование приложения, после внесения в него или в инфраструктуру изменений, или после изменения требований к производительности.

Версия документа например, 1.0, которая указывает текущую модификацию акта в пределах одного этапа тестирования;

Дата составления отчетауказывается дата составления текущей версии документа.

Ответственное лицоуказывается ответственный за проведение тестирования и составление отчета (РП или нач. отдела).
Введение.

Указывается, что представляет собой документ и дается краткое описание тестируемого приложения, которое можно взять, например, из ТЗ.
Указывается, какие основные функции, подсистемы или модули приложения тестировались.

Используемые инструменты тестированияперечисляется весь инструментарий для проведения тестирования, например, apache-jmeter-2.7, JMeterPlugins-0.5.2, Selenium IDE-1.8.1.

Приложениявсе артефакты тестирования, например, тест-план JMeter, .jtl-файлы с результатами, графики результатов измерений, скриншоты и т.п.
Цели и задачи. Например:

Определить соответствие производительности системы предъявленным требованиям для различных профилей нагрузки, описанных далее.
Определить критические параметры нагрузки, которые приведут к отказу Приложения.
Термины и определения, используемые в отчете.
Инфраструктура Приложения.

IP-адресуказывается ip-адрес или адреса серверов, где развернут тестовый стенд Приложения.

Сетевой путь к приложению указывается сетевой адрес или адреса, по которым можно получить доступ к интерфейсу Приложения.

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

Инвентаризация ресурсов Приложения. В табличном виде описываются ресурсы приложения, представленные выше на схеме. Таблица включает в себя столбцы: № п/п, Ресурс, Hardware, Software.
Показатели производительности. Указываются измеряемые на данном этапе показатели и используемые для этого метрики. Например, показатели приведенные выше.
Профили нагрузки. Описываются наборы операций с различными интенсивностями нагрузки, условия для выполнения теста, например, требуемые настройки приложения, число одновременно работающих пользователей, нагружаемая подсистема приложения, время выполнения теста и т.д.
Требования к производительности. Описываются допустимые значения измеряемых параметров, при которых нагрузочный тест считается успешно пройденным.
Описание методики тестирования. Кратко описываются подходы к проведению тестирования, рассказывается о подготовке тестового стенда, например, описание структуры bot-net, описание полезной нагрузки, принцип подбора тестов.
Измерительная часть, содержащая обобщенные результаты тестирования по каждому профилю с пояснениями. В начале можно указать таблицу видов запросов, используемых при тестировании нагрузки.
Анализ результатов тестирования, сведение результатов измерений в обобщенные таблицы, их сравнение с результатами предыдущего этапа тестирования (при необходимости). Сравнение результатов может быть приведено на графиках-гистограммах.
Общие выводы и рекомендации. По результатам нагрузочного тестирования и анализа данных делается вывод о работоспособности приложения под нагрузкой. Например, при каком количестве потоков (подключений пользователей) и режиме нагрузки, оно показывает устойчивую работоспособность. Приводятся рекомендации по обеспечению приемлемой работы пользователей. Выносятся предложения для повышения производительности приложения и обеспечения комфортной работы требуемого числа пользователей.

Шаблон акта выполненных работ Performance_testing_Step_1_ver_1_0_Template.doc, содержащий указанную структуру, можно скачать здесь:https://docs.google.com/open?id=0B-1rf8K04ZS5cFRDQmd0RV9UVU0Пример одного из отчётов perfomance_testing_example_2011.pdf, созданный на основе данной структуры, можно скачать здесь:https://docs.google.com/open?id=0B-1rf8K04ZS5bFpMSFc3OGNKN2s

Основные оцениваемые метрики

Некоторые, наиболее общеупотребительные и рекомендуемые в методологии ISTQB (стр. 36, 52) метрики, приведены в таблице ниже.

Метрики нагрузочного агента	Метрики целевой системы или приложения, тестируемых под нагрузкой
Количество vCPU и памяти RAM, Disk (в Mb или Gb) — «железные» характеристики нагрузочного агента.	CPU, Memory, Disk usage — динамика загрузки процессора, памяти и диска в процессе тестирования. Обычно измеряется в % от максимально доступных значений.
Network throughput (load agent) — пропускная способность сетевого интерфейса на сервере, где установлен нагрузочный агент. Обычно измеряется в байтах в секунду (bps).	Network throughput (target) — пропускная способность сети на целевом сервере. Обычно измеряется в байтах в секунду (bps).
Virtual users — количество виртуальных пользователей, реализующих сценарии нагрузки и имитирующие реальные действия пользователей.	Virtual users status, Passed/Failed/Total — количество успешных, неуспешных статусов работы виртуальных пользователей для сценариев нагрузки, и их общее количество. Обычно ожидается, что все пользователи смогли выполнить все свои задачи, указанные в профиле нагрузки. Любая ошибка будет означать то, что и реальный пользователь не сможет решить свою задачу при работе с системой.
Requests per second (minute) — количество сетевых запросов в секунду (или минуту). Важная характеристика нагрузочного агента: сколько он может генерировать запросов. Фактически, это обращения к приложению виртуальными пользователями.	Responses per second (minute) — количество сетевых ответов в секунду (или минуту). Важная характеристика целевого сервиса: сколько было получено ответов на отправленные с нагрузочного агента запросы.
	HTTP responses status — количество различных кодов ответа от сервера приложения. Например, 200 OK означает успешное обращение, а 404, что ресурс не обнаружен.
	Latency (время отклика) — время от окончания отправки запроса (request) до начала приёма ответа (response). Обычно измеряется в миллисекундах (ms).
	Transaction response time — время одной полной транзакции: завершение цикла запрос – ответ. Это время от начала отправки запроса (request) до завершения приёма ответа (response). Время транзакции может измеряться в секундах (или минутах) несколькими способами: считают минимальное, максимальное, среднее и, например, 90-й перцентиль. Минимальные и максимальные показания показывают крайние состояния производительности системы. 90-й перцентиль используется наиболее часто, поскольку он показывает большинство пользователей, комфортно работающих на пороге производительности системы.
	Transactions per second (minute) — количество полных транзакций в секунду (минуту), то есть сколько приложение смогло принять и обработать запросов и выдать ответов. Фактически, это пропускная способность системы.
	Transactions status, Passed / Failed / Total — количество успешных, неуспешных и общее количество транзакций. Для реальных пользователей неуспешная транзакция фактически будет означать невозможность работы с системой под нагрузкой.

BlazeMeter

BlazeMeter – компания-производитель одноимённого программного
обеспечения для тестирования, предоставляющая пользователям тестирование
производительности и нагрузочное тестирование как услугу. Служба содержит
инновационную и всеобъемлющую платформу непрерывного тестирования.
Веб-интерфейс приложения эффективен для создания статических нагрузочных тестов
и использования сценариев JMeter для выполнения динамических нагрузочных
тестов.

BlazeMeter известен широчайшим использованием одного из лучших
инструментов нагрузочного тестирования с открытым исходным кодом – Apache
Jmeter. Он предоставляет различные корпоративные функции для бесплатной
платформы. То есть пользователи могут получить доступ ко многим расширенным
функциям, таким как мониторинг производительности приложений (APM), создание
отчетов в режиме реального времени, распределенное тестирование и интеграция с
инструментами разработчика для непрерывной интеграции (CI).

Плюсы

100% совместимость с Apache JMeter
Создание масштабных тестов – до 1 миллиона одновременно
работающих пользователей.
Настройка тестов в течение нескольких минут
Запуск тестов без сценариев или загрузка списков URL
Запуск из облака или локально
Запуск тестов из нескольких географических местоположений
Имитация мобильного тестирования с реальных устройств
Облегчает командное сотрудничество с помощью сценариев и
обмена отчетами
Поддержка нескольких инструментов
Интеграция с ведущими инструментами CI и APM
Поддержка и профессиональные услуги
Подробный отчет о результатах нагрузочных испытаний в режиме
реального времени
Установка КПЭ поведения тестируемого приложения
Мониторинг собранного пользовательского опыта на компьютере
и мобильных устройствах

Минусы

Отчеты Blazemeter довольно простые и не детализированные
Blazemeter дорог для нагрузочных тестов больше чем с 1000
пользователей.

Ценообразование (годовые планы)

Бесплатно (50 одновременных пользователей)
Базовый: $ 99 / мес (1000 одновременных пользователей)
Pro: $ 499 / мес (5000 одновременных пользователей)

Кому подходит

BlazeMeter – отличный инструмент для
нагрузочного тестирования для организаций, которые уже используют Apache Jmeter.

Выберите тег:

автоматизация
(20)

DevOps
(19)

тестирование
(15)

testing
(12)

web-приложения
(11)

python
(9)

разработка
(9)

инструменты тестирования
(7)

процессы
(7)

TeamCity
(6)

selenium
(6)

безопасность
(6)

continuous integration
(5)

xPath
(5)

девопс
(5)

тесты
(5)

Test Tool
(4)

WebDriver
(4)

нагрузка
(4)

DevSecOps
(3)

GUI
(3)

JMeter
(3)

auth
(3)

automation
(3)

ci
(3)

анализ
(3)

билд-конфигурации
(3)

митап
(3)

моделирование
(3)

план
(3)

планирование
(3)

тест-план
(3)

функциональные тесты
(3)

HTTP
(2)

IDE
(2)

OWASP
(2)

Positive Technologies
(2)

application inspector
(2)

best practices
(2)

crawler
(2)

dependencies
(2)

development
(2)

git
(2)

github
(2)

headers
(2)

load testing
(2)

mind-map
(2)

opdevops
(2)

интеллект-карта
(2)

карта
(2)

компетенции
(2)

конвейер
(2)

нечеткие шкалы
(2)

оценка качества
(2)

сканер ИБ
(2)

скриншот
(2)

управление
(2)

уязвимости
(2)

фреймворк для тестирования
(2)

шаблоны
(2)

CRUD
(1)

Crawljax
(1)

DevOpsHQ
(1)

Linux
(1)

Meta-Runners
(1)

Nginx
(1)

Op!DevOps!
(1)

PT AI
(1)

PlantUML
(1)

RobotFramework
(1)

Yandex.Tank
(1)

allpairs
(1)

analyse
(1)

aptly
(1)

architect
(1)

autoit
(1)

basic auth
(1)

boomstarter
(1)

brainstorming
(1)

bruter
(1)

bug
(1)

build
(1)

cd
(1)

codacy
(1)

code
(1)

commit
(1)

configuration
(1)

debrifing
(1)

defect
(1)

deploy
(1)

diagram
(1)

digest auth
(1)

form-based
(1)

gantt
(1)

git extension
(1)

gitlab
(1)

hook
(1)

html
(1)

httest
(1)

httpbin
(1)

infrastructure
(1)

integrity
(1)

logins
(1)

lxml
(1)

management
(1)

meetup
(1)

modeling
(1)

multi-threads
(1)

neural network
(1)

osg
(1)

pairwise
(1)

paralleling
(1)

passwords
(1)

phantom
(1)

pre-commit
(1)

process
(1)

proxy
(1)

pyzo
(1)

release
(1)

request
(1)

response
(1)

rsa
(1)

schemas
(1)

scp
(1)

screenshot
(1)

security
(1)

security scanner
(1)

service
(1)

ssh
(1)

static
(1)

templates
(1)

test-plan
(1)

testrun
(1)

triggers
(1)

uml
(1)

unit-test
(1)

vulnerabilities
(1)

windows
(1)

yandex-tank
(1)

ЗУН
(1)

Яндекс.Танк
(1)

авторизация
(1)

агрегирование
(1)

архитектура
(1)

аутентификация
(1)

баги
(1)

брутер
(1)

брутфорс
(1)

бумстартер
(1)

вектор признаков
(1)

генератор сайтов
(1)

гитлаб
(1)

графики
(1)

дефекты
(1)

диаграммы
(1)

доставка
(1)

зависимости
(1)

зависимые конфигурации
(1)

знания
(1)

измерительные шкалы
(1)

инженер
(1)

инженеры
(1)

история
(1)

история математики
(1)

как писать
(1)

карьера
(1)

классификация
(1)

классы
(1)

ключевая пара
(1)

книга
(1)

код
(1)

контроль целостности
(1)

конференция
(1)

краулер
(1)

критерии качества
(1)

логины
(1)

математика
(1)

менеджмент
(1)

мета-раннер
(1)

методы
(1)

метрики качества
(1)

многопоточность
(1)

мозговой штурм
(1)

навыки
(1)

нейросети
(1)

опдевопс
(1)

оргвопросы
(1)

пароли
(1)

питон
(1)

попарное тестирование
(1)

попарный анализ
(1)

постмортем
(1)

происшествия
(1)

разбор полётов
(1)

разделение элементов
(1)

распараллеливание
(1)

рассказ
(1)

ревизия кода
(1)

репозитории
(1)

сервис
(1)

сканер кода
(1)

сравнение сканеров безопасности
(1)

структура
(1)

схемы
(1)

тексты
(1)

терминология
(1)

тест-раны
(1)

тестовая процедура
(1)

технические статьи
(1)

техпроцессы
(1)

типы тестов
(1)

триггеры
(1)

умения
(1)

учебник
(1)

учёные
(1)

целостность
(1)

юнит-тесты
(1)

Реализация расширения для Gatling

Нередко случаются задачи, когда необходимо протестировать под нагрузкой систему у которой протокол прикладного уровня отличный от HTTP или WebSocks. В таком случае для Gatling можно написать свое расширение и реализовать необходимый функционал.

И так, нам необходимо реализовать вот такую возможность:

Так как функция может принимать тип необходимо написать свой класс и расширить его типом .

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

Ниже рабочий пример данного подхода

Важно отметить, что такой способ не является лучшим решением, но оно максимально «простое» для реализации