Редактирование: Нагрузочное тестирование

'''Нагрузочное тестирование''' ({{lang-en|load testing}}) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

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

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

Основная цель нагрузочного тестирования заключается в том, чтобы, создав определённую ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) и, обычно, использовав идентичное программное и аппаратное обеспечение, наблюдать за показателями производительности системы.
{| class="standard" style="background:#f0f0f0"
 |'''Пример 1:'''
''Веб-сервис с функциональностью корзины покупателя рассчитан на 100 одновременно работающих пользователей, которые следуют некоторому определённому сценарию (заданные действия в указанных пропорциях):''
* ''25 пользователей просматривают товар и выходят из системы.''
* ''25 пользователей добавляют товар в корзину, оформляют его и выходят из системы.''
* ''25 пользователей используют функцию возврата товара и выходят из системы.''
* ''25 пользователей входят в систему и не проявляют никакой активности.''
''В данном случае нагрузочное тестирование должно эмулировать вышеописанный типичный сценарий работы с веб-сервисом с целью удостовериться, что система готова к выходу в эксплуатацию. При этом для анализа могут сниматься показатели производительности системы в целом или каждого узла системы в частности.''
 |}
В идеальном случае в качестве критериев успешности нагрузочного тестирования выступают требования к производительности системы, которые формулируются и документируются на стадии разработки функциональных требований к системе до начала программирования основных архитектурных решений. Однако часто бывает так, что такие требования не были четко сформулированы или не были сформулированы вовсе. В этом случае первое нагрузочное тестирование будет являться ''пробным'' ({{lang-en|exploratory load testing}}) и основываться на разумных предположениях об ожидаемой нагрузке и потреблении аппаратной части ресурсов.

Одним из оптимальных подходов в использовании нагрузочного тестирования для измерений производительности системы является тестирование на стадии ранней разработки. Нагрузочное тестирование на первых стадиях готовности архитектурного решения с целью определить его состоятельность называется 'proof-of-concept' тестированием.

=== Основные принципы нагрузочного тестирования ===
Ниже рассмотрены некоторые экспериментальные факты, обобщённые принципы, используемые при тестировании производительности в целом и применимые к любому типу тестирования производительности (в частности и к нагрузочному тестированию).

: '''1. Уникальность запросов'''

''Даже сформировав реалистичный сценарий работы с системой на основе статистики её использования, необходимо понимать, что всегда найдутся исключения из этого сценария.''
[[Файл:Distribution load testing.png|thumb|180px|Иллюстрация различной дисперсии распределений для времени выполнения запросов X и Y.]]
В случае ''Примера 1'' это может быть пользователь, обращающийся к отличным от всех остальных, уникальным страницам веб-сервиса.

: '''2. Время отклика системы'''

''В общем случае время отклика системы подчиняется [[Нормальное распределение|функции нормального распределения]].''

В частности, это означает, что, имея достаточное количество измерений, можно определить вероятность с которой отклик системы на запрос попадёт в тот или иной интервал времени.

: '''3. Зависимость времени отклика системы от степени распределённости этой системы.'''

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

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

: '''4. Разброс времени отклика системы'''

''Из утверждений 1, 2 и 3 можно также заключить, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся запросы, время обработки которых превышает определённые в требованиях максимумы; причем, чем больше суммарное время проведения эксперимента тем выше окажутся новые максимумы.''

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

: '''5. Точность воспроизведения профилей нагрузки'''

''Необходимая точность воспроизведения профилей нагрузки тем дороже, чем больше компонент содержит система.''

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

=== Инструментарий для тестирования производительности ===
Следует отметить, что для большинства видов тестирования производительности используется один и тот же инструментарий, умеющий выполнять типовые задачи.

Существует распространённое ошибочное понимание{{Нет АИ|16|11|2013}} того, что инструменты для нагрузочного тестирования системы — это инструменты такие же по принципу записи и воспроизведения как и инструменты для автоматизации [[Регрессионное тестирование|регрессионного тестирования]]. Инструменты для нагрузочного тестирования работают на уровне протокола, тогда как инструменты для автоматизации регрессионного тестирования работают на уровне объектов графического пользовательского интерфейса.

