Ответ
Нагрузочное тестирование (Load testing) — это тип нефункционального тестирования, которое проверяет поведение системы под ожидаемой рабочей нагрузкой (например, определённым количеством одновременных пользователей или транзакций). Его цель — убедиться, что приложение стабильно работает в условиях, имитирующих реальное использование, и выявить проблемы производительности до релиза.
Ключевые цели и проверяемые метрики:
- Время отклика системы на действия пользователей.
- Пропускная способность (throughput) — количество обработанных операций в единицу времени.
- Использование ресурсов сервера: загрузка CPU, потребление памяти (RAM), операции ввода-вывода (I/O).
- Стабильность — отсутствие сбоев, утечек памяти или деградации производительности в течение теста.
Пример сценария в Apache JMeter:
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Пользовательская нагрузка" enabled="true">
<intProp name="ThreadGroup.num_threads">100</intProp> <!-- 100 виртуальных пользователей -->
<intProp name="ThreadGroup.ramp_time">60</intProp> <!-- Наращивание нагрузки за 60 секунд -->
<longProp name="ThreadGroup.duration">300</longProp> <!-- Длительность теста 300 секунд -->
</ThreadGroup>Важное отличие: Load testing не следует путать со стресс-тестированием (Stress testing). Нагрузочное тестирование проверяет систему в пределах или около плановых нагрузок, в то время как стресс-тестирование нацелено на работу за пределами нормальной ёмкости, чтобы определить точку отказа и поведение системы при восстановлении.
Ответ 18+ 🔞
Да ты посмотри, какая тема подъехала! Нагрузочное тестирование, ёпта! Это ж когда ты берёшь свою систему, которая вроде как работает, и начинаешь её нагружать, как тупого осла, чтобы посмотреть, когда у неё жопа отвалится. Но не сразу, а по плану, с изяществом!
Представь: у тебя есть сайт, и ты думаешь: "О, да тут 100 человек одновременно зайдут — и всё будет пиздато!". А на деле-то, блядь, при 50-ти уже сервер начинает пыхтеть, как паровоз, и время отклика такое, что можно сходить за пивом, вернуться, а страница ещё не открылась. Вот чтобы такого пиздеца не было, и придумали эту самую нагрузку гонять.
Чего мы хотим этим добиться, спросишь ты? А вот чего:
- Время отклика. Чтобы система не тупила, как манда с ушами, а отвечала быстро. Кликнул кнопку — и тут же результат, а не через полчаса, когда уже и желание пропало.
- Пропускная способность. Сколько операций в секунду она может проглотить, не подавившись. Чтобы не было так, что первые десять запросов пролетели, а на одиннадцатом всё накрылось медным тазом.
- Жор ресурсов. Смотрим, как система жрёт память, грузит процессор и дёргает диски. Чтобы не было утечек памяти, которые тихой сапой, блядь, приводят к тому, что сервер просто падает через час работы, и все начинают охуевать.
- Стабильность. Чтобы под нагрузкой система не начинала глючить, не падала и не деградировала. Проработала тестовые 5 минут, 5 часов — и всё так же шустро, без сюрпризов.
Вот, смотри, как это примерно в JMeter'е выглядит, этот самый сценарий:
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Пользовательская нагрузка" enabled="true">
<intProp name="ThreadGroup.num_threads">100</intProp> <!-- 100 виртуальных юзеров, которые будут насиловать систему -->
<intProp name="ThreadGroup.ramp_time">60</intProp> <!-- Не всех сразу, а наращиваем за минуту, по-человечески -->
<longProp name="ThreadGroup.duration">300</longProp> <!-- И гоняем эту карусель целых 5 минут -->
</ThreadGroup>И главное, блядь, не перепутай! Это не стресс-тестирование, где мы доводим систему до белого каления, чтобы посмотреть, как она сдохнет и воскреснет. Нет! Нагрузочное тестирование — это про реализм. Мы наваливаем на неё ровно столько, сколько она, по нашим прикидкам, должна выдерживать в рабочем режиме. А стресс-тест — это уже когда мы говорим: "А что будет, если пользователей будет овердохуища?" и начинаем ломать всё к хуям, чтобы найти пределы прочности. Это разные вещи, как кот и сука собака!