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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым сборщиком мусора. Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в 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.

У этой статьи есть несколько проблем, помогите их исправить: В статье не хватает ссылок на источники (см. рекомендации по поиску). Информация должна быть проверяема, иначе она может быть удалена. Вы можете отредактировать статью, добавив ссылки на авторитетные источники в виде сносок. (12 сентября 2012) В статье есть список источников, но не хватает сносок. Без сносок сложно определить, из какого источника взято каждое отдельное утверждение. Вы можете улучшить статью, проставив сноски на источники, подтверждающие информацию. Сведения без сносок могут быть удалены. (12 сентября 2012) Пожалуйста, после исправления проблемы исключите её из списка параметров. После устранения всех недостатков этот шаблон может быть удалён любым участником.