Как провести тестирование нагрузки: что нужно знать и какими инструментами пользоваться

Трафик и нагрузка на приложения растут, поэтому нагрузочное тестирование становится все более популярным в проектах. Если вы только начинаете знакомство с ним или уже практикуете и до сих пор сомневаетесь, все ли делаете правильно — эта статья будет для вас полезна.

Меня зовут Андрей Кушлак, я QA-специалист в NIX и спикер IT-конференции NIX MultiConf. Сегодня я расскажу, для чего используется нагрузочное тестирование и на что следует обратить внимание начинающим. Также приведу несколько типичных проблем, с которыми я сталкивался, как тестировщик, и объясню, как их решить.

Содержание

1. Когда необходимо нагрузочное тестирование
2. Цель нагрузочного тестирования
3. Что нужно знать QA-специалисту
3.1 Инструменты для написания скриптов
3.2 Знание языков программирования
3.3 Знание архитектуры приложения
3.4 Знание систем CI/CD-процесса
3.5 Понимание бизнес-значений и главных функций продукта
4. Инструменты для нагрузочного тестирования
4.1 Сервисные инструменты
4.2 Браузерные инструменты
5. Где можно получить больше знаний о нагрузочном тестировании
6. Вывод

---

Когда необходимо нагрузочное тестирование

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

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

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

В моей жизни все было именно так. Однажды проект, которым занималась наша команда, начал расти, и заказчик сообщил: некоторый функционал уже не работает или работает плохо. Наконец, 20% пользователей были недовольны приложением.

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

У нас сформировалась команда, которая находила проблемы и возвращала проект на доработку с оптимизацией кода, архитектуры и т.д.

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

• Убедитесь, что приложение одинаково качественно работает как с одним, так и с множеством пользователей. При этом время запроса от пользователя к серверу и обратно не должно меняться. Правда, в реальной жизни оно все равно меняется. Поэтому необходимо проверить, что изменения не настолько критичны, чтобы раздражать пользователей.
• Проверьте работоспособность приложения под значительным трафиком. Сайт или приложение под наплывом большого количества пользователей не должны постоянно перезагружаться и крутить спиннеры. Яркий пример — когда интернет-магазин начинает акцию со скидками на все товары. В таком случае трафик может возрасти, допустим, с 10 тысяч до миллиона пользователей. А это может критически повлиять на перформанс. Специалисты по нагрузочному тестированию должны проверить, как поведет себя сайт при таких условиях.
• Оценить качество работы приложения при нормальной нагрузке. Приведу пример из своей практики. Есть облачное приложение на микросервисах, в одном из которых на тестах нашли проблему. Этот микросервис перезагружался через неделю пять раз без понятных причин. Проанализировав ситуацию, мы обнаружили, что разработчики так «оптимизировали» код, что каждый запрос от клиента к серверу хранился в оперативной памяти. Для сервиса было выделено 2 ГБ: по одному для него и для кэша. И хотя каждый запрос занимал очень мало места, после миллиона таких запросов кэш переполнялся. Поэтому сервис не мог обрабатывать значительный объем данных и был вынужден перезагружаться для очистки кэша.

Что нужно знать QA-специалисту

Инструменты для написания скриптов

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

На одном проекте мы использовали Gatling — хороший инструмент, который подходил нам на 100%. Тем не менее, заказчик попросил добавить новую функцию. И для нее мы не смогли с этим инструментом написать нагрузочный тест. Gatling работает на HTTP, а новая функциональность — на MQTT.

Сам инструмент может работать с этим протоколом, но только в платной версии (мы использовали бесплатную). Как бы мы ни прикручивали библиотеки или плагины, мы могли бы это запустить, но результаты были бы плохими. Потому пришлось искать новые инструменты для этого функционала. В результате все скрипты мы написали на Gatling и один — на языке Golang.

Знание языков программирования

Конечно, у всех инструментов есть документация с описанием, как правильно с ними работать, как можно применять те или иные методы, какие существуют фишки.

