Ответ
Тестирование производительности — это не один тип теста, а целое семейство, каждое из которых решает свою задачу. Основные виды:
| Вид тестирования | Цель | Ключевой вопрос | Пример сценария |
|---|---|---|---|
| Нагрузочное (Load Testing) | Проверить поведение системы под ожидаемой (пиковой) нагрузкой. | Выдерживает ли система планируемое количество пользователей? | 1000 пользователей одновременно просматривают каталог товаров и добавляют их в корзину в течение 1 часа. Проверяются время отклика и процент ошибок. |
| Стресс-тестирование (Stress Testing) | Найти предел производительности и точку отказа системы, а также проверить механизмы восстановления. | Как система ведет себя за пределами нормальной нагрузки? Где она ломается? | Постепенно увеличиваем нагрузку с 1000 до 5000 пользователей, пока сервер не начнет возвращать ошибки 5xx. Смотрим, как система восстанавливается после снятия нагрузки. |
| Тестирование стабильности/надежности (Soak/Endurance Testing) | Обнаружить проблемы, возникающие при длительной работе под нагрузкой (утечки памяти, фрагментация, рост логов). | Стабильна ли система при длительной эксплуатации? | 500 пользователей непрерывно работают с приложением в течение 72 часов. Мониторим потребление памяти (RAM) и утилизацию CPU. |
| Тестирование масштабируемости (Scalability Testing) | Определить, как увеличение ресурсов (серверов, CPU, RAM) влияет на производительность. | Позволяет ли архитектура системы эффективно масштабироваться? | Проводим нагрузочный тест на текущей конфигурации (2 сервера). Затем добавляем еще 2 сервера и повторяем тест. Ожидаем, что пропускная способность (throughput) увеличится почти в 2 раза. |
| Spike Testing (Тестирование на всплеск нагрузки) | Проверить реакцию системы на резкое, кратковременное увеличение нагрузки. | Как система справляется с внезапным наплывом пользователей? | Нагрузка резко возрастает с 100 до 2000 пользователей за 1 минуту, затем так же резко падает. |
Практический пример: конфигурация Thread Group в Apache JMeter для нагрузочного теста.
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="E-Commerce Load Test">
<!-- Количество виртуальных пользователей (потоков) -->
<intProp name="ThreadGroup.num_threads">1000</intProp>
<!-- Время (в секундах) на «разгон» до полного количества пользователей -->
<intProp name="ThreadGroup.ramp_time">300</intProp>
<!-- Количество повторений (0 = бесконечно, пока не остановят) -->
<intProp name="ThreadGroup.loop_count">0</intProp>
<!-- Длительность теста (секунд) -->
<stringProp name="ThreadGroup.duration">3600</stringProp>
</ThreadGroup>Ключевые метрики, которые собирают во всех этих тестах: время отклика (Response Time), пропускная способность (Throughput, запр./сек), процент ошибок (Error Rate), утилизация ресурсов (CPU, RAM, I/O, Network).
Ответ 18+ 🔞
Слушай, а вот это самое тестирование производительности — это ж не какая-то одна хуйня, а целая банда родственников, и у каждого своя миссия на этом празднике жизни. Давай разбираться, пока не охуели.
Вот смотри, таблица, блядь, чтобы не запутаться:
| Вид тестирования | Цель | Ключевой вопрос | Пример сценария |
|---|---|---|---|
| Нагрузочное (Load Testing) | Понять, как система себя ведёт под нормальной, ожидаемой нагрузкой. Не упадёт ли? | Выдержит ли наша хрень планируемое количество юзеров, или они нам всё сломают? | 1000 человек одновременно лазают по каталогу и тыкают «в корзину» целый час. Смотрим, не тормозит ли всё в пизду и сколько ошибок вылезает. |
| Стресс-тестирование (Stress Testing) | Найти предел, где всё ебётся, и посмотреть, как система потом отходит. | А что будет, если навалиться сверх нормы? Где конкретно она сломается и как потом оживёт? | Плавно накручиваем нагрузку с 1000 до 5000 юзеров, пока сервера не начнут плеваться ошибками «500 Internal Server Error». Потом снимаем нагрузку и смотрим, не сдохла ли система насовсем. |
| Тестирование стабильности/надежности (Soak/Endurance Testing) | Поймать проблемы, которые всплывают только со временем: утечки памяти, забитые логи, фрагментация — всякое такое. | А не сольётся ли система через сутки-двое работы? | 500 пользователей без остановки дёргают приложение 72 часа. Сидим, смотрим, не жрёт ли память как сумасшедшая и не греется ли процессор до состояния ядерного гриля. |
| Тестирование масштабируемости (Scalability Testing) | Понять, помогает ли добавление железа (серверов, ядер, памяти) или мы просто деньги на ветер кидаем. | Масштабируется ли наша архитектура, или мы упёрлись в потолок? | Гоняем тест на двух серверах, запоминаем цифры. Потом добавляем ещё два и гоняем тот же тест. Если всё правильно, пропускная способность должна вырасти почти вдвое, а не остаться на том же уровне, блядь. |
| Spike Testing (Тестирование на всплеск нагрузки) | Проверить, что будет, если нагрузка прилетит резко и нежданно, как хуй из-за угла. | А справится ли система, если все пользователи вдруг одновременно решат зайти, как на распродажу? | Нагрузка скачком с 100 человек взлетает до 2000 за минуту, потом так же резко падает. Смотрим, не ляжет ли всё в этот момент. |
А вот, например, как это может выглядеть в Apache JMeter для нагрузочного теста. Код не трогаем, он святой:
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="E-Commerce Load Test">
<!-- Количество виртуальных пользователей (потоков) -->
<intProp name="ThreadGroup.num_threads">1000</intProp>
<!-- Время (в секундах) на «разгон» до полного количества пользователей -->
<intProp name="ThreadGroup.ramp_time">300</intProp>
<!-- Количество повторений (0 = бесконечно, пока не остановят) -->
<intProp name="ThreadGroup.loop_count">0</intProp>
<!-- Длительность теста (секунд) -->
<stringProp name="ThreadGroup.duration">3600</stringProp>
</ThreadGroup>И во всех этих танцах с бубнами мы смотрим на одни и те же ключевые метрики, ёпта: время отклика (Response Time — сколько ждать), пропускную способность (Throughput — сколько запросов в секунду пролетает), процент ошибок (Error Rate — сколько всё-таки сломалось) и утилизацию ресурсов (CPU, RAM, I/O, Network — чтобы железо не плавилось). Вот так вот, в рот меня чих-пых.