{| class="standard" style="background:#f0f0f0"
 |'''Пример 2:'''
''Имеется стандартный интернет-браузер, выполняющий функцию перехода по указанной ссылке при нажатии кнопки. ''

''В данном случае для автоматизации регрессионного тестирования необходимо написать скрипт, передающий браузеру клик мышью и нажатие кнопки, в то время как для создания скрипта для нагрузочного тестирования необходимо написать передачу гиперссылки от браузера для нескольких пользователей, включая уникальные для каждого из них имя пользователя и пароль.''
|}

Существуют различные инструменты для обнаружения и исследования проблем в различных узлах системы. Все узлы системы могут быть классифицированы следующим образом:
* Приложение,
* База данных,
* Сеть,
* Обработка на клиентской стороне,
* Балансировка нагрузки.

Также следует отметить появление сетевых [[B2B|Business-to-business]] (B2B) приложений, использующих [[соглашение об уровне услуг]] (или SLA, Service Level Agreement). Нарастающая популярность B2B-приложений привела к тому, что всё больше приложений переходят на [[сервис-ориентированная архитектура|сервис-ориентированную архитектуру]], в случае которой обмен информацией происходит без участия веб-браузеров. Примером такого взаимодействия может служить бюро туристических услуг, запрашивающее информацию об определённом авиарейсе между Санкт-Петербургом и Омском, в то время как авиакомпания обязана предоставить ответ в течение 5 секунд. Часто нарушение договора об SLA грозит крупным штрафом.

Некоторые инструменты для нагрузочного тестирования представлены ниже<ref>{{книга
 | автор         = Molyneaux, I.
 | заглавие      = The Art of Application Performance Testing: Help for Programmers and Quality Assurance
 | издательство  = O'Reilly Media
 | год           = 2009
 | allpages      = 158
 | pages = 130
 | isbn          = 9780596555436
 | ref           = Molyneaux
}}</ref><ref>{{книга
 | автор         = Sosinsky, B.
 | заглавие      = Cloud Computing Bible
 | издательство  = Wiley
 | год           = 2010
 | allpages      = 
 | pages = 121
 | isbn          = 9781118023990
 | ref           = Sosinsky, B.
}}</ref>:

