Нагрузочное тестирование является одним из самых сложных видов тестирования программного обеспечения. Да и инструменты для таких проверок далеки от совершенства. Почему так?

Если вкратце отвечать на данный вопрос, то все трудности сводятся к 3 вещам:

1. Больше половины инструментов нагрузочного тестирования могут поддерживать лишь самые простые нагрузки. И даже программы с широким функционалом пока не имеют всех требуемых опций для эффективной симуляции реального применения ПО.
2. Самая сложная вещь – создание теста с симуляцией реального применения продукта, даже если используемые инструменты могут поддерживать нужные нам возможности.
3. Поддержка теста – очень сложная задача, а используемые инструменты нагрузочного тестирования не могут предоставить никакой существенной помощи.

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

Симуляция реальных пользователей

Несомненно, она важна, но все зависит от конкретной ситуации на каждом отдельном проекте. В нашем случае подразумевается пользователь определенного сервиса: если это монолит – это все пользователи в целом, но если это микросервис – здесь пользователями могут быть другие сервисы!

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

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

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

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

Создание и поддержка тестов – трудная задача

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

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

Порой, приходится анализировать логи, пока не приходит понимание того, какова реальная схема использования.

Дальше следует процесс создания такой симуляции – необычная задача, так как нужно обрабатывать состояние внушительного числа объектов, которые представляют собой пользователей вашего API.

Ну а теперь нужно создавать для всего этого интеграционные тесты!

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

Все ли надо покрывать нагрузочными тестами?

Все нагрузочные тесты содержат массу сложностей, справиться с которыми можно исключительно применяя множество разнообразных инструментов. Это значит, что выход в следующем: [highlight dark=”no”]создавать минимум тестов и не слишком сильно надеяться на то, что они смогут ответить на все вопросы о текущей производительности ПО[/highlight].

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

• Анализ. Достаточно потратить несколько часов на то, чтобы понять базовые расчеты параметров и максимальных ограничений в производительности тестируемой системы. Если во время анализа вы столкнетесь с неизвестными переменными или данными, вы сразу же сможете их быстро проверить.
• Развертывание фич. Если у вас получается медленно разворачивать фичи на всех пользователей, то вам может даже не понадобится тестирование нагрузки! Замеры производительности вы сможете измерять экспериментально и тестировать, хватает ли ее.
• Повтор трафика. Подобное точно не поможет с новыми фичами, но позволит правильно понимать критические точки ПО для уже созданных фич. Вы можете заручиться зафиксированным ранее трафиком и прогонять его на постоянной основе, анализируя состояние производительности системы.

В заключение

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

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