🎯

Load Testing Basics

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

Определение НТ

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

Цели НТ

1) Определение максимальной производительности системы.

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

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

3) Проверка стабильности (надежности) – длительная нагрузка системы на уровне 70-80% от максимума. Максимальная нагрузка указана в требованиях к программному продукту или ранее найдена при тестировании максимальной производительности. Целью данного тестирования является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки (не зависает ли система при длительной нагрузке на нее и в целом - правильно ли работает система либо возникают какие-либо проблемы);

4) Проверка системы под действием стресс-нагрузки – тестирование, при котором система нагружается нагрузкой, которая в несколько раз превышает норму. Цель данного тестирования

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

5) Re-test - проверка исправления ошибки (дефекта) после обнаружения проблемных участков в системе. Необходимо делать после исправления дефектов разработчиками чтобы убедиться в том, что дефекты действительно исправлены и система работает в соответствии с ожидаемым результатом;

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

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

7) Воспроизведение проблем промышленной среды - воспроизведение на тестовом стенде максимально похожую проблему при ее обнаружении на боевом\Прод сервере системы. Тестовый стенд всегда отличается от Прода (сервер, на котором размещена стабильная версия веб-приложения), даже если установлена одна версия ПО. Если мы на Проде получили проблему, ее нужно постараться воспроизвести максимально похоже на тестовом стенде и после этого приступать к решению возникшей проблемы.

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

1) Выпуск нового ПО –проводится при выпуске нового программного обеспечения и осуществляется для того, чтобы сравнить фактическое поведение ПО с ожидаемым (поведение ПО в соответствии с требованиями). В данном случае необходимо провести:

определение максимальной производительности системы;

выявление проблемных участков системы ("узких мест");

проверку системы под действием стресс-нагрузки;

проверку отказоустойчивости;

2) Добавление нового функционала – проводится при добавлении нового функционала в выпущенном ПО. Допустим, добавлена отправка электронной почты, поисковую систему, прогноз погоды и т.д. (примеров масса), нам необходимо нагрузить новый добавленный функционал в связи с этим актуализировав профиль нагрузки(путём добавления нового функционала). Для того, чтобы понять - какую нагрузку способна выдержать система с обновленным профилем. Иногда перед этим проводят тест со старым профилем, для того чтобы понять изменения в производительности системы;

3) Плановое тестирование – тестирование, которое проводится по плану. Данное тестирование необходимо проводить исходя из планового расписания, чтобы убедиться в том, что ПО работает в соответствии с заявленными требованиями через определенный промежуток времени, указанный в плановом расписании;

4) Смена технологии - тестирование, которое проводится, когда меняется оборудование (например БД использовало HDD диски, а теперь SSD), и\или кардинальные изменения в части непосредственно ПО (например смена языка программирования,фреймворка и тд).

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

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

Определение и постановка задачи.

На данном этапе мы:

собираем всю информацию по продукту - для чего необходимо ПО (цель использования ПО), требования к производительности данного ПО (SLA), и какие действия осуществляют пользователи при использовании ПО для составления тест-кейсов;

определяем состав группы: тестировщики, разработчики, аналитики, архитекторы, project менеджеры;

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

Подготовка тестового стенда и средств тестирования:

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

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

установка всех необходимых программ для тестировщиков;

Создание стенда

получение доступов к стендам для тестировщиков.

Подготовка тестового плана (методики НТ).

В данном документе описываются тест-кейсы (тестовые сценарии, процессы и шаги, которые мы будем проводить во время нашего тестирования) с целью имитации деятельности конечных пользователей. На данном этапе также описываются сроки, количество участников, частота проведения наших тестов, профиль нагрузки, описание тестового и Пром контуров и различия в их аппаратных ресурсах,ограничения тестирования (например разница в объёме наполнения БД тестового и Пром контуров, наличие заглушенных интеграций и тд.), средства мониторинга используемые при проведении тестирования.

4) Настройка тестового стенда и вспомогательного ПО.

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

5) Определение профиля нагрузки

Перечисление операций и их интенсивность.

Есть два различных подхода к составлению профиля:

1) По часу пиковой нагрузки (далее ЧПН).

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

