Как провести нагрузочное тестирование программы

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

Обсудим, как написать план такого тестирования. В нем нужно рассмотреть следующие моменты:

• Какой результат ожидается от нагрузочного тестирования?
• Как мы будем тестировать это веб-приложение:

• В реалистичных условиях
• В пиковых условиях

• Какое реальное количество одновременных пользователей ожидается?
• Какие места в приложении «принимают» больше пользователей?
• Пределы выносливости

Какой результат ожидается от нагрузочного тестирования?

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

Что такое нагрузочное тестирование (load testing)?

Что нужно уяснить во время нагрузочного тестирования:

1. Какой элемент приложения будет “стопорящим” (так называемый bottleneck), когда резко возрастет количество пользователей?
2. Корректно ли масштабируется приложение под большой нагрузкой?
3. Корректно ли ведет себя приложение во время тестирования в условиях, имитирующих реальную нагрузку?
4. Сколько пользователей одновременно может работать с приложением в “пиковых” условиях?
5. Как время ответа (response time) изменяется в ответ на рост числа пользователей?
6. Как можно оптимизировать производительность приложения?

Как мы будем тестировать приложение?

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

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

Будем тестировать приложение в двух условиях нагрузки.

При реалистичной нагрузке

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

При пиковой нагрузке

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

Обзор JMeter | Что такое JMeter? | Нагрузочное тестирование в JMeter.

Сбор начальных данных для сценариев

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

Какое максимальное количество одновременных пользователей ожидается?

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

1. Идем на страницу «Сессии» или «Пользователи» в приложении аналитики посещаемости (той же Google Alalytics, Яндекс.Метрике и т.п.)
2. Находим самый нагруженный день за последний год.
3. В этом дне, выделяем 2 самых нагруженных часа.
4. Из этих цифр посещаемости, вычисляем количество одновременных пользователей, по формуле:

Количество одновременных пользователей = (количество пользователей за 2 часа) * среднее время проведенное на странице, в секундах / 3600 секунд / 2 часа = ?

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

В нашем случае, у нас было 20 тысяч сессий, а среднее время проведенное на странице составило 2 минуты. В итоге получилось 333 одновременных пользователя.

Всего сессий за 2 часа = 20 000 сессий

Среднее время проведенное на странице = 120 секунд

Одновременных пользователей = 333 пользователя

Какие части веб-приложения нагружаются больше всего?

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

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

Анализ может выглядеть примерно так (сайт магазина):

СтраницаПроцент трафика

/	60%
/articles	20%
/shop	15%
/contact	5%

Проверяем пределы выносливости приложения

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

1. Сколько времени приложению нужно, чтобы обработать запрос?
2. Какой ответ считается успешным?

Эти пределы должны быть испытаны в тестовом наборе.

Создание тестовых сценариев

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

В таблице ниже — у нас 3 сценария реалистичной нагрузки, и 3 сценария пиковой нагрузки. При пиковой нагрузке количество одновременных пользователей увеличивается “по ступенькам”, таким образом и оценивается устойчивость приложения.

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

СценарийОдновременное количество пользователейВремя роста нагрузкиДлительность нагрузки

Один пользователь	1	0 минут	5 минут
Реалистичные условия #1	100	5 минут	20 минут
Реалистичные условия #2	200	10 минут	30 минут
Реалистичные условия #3	350	20 минут	60 минут
Пиковые условия #1	300	10 минут	30 минут
Пиковые условия #2	400	15 минут	40 минут
Пиковые условия #3	600	20 минут	50 минут

Выполнение тестов

После создания плана, и написания скриптов, выполняем тесты.

При этом надо учесть следующее:

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

• Наладить мониторинг в реальном времени, чтобы сразу видеть последствия нагрузки; как высокий трафик влияет на веб-приложение и другие части сервера.

• Тестировать приложение в продакшн-среде, или среде, сопоставимой по мощности.

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

Разбор результатов

Все это выглядит примерно так:

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

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

Источник: testengineer.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1: Мониторинг ресурсов

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

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

Если у вас уже есть система мониторинга типа Prometheus, Graphite или CollectD, вы сможете собрать все необходимые данные.

