Тестирование производительности в инженерии программного обеспечения — тестирование, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов.
Тестирование производительности — это одна из сфер деятельности развивающейся в области информатики инженерии производительности, которая стремится учитывать производительность на стадии моделирования и проектирования системы, перед началом основной стадии кодирования.
Направления тестирования производительности
В тестировании производительности различают следующие направления:
- нагрузочное (load)
- стресс (stress)
- тестирование стабильности (endurance or soak or stability)
- конфигурационное (configuration)
Возможны два подхода к тестированию производительности программного обеспечения[1]:
- в терминах рабочей нагрузки: программное обеспечение подвергается тестированию в ситуациях, соответствующих различным сценариям использования;
- в рамках бета-тестирования, когда система испытывается реальными конечными пользователями.
Нагрузочное тестирование
Нагрузочное тестирование — это простейшая форма тестирования производительности. Нагрузочное тестирование обычно проводится для того, чтобы оценить поведение приложения под заданной ожидаемой нагрузкой. Этой нагрузкой может быть, например, ожидаемое количество одновременно работающих пользователей приложения, совершающих заданное число транзакций за интервал времени. Такой тип тестирования обычно позволяет получить время отклика всех самых важных бизнес-транзакций. В случае наблюдения за базой данных, сервером приложений, сетью и т. д., этот тип тестирования может также идентифицировать некоторые узкие места приложения.
Стресс-тестирование
Стресс-тестирование обычно используется для понимания пределов пропускной способности приложения. Этот тип тестирования проводится для определения надёжности системы во время экстремальных или диспропорциональных нагрузок и отвечает на вопросы о достаточной производительности системы в случае, если текущая нагрузка сильно превысит ожидаемый максимум.
Тестирование стабильности
Тестирование стабильности проводится с целью убедиться в том, что приложение выдерживает ожидаемую нагрузку в течение длительного времени. При проведении этого вида тестирования осуществляется наблюдение за потреблением приложением памяти, чтобы выявить потенциальные утечки. Кроме того, такое тестирование выявляет деградацию производительности, выражающуюся в снижении скорости обработки информации и/или увеличении времени ответа приложения после продолжительной работы по сравнению с началом теста.
Конфигурационное тестирование
Конфигурационное тестирование — ещё один из видов традиционного тестирования производительности. В этом случае вместо того, чтобы тестировать производительность системы с точки зрения подаваемой нагрузки, тестируется эффект влияния на производительность изменений в конфигурации. Хорошим примером такого тестирования могут быть эксперименты с различными методами балансировки нагрузки. Конфигурационное тестирование также может быть совмещено с нагрузочным, стресс или тестированием стабильности.
Определение целей тестирования производительности
В общих случаях тестирование производительности может служить разным целям.
- С целью демонстрации того, что система удовлетворяет критериям производительности.
- С целью определения, производительность какой из двух или нескольких систем лучше.
- С целью определения, какой элемент нагрузки или часть системы приводит к снижению производительности.
Многие тесты на производительность делаются без попытки осмыслить их реальные цели. Перед началом тестирования всегда должен быть задан бизнес-вопрос: «Какую цель мы преследуем, тестируя производительность?». Ответы на этот вопрос являются частью технико-экономического обоснования (или business case) тестирования. Цели могут различаться в зависимости от технологий, используемых приложением, или его назначения, однако, они всегда включают что-то из нижеследующего:
Параллелизм / Пропускная способность
Если конечными пользователями приложения считаются пользователи, выполняющие логин в систему в любой форме, то в этом случае крайне желательно достижение параллелизма. По определению это максимальное число параллельных работающих пользователей приложения, поддержка которого ожидается от приложения в любой момент времени. Модель поведения пользователя может значительно влиять на способность приложения к параллельной обработке запросов, особенно если он включает в себя периодически вход и выход из системы.
Если концепция приложения не заключается в работе с конкретными конечными пользователями, то преследуемая цель для производительности будет основана на максимальной пропускной способности или числе транзакций в единицу времени. Хорошим примером в данном случае будет являться просмотр веб-страниц, например, на портале Wikipedia.
Время ответа сервера
Эта концепция строится вокруг времени ответа одного узла приложения на запрос, посланный другим. Простым примером является HTTP 'GET' запрос из браузера рабочей станции на веб-сервер. Практически все приложения, разработанные для нагрузочного тестирования работают именно по этой схеме измерений. Иногда целесообразно ставить задачи по достижению производительности времени ответа сервера среди всех узлов приложения.
Время отображения
Время отображения — одно из самых сложных для приложения для нагрузочного тестирования понятий, так как в общем случае они не используют концепцию работы с тем, что происходит на отдельных узлах системы, ограничиваясь только распознаванием периода времени в течение которого нет сетевой активности. Для того, чтобы замерить время отображения, в общем случае требуется включать функциональные тестовые сценарии в тесты производительности, но большинство приложений для тестирования производительности не включают в себя такую возможность.
Требования к производительности
Очень важно детализировать требования к производительности и документировать их в каком-либо плане тестирования производительности. В идеальном случае это делается на стадии разработки требований при разработке системы, до проработки деталей её дизайна. См. Инженерия производительности.
Однако тестирование производительности часто не проводится согласно спецификации, так как нет зафиксированного понимания о максимальном времени ответа для заданного числа пользователей. Тестирование производительности часто используется как часть процесса профайлинга производительности. Его идея заключается в том, чтобы найти «слабое звено» — такую часть системы, соптимизировав время реакции которой, можно улучшить общую производительность системы. Определение конкретной части системы, стоящей на этом критическом пути, иногда очень непростая задача, поэтому некоторые приложения для тестирования включают в себя (или могут быть добавлены с помощью add-on’ов) инструменты, запущенные на сервере (агенты) и наблюдающие за временем выполнения транзакций, временем доступа к базе данных, оверхедами сети и другими показателями серверной части системы, которые могут быть проанализированы вместе с остальной статистикой по производительности.
Тестирование производительности может проводиться с использованием глобальной сети и даже в географически удаленных местах, если учитывать тот факт, что скорость работы сети Интернет зависит от местоположения. Оно также может проводиться и локально, но в этом случае необходимо настроить сетевые маршрутизаторы таким образом, чтобы появилась задержка, присутствующая во всех публичных сетях. Нагрузка, прилагаемая к системе, должна совпадать с реальным положением дел. Так например, если 50 % пользователей системы для доступа к системе используют сетевой канал шириной 56К, а другая половина использует оптический канал, то компьютеры, создающие тестовую нагрузку на систему должны использовать те же соединения (идеальный вариант) или эмулировать задержки вышеуказанных сетевых соединений, следуя заданным профайлам пользователей.
Типичные вопросы тестирования производительности
Требования к производительности должны адресовать следующие, как минимум, вопросы:
- Что охватывается тестом производительности? Какие подсистемы, компоненты, интерфейсы и т. д. должны быть протестированы?
- Если в тест включаются пользовательские интерфейсы, то сколько одновременно работающих в системе пользователей ожидается для каждого интерфейса (необходимо определить пиковые и нормальные значения)
- Как выглядит аппаратная составляющая тестируемой системы? (Необходимо описать все сервера и сетевое оборудование)
- Каков сценарий использования каждого компонента системы? (например, 20 % запросов составляет вход в систему, 40 % — поиск, 30 % — выбор элемента, 10 % — выход из системы)
- Каков сценарий использования системы? [в одном тесте на производительность могут быть задействованы разные сценарии использования каждого компонента]
- Каковы требования ко времени выполнения серии операций серверной части приложения?
Инструментарий
Существует распространённое ошибочное понимание того, что инструменты для нагрузочного тестирования системы — это инструменты такие же по принципу записи и воспроизведения как и инструменты для автоматизации регрессионного тестирования. Инструменты для нагрузочного тестирования работают с использованием протокола, тогда как инструменты для автоматизации регрессионного тестирования работают как с использованием протокола, так и используя объекты графического пользовательского интерфейса.
| Пример 1:
Имеется стандартный интернет-браузер, выполняющий функцию перехода по указанной ссылке при нажатии кнопки. В данном случае для автоматизации регрессионного тестирования необходимо написать скрипт, передающий браузеру клик мышью и нажатие кнопки, в то время как для создания скрипта для нагрузочного тестирования необходимо написать передачу гиперссылки от браузера для нескольких пользователей, включая уникальные для каждого из них имя пользователя и пароль. |
Существуют различные инструменты для обнаружения и исследования проблем в различных узлах системы. Все узлы системы могут быть классифицированы следующим образом:
- Приложение
- База данных
- Сеть
- Обработка на клиентской стороне
- Балансировка нагрузки
Также следует отметить появление сетевых 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- или интеграционного. |
| SilkPerformer | Micro Focus | |
| Visual Studio Load Test | Microsoft | Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing |
Основные показатели (метрики) производительности
Одним из результатов, получаемых при нагрузочном тестировании и используемых в дальнейшем для анализа, являются показатели производительности приложения. Основные из них разобраны ниже.
- 1. Потребление ресурсов центрального процессора (CPU, %)
Метрика, показывающая сколько времени из заданного определённого интервала было потрачено процессором на вычисления для выбранного процесса. В современных системах важным фактором является способность процесса работать в нескольких потоках, для того, чтобы процессор мог производить вычисления параллельно. Анализ истории потребления ресурсов процессора может объяснять влияние на общую производительность системы потоков обрабатываемых данных, конфигурации приложения и операционной системы, мультипоточности вычислений, и других факторов.
- 2. Потребление оперативной памяти (Memory usage, Mb)
Метрика, показывающая количество памяти, использованной приложением. Использованная память может делиться на три категории:
- Virtual — объём виртуального адресного пространства, которое использует процессор. Этот объём не обязательно подразумевает использование соответствующего дискового пространства или оперативной памяти. Виртуальное пространство конечно и процесс может быть ограничен в возможности загружать необходимые библиотеки.
- Private — объём адресного пространства, занятого процессом и не разделяемого с другими процессами.
- Working Set — набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае когда, свободной памяти остается мало, использованные страницы удаляются.
При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым «сборщиком мусора» (англ. Garbage Collector). Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java — так называемый «постоянный Full GC») или когда процессу выделены большие объёмы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.
- 3. Потребление сетевых ресурсов
Эта метрика не связана непосредственно с производительностью приложения, однако её показатели могут указывать на пределы производительности системы в целом.
| Пример 2:
Серверное приложение обрабатывая запрос пользователя, возвращает ему видео-поток, используя сетевой канал в 2 мегабит. Требование гласит, что сервер должен обрабатывать 5 запросов пользователей одновременно. Нагрузочное тестирование показало, что эффективно сервер может предоставлять данные только 4 пользователям одновременно, так как мультимедиа-поток имеет битрейт в 500 килобит. Очевидно, что предоставление этого потока 5 пользователям одновременно невозможно в силу превышения пропускной способности сетевого канала, а значит, система не удовлетворяет заданным требованиям производительности, хотя при этом потребление ей ресурсов процессора и памяти может быть невысоким. |
- 4. Работа с дисковой подсистемой (I/O Wait)
Работа с дисковой подсистемой может значительно влиять на производительность системы, поэтому сбор статистики по работе с диском может помогать выявлять узкие места в этой области. Большое количество чтений или записей может приводить к простаиванию процессора в ожидании обработки данных с диска и в итоге увеличению потребления CPU и увеличению времени отклика.
- 5. Время выполнения запроса (request response time, ms)
Время выполнения запроса приложением остаётся одним из самых главных показателей производительности системы или приложения. Это время может быть измерено на серверной стороне, как показатель времени, которое требуется серверной части для обработки запроса; так и на клиентской, как показатель полного времени, которое требуется на сериализацию / десериализацию, пересылку и обработку запроса. Надо заметить, что не каждое приложение для тестирования производительности может измерить оба этих времени.
Мифы тестирования производительности
Некоторые из самых распространенных мифов приведены ниже.
1. Тестирование производительности проводится с целью сломать систему. Стресс тестирование делается с целью найти критическую точку прочности системы. В других же случаях, обычное нагрузочное тестирование делается с целью исследовать поведение системы при ожидаемой нагрузке. В зависимости от других требований, может потребоваться тестирование стабильности, конфигурационное или стресс-тестирование.
2. Тестирование производительности должно осуществляться только после Интеграционного тестирования производительности Хотя это практически норма в индустрии создании ПО, тестирование производительности может также производиться на первичной стадии разработки приложения. Такой подход называется Раннее тестирование производительности. Он помогает целостному подходу к разработке, учитывая параметры производительности и, таким образом, уменьшает не только вероятность нахождения проблемы производительности непосредственно перед релизом, но и стоимость исправления подобных проблем.
3. Тестирование производительности состоит только из написания скриптов и любое изменение в приложении приводит к небольшому рефакторингу этих скриптов. Тестирование производительности само по себе — это развивающаяся отрасль индустрии программного обеспечения. Написание скриптов, хоть и важная, но всего лишь часть тестирования производительности. Наиболее сложная задача для специалиста по тестированию — это определение необходимых к проведению тестов и анализ различных метрик производительности для выявления узких мест системы.
Другая часть мифа, касательно небольших изменений в скриптах тоже неправда, так как любые изменения в UI, особенно в сетевом протоколе, приведет к полному переписыванию скриптов с самого начала. Проблема становится более ощутимой в случае использования таких протоколов, как Web Services, Siebel, Citrix, SAP.
4. Стресс-тестирование, нагрузочное тестирование и тестирование стабильности это одно и то же. Один из самых распространенных мифов, связанный с недопониманием терминологии. Стресс-тестирование и нагрузочное тестирование — два различных вида деятельности, которая называется общим термином тестирования производительности, и решающих различные задачи. Задача стресс-тестирования — найти критическую точку прочности системы при нагрузках значительно превышающих ожидаемых или же диспропорциональных; задача нагрузочного тестирования — проверить соответствие системы требованиям при ожидаемой нагрузке.
См. также
Примечания
Литература
- Richard Bradtke. ISTQB 100 Success Secrets - ISTQB Foundation Certification Software Testing the ISTQB Certified Software Tester 100 Most Asked Questions. — Emereo Publishing, 2008. — P. 35—38. — 170 p. — ISBN 978-1921523175.
Ссылки
- Портал специалистов по тестированию и обеспечению качества ПО (рус.) — Проект посвящён вопросам тестирования и повышения качества программного обеспечения.
 | В этой статье не хватает ссылок на источники информации. |
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .