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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

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

Некоторые принципы[править | править код]

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

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

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

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

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

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

Инструментарий[править | править код]

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

ПО Наименование производителя Комментарии
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 — это утилита для нагрузочного тестирования веб-серверов.[3]
Visual Studio Team System Microsoft Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing
QTest Quotium
HTTPerf
QALoad Compuware Ltd.
(The) Grinder
WebLOAD RadView Software Нагрузочное тестирование инструмент для веб-и мобильных приложений, включая веб-панели для тестирования производительности анализа. Используется для крупномасштабных нагрузок, которые могут быть сгенерированы также из облака. лицензированный.[4]

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

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

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

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

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

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

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

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

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

Примечания[править | править код]

  1. Molyneaux, I. The Art of Application Performance Testing: Help for Programmers and Quality Assurance. — O'Reilly Media, 2009. — P. 130. — 158 p. — ISBN 9780596555436.
  2. Sosinsky, B. Cloud Computing Bible. — Wiley, 2010. — P. 121. — ISBN 9781118023990.
  3. Домашняя страница Siege
  4. «WebLOAD Review-Getting Started with WebLOAD Load Testing Tool»

Литература[править | править код]

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