Но бывают моменты, когда нужно все равно писать самому: генераторы данных, плагины для покрытия определенного функционала. Для этого достаточно знать язык на среднем уровне, чтобы самостоятельно писать тесты.

Если у вас не получается написать что-нибудь самому, можно обратиться в команду разработки. Желательно, чтобы ваш инструмент был на том же языке, на котором создается приложение. Это позволяет работать совместно с девелоперами. Разработчики могут помочь с написанием генератора или библиотеки, показать правильную структуру проекта и рассказать о best practices. Так им будет не только проще, но и интереснее.

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

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

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

Знание архитектуры приложения

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

В нашей практике мы также убедились в важности подобных знаний. После появления ошибок в одном приложении в логах мы обнаружили только 30% отправленных запросов. Ошибки находились в формате таймаут. То есть запрос шел на сервер, становился в очередь на обработку, некоторое время не мог дождаться ответа, а потому отваливался. Необходимо было разобраться, почему этих ошибок нет в логах.

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

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

Знание систем CI/CD-процесса

Эти системы доставляют код от разработчиков на сервер (тестовый или сервер клиента). Работают они не только с кодом. С помощью CI/CD можно писать автотесты, перфоманс-тесты и любые другие.

Сначала мы запускали проверки локально на рабочих компьютерах, но таким образом невозможно выжать столько ресурсов, чтобы серьезно нагрузить некоторые микросервисы. Более того, при большой нагрузке заканчивались ресурсы компьютера. Потому мы сделали и добавили в проект Jenkins job на сервере и начали запускать тесты на нем.

Обратите внимание: это процесс тестирования микросервиса напрямую, ведь локально запрос идет через интернет и файрвол. Когда сервер с тестами и сервер с микросервисом находятся в одной сети, запросы бегают туда-сюда. Поэтому нет потерь времени, как при запросе от клиента через интернет, а результаты более чистые.

Понимание бизнес-значения и главных функций продукта

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

Функций в приложении может быть 500, а протестировать необходимо только пять, потому что они самые важные и критические.

В качестве примера вспомним работу банковской системы. Когда вы оформляете карту, вам создают счет, и вы можете производить транзакции в своем приложении. Если клиентов миллиард, столько же будет запросов и на создание аккаунта. Но они стартуют не одновременно, а через некоторое время. После создания одного другой профиль клиенту не нужен. Запрос одноразовый, а открытие карты происходит раз в 3-5 лет. Однако затем следуют миллиарды запросов транзакций — и это главный функционал приложения. Поэтому нужно внимательно тестировать именно эти функции, а другие достаточно прогнать раз и убедиться, что проблем нет.

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

Для этой разновидности тестирования существует множество инструментов. Каждый из них проверяет что-то свое: базы данных, ресурсы, сеть на пропускную способность и т.д. Мы же тестируем прежде всего две вещи — сервисы и визуальную часть (назовем ее браузерным перфоманс-тестированием). Что же нам нужно для работы?

Сервисные инструменты

Jmeter

Прежде всего, это Jmeter — он очень популярен и использует языки Java и Groovy. Эта тулза очень простая, потому что визуальная. Вы открываете проект и в окошечке блоками выставляете, как будет идти запрос и что будете делать. Затем следует вписать URL и данные, которые нужно передать для отправки и проверки, и забрать данные из ответа микросервиса.

Здесь не потребуется много знаний по программированию — можно самому создать банальные скрипты. У Jmeter есть множество библиотек и плагинов, он может тестировать все:

• визуальную часть;
• бэкенд;
• базы данных;
• MQTT.

В нашей команде с помощью Jmeter мы написали 5-10 скриптов, затем перешли на Gatling.

Gatling

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

К примеру, в проекте поменялась логика получения авторизации. Если было бы 50 скриптов, то из Jmeter нужно пройти по всем для правки одного URL. Со скриптовым Gatling достаточно написать одну функцию для логина и получения авторизации и изменить URL в этом методе, чтобы другие тесты работали как следует. Очень заманчивая альтернатива.

Locust

