Part 3. Инструменты тестирования производительности
Уважаемые читатели Хабра! Меня зовут Вадим Лунин. Я являюсь QA Manager в Альфа Банке в Беларуси. С 2022 года я работаю в Банке и одно из моих направлений работы — выбор инструментов тестирования. Не так давно я начал писать цикл статей:
В этой статье я расскажу о нашем подходе к тестированию производительности и какие инструменты мы используем.
Выбор подхода к организации проведения тестирования производительности
Тестирование производительности — это процесс измерения и оценки характеристик производительности приложений, таких как время отклика, пропускная способность, нагрузочная способность и устойчивость. При тестировании производительности мы сталкиваемся с такими задачами, как выбор тестового окружения, выбор измеряемых параметров, выбор модели нагрузки, анализ и интерпретация полученных результатов, выбор критериев приемки результатов тестирования, а также выбор инструментов тестирования. Наша основная цель в Банке — сделать тестирование производительности обязательным для каждого релиза, чтобы избежать проблем с производительностью на проде. Кроме того, мы хотим сэкономить деньги и время на этом процессе. Для этого мы рассмотрели два подхода к организации тестирования производительности: продуктовый и сервисный.
Продуктовый подход
В продуктовом подходе каждая продуктовая команда имеет своего инженера по производительности, который отвечает за разработку, запуск и анализ тестов производительности для своего приложения или сервиса. Этот подход имеет следующие недостатки:
Высокая стоимость. Найти и нанять квалифицированного инженера по производительности — это дорого и сложно. К тому же, при увеличении количества проектов потребуется все больше и больше инженеров по производительности, что увеличит затраты на зарплаты и обучение.
Низкая эффективность. Инженеры по производительности могут иметь разный уровень знаний и опыта, что может привести к разному качеству тестирования производительности на разных проектах. Кроме того, инженеры по производительности могут использовать разные инструменты и методологии, что может привести к несовместимости и дублированию данных и кода.
Потеря контекста. Инженеры по производительности могут не иметь достаточного понимания логики работы приложений и сервисов, которые они тестируют. Это может привести к неправильному планированию, моделированию и анализу тестов производительности.
Сервисный подход
В сервисном подходе есть отдельная команда PerfOps, которая предоставляет тестирование производительности как сервис для продуктовых команд. Эта команда разрабатывает и поддерживает общие инструменты и библиотеки для тестирования производительности, а также консультирует и помогает продуктовым командам в случае необходимости. Этот подход имеет следующие преимущества:
Снижение стоимости. Нам не нужно нанимать много инженеров по производительности для каждого проекта. Мы можем использовать одну команду PerfOps для всех наших приложений и сервисов. Это снижает затраты на зарплаты и обучение, а также позволяет оптимизировать использование ресурсов.
Повышение эффективности. Команда PerfOps имеет высокий уровень знаний и опыта в области тестирования производительности. Она может обеспечить высокое качество тестирования производительности на всех наших проектах. Кроме того, команда PerfOps использует единые инструменты и методологии, что позволяет обеспечить совместимость и переиспользование данных и кода.
Сохранение контекста. Команда PerfOps не занимается разработкой и запуском тестов производительности самостоятельно. Она предоставляет инструменты и поддержку для продуктовых команд, которые сами разрабатывают и запускают тесты производительности для своих приложений и сервисов. Таким образом, продуктовые команды сохраняют контекст по своим продуктам и могут лучше планировать, моделировать и анализировать тесты производительности.
Вот как выглядит общий процесс работы в сервисном подходе. Поступает задача на создание или изменение функциональности. После реализации задачи запускаются smoke-тесты и продуктовая команда сама определяет влияние этой задачи на производительность продукта. Если влияния нет, то задача отправляется в продакшен. Если влияние есть, то продуктовая команда пишет тесты производительности, используя инструменты и базу знаний, которые предоставляет команда PerfOps. Затем идут этапы прогона и анализа тестов производительности. В зоне, которая отмечена пунктиром, могут привлекаться инженеры PerfOps. Если продуктовая команда не может самостоятельно найти проблему с производительностью, то она подключает экспертизу PerfOps, и они ищут ее вместе. Как только проблема устранена, задача отправляется в продакшен.
Выбор инструмента тестирования производительности
В этой части статьи я расскажу о нашем выборе инструмента для тестирования производительности. На начальном этапе внедрения новой концепции мы использовали Apache JMeter для разработки и запуска тестов производительности. Команда PerfOps имела большой опыт работы с этим инструментом. Apache JMeter — это мощный и гибкий инструмент для тестирования производительности различных типов приложений, таких как веб-приложения, REST API, SOAP API и другие. Однако мы столкнулись с некоторыми проблемами при использовании Apache JMeter на большом количестве проектов, а именно:
Сложность управления тестовыми сценариями. Apache JMeter хранит тестовые сценарии в виде XML-файлов, которые сложно читать и редактировать. Также сложно переиспользовать код и данные между разными тестами и проектами. Для хранения и синхронизации тестовых сценариев мы использовали Git, но это не решало проблему сложности XML-формата.
Отсутствие автокомплита и подсветки синтаксиса. Apache JMeter не имеет встроенного редактора кода, который бы поддерживал автодополнение и подсветку синтаксиса. Это затрудняет написание и отладку тестового кода, особенно при использовании скриптовых элементов, таких как BeanShell, JSR223 или Groovy.
Несоответствие языка тестирования и языка разработки. Наша зона ответственности за API находилась у QA, которые писали UI-тесты для веб-проектов используя Playwright (TS/JS). Это означало, что они использовали TypeScript или JavaScript для разработки UI-тестов, а Apache JMeter для разработки тестов производительности. Это создавало дополнительную когнитивную нагрузку и не позволяло переиспользовать код и библиотеки между UI-тестами и тестами производительности.
Поэтому мы решили перейти на другой инструмент для тестирования производительности, который бы лучше подходил нашим потребностям и специфике наших проектов. Мы выбрали k6 — это современный и легковесный инструмент для тестирования производительности, который позволяет писать тесты на JavaScript с использованием различных API и модулей. k6 имеет следующие преимущества перед Apache JMeter:
Простота управления тестовыми сценариями. k6 хранит тестовые сценарии в виде обычных JS-файлов, которые легко читать и редактировать. Также легко переиспользовать код и данные между разными тестами и проектами. Для хранения и синхронизации тестовых сценариев мы по-прежнему используем Git, но это не создает проблему сложности формата.
Наличие автокомплита и подсветки синтаксиса. k6 имеет встроенный редактор кода, который поддерживает автодополнение и подсветку синтаксиса. Это облегчает написание и отладку тестового кода, особенно при использовании различных API и модулей, таких как HTTP, WebSocket, GraphQL и другие.
Соответствие языка тестирования и языка разработки. Наша зона ответственности за API находится у QA, которые пишут UI-тесты для веб-проектов используя Playwright (TS/JS). Это означает, что они используют TypeScript или JavaScript для разработки UI-тестов, а также для разработки тестов производительности. Это уменьшает когнитивную нагрузку и позволяет переиспользовать код и библиотеки между UI-тестами и тестами производительности.
Схема тестирования производительности в Альфа Банке
В данной схеме описывается процесс тестирования производительности нашего приложения, использующего различные инструменты и технологии. Цель тестирования — определить характеристики производительности приложения при разной нагрузке и выявить возможные узкие места и ошибки.
Для тестирования производительности мы используем следующую схему работы. Наш код со скриптами тестирования хранится в репозитории кода Bitbucket, который является нашим инструментом для управления версиями кода. Для автоматизации процесса сборки, развертывания и запуска тестов мы используем инструмент CI/CD Tekton, который позволяет создавать гибкие и масштабируемые конвейеры работы. Основным инструментом для генерации нагрузки и измерения производительности мы выбрали k6, который представляет собой современный и мощный инструмент для тестирования производительности веб-приложений. K6 установлен на отдельно выделенном стенде Load Generator, который имеет достаточные ресурсы для создания высокой нагрузки. Со стенда Load Generator мы отправляем запросы на наше тестируемое приложение, которое расположено в Red Hat OpenShift, который является нашим инструментом для оркестрации контейнеров с микросервисами.
В ходе тестирования производительности мы собираем следующие данные с генератора нагрузки:
Resource utilization metrics — метрики программно-аппаратных ресурсов: ЦП, память, диск и т.п. Эти метрики необходимы для понимания того, не перегружен ли генератор во время тестов, так как это может повлиять на точность результатов.
Test metrics — результаты измерений производительности инструментами тестирования производительности. К этим результатам относятся время сетевых соединений, время ответа на запрос, сетевые адреса. Каждому запросу, выполненному в ходе теста, соответствует по крайней мере одна запись с числовыми метриками и метаинформацией.
Logs — (консольные) логи работы инструмента измерения производительности. Эти логи необходимы для отслеживания проблемных ситуаций в ходе выполнения теста, таких как ошибки, предупреждения, отказы и т.п.
Часть данных, которые хранятся в Kafka, проходят через обработчик данных, в нашем случае это Logstash. Logstash — это инструмент для сбора, обогащения и трансформации данных из разных источников. Он позволяет нам фильтровать, парсить, агрегировать и модифицировать данные из Kafka в соответствии с нашими потребностями.
Одним из мест назначения для наших данных из Logstash является Grafana. Grafana — это платформа для визуализации и анализа данных. Она позволяет нам создавать красивые и интерактивные графики и дашборды из наших данных. Она также позволяет нам настраивать разные оповещения и уведомления, если что-то не так с нашими данными. С помощью Grafana мы можем легко отслеживать и мониторить разные метрики и показатели наших данных.
Другим местом назначения для наших данных из Logstash является OpenSearch. OpenSearch — это открытый и бесплатный поисковый движок, который позволяет нам индексировать, хранить и искать наши данные. Он позволяет нам выполнять разные виды поиска по нашим данным, такие как полнотекстовый поиск, фасетный поиск, геопространственный поиск и т.д. Он также позволяет нам выполнять разные виды аналитики по нашим данным, такие как агрегация, группировка, сортировка и т.д. С помощью OpenSearch мы можем легко находить и извлекать нужную информацию из наших данных.
Заключение
В заключение можно сказать, что мы используем современный и эффективный набор инструментов и технологий для тестирования производительности нашего приложения. Это позволяет нам получать достоверные и подробные данные о характеристиках производительности приложения при разной нагрузке и выявлять возможные узкие места и ошибки. Таким образом, мы можем улучшать качество нашего продукта и повышать удовлетворенность наших клиентов.
Я хочу подвести итоги своего цикла статей, в которых я рассказывал о том, какие инструменты мы используем в тестировании в Альфа Банке. Надеюсь, что эти статьи были полезными и интересными для вас. Что вы узнали много нового о том, как мы обеспечиваем качество нашего продукта. В этих статьях я рассказал вам о следующих темах:
Part 0. Инструментарий QA в Альфа Банке — в этой статье я рассказал про тестировщиков, показал какие инструменты и плагины мы используем.
Part 1. Инструменты автоматизации тестирования — в этой статье я больше углубился в наши инструменты автоматизации. Рассказал почему выбрали Playwright, Appium и Browserstack.
Part 2. Инструменты управления тестированием — в этой статье я поговорил про систему управления тестированием Allure TestOps. Рассказал почему выбрали Allure и привел примеры работы.
Part 3. Инструменты тестирования производительности — в финальной статье я рассказал как у нас выглядит схема тестирования производительности и какие инструменты мы для этого используем.
Я благодарю вас за то, что читали мои статьи. Буду рад ответить на ваши вопросы и обсудить с вами любые темы, связанные с тестированием. Если вы хотите узнать больше о нашей компании и наших проектах, вы можете присоединиться к нам в telegram-канал Альфа-Среда. Спасибо за внимание!
