Нагрузочное тестирование: что? где? когда? Хабр

Для чего-то требуется предварительная авторизация, для чего-то — нет. Поведение из некоторых UI-тестов копируется в бэкендовых нагрузочных тестах и позволяет проверять пропускную способность сервиса на пользовательских сценариях. Нехитрыми способами, описанными выше, можно покрыть существенную часть тестов. Пример графиков, генерируемых “Яндекс.Танком” в процессе тестирования 👆🏻 Apache JMeter —инструмент для проведения нагрузочного тестирования, разрабатываемыйApache Software Foundation. Хотя изначально JMeter разрабатывался как средство тестирования web-приложений, в настоящее время он способен проводить нагрузочные тесты для JDBC-соединений, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP и TCP. Интересна возможность создания большого количества запросов с помощью нескольких компьютеров при управлении этим процессом с одного из них.

В структуре патрона важную роль играет поле Tag, в зависимости от которого поведение пушки меняется по switch case’у. Пример есть ниже в практической части статьи. Мы в Ozon Fintech пишем на Go и работаем с gRPC, что надо учитывать при выборе пушек для Танка.

Профилирование пушки

Параллельно наша команда работает над концепцией «Нагрузочное тестирование как сервис» — предоставлением полного цикла стрельбы от генерации и загрузки патронов на сервер и сборки пушки до проведения обстрела, сбора метрик и выведения результатов по нажатию на кнопочку в пайплайне CI. UpdateBalance — кейс с последовательным выполнением запросов к одному и тому же сервису сначала на UpdateBalance, потом — на ComplyBalance. MyAccountHandle — кейс с запросом к стороннему сервису авторизации. Что, если у меня нет возможности сделать каждый выстрел уникальным? Например, я в запросах обращаюсь к тестовым пользователям, а их в нужном количестве нет. Тогда патронов можно сделать меньше — и после первого прохода по файлу с ними Яндекс.Танк пойдёт на повтор.

• Тестирование производительности при всплесках нагрузки моделирует резкий импульсный рост количества параллельных пользователей или процессов внутри системы и позволяет оценить её стабильность при таких скачках и между ними, убедившись, что между скачками система полностью вернулась в норму.
• Запросы создаются таким образом, чтобы смоделировать одновременную работу набора пользователей.
• Кроме того, оно помогает выявить ошибки как в архитектуре проекта, так и в его кодовой базе.
• Поведение из некоторых UI-тестов копируется в бэкендовых нагрузочных тестах и позволяет проверять пропускную способность сервиса на пользовательских сценариях.

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

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

Площадка 2 имеет проблемы с чрезмерной нагрузкой на worker-серверах, и при среднем значении в 205 RPS страницы отдаются существенно дольше. Тестирование надёжности проверяет способность системы выполнять свои функции в определённых условиях в течение заданного промежутка времени или при заданном количестве операций. Тестирование утилизации ресурсов оценивает производительности процессора под нагрузкой и использование ОЗУ и дисковой памяти. Если тестировщик умеет обращаться с определённым инструментом для тестирования, то ему больше ничего не требуется. На самом деле в НТ необходима крайне тщательная и обширная подготовка, поэтому одним инструментом тут не спастись. Под капотом неэффективности чаще всего прячутся непродуманные дизайн и архитектура, а в них сложно вносить изменения на поздних стадиях разработки.

Автоматизация тестирования ПО

Пример из отчета с рекомендациями по оптимизации SQL-запросов 👆🏻Ниже приведены примеры с рекомендациями по результатам нагрузочного тестирования. Из минусов — нет встроенных графиков, приходится дополнительно конфигурировать связку с Grafana (что, впрочем, делается довольно легко). Из плюсов — большое комьюнити + большое количество плагинов для тестирования чего угодно (в нашейбигдата платформемы используем JMeter для генерирования потоковых данных для Apache Kafka и дальнейшей обработки через Apache Spark).

Кроме того, оно помогает выявить ошибки как в архитектуре проекта, так и в его кодовой базе. В нашей практике был интересный пример, когда stage-проект, развернутый в managed-кластере K8s, выдерживал всего лишь 8 RPS, а потом падал вплоть до рестартов всех pod’ов деплоймента. После трех итераций нагрузочного тестирования (с разницей в неделю) производительность выросла до 110 RPS. Тестирование производительности при всплесках нагрузки моделирует резкий импульсный рост количества параллельных пользователей или процессов внутри системы и позволяет оценить её стабильность при таких скачках и между ними, убедившись, что между скачками система полностью вернулась в норму. Как и любые профилактические проверки, периодическое нагрузочное тестирование будет, несомненно, позитивно влиять на развитие вашего продукта/сервиса. В идеальном мире, при наличии stage-площадки, идентичной продакшну, нагрузочное тестирование можно встраивать непосредственно в процессы CI/CD при выкладке новой версии проекта на препродакшн.

Нагрузочное тестирование: что? где? когда?

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

Вспомогательные компоненты— настроены ли у проекта мониторинг, система сбора логов и трейсов, которые могут быть полезны в процессе нагрузочного тестирования для получения дополнительных данных и инсайтов. В третьем случае мы последовательно отправляем запросы к одному и тому же сервису. Запросом к первой ручке создаётся запись в базе в статусе черновика, а вторым запросом эта запись подтверждается. Опрокидывающее тестирование (тестирование пресыщения) (tip-over testing) нацелено на насыщение системы нагрузкой и нахождение точки и места отказа.

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

Хранение данных(как БД, так и загружаемые пользовательские файлы) — используется ли on-premise или managed база данных, настроена ли репликация (запись в мастер / чтение со слэйва) и т д. Где хранятся загружаемые пользовательские данные — локальный диск, s3-хранилище и т.д.

Сценарии тестирования и выбор инструментов

Современное программное обеспечение просто обязано бесперебойно работать под колоссальными нагрузками. Любого рода проблемы, связанные с плохой производительностью, могут стать причиной отказа клиентов от использования вашего ПО. В связи с этим, проведение качественного нагрузочного тестирования должно стать обязательным, для обеспечения стабильности работы ваших приложений. Упор делается на ожидаемую и реалистичную нагрузку, хотя в основу этого НТ включают разнообразные сочетания запросов и их количество. Запросы создаются таким образом, чтобы смоделировать одновременную работу набора пользователей. Это позволяет оценить время ответа и пропускную способность.

Кроме того, наши пушки необходимо кастомизировать под свои нужды — выполнение сценариев, создание утилит для автогенерации пушки, автогенерация патронов — поэтому выбор пал именно на Pandora. Мы используем Яндекс.Танк — это удобный инструмент для тестирования бэка. НТ существует уже не первый год, и за это время накопилось много разных инструментов для его проведения. Также из-за проблем с отдачей js-файла, часть тестовых пользователей не смогла пройти авторизацию и, соответственно, не смогла пройти тестирование вовсе.