2) Второй подход более затратен по времени на анализ статистики, но дает существенно больший процент покрытия профиля (будет объяснен далее).

Он состоит в поиске пикового часа для каждой отдельной операции в имеющейся статистике.

Например:

В ЧПН (пусть будет 01.01.2025 13:00 - 14:00) мы можем видеть следующие цифры:

Что говорит нам о том, что 100% интенсивности профиля составляет 2250 TPS. Однако во многих случаях это не отражает реальных пиковых значения каждого кейса и как следствие может привести к чувству ложной уверенности в запасе прочности нашей системы.

Например 01.01.2025 14:00 - 15:00, мы можем обнаружить следующее:

А скажем 05.01.2025 в 12:00 - 13:00 увидеть следующую картину:

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

Что даёт нам 2500 TPS на выходе, а следовательно разницу в нагрузке чуть больше чем на 10% относительно 2250 TPS в ЧПН, и в том числе был учтен ресурсоемкий кейс формирования справки 2-ндфл. Фокус состоит в том, что общее кол-во запросов в каждом конкретном часе может быть меньше, по сравнению с ЧПН, но иметь существенную разницу в пиковых значениях для операций входящих в наш профиль, а следовательно меньшую гарантию того, что представленные нами результаты тестирования дадут исчерпывающую информацию о реальных возможностях системы, ее скрытых дефектах под нагрузкой и “узких местах”.

Стоит отметить, что в профиль нагрузки попадают операции по трём критериям:

а) Высокоинтенсивные операции (операции преобладающие количественно в статистике)

б) Тяжелые\ресурсоемкие операции (например отправка файла)

в) Бизнес критичные операции (например выгрузка статистики\отчета об операциях за день)

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

Например, если в реальности система обрабатывает 10 000 RPS (запросов в секунду), а в тесте — только 5 000 RPS, то покрытие — 50%.

Покрытие есть ни, что иное как процентное соотношение запросов на реальном Пром контуре (или спрогнозированный аналитиками) к эмулированным запросам в нашем профиле. Далее критерии оценки покрытия:

< 70% - недостаточный процент покрытия

70 - 80% - приемлемый процент покрытия

80 - 90% - отличный процент покрытия

>90% - в большинстве случаев является избыточным

6) Проведение нагрузочного тестирования.

На данном этапе мы проводим нагрузочные тесты исходя из определенных ранее целей нагрузочного тестирования.

В примере ниже указаны тесты на случай необходимости узнать реальный максимально возможный уровень нагрузки на систему и проверка ее работоспособности в рамках ранее выдвинутых нефункциональных требований (SLA). А также проверка стабильности\надёжности нашего продукта в рамках длительной эксплуатации.

В данной случае будут входить:

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

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

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

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

тестирование стабильности (надежности). Данный тест проводиться на уровне 70-80% (в зависимости от методологии и требований к системе может быть как 70, так и 80%) от ранее найденного максимума в течении 24 или более часов, и служит для анализа работы системы на длительных временных промежутках для выявления накопительных проблем (как пример - утечка памяти);

7) Подготовка отчета и анализ результата тестирования

На данном этапе у нас происходит фиксирование таких данных, как:

процент успешных операций, так называемая доступность;

время отклика системы под нагрузкой;

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

% утилизации ресурсов компонентов входящих в тестирование.

Виды тестов

1. Смоук-тестирование (Smoke Testing)

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

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

Объяснение: Смоук-тестирование помогает выявить критические ошибки на ранних этапах и убедиться, что система готова для более глубокого тестирования. Является единственным тестом направленным именно на выявление функциональных дефектов.

2. Поиск максимума (Finding the Maximum)

Цель: Определить максимальную нагрузку, которую система может выдержать не выходя за определенные критерии не/успешности(SLA).

Пример: Увеличение числа одновременных пользователей на веб-сайте до тех пор, пока отклик системы не станет неприемлемым.

Объяснение: Этот вид тестирования помогает определить пределы производительности системы и выявить точки, где система начинает терять эффективность.

Проводится в виде ступенчатого теста с постепенным увеличением нагрузки на каждой из ступеней. Последняя ступень нагрузки в рамках которой система не выходит за рамки зафиксированного SLA признается максимумом для системы или Lmax.