• Мониторинг сервера Ubuntu 14.04 с помощью Prometheus
• Отслеживание статистики сайта (инструменты Graphite, StatsD и CollectD)

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

Для мониторинга доступной памяти используйте команду free. В комбинации с командой watch данные будут обновляться каждые 2 секунды.

Флаг -h выводит числа в удобочитаемом формате.

total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
-/+ buffers/cache: 39M 450M
Swap: 0B 0B 0B

Выделенное число в выводе представляет свободную память после вычитания буфера и кэша. Новые версии free выводят другие результаты:

. total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M 260M
Swap: 0B 0B 0B

Новый столбец available вычисляется по-разному, но обычно представляет одну и ту же метрику: текущий объем доступной памяти для приложений.

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

sudo apt-get install sysstat

При запуске mpstat нужно задать интервал обновления данных в секундах:

Она выведет строку заголовков, а затем строку статистики, и будет обновляться каждые две секунды:

Linux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

Столбец %idle показывает, какой процент ресурсов ЦП не используется. Загрузка процессора часто разделяется на разные категории (user CPU и system CPU).

2: Определение максимальной скорости отклика

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

Конкурентность – это показатель, который отображает количество параллельных подключений, которое может обрабатывать сервер. Значение по умолчанию 100 подходит в большинстве случаев, но вы можете выбрать индивидуальное значение. Для этого нужно проверить MaxClients, MaxThreads сервера и другие подобные параметры.

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

Некоторое программное обеспечение для нагрузочного тестирования позволяет сразу указать несколько URL-адресов, которые нужно проверить. Это позволяет более точно имитировать реальный трафик. Если у вас есть данные об использовании сайта (из аналитического программного обеспечения или логов сервера), вы можете применить эти данные в тестировании.

Отобрав URL-адреса, запустите тестирование. Убедитесь, что программное обеспечение очень быстро отправляет запросы. Если программное обеспечение разрешает выбрать скорость запроса, выберите значение, которое почти наверняка будет слишком высоким для вашего сервера. Если программное позволяет установить задержку между запросами, уменьшите это значение до нуля.

Использование ресурсов процессора и памяти будет увеличиваться. Свободные ресурсы процессора могут достигать 0%, и клиент может получить ошибку соединения. Это нормально, поскольку сервер работает на пределе возможностей.

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

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

3: Определение максимальной пропускной способности

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

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

Возьмите максимальную скорость запросов, которую вы определили на предыдущем этапе, и разделите ее на 2. Запустите еще один тест с новыми данными и обратите внимание на время ответа. Находится ли показатель в приемлемом диапазоне?

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

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

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

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

Инструмент ab

ab (или ApacheBench) – это простой однопоточный инструмент командной строки для тестирования HTTP-серверов. Изначально он разрабатывался как часть HTTP-сервера Apache, но его можно использовать для тестирования любого HTTP- или HTTPS-сервера.

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

Базовый вызов команды ab выглядит следующим образом:

ab -n 1000 -c 100 http://example.com/

Флаг –n задает количество запросов. Флаг –с задает конкурентность. Затем нужно указать URL, который нужно протестировать. Вывод (выдержка из которого приведена ниже) указывает количество запросов в секунду, время запроса и список процентилей времени ответа:

. . .
Requests per second: 734.76 [#/sec] (mean)

Time per request: 136.098 [ms] (mean)
Time per request: 1.361 [ms] (mean, across all concurrent requests)
Transfer rate: 60645.11 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)
50% 133

66% 135

75% 137

80% 139

90% 145

95% 149

98% 150

99% 151

100% 189 (longest request)

JMeter

JMeter – это мощное и многофункциональное приложение для нагрузочного и функционального тестирования от Apache Software Foundation. Функциональное тестирование – это проверка вывода приложения.

JMeter предлагает графический интерфейс Java для настройки тестовых планов.

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

JMeter может выводить информацию о процентилях в отчетах HTML и других форматах.

Siege

Siege – еще один инструмент командной строки для нагрузочного тестирования. Он похож на ab, но имеет несколько дополнительных функций. Siege – многопоточный инструмент, что обеспечивает относительно высокую пропускную способность. Он также позволяет указать сразу несколько URL-адресов для нагрузочного тестирования. Базовый вызов выглядит так:

