Нагрузочное тестирование (Ugijr[kcuky myvmnjkfguny)

Нагрузочное тестирование (англ. load testing) — процесс систематического анализа и проверки программного продукта на соответствие нефункциональным требованиям путём подачи предопределенной нагрузки с использованием инструментов нагрузочного тестирования.

Предопределенная нагрузка - нагрузка, подаваемая в % соотношении от профиля нагрузочного тестирования.

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

Наиболее яркими примерами инструментов нагрузочного тестирования являются: Apache Jmeter, Loadrunner, Gatling, K6.

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

Производительность - это мера того, насколько эффективно и хорошо система выполняет задачи, для которых она предназначена.

В рамках проверки производительности нагрузочное тестирование позволяет решить следующие задачи:

1. найти максимальную производительность системы (maxperf, выше которой система перестает отвечать нефункциональным требованиям);
2. найти пиковую производительность системы (peakperf, выше которой система перестает отвечать функциональным требованиям);
3. определить пропускную способность системы;
4. найти узкие места в системе;
5. моделирование производительности;
6. прогнозирование производительности;
7. определить время отклика;
8. определить объем утилизации памяти (memory leak).

Некоторые принципы

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

Иллюстрация различной дисперсии распределений для времени выполнения запросов X и Y.

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

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

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

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

Инструментарий

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

ПО	Наименование производителя	Комментарии
OpenSTA	'Open System Testing Architecture'	Свободно распространяемое программное обеспечение для нагрузочного/стресс тестирования, лицензированное GNU GPL. Использует распределённую архитектуру приложений, основанную на CORBA. Доступна версия под Windows, хотя имеются проблемы с совместимостью с Windows Vista. Поддержка прекращена в 2007 году.
IBM Rational Performance Tester	IBM	Основанное на среде разработки Eclipse ПО, позволяющее создавать нагрузку больших объёмов и измерять время отклика для приложений с клиент-серверной архитектурой. Требует лицензирования.
JMeter	Открытый проект Apache Jakarta Project	Основанный на Java кроссплатформенный инструментарий, позволяющий производить нагрузочные тесты с использованием JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP соединений. Даёт возможность создавать большое количество запросов с разных компьютеров и контролировать процесс с одного из них.
HP LoadRunner	HP	Инструмент для нагрузочного тестирования, изначально разработанный для эмуляции работы большого количества параллельно работающих пользователей. Также может быть использован для unit- или интеграционного тестирования.
LoadComplete	SmartBear	Проприетарный продукт, позволяющий проводить нагрузочное тестирование веб-приложений
SilkPerformer	Micro Focus (Borland)
Siege	Joe Dog Software	Siege — это утилита для нагрузочного тестирования веб-серверов.
Visual Studio Team System	Microsoft	Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing
QTest	Quotium
HTTPerf
QALoad	Compuware Ltd.
(The) Grinder
WebLOAD	RadView Software	Нагрузочное тестирование инструмент для веб-и мобильных приложений, включая веб-панели для тестирования производительности анализа. Используется для крупномасштабных нагрузок, которые могут быть сгенерированы также из облака. лицензированный.

Показатели производительности

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

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

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

• виртуальная память — объём виртуального адресного пространства, которое использует процесс. Этот объём подразумевает, как использование соответствующего дискового пространства так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти принадлежащей другому процессу;
• приватная память — объём адресного пространства, занятого процессом и не разделяемого с другими процессами;
• рабочее множество — набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остаётся мало, использованные страницы перемещаются из оперативной памяти на накопитель;
• разделяемая память — объём используемой процессом физической памяти, которая может использоваться совместно с другими процессами. Хотя память выделенная процессу должна быть изолированной, процессам, иногда, необходимо иметь возможность обмениваться информацией. Общая память является самым быстрым способом межпроцессного взаимодействия.

При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым сборщиком мусора. Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java — так называемый «постоянный Full GC») или когда процессу выделены большие объёмы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.

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

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

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

Литература

• Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М.: «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series). — 1000 экз. — ISBN 978-5-8459-1625-9.