Хотя еще есть Locust — достаточно популярный скриптовый инструмент на Python, который в целом выполняет те же функции, что и Gatling.

Браузерные инструменты

Что касается визуальных инструментов, то это совсем другая логика тестирования. Используя сервисный инструмент, мы работаем с запросами. Браузерный перфоманс-инструмент измеряет состояние страницы в нескольких случаях:

• когда появляется первый контент;
• когда можно кликнуть на элементы странички;
• когда страница полностью готова к работе с пользователем;
• сколько страница загружалась и т.д.

Google Lighthouse

На первое место я бы здесь поставил Google Lighthouse. Он есть в любом браузере. Для создания репорта вам достаточно зайти на страницу, нажать F12 или открыть инструменты разработчика, найти вкладку Lighthouse и там нажать кнопку Generate Report.

В Google Lighthouse используется цветовая палитра с красным маркером для обозначения критических результатов, желтым — для плохих и зеленым — для хороших.

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

Например, у нас в одном проекте файл со CSS-стилями был слишком большим. Программа подсказала разбить его на 3-5 частей. Так загрузка идет параллельно, что экономит время. Или, скажем, небольшое по пикселям изображение весило 2 МБ. Инструмент предложил уменьшить файл, чтобы выиграть в быстродействии обозревателя. Сам отчет можно отдавать потом разработчикам, чтоб они решили, что следует пофиксить сначала.

Speedtest.io

Следующий инструмент — Speedtest.io. Есть два варианта его использования:

1. На официальном сайте, где можно вставить URL и получить отчет. Но это не подходит при сканировании страницы авторизованным пользователем.
2. Другой вариант — загрузить и запустить тулзу на локальной машине и написать скрипт подобно UI-автоматизации на JavaScript. Этот скрипт будет открывать браузер, проходить логин-этап и ходить по страницам.

Интересно, что Speedtest.io может замерять это время и анализировать только указанные страницы или измерять все время. То есть вместо того, чтобы из Lighthouse проверять отдельно каждую страницу (которых может быть множество), лучше создать один скрипт и прогонять его по всем страницам для одного большого отчета.

Инструмент также подразумевает логику анализа, которая подскажет проблемные места. Хотя их всегда можно посмотреть по метрикам.

Webpagetest.org

Webpagetest.org отличается от двух предыдущих. Эта тулза выполняет такие же функции, что и Speedtest.io. Вы можете просмотреть страницы через URL или скрипты. Также есть интеграция с Google Lighthouse — через него можно сгенерировать отчет.

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

Где можно получить больше знаний о нагрузочном тестировании

Я разделяю знания на две категории: общие и проектные:

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

Общие знания

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

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

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

Среди примеров подобных книг могу порекомендовать The Art of Application Performance Testing Ian Molyneaux и The Hitchhiking Guide To Load Testing Projects – A Fun, Step-by-Step Walk-Through Guide by Leandro Melendez.

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

Могу привести следующие примеры таких книг: Performance Testing Guidance for Web Applications by J.D. Meier, C. Farre, P. Bansode, S. Barber, D. Rea или Systems Performance Enterprise and the Cloud by Brendan Gregg.

Проектные знания

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

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

Например, если вы спросите бизнес-аналитика об отправке письма о регистрации на сайте, оно ответит примерно так: «Заходим в приложение, открывается форма, мы ее заполняем, жмем кнопку “Отправить” — и на email приходит письмо “Поздравляем, вы зарегистрировались на сайте”» .

Когда вы с таким вопросом обратитесь к разработчику, ответ будет более обширным, техническим: запрос попадает на микросервис и сохраняется в базе, генерируются данные, затем они отправляются на email-сервер, который берет шаблон письма и формирует его с заданным изображением и текстом, отправляет их на Gmail, где происходит анализ и проверка на инфицированные файлы, а после валидации сохраняется письмо — и в папке «Входящие» появляется отметка +1.

Советую вам как тестировщику балансировать между поиском знаний о проекте от бизнес-аналитика и девелопера.

Вместо вывода

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