Серверное приложение обрабатывает запрос пользователя и отправляет ему видеопоток через 2-мегабитное сетевое соединение. Требование заключается в том, что сервер должен обрабатывать 5 пользовательских запросов одновременно.
Нагрузочное тестирование
Нагрузочное тестирование — определение или регистрация производительности и времени отклика системы или аппаратно-программного устройства в ответ на внешние запросы для определения соответствия требованиям к системе (устройству).
Стресс-тестирование используется для изучения времени отклика системы при высоких или пиковых нагрузках, когда нагрузка, оказываемая на систему, превышает обычные сценарии использования. Четкой границы между нагрузочным и стресс-тестированием не существует, но эти понятия не следует путать, поскольку эти типы тестов отвечают на разные бизнес-вопросы и используют разные методологии.
Содержание
Термин нагрузочный тест может использоваться в различных значениях в профессиональной среде тестирования программного обеспечения. В целом, это означает имитацию ожидаемого использования приложения путем одновременного моделирования нескольких пользователей. Поэтому данный тест лучше всего подходит для многопользовательских систем, которые обычно используют архитектуру клиент-сервер (например, веб-серверы). Но и другие типы программных систем также могут быть протестированы таким образом. Например, текстовый или графический редактор может прочитать очень большой документ; финансовый пакет может создать отчет на основе данных за несколько лет. Наилучшим образом разработанное нагрузочное испытание даст наиболее точные результаты.
Основной целью нагрузочного тестирования является наблюдение за производительностью системы путем создания определенной ожидаемой нагрузки на систему (например, виртуальными пользователями) и обычно с использованием идентичного программного и аппаратного обеспечения.
Веб-сервис с функцией корзины предназначен для 100 одновременных пользователей, следующих определенному сценарию (определенные действия в определенных пропорциях):
- 25 пользователей просматривают товар и выходят из системы.
- 25 пользователей добавляют товар в корзину, оформляют его и выходят из системы.
- 25 пользователей используют функцию возврата товара и выходят из системы.
- 25 пользователей входят в систему и не проявляют никакой активности.
В этом случае нагрузочный тест должен имитировать типичный сценарий веб-сервиса, описанный выше, чтобы убедиться, что система готова к запуску. Для анализа может использоваться производительность системы в целом или каждого узла системы в частности.
В идеале критерием успешного нагрузочного тестирования должны быть требования к производительности системы, которые формулируются и документируются во время разработки функциональных требований к системе до планирования основных архитектурных решений. Однако часто эти требования сформулированы нечетко или вообще не сформулированы. В этом случае первоначальный нагрузочный тест должен быть исследовательским («исследовательский нагрузочный тест») и основан на разумных предположениях
Ниже приведены некоторые экспериментальные данные, обобщающие принципы, применяемые к тестам производительности в целом и применимые к любому типу тестов производительности (особенно к стресс-тестам).
Основные принципы нагрузочного тестирования
1. уникальность вопросов
Даже если мы создали реалистичный сценарий использования системы, основанный на статистике использования, мы должны признать, что всегда будут исключения из этого сценария.
Тестирование производительности используется для определения максимальной скорости транзакций, при которой система будет соответствовать требованиям по времени отклика. Тестирование производительности рекомендуется при внедрении новой версии программного обеспечения.
См. также
- Площадка услуг по тестированию сайтов и программного обеспечения (рус.)
- Портал специалистов по тестированию и обеспечению качества ПО (рус.) — Проект посвящён вопросам тестирования и повышения качества программного обеспечения.
- База знаний тестировщика (рус.) — Багтрекеры, автоматизированное тестирование, нагрузочное тестирование, юзабилити тестирование, сообщества, печатные издания, книги
- Автоматизация нагрузочного тестирования (рус.)
- Заметки по нагрузочному тестированию (рус.)
- Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М .: «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series). — 1000 экз. — ISBN 978-5-8459-1625-9
- Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.
- Проставив сноски, внести более точные указания на источники.
Тестирование производительности
⦁ Выявление и предотвращение сбоев системы до ее внедрения в производство. ⦁ Определите максимальное количество одновременно работающих пользователей в системе. ⦁ Определите максимальное количество одновременных операций без потери качества обслуживания.
Ключевые преимущества
В рамках тестирования производительности собирается статистика использования системы, на основе которой создается профиль нагрузки. Затем рассчитывается начальная точка и размер шага для увеличения интенсивности работы.
Основные задачи
Во время испытания определяется максимальная мощность системы:
⦁ наибольшая интенсивность оперативного выполнения с требуемым качеством обслуживания (SLA); ⦁ максимальная производительность системы, при которой наблюдается ухудшение показателей качества оперативного обслуживания (время выполнения, отказы).
Этот вид тестирования позволяет контролировать использование системных ресурсов при увеличении объема данных и принимать упреждающие меры для предотвращения сбоев системы в будущем. Объемные испытания подходят не только для систем, которые будут использоваться на пилотной установке, но и на этапе проектирования.
Объемное тестирование
⦁ Определите глубину хранения, при которой производительность системы не снижается. ⦁ Выберите оптимальный набор оборудования. ⦁ Определите наилучшее архитектурное решение для проектируемой системы.
Ключевые преимущества
Объемное тестирование позволяет:
Основная цель объемных тестов — оценить производительность системы при увеличении потока данных. Тесты имитируют увеличение объема транзакций системы при увеличении объема базы данных. Во время процедуры тестирования измеряется общая производительность системы: количество операций за определенный период времени, время отклика системы и количество пользователей, работающих с системой одновременно.
Основные задачи
⦁ Как можно увеличить количество пользователей системы? ⦁ Как увеличится объем операций? ⦁ Насколько большой будет база данных, например, через 5 лет?
Объемное тестирование рекомендуется основывать на следующих бизнес-прогнозах:
Испытания на стабильность предназначены для оценки способности системы работать под нагрузкой в течение длительного периода времени. Этот тип тестирования позволяет обнаружить утечки памяти или неправильную конфигурацию программного обеспечения. Этот вид работ выполняется как для новых систем, так и для новых версий уже работающих систем
Тестирование стабильности
Во время испытания на стабильность целевая система подвергается средней нагрузке в 70-80 % от максимального значения в течение не менее 24 часов. Следующие показатели измеряются одновременно с нагрузкой: ⦁ время выполнения функций; ⦁ распределение ресурсов системы; ⦁ другие метрики, учитывающие специфику системы.
Ключевые преимущества
Тестирование может выявить множество ошибок, которые трудно обнаружить в обычных условиях, например, утечки памяти, неправильную конфигурацию серверной среды, недостающие аппаратные или системные ресурсы.
Основные задачи
Но так ли важны и необходимы нагрузочные тесты, как, например, тестирование основных функций продукта? Потому что на первый взгляд это явно акт доброй воли: продукт работает, мы удовлетворены качеством его ключевых показателей, и все хорошо. Но у нас все еще есть время и ресурсы для большего тестирования, поэтому мы должны сделать больше работы и провести больше тестов под нагрузкой!
Здесь лучше всего ответить на вопрос как можно более честно: «Что произойдет, если мы не проведем нагрузочное тестирование, и конечный пользователь пострадает от последствий этого решения?». Особенность нагрузочного тестирования заключается в том, что результат резко возрастает, когда пользователь достигает этих крайних значений, которые мы можем определить, расширить или ограничить заранее. Если в какой-то момент наш продукт просто перестанет работать (заглохнет двигатель автомобиля или отвалятся все колеса), мы окажемся вне опасности. Но что произойдет, если обработанные данные будут повреждены (просто отвалится одна шина, машина врежется в столб и водитель погибнет)? Прежде всего, мы должны думать о безопасности людей и их данных. Это может привести к огромным репутационным и финансовым потерям, что в долгосрочной перспективе может привести даже к закрытию компании.
Роль нагрузочного тестирования в жизни продукта
Нагрузочное тестирование может быть не столь важным для продуктов, предназначенных для малого бизнеса или небольших объемов данных. Но когда компания выходит на корпоративный рынок, где стоимость продукта может составлять десятки миллионов долларов, а финансовые риски — сотни миллионов долларов, лучше освоить эту область знаний.
Однако любой опытный испытатель скажет вам (и он абсолютно прав), что так называемый краш-тест должен проводиться в любом случае. Просто чтобы вы знали, что происходит при пиковой нагрузке, чтобы вы могли спать спокойнее. С другой стороны, одно дело, если он срабатывает, грубо говоря, раз в пять лет, и вы можете пережить неприятный момент, просто держа резервный. Волна прошла, недовольные роптали, ситуация стабилизировалась, и вы можете двигаться дальше. С другой стороны, представьте, что онлайн-игра, которую вы ждали годами, выходит в этот момент. Вы купили игру, скачали ее заранее, выгнали всех из дома, чтобы никто не мешал вам наслаждаться моментом, и вдруг вы видите, что вы 100500-й в очереди на вход на сервер, и, к сожалению, вам придется ждать несколько часов. Могли ли разработчики предвидеть наплыв игроков на старте? Конечно, они могли. Справились ли они с этой ситуацией? И да, и нет. С одной стороны, серверы все еще работают и выполняют свою основную функцию. С другой стороны, игрокам приходится ждать в очереди. Это, в свою очередь, не только заставляет серверы работать, но и мешает многим людям наслаждаться игрой. Это было сознательное решение или просто так получилось? Это был совершенно продуманный и осознанный шаг. Триггерный момент — это классическая пиковая нагрузка. Чтобы сбалансировать это, нужно купить много оборудования. Но что происходит с ним после пика рецессии? Как вы можете компенсировать эти затраты? Это неочевидные вопросы, к которым может привести что-то вроде теста на выносливость.
Классический жизненный цикл продукта выглядит следующим образом: Требования должны быть собраны и формализованы в виде спецификаций требований, на основе которых разработчики пишут код, а служба обеспечения качества проверяет результат их деятельности. Затем выносится суждение об уровне качества конечного продукта. Сразу становится ясно, что у нас есть время для тестирования продукта под нагрузкой только в конце, потому что зачем нам тестировать нестабильный продукт под нагрузкой, если его поведение может измениться в любой момент?
Все это звучит очень логично, за исключением одного важного «но»: в современном мире любое программное обеспечение представляет собой сложную многокомпонентную систему, состоящую из различных модулей, функций и сервисов. Если мы добавим в эту систему что-то новое, это может повлиять на общую архитектуру таким образом, что весь продукт перестанет работать под нагрузкой. Поэтому новые функции должны быть протестированы заранее и отдельно. Как только выходит более или менее стабильная версия, она уже тогда должна подвергаться нагрузочному тестированию. Ведь если архитектурная проблема обнаруживается только в конце, вам придется потратить гораздо больше усилий и ресурсов на ее устранение и повторное тестирование, чем если бы вы заметили ее в самом начале.
В какой момент подключается команда нагрузочного тестирования?
Тем не менее, перед выпуском еще предстоит провести множество системных и регрессионных испытаний. Если вы начнете тестировать каждый ингредиент по отдельности, то в итоге вам придется тестировать весь продукт в целом. Обычно это довольно сложная и утомительная задача, поскольку это не то же самое, что тестирование всех компонентов одновременно.
Результатом работы «классического» тестера часто является список проблем, обнаруженных в продукте, и предложения по его улучшению. А что остается после нагрузочного теста, кроме красивых графиков, из которых можно сделать осмысленные выводы? Они тоже являются ошибками, но их невозможно обнаружить с помощью других методов тестирования и метрик времени и нагрузки. Например: слишком большое открытие интерфейса с большим количеством объектов, внезапное увеличение нагрузки на процессор при определенных условиях, утечка памяти при длительном выполнении и т.д.
Кроме того, как уже упоминалось в начале, только после нагрузочных испытаний можно определить пределы, при которых изделие было проверено на работоспособность. Пробовали ли вы создать резервную копию 10 000 компьютеров одновременно? Хорошо, вы можете написать это в документации. Обработка миллиона объектов инфраструктуры — еще один тик. Работа с тысячей серверов одновременно — создание лучших практик репликации для клиента. Или вы считаете, что последние написаны на основе догадок? Нет, все является результатом тестирования с тщательным анализом результатов.
Пишут ли нагрузочники баги?
Существует множество инструментов для такого рода тестирования. Каждый из них тестирует что-то свое: базы данных, ресурсы, сеть на пропускную способность и т.д. В основном мы тестируем две вещи — сервисы и визуальную часть (назовем это тестированием производительности на основе браузера). Что же нам нужно для решения этой задачи?
Jmeter .
Инструменты для нагрузочного тестирования
Прежде всего, нам понадобится Jmeter — он очень популярен и использует как Java, так и Groovy. Этот инструмент очень прост, потому что он визуальный. Вы открываете проект и указываете в поле блока, как вы хотите, чтобы ваше приложение работало и что вы хотите делать. Затем вы вводите URL и данные, которые хотите отправить, проверяете и извлекаете данные из ответа микросервиса.
Сервисные инструменты
Здесь не требуется больших навыков программирования — вы можете сами создавать простые скрипты. Jmeter имеет множество библиотек и плагинов и может тестировать что угодно:
В нашей группе мы написали 5-10 сценариев с Jmeter, а затем перешли на Gatling.
Гатлинг
- визуальную часть;
- бэкенд;
- базы данных;
- MQTT.
Gatling основан на Scala, языке сценариев. Gatling — это язык сценариев, поэтому здесь вам придется писать код. Этот инструмент оказался лучшим для нашей команды, потому что у нас много скриптов, и важно поддерживать их для устранения проблем.
Например, была изменена логика получения разрешений в проекте. Если бы было 50 скриптов, нам пришлось бы протестировать их все с помощью Jmeter для обработки URL. С помощью Gatling Scripting достаточно написать функцию для входа в систему и получения авторизации, а также изменить URL в этом методе, чтобы остальные тесты работали правильно. Очень заманчивая альтернатива.
Кузнечик
Также существует Locust, который является довольно популярным инструментом для создания сценариев на основе Python, который, по сути, выполняет те же функции.
Инструмент также имеет базу знаний для анализа. Это означает, что отчет сразу показывает, где возникла проблема, и предлагает решения.
Например, в одном проекте у нас была таблица стилей CSS, которая была очень большой. Инструмент заставил нас разделить его на 3-5 частей. Таким образом, он загружается параллельно, что экономит время. Или, скажем, изображение весом 2 МБ в пикселях. Утилита предложила уменьшить размер файла для повышения производительности браузера. Сам отчет может быть передан разработчикам, чтобы они решили, что нужно исправить в первую очередь.
Браузерные инструменты
Я делю знания на две категории: Общие знания и знание проектов:
- когда появляется первый контент;
- когда можно кликнуть на элементы странички;
- когда страница полностью готова к работе с пользователем;
- сколько страница загружалась и т.д.
Во-первых, есть классы. Но курсы часто содержат много теории и мало практики. Вы узнаете, что такое тестирование и какие существуют его этапы, а также познакомитесь с основными инструментами. Это позволит вам делать простые запросы к серверу и получать конкретные результаты.
Еще одним источником общих знаний является лаборатория. Здесь все наоборот: мало теории и много практики. Вас учат, как правильно писать тесты, вы узнаете о новых инструментах и пробуете с ними работать, вы получаете тестовую среду для проведения тестов, изучения отчетов или даже пытаетесь настроить сервер, чтобы посмотреть, как он работает в реальной жизни.
И, конечно, литература. Самые важные книги — это почти художественные повествования о пути тестировщика к нагрузочному тестированию. Они описывают проблемы тестирования, рассказывают, что делать и почему, а также описывают правильный выбор сценария. Такая литература читается быстро.
Существуют также целые руководства по нагрузочному тестированию. Они шаг за шагом описывают, что должен делать эксперт: от беседы с клиентом о потребностях приложения до демонстрации отчета и объяснения его положительных и отрицательных сторон. За всеми шагами следуют вопросы для клиента, разработчиков и devops.
Эти знания можно почерпнуть из проектной документации. Это полутехническая и полуобщая информация о том, как работает функциональность приложения, сколько инструментов в проекте, какие технологии используются, как взаимодействуют микросервисы, данные блок-схемы и т.д.
Где можно получить больше знаний о нагрузочном тестировании
Этими же знаниями можно поделиться с людьми, участвующими в проекте. В первую очередь это клиент или бизнес-аналитик, иногда аудитор. Они могут рассказать вам, как работает приложение, каковы его основные и дополнительные функции и почему этот проект необходим. Команда разработчиков предоставит много знаний. Разработчик подробно объяснит, как работает что-то конкретное.
- Общие — это инструменты, языки, гайдлайны, теория тестирования.
- Проектные — это знания и навыки, которые можно получить при работе с конкретным приложением. То есть разобраться, какой у него функционал и как он работает.
Общие знания
Например, если вы попросите бизнес-аналитика отправить письмо о регистрации на сайте, он ответит примерно так: «Мы заходим в приложение, открывается форма, мы заполняем ее, нажимаем «отправить» — и приходит письмо со словами: «Поздравляем, вы зарегистрировались на сайте».
Если вы обратитесь с таким вопросом к разработчику, ответ будет более подробным и техническим: Запрос поступает в микросервис и сохраняется в базе данных, данные генерируются и затем отправляются на почтовый сервер, который берет шаблон письма и форматирует его с указанным изображением и текстом, отправляет его в Gmail, где проводится анализ и проверка на наличие зараженных файлов, после проверки письмо сохраняется — и во «входящих» появляется сигнал +1.
Мой совет вам как тестировщику — найти баланс между поиском информации о проекте у бизнес-аналитика и разработчика.
Надеюсь, эта статья помогла вам понять основы нагрузочного тестирования. Это действительно очень интересный вид работы. Лично я чувствую себя детективом в расследовании, когда ищу проблемы с производительностью службы или запроса. И когда я нахожу причину проблемы, предлагаю решение и в итоге все работает как надо, этот процесс приносит мне огромное удовлетворение. Так что желаю, чтобы у вас был такой же опыт сдачи экзаменов.
Проектные знания
Если вы обнаружили ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter .
Спойлер: Нагрузочное тестирование и техническое тестирование сайта помогли нам понять, как оптимизировать код, чтобы ресурс мог обслуживать до 60 тысяч посетителей в день, а клиенту не пришлось тратить деньги на разработку нового интернет-магазина.
Нагрузочное тестирование — это процесс оценки производительности и времени отклика веб-сайта при различных условиях нагрузки. Тест имитирует увеличение числа посетителей сайта, чтобы оценить, насколько хорошо ресурс справляется с нагрузкой и как он обрабатывает запросы посетителей.
Тесты на устойчивость к нагрузке необходимы для того, чтобы убедиться, что сервер не «упадет» при запуске сайта или увеличении числа посетителей. Эта процедура не гарантирует безошибочной работы под нагрузкой, но помогает понять фактическую мощность участка.
Цель стресс-теста — не просто «загрузить» сайт, а понять, как он работает под нагрузкой, определить запас прочности сервера и выявить слабые места в его работе. Своевременно проведя тестирование, вы сможете подготовить сайт к будущим нагрузкам — технически переработать функции и оптимизировать серверы.
Вместо вывода
Нагрузочные тесты — рутинный процесс, но они особенно важны перед масштабными маркетинговыми кампаниями — например, перед сезоном рождественских покупок, когда ожидается наплыв пользователей. Если ваш интернет-магазин не функционирует должным образом и не отвечает на запросы пользователей, его репутация у посетителей и поисковых систем пострадает.
Стоит проводить нагрузочные тесты в различных сценариях — как при запуске новых проектов, так и при изменении функциональности старого сайта.
Как провести нагрузочное тестирование интернет-магазина на Битрикс
