Лекция
Привет, Вы узнаете о том , что такое нагрузочное тестирование или тестирование производительности, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое нагрузочное тестирование или тестирование производительности , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Нагрузочное тестирование или тестирование производительности - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.
Рассмотрим основные виды нагрузочного тестирования, также задачи стоящие перед ними.
Тестирование производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Объемное тестирование (Volume Testing)
Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:
Тестирование стабильности или надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.
Ниже рассмотрены некоторые экспериментальные факты, обобщенные принципы, используемые при тестировании производительности в целом и применимые к любому типу тестирования производительности (в частности и к нагрузочному тестированию).
1. Уникальность запросов
Даже сформировав реалистичный сценарий работы с системой на основе статистики ее использования, необходимо понимать, что всегда найдутся исключения из этого сценария.
Иллюстрация различной дисперсии распределений для времени выполнения запросов X и Y.
В случае Примера 1 это может быть пользователь, обращающийся к отличным от всех остальных, уникальным страницам веб-сервиса.
2. Время отклика системы
В общем случае время отклика системы подчиняется функции нормального распределения.
В частности, это означает, что, имея достаточное количество измерений, можно определить вероятность с которой отклик системы на запрос попадет в тот или иной интервал времени.
3. Зависимость времени отклика системы от степени распределенности этой системы.
Дисперсия нормального распределения времени отклика системы на запрос пропорциональна отношению количества узлов системы, параллельно обрабатывающих такие запросы и количеству запросов, приходящихся на каждый узел.
То есть, на разброс значений времени отклика системы влияет одновременно количество запросов приходящихся на каждый узел системы и само количество узлов, каждый из которых добавляет некоторую случайную величину задержки при обработке запросов.
4. Разброс времени отклика системы
Из утверждений 1, 2 и 3 можно также заключить, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся запросы, время обработки которых превышает определенные в требованиях максимумы; причем, чем больше суммарное время проведения эксперимента тем выше окажутся новые максимумы.
Этот факт необходимо учитывать при формировании требований к производительности системы, а также при проведении регулярного нагрузочного тестирования.
5. Точность воспроизведения профилей нагрузки
Необходимая точность воспроизведения профилей нагрузки тем дороже, чем больше компонент содержит система.
Часто невозможно учесть все аспекты профиля нагрузки для сложных систем, так как чем сложнее система, тем больше времени будет затрачено на проектирование, программирование и поддержку адекватного профиля нагрузки для нее, что не всегда является необходимостью. Об этом говорит сайт https://intellect.icu . Оптимальный подход в данном случае заключается в балансировании между стоимостью разработки теста и покрытием функциональности системы, в результате которого появляются допущения о влиянии на общую производительность той или иной части тестируемой системы.
Подробную информацию о том, что такое нагрузочное тестирование и тестирование производительности программ, а так же информацию о методике проведения, вы можете узнать в разделе Автоматизация нагрузочного тестирования.
Следует отметить, что для большинства видов тестирования производительности используется один и тот же инструментарий, умеющий выполнять типовые задачи.
Существует распространенное ошибочное понимание того, что инструменты для нагрузочного тестирования системы — это инструменты такие же по принципу записи и воспроизведения как и инструменты для автоматизации регрессионного тестирования. Инструменты для нагрузочного тестирования работают на уровне протокола, тогда как инструменты для автоматизации регрессионного тестирования работают на уровне объектов графического пользовательского интерфейса.
| Пример 2:
Имеется стандартный интернет-браузер, выполняющий функцию перехода по указанной ссылке при нажатии кнопки. В данном случае для автоматизации регрессионного тестирования необходимо написать скрипт, передающий браузеру клик мышью и нажатие кнопки, в то время как для создания скрипта для нагрузочного тестирования необходимо написать передачу гиперссылки от браузера для нескольких пользователей, включая уникальные для каждого из них имя пользователя и пароль. |
Существуют различные инструменты для обнаружения и исследования проблем в различных узлах системы. Все узлы системы могут быть классифицированы следующим образом:
Также следует отметить появление сетевых Business-to-business (B2B) приложений, использующих соглашение об уровне услуг (или SLA, Service Level Agreement). Нарастающая популярность B2B-приложений привела к тому, что все больше приложений переходят на сервис-ориентированную архитектуру, в случае которой обмен информацией происходит без участия веб-браузеров. Примером такого взаимодействия может служить бюро туристических услуг, запрашивающее информацию об определенном авиарейсе между Санкт-Петербургом и Омском, в то время как авиакомпания обязана предоставить ответ в течение 5 секунд. Часто нарушение договора об SLA грозит крупным штрафом.
Некоторые инструменты для нагрузочного тестирования представлены ниже :
| ПО | Наименование производителя | Комментарии |
|---|---|---|
| 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 StudioTeam System | Microsoft | Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing |
| QTest | Quotium | |
| HTTPerf | ||
| QALoad | Compuware Ltd. | |
| (The) Grinder | ||
| WebLOAD | RadView Software | Нагрузочное тестирование инструмент для веб-и мобильных приложений, включая веб-панели для тестирования производительности анализа. Используется для крупномасштабных нагрузок, которые могут быть сгенерированы также из облака. лицензированный.[4] |
| Яндекс.Танк | Яндекс | Модульный и расширяемый инструмент, позволяющий использовать внутри разные генераторы, в частности, знакомый многим JMeter. Это open-source проект, опубликованный Яндексом в 2012 году. |
Одним из результатов, получаемых при нагрузочном тестировании и используемых в дальнейшем для анализа, являются показатели производительности приложения. Основные из них разобраны ниже.
1. Потребление ресурсов центрального процессора, %
Метрика, показывающая сколько времени из заданного определенного интервала было потрачено процессором на вычисления для выбранного процесса. В современных системах важным фактором является способность процесса работать в нескольких потоках, для того, чтобы процессор мог производить вычисления параллельно. Анализ истории потребления ресурсов процессора может объяснять влияние на общую производительность системы потоков обрабатываемых данных, конфигурации приложения и операционной системы, многопоточности вычислений, и других факторов.
2. Потребление оперативной памяти, Мб
Метрика, показывающая количество памяти, использованной приложением. Использованная память делится на несколько категорий:
При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым сборщиком мусора. Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java — так называемый «постоянный Full GC») или когда процессу выделены большие объемы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.
3. Потребление сетевых ресурсов
Эта метрика не связана непосредственно с производительностью приложения, однако ее показатели могут указывать на пределы производительности системы в целом.
| Пример 3:
Серверное приложение обрабатывая запрос пользователя, возвращает ему видео-поток, используя сетевой канал в 2 мегабит. Требование гласит, что сервер должен обрабатывать 5 запросов пользователей одновременно. Нагрузочное тестирование показало, что эффективно сервер может предоставлять данные только 4 пользователям одновременно, так как мультимедиа-поток имеет битрейт в 500 килобит. Очевидно, что предоставление этого потока 5 пользователям одновременно невозможно в силу превышения пропускной способности сетевого канала, а значит, система не удовлетворяет заданным требованиям производительности, хотя при этом потребление ей ресурсов процессора и памяти может быть невысоким. |
4. Работа с дисковой подсистемой (время ожидания ввода-вывода, англ. I/O wait)
Работа с дисковой подсистемой может значительно влиять на производительность системы, поэтому сбор статистики по работе с диском может помогать выявлять узкие места в этой области. Большое количество чтений или записей может приводить к простаиванию процессора в ожидании обработки данных с диска и в итоге увеличению потребления CPU и увеличению времени отклика.
5. Время выполнения запроса, мс
Время выполнения запроса приложением остается одним из самых главных показателей производительности системы или приложения. Это время может быть измерено на серверной стороне, как показатель времени, которое требуется серверной части для обработки запроса; так и на клиентской, как показатель полного времени, которое требуется на сериализацию / десериализацию, пересылку и обработку запроса.
Следует заметить, что не каждое приложение для тестирования производительности может измерить оба этих времени.
Ниже рассмотрены некоторые экспериментальные факты, обобщенные принципы, используемые при тестировании производительности в целом и применимые к любому типу тестирования производительности (в частности и к нагрузочному тестированию).
1. Уникальность запросов
Даже сформировав реалистичный сценарий работы с системой на основе статистики ее использования, необходимо понимать, что всегда найдутся исключения из этого сценария.
Иллюстрация различной дисперсии распределений для времени выполнения запросов X и Y.
В случае Примера 1 это может быть пользователь, обращающийся к отличным от всех остальных, уникальным страницам веб-сервиса.
2. Время отклика системы
В общем случае время отклика системы подчиняется функции нормального распределения.
В частности, это означает, что, имея достаточное количество измерений, можно определить вероятность с которой отклик системы на запрос попадет в тот или иной интервал времени.
3. Зависимость времени отклика системы от степени распределенности этой системы.
Дисперсия нормального распределения времени отклика системы на запрос пропорциональна отношению количества узлов системы, параллельно обрабатывающих такие запросы и количеству запросов, приходящихся на каждый узел.
То есть, на разброс значений времени отклика системы влияет одновременно количество запросов приходящихся на каждый узел системы и само количество узлов, каждый из которых добавляет некоторую случайную величину задержки при обработке запросов.
4. Разброс времени отклика системы
Из утверждений 1, 2 и 3 можно также заключить, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся запросы, время обработки которых превышает определенные в требованиях максимумы; причем, чем больше суммарное время проведения эксперимента тем выше окажутся новые максимумы.
Этот факт необходимо учитывать при формировании требований к производительности системы, а также при проведении регулярного нагрузочного тестирования.
5. Точность воспроизведения профилей нагрузки
Необходимая точность воспроизведения профилей нагрузки тем дороже, чем больше компонент содержит система.
Часто невозможно учесть все аспекты профиля нагрузки для сложных систем, так как чем сложнее система, тем больше времени будет затрачено на проектирование, программирование и поддержку адекватного профиля нагрузки для нее, что не всегда является необходимостью. Оптимальный подход в данном случае заключается в балансировании между стоимостью разработки теста и покрытием функциональности системы, в результате которого появляются допущения о влиянии на общую производительность той или иной части тестируемой системы.
Выводы из данной статьи про нагрузочное тестирование или тестирование производительности указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое нагрузочное тестирование или тестирование производительности и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.