3. Подтверждение максимума (Confirming the Maximum)

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

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

Объяснение: Этот вид тестирования подтверждает, что система может стабильно работать под максимальной нагрузкой и не теряет производительность со временем. Проводится в виде относительного короткого теста длительностью в час, на уровне нагрузки Lmax. Обычно проводится не более часа по времени, т.к. существует понятие ЧПН.

4. Тест надежности (Reliability Testing)

Цель: Проверить, как система работает под продолжительной нагрузкой.

Пример: Тестирование сервера под постоянной нагрузкой в течение >= 24 часов.

Объяснение: Этот вид тестирования помогает выявить проблемы, которые могут возникнуть при длительной эксплуатации системы, такие как утечки памяти или деградация производительности (могут не быть обнаружены при тесте максимума) на уровне нагрузки близким к Lmax.

Проводится на уровне 70-80% от Lmax в течении 24 или более часов.

Остаток в 20-30% необходим в качестве резерва для непредвиденных скачков нагрузки на Пром контуре.

5. Стресс-тестирование (Stress Testing)

Цель: Определить поведение системы, подвергая ее экстремальным условиям (выше ее максимума).

Пример: Выход на стабильную нагрузку в ~80% (обычно по тесту надежности). Далее увеличение нагрузки до 120-150% на короткое время (15-30 минут). Уменьшение нагрузки до стабильной и подержать ещё какое-то время.

Объяснение: Стресс-тестирование помогает понять, как система ведет себя под чрезмерной нагрузкой и выявляет точки отказа. Также позволяет узнать, как система восстанавливается после такой нагрузки.

6. Негативное тестирование (Negative Testing)

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

Пример: Умышленный ввод некорректных данных в форму регистрации и проверка, как система реагирует на это под нагрузкой.

Объяснение: Негативное тестирование помогает выявить уязвимости и ошибки в обработке некорректных данных. Также можно заложить определенный процент некорректных запросов в тесты Максимума/Надежности, если стоит такая задача (обычно не более 5% от общей нагрузки).

7. Регрессионное тестирование (Regression Testing)

Цель: Убедиться, что новые изменения в системе не привели к появлению новых ошибок или ухудшению производительности.

Пример: Проверка, что после внесения изменений в код система продолжает работать корректно и не теряет производительность.

Объяснение: Регрессионное тестирование помогает убедиться, что новые изменения не нарушили существующую функциональность и производительность системы. Проводится в сравнении с результатами “эталонного” тестирования профиля нагрузки, выявленного в результате предыдущего цикла тестирования системы.

8. Тестирование на отказоустойчивость (Failover Testing)

Цель: Проверить, как система справляется с отказами компонентов.

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

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

запускается тест на уровне нагрузки теста надёжности (80% от Lmax). В первые полчаса наша задача убедится в том, что система отрабатывает штатно. Далее необходимо отключить интересующий нас компонент на следующие полчаса. После отключенный компонент снова вводится в эксплуатацию. Далее необходимо зафиксировать за какое время и с какими артефактами система будет восстанавливать свою первоначальную работоспособность и восстановит ли в принципе.

9. Volume Testing (Тестирование объёма)

Цель: Проверить, как система справляется с разными объемами данных.

Пример:

Загрузка большого количества данных в БД за квартал\полгода\год эксплуатации или за зафиксированное время глубины хранения данных (сколько по времени данные будут храниться в БД) и проверка, как система реагирует на подобный объём.

Выгрузка файлов разного размера (100 мб, 1 гб и тд)

Объяснение: Volume тестирование помогает убедиться, что система сохраняет свои не функциональные свойства и не превышает заявленный SLA с разным обозначенным объемом данных. Логика состоит в том, что чем больше у Вас объём данных в БД при например неверно настроенных индексах, тем медленнее БД будет производить операции внутри себя и тем самым тормозить всю систему в целом.

10. Тестирование на масштабируемость (Scalability Testing)

Цель: Оценить способность системы увеличивать производительность при увеличении ресурсов/экземпляров системы.