{| class="wikitable"
|-
! ПО
! Наименование производителя
! Комментарии
|-
|OpenSTA
|'Open System Testing Architecture'
|Свободно распространяемое программное обеспечение для нагрузочного/стресс тестирования, лицензированное GNU GPL. Использует распределённую архитектуру приложений, основанную на [[CORBA]]. Доступна версия под Windows, хотя имеются проблемы с совместимостью с Windows Vista. Поддержка прекращена в 2007 году.
|-
|IBM Rational Performance Tester
|IBM
|Основанное на среде разработки [[Eclipse (среда разработки)|Eclipse]] ПО, позволяющее создавать нагрузку больших объёмов и измерять время отклика для приложений с клиент-серверной архитектурой. Требует лицензирования.
|-
|[[JMeter]]
|Открытый проект Apache Jakarta Project
|Основанный на Java кроссплатформенный инструментарий, позволяющий производить нагрузочные тесты с использованием JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP соединений. Даёт возможность создавать большое количество запросов с разных компьютеров и контролировать процесс с одного из них.
|-
|[[HP LoadRunner]]
|HP
|Инструмент для нагрузочного тестирования, изначально разработанный для эмуляции работы большого количества параллельно работающих пользователей. Также может быть использован для [[Модульное тестирование|unit-]] или [[Интеграционное тестирование|интеграционного тестирования]].
|-
|[https://smartbear.com/product/loadcomplete/overview/ LoadComplete]
|SmartBear
|Проприетарный продукт, позволяющий проводить нагрузочное тестирование веб-приложений
|-
|[[SilkPerformer]]
|Micro Focus (Borland)
|-
|Siege
| Joe Dog Software
|Siege — это утилита для нагрузочного тестирования веб-серверов.<ref>[http://www.joedog.org/siege-home/ Домашняя страница Siege]</ref>
|-
|[[Microsoft Visual Studio|Visual Studio]] Team System
|[[Microsoft]]
|Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing
|-
|QTest
| Quotium
|
|-
|HTTPerf
| 
|
|-
|QALoad
| Compuware Ltd.
|-
|(The) Grinder
| 
|
|-
|WebLOAD
|RadView Software
|Нагрузочное тестирование инструмент для веб-и мобильных приложений, включая веб-панели для тестирования производительности анализа. Используется для крупномасштабных нагрузок, которые могут быть сгенерированы также из облака. лицензированный.<ref>[http://www.softwaretestinghelp.com/webload-load-testing-tool-review "WebLOAD Review-Getting Started with WebLOAD Load Testing Tool"]</ref>
|-
|[[Яндекс.Танк]]
|Яндекс
|Модульный и расширяемый инструмент, позволяющий использовать внутри разные генераторы, в частности, знакомый многим JMeter. Это open-source проект, опубликованный Яндексом в 2012 году.
|}

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

: '''1. Потребление ресурсов центрального процессора, %'''

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

: '''2. Потребление оперативной памяти, Мб'''

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

* [[Виртуальная память|Virtual]] — объём виртуального адресного пространства, которое использует процесс. Этот объём подразумевает, как использование соответствующего дискового пространства так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти принадлежащей другому процессу.
* Private — объём адресного пространства, занятого процессом и не разделяемого с другими процессами.
* [[Working Set]] — набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остаётся мало, использованные страницы перемещаются из ОЗУ на жёсткий диск (или другой накопитель, такой как [[Флеш-память]]), освобождая ОЗУ для загрузки других активных страниц памяти.
* [[Разделяемая память|Shared]] — объём используемой процессом физической памяти, которая может использоваться совместно с другими процессами. Хотя память выделенная процессу должна быть изолированной, процессам, иногда, необходимо иметь возможность обмениваться информацией. Общая память является самым быстрым способом [[Межпроцессное взаимодействие|межпроцессного взаимодействия]].

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

: '''3. Потребление сетевых ресурсов'''

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

 {| class="standard" style="background:#f0f0f0"
 |'''Пример 3:'''
''Серверное приложение обрабатывая запрос пользователя, возвращает ему видео-поток, используя сетевой канал в 2 мегабит. Требование гласит, что сервер должен обрабатывать 5 запросов пользователей одновременно.''

''Нагрузочное тестирование показало, что эффективно сервер может предоставлять данные только 4 пользователям одновременно, так как мультимедиа-поток имеет [[битрейт]] в 500 килобит. Очевидно, что предоставление этого потока 5 пользователям одновременно невозможно в силу превышения пропускной способности сетевого канала, а значит, система не удовлетворяет заданным требованиям производительности, хотя при этом потребление ей ресурсов процессора и памяти может быть невысоким.''
|}

: '''4. Работа с дисковой подсистемой (время ожидания ввода-вывода, {{lang-en|I/O wait}})'''

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

: '''5. Время выполнения запроса, мс'''

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

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

== См. также ==
* [[Тестирование производительности]]
* [[Инженерия производительности]]
* [[Стресс-тестирование]]
* [[Тестирование программного обеспечения]]

== Примечания ==
{{примечания}}

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

== Ссылки ==
* [http://software-testing.ru/ Портал специалистов по тестированию и обеспечению качества ПО]{{ref-ru}} — проект посвящён вопросам тестирования и повышения качества программного обеспечения.
* [http://automated-testing.info Автоматизация нагрузочного тестирования]{{ref-ru}}

{{rq|sources|refless}}

[[Категория:Тестирование программного обеспечения]]