siege -c 100 -t 30s http://example.com/

Флаг –с указывает конкурентность. Флаг -t определяет продолжительность тестирования (в данном случае – 30 секунд). Siege выводит среднее время отклика и скорость запроса:

. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Response time: 0.01 secs

Transaction rate: 197.15 trans/sec
Throughput: 4.59 MB/sec
Concurrency: 2.23
. . .

Siege не предоставляет процентилей для статистики задержек.

Locust

Locust – это инструмент для нагрузочного тестирования на основе Python, который предоставляет веб-интерфейс для мониторинга результатов в реальном времени.

Сценарии тестирования Locust пишутся с помощью кода Python, что предоставляет дополнительные преимущества тем, кто хорошо знаком с этим языком программирования.

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

Locust может предоставить подробную статистику в CSV-файлах, которые можно загрузить.

Инструмент wrk2

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

wrk2 вызывается командой wrk:

wrk -t4 -c100 -d30s -R100 —latency http://example.com/

Параметр -t определяет количество потоков (в данном случае их 4, здесь нужно использовать количество процессорных ядер вашего сервера). Параметр -c указывает количество одновременных запросов (здесь 100). Флаг –d определяет продолжительность тестирования (30 секунд). Флаг –R указывает частоту запросов в секунду (100). Подробный вывод задержки предоставит флаг –latency.

. . .
Latency Distribution (HdrHistogram — Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .

Заключение

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

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

Источник: www.8host.com

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

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

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

Нагрузочное тестирование — основы

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

Нет ничего сложного в том, чтобы взять, например, легковушку, посадить в нее пять человек, в багажник положить три мешка картошки, завести и поехать по прямой. Гораздо важнее понять, какое расстояние она сможет проехать с такой нагрузкой, как поведет себя на разных дорожных покрытиях, когда потребует техосмотра. И не нужны ли ей будут конструктивные изменения. Определение таких вещей значительно важнее для качества продукта, нежели просто поиск предельных значений.

Поэтому предлагаем сойтись на таком определении: нагрузочное тестирование — это определение качества работы продукта под определённой нагрузкой на заданном интервале времени.

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

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

Получилось — хорошо, значит, основная функция продолжает работать штатно. А что будет, если мы так проездим целый день? Если потратим бензина на 30% больше — это допустимо или нет? А если в пять раз больше, тогда что? Как поведёт себя машина при подъёме на гору с уклоном в 12 градусов? А если дорога будет не с асфальтовым покрытием, а с грунтовым, и прошёл дождь?

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

Роль нагрузочного тестирования в жизни продукта

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

Здесь лучше самим себе максимально честно ответить на вопрос: “А что будет, если мы не проведём нагрузочные тесты, и конечный пользователь столкнётся с последствиями этого решения?” Особенность нагрузочного тестирования в том, что когда пользователь подходит к тем самым экстремумам, которые мы можем заранее определить, расширить или ограничить, результат стреляет так, что мало не покажется. Если наш продукт просто перестанет работать в какой-то момент (у машины заглох двигатель, или отвалились все колёса), это мы легко отделались. А если он повредит обрабатываемые данные (отвалилось только одно колесо, машина влетела в столб и водитель погиб), то что тогда? Прежде всего мы должны думать о безопасности людей и их данных. Такие вещи могут приводить к огромным репутационным и финансовым потерям, что в перспективе может привести даже к закрытию компании.

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

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

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

Вы её купили, заранее скачали, выгнали всех из дома, чтобы никто не мешал вам целиком и полностью насладиться моментом, и вдруг видите, что вы 100500-ый в очереди на подключение к серверу, и надо грустно ждать несколько часов. Разработчики могли предсказать наплыв игроков на релизе? Конечно, могли. Они справились с такой ситуацией? И да, и нет.

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

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

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

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

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

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

Обычно это довольно сложная и кропотливая работа, так как одновременно нагрузить все компоненты — это не тоже самое, что просто включить все имеющиеся у нас тесты и снимать метрики. Конкретно в случае нашего Veeam Backup https://habr.com/ru/companies/veeam/articles/578942/» target=»_blank»]habr.com[/mask_link]