Пример: Добавление новых ресурсов/серверов и проверка, как это влияет на производительность системы.

Объяснение: Масштабируемость тестирования помогает понять, как система справляется с увеличением нагрузки и выявляет как ограничения в масштабировании, так и коэффициент прироста производительности при различных подходах в нём (горизонтальная (увеличение кол-ва серверов/экземпляров) либо вертикальная (добавление ресурсов в существующий контур) масштабируемость).

МНТ

МНТ – это очень важный документ, который включает в себя цели тестирования, объект тестирования, стратегию тестирования, описание тестового стенда, моделирование нагрузки, описание заглушек, эмуляторов, баз данных и средств для мониторинга. Это документ, который обязательно должен согласовываться с вышестоящим руководством. Без МНТ невозможно провести качественное нагрузочное тестирование нашего ПО.

Основные пункты, которые входят в методику нагрузочного тестирования (МНТ):

0) Аббревиатуры и сокращения

1) Цели тестирования ПО.

Цели тестирования различают на бизнес цели и технические цели.

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

получения большей прибыли от использования пользователями данной системы.

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

2) Объект тестирования - включает в себя характеристики системы, все её компоненты и взаимосвязь этих компонентов между собой.

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

4) Описание ПРОМ/ПРОД стенда - включает в себя:

архитектуру промышленного стенда (описание/схему самого стенда и описание смежных систем)

характеристики и требования к оборудованию промышленного стенда

Пример таблицы для заполнения:

5) Описание тестового стенда - включает в себя:

архитектуру тестового стенда (описание/схему самого стенда и описание смежных систем/заглушек)

характеристики и требования к оборудованию тестового стенда

Пример таблицы для заполнения:

6) Сравнение тестового и промышленного стендов. Главный критерий в данном случае - их максимальная схожесть (в идеале 1 в 1, но по практике тестовый стенд почти всегда уступает в ресурсах)

Пример таблицы для заполнения:

7) Ограничения тестирования - обозначаем риски, которые могут возникнуть при проведении тестирования, обычно учитывает сравнение стенда (см. п. №6).

Определенные риски либо принимаются как данность, либо объясняются как несущественные, например - разность в дисках у БД.

Вместо каких интеграций ставятся заглушки

В случае возникновения проблем на ПРОДе, начинается разбор причин невыявления бага/проблемы при прохождении НТ - либо мы помечаем как не относящуюся к производительности (в таком случае к НТ претензий нет), либо отсылаемся на риски в данном пункте (если проблема связана именно с ними).

8) Критерии успешности тестирования (SLA)

В данном пункте определяем критерии успешного прохождения нашего тестирования. Подробнее в пункте Аббревиатуры и определения. И в разделе “мониторинг” - Теория.

9) Профиль нагрузки

Перечисление операций и их интенсивность.

Например :

UC в данном примере сокращение от user case.

10) Моделирование нагрузки - детальное пошаговое описание операций с ожидаемым результатом.

Например рассмотрим кейс авторизации пользователя:

и тд.

11) Описание заглушек и эмуляторов - описание характеристик заглушек и эмуляторов, что они должны выполнять (Могут быть указаны в “ограничения тестирования”).

12) Базы данных - описываются характеристики БД, ее наполнение, т.е. количество данных в ней (id пользователя, его электронная почта, адрес, тел., количество совершенных операций и т.д.) перед началом тестирования.

13) Мониторинг - необходим для сбора характеристик производительности компонентов системы. В данном разделе описывается вспомогательное ПО для проведения мониторинга.

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

1) Определение максимальной производительности

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

(сбоев) при максимальной загруженности системы;

2) Выявление «узких мест» - выявление проблемных участков. Необходимо для того, чтобы разработчик исправил дефекты в системе для её правильной работоспособности;

3) Проверка стабильности (надежности) – длительная нагрузка системы при нормальных условиях (70-80% от максимума). Максимальная нагрузка указана в требованиях к программному продукту. Целью данного тестирования является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки (не зависает ли система при длительной нагрузке на нее и в целом - правильно ли работает система либо возникают какие-либо проблемы);

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

5) Re-test - проверка исправления ошибки (дефекта) после обнаружения проблемных участков в системе. Необходимо делать

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

6) Проверка отказоустойчивости - это тестирование системы, которое позволяет проверить работоспособность системы в

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

Целью тестирования является обеспечение надежности и

стабильности системы при возникновении непредвиденных ситуаций;

7) Воспроизведение проблем промышленной

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

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

определение максимальной производительности системы;

выявление проблемных участков системы ("узких мест");

проверку системы под действием стресс-нагрузки;

проверку отказоустойчивости;

2) Добавление нового функционала – проводится при добавлении нового функционала в выпущенном ПО. В данном случае нагружается новый функционал. Допустим, если в наше ПО мы добавляем такой

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

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

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

3) Плановое тестирование – тестирование, которое производится по плану. Данное тестирование необходимо проводить исходя из планового расписания, чтобы убедиться в том, что ПО работает в соответствии с заявленными требованиями через определенный промежуток времени, указанный в плановом расписании;

4) Исследовательское тестирование – тестирование, цель которого выяснить максимальные возможности ПО. В данном случае необходимо провести:

определение максимальной производительности;

проверку стабильности (надежности);

проверку системы под действием стресс-нагрузки;

5) Смена переходит с одной базы данных на другую. В данном случае необходимо нагрузить технологий – тестирование ПО, когда меняется оборудование и мощности, система систему и проанализировать её поведение, т.е. система работает в соответствии с требованиями либо возникают проблемы в её работе;

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

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

1) Определение и постановка задачи.

На данном этапе мы:

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

определяем состав группу: тестировщики, аналитики, архитекторы, projekt менеджеры;

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

2) Подготовка тестового стенда и средств тестирования:

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

установка всех необходимых программ для тестировщиков;

получение доступов к стендам для тестировщиков.

3) Подготовка тестового плана (методики НТ).

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

количество участников, частота проведения наших тестов и т.д.

4) Настройка тестового стенда и вспомогательного ПО.

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

вариативностью ответа.

(4.5. Профиль нагрузки

Перечисление операций и интенсивность.)

5) Проведение нагрузочного тестирования.

В данный этап входит:

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

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

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

получили верные данные;

тестирование стабильности (надежности);

6) Подготовка отчета и анализ результата тестирования

На данном этапе у нас происходит фиксирование таких данных, как:

процент успешных операций, так называемая доступность;

время отклика системы на нагрузку;

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

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

обязательно должен согласовываться с вышестоящим руководством. Без МНТ невозможно провести качественное нагрузочное тестирование нашего ПО.

Основные пункты, которые входят в методику нагрузочного тестирования (МНТ):

0) Аббревиатуры

1) Цели тестирования ПО.

Цели тестирования различают на бизнес цели и технические цели.

получения большей прибыли от использования пользователями данной системы.

отказоустойчивости системы; при проверке системы под действием стресс-нагрузки).

4) Описание тестового стенда - включает в себя:

архитектуру тестового стенда (описание самого стенда и описание смежных систем)

характеристики и требования к оборудованию тестового стенда

сравнение тестового и пользовательского стенда. Главный критерий в данном случае - их максимальная схожесть (в идеале 1 в 1, но по практике тестовый стенд почти всегда хуже))))

5) Моделирование нагрузки - описанием процессов и операций,

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

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

7) Базы данных - описываются характеристики БД, ее наполнение, т.е. количество данных в ней (id пользователя, его электронная почта, адрес, тел., количество совершенных операций и т.д.)

8) Мониторинг - необходим для сбора характеристик производительности компонентов системы. В данном разделе описывается вспомогательное ПО для проведения мониторинга.

ВИДЫ ТЕСТИРОВАНИЯ

1. Смоук-тестирование (Smoke Testing)

Объяснение: Смоук-тестирование помогает выявить критические ошибки на ранних этапах и убедиться, что система готова для более глубокого тестирования.

2. Поиск максимума (Finding the Maximum)

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

3. Подтверждение максимума (Confirming the Maximum)

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

Объяснение: Этот вид тестирования подтверждает, что система может стабильно работать под максимальной нагрузкой и не теряет производительность со временем.

4. Стресс-тестирование (Stress Testing)

Цель: Определить пределы системы, подвергая ее экстремальным условиям.

Пример: Увеличение числа пользователей до тех пор, пока система не начнет сбоить или отказывать.

Объяснение: Стресс-тестирование помогает понять, как система ведет себя под чрезмерной нагрузкой и выявляет точки отказа.

5. Тест надежности (Reliability Testing)

Цель: Проверить, как система работает под продолжительной нагрузкой.

Пример: Тестирование сервера под постоянной нагрузкой в течение 24 часов.

6. Негативное тестирование (Negative Testing)

Цель: Проверить, как система справляется с некорректными или неожиданными входными данными.

Пример: Ввод некорректных данных в форму регистрации и проверка, как система реагирует на это.

Объяснение: Негативное тестирование помогает выявить уязвимости и ошибки в обработке некорректных данных.

7. Регрессивное тестирование (Regression Testing) оно же re-test

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

8. Тестирование на отказоустойчивость (Failover Testing)

Цель: Проверить, как система справляется с отказами компонентов.

Пример: Отключение одного из серверов в кластере и проверка, как система перенаправляет запросы на другие серверы.

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

9. Volume Testing (Тестирование объема)

Цель: Проверить, как система справляется с большими объемами данных.

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

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

10. Тестирование на масштабируемость (Scalability Testing)

Цель: Оценить способность системы увеличивать производительность при увеличении ресурсов.

Пример: Добавление новых серверов и проверка, как это влияет на производительность системы.

Объяснение: Масштабируемость тестирования помогает понять, как система справляется с увеличением нагрузки и выявляет ограничения в масштабировании.

ТPC и RPS

TPC (Transactions Per Second) и RPS (Requests Per Second) — это метрики, используемые для оценки производительности систем. Они помогают понять, как система справляется с нагрузкой и обрабатывает запросы или транзакции. Давайте рассмотрим их определения, объяснения и отличия.

TPC — это метрика, которая измеряет количество транзакций, которые система может обработать за одну секунду.

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

RPS (Requests Per Second)

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

Запрос обычно представляет собой более простой процесс, такой как HTTP-запрос к веб-серверу. RPS используется для оценки производительности веб-серверов, API и других систем, которые обрабатывают большое количество запросов.

Отличия между TPC и RPS

Применение:

-TPC: Используется для оценки производительности систем, которые обрабатывают сложные транзакции, такие как банковские системы, системы управления заказами и т.д.

RPS: Используется для оценки производительности веб-серверов, API и других систем, которые обрабатывают большое количество запросов.

Перцентиль (например 90 и 95-ый)

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

Определение перцентилей:

· 90-й перцентиль (P90): Это значение, ниже которого находится 90% всех измерений. Например, если 90-й перцентиль времени отклика составляет 100 миллисекунд, это означает, что 90% всех запросов были выполнены быстрее 100 миллисекунд.

· 95-й перцентиль (P95): Это значение, ниже которого находится 95% всех измерений. Например, если 95-й перцентиль времени отклика составляет 150 миллисекунд, это означает, что 95% всех запросов были выполнены быстрее 150 миллисекунд.

Применение перцентилей:

· Оценка производительности: Перцентили помогают понять, как система выполняет запросы или транзакции в реальных условиях. Они показывают не только среднее время отклика, но и как система справляется с пиковыми нагрузками.

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

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

Параметризация и корреляция

Горизонтальная масштабируемость – прирост количества (чуть меньше производительность из-за распределения и выше отказоустойчивость).

Вертикальная масштабируемость – прирост производительности (больший прирост, меньше отказоустойчивость).

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

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

Некоторые параметры, которые включает в себя профиль нагрузки:

· количество виртуальных пользователей;

· количество сценариев (операций и задержек);

· интенсивность операций.

Примеры профилей нагрузки:

· Средний (обычный). Отражает ожидаемые или фактические типовые (усреднённые) условия использования.

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

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

все виды join в sql

MQ и Kafka(различия)

MQ изучить

Сборщик мусора

Черновик Владос

Инфографика pacing:

Стандартный нагрузочный тест:

Max Performance Test (Peak Load Test)

Volume Test

Stress Test

Stability (Soak) Test