Основы тестирования ПО

121

o Определение предела применимости программы по числу пользователей.

o Определение влияния конфигурации системы на производительность. o Пиковая нагрузка на систему.

На стадии поставки:

oУдовлетворяет ли архитектура и настройка сети требованиям производительности?

Классическая ошибка - проведение тестирования производительности только на стадии тестирования.

Узкие места и объекты тестирования

Достаточно часто, схема бизнес приложения выглядит следующим образом:

Если рассматривать логические потоки информации, то очевидно узким местом становятся сервер приложений и сервер БД. Как правило, возможности системы ограничиваются возможностями сервера приложений, иногда сервера БД. Для увеличения производительности применяют два метода: оптимизацию кода или БД и аппаратное наращивание (увеличение мощности серверов, создание кластеров).

Если рассматривать физическую организацию, то к этим узким местам добавляется производительность сети. Здесь так же имеются два метода увеличения производительности: программная (минимизация трафика длябизнес операций) и аппаратная (изменение параметров сети).

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

% загрузки процессора сервера приложений % загрузки процессора сервера БД

Средний объем переданных по сети байт за секунду % использования памяти на сервере БД

Средний объем считанных с винчестера сервера БД байт за секунду

122

прочее

Параметр близкий к насыщению указывает на участок, отвечающий за производительность системы в целом. «Цепь не может быть прочнее, чем самое слабое звено»

Метод тестирования

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

Здесь уместна аналогия с экзаменом. Цикл: студент обдумывает решение, отвечает, экзаменатор оценивает решение, дает следующее задание.

При одном студенте экзаменатор будет большую часть времени простаивать. Его производительность в единицу времени будет незначительной.

При некотором количестве студентов мы получаем оптимум: и преподаватель и студенты постоянно заняты.

При дальнейшем увеличении студентов производительность преподавателя остается примерно постоянной, но время ожидания студентов растет пропорционально их числу.

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

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

Наиболее распространенный метод проведения тестирования – запуск нескольких потоков и непрерывные запросы в каждом потоке. Другой метод – имитация действий пользователя в каждом потоке со всеми паузами между

Объекты тестирования

Тестирования времени выполнения системой одной операции Тестирование времени выполнения системой цепочки действий (бизнес операции)

Тестирования времени выполнения компонентом одной операции. Применяется для исследования и оптимизации узких мест.

123

Типичный сценарий тестирования

1. Пользователь определяет следующие параметры:

o Команду, время отклика которой тестируется

o Общее время выполнения. По умолчанию пять минут.

o Время начала замера от начала выполнения. По умолчанию 1 минута.

oВремя окончания замера от начала выполнения. По умолчанию 4 минуты.

o Время задается в целых минутах

o Проверки на правильность ввода можно не проводить o Паузу в сек между отдачей команд

oСписок значений для выбранного пользователем параметра если таковой имеется. (Как вариант задавать список идентификаторов

объектов)

o Число потоков

oДля каждого потока логин и пароль. Можно задать различные, можно одинаковые. Пароль в поле ввода не скрывать

2.Пользователь отдает команду на начало выполнения теста

3.Демон отдает команду тестируемой системе и ожидает ее завершения.

4.После получения управления демон посылает следующий запрос.

Демон считает число удачных запросов между временем начала и окончания запроса в каждом потоке. Удачным считается запрос, начало и окончание которого находится внутри диапазона измерения

5.После окончания теста собираются следующие данные:

oОбщее число удачных запросов.

o Среднее время отклика в секундах, с точностью до сотых

oСреднее время отклика в секундах, с точностью до сотых для каждого потока и их номера

Также желательны:

o Число переданных и принятых по сети байт o Загрузки процессора на сервере и клиенте

o Объемы занятой и свободной памяти на сервере и клиенте

Техника выполнения

Ручная

Может быть использована при отсутствии других вариантов.

Пусть требуется протестировать приложение клиент-банк на возможность одновременной работы до 100 работающих пользователей. Наблюдение за операторами показывает, что они работают с приложением только 20% времени и в среднем тратят на бизнес операцию 2 мин.

Средняя нагрузка от одного оператора – 1 бизнес операция в 10 мин

124

В пике от всех – до 50 бизнес операций в 10 мин и до 10 в минуту.

Если не беспокоиться о правильности ввода, то можно совершать 1 операцию в 30 сек.

Итак, нам понадобится 7 тестеров:

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

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

Специализированными средствами нагрузочного тестирования

На рынке есть масса средств для нагрузочного тестирования со своими преимуществами и недостатками:

RationalPerformanceStudio LoadRunner

WAST

И т.д.

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

Самостоятельно написанной утилитой

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

Типичные результаты тестирования

125

Характерное поведение web приложения под возрастающей нагрузкой.

B – точка максимальной производительности системы

D – точка потери производительности

E – точка краха системы.

При увеличении числа потоков производительность системы растет, до достижения точки максимальной производительности (B). Для динамической вебстраницы на IIS это обычно происходит при 2-5 потоках. Далее идет почти ровное плато производительности (B-C-D) при линейном возрастании времени отклика. Затем происходит резкое падение производительности. Типичная ситуация: при 24 потоках время отклика -2.7 сек, при 25 – 7 сек, при 26 – система не отвечает. Для веб сервера, как правило, точка D соответствует времени отклика 3 сек.

Из этих выкладок следует, что можно оценить максимальную производительность и максимальное число одновременных запросов по одному запросу. Если при 8 потоках время отклика составляет 1 сек (8 запросов в секунду), то разумно искать точку краха системы в области 18-24 запроса. А максимальная производительность будет порядка 9 запросов в секунду (+10%) при 2-3 одновременных запросах (точка B).

Интерпретация результатов

Допустим мы получили результат: Максимальная производительность достигается при трех одновременных запросах. При этом производительность системы составляет девять запросов в секунду. А каково максимальное количество пользователей?

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

Если пользователь обращается к системе один раз в 60 секунд (режим просмотра сообщений в форуме), тогда максимальное число одновременно работающих пользователей – 270 человек.

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

Виды нагрузочного тестирования

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

126

способность системы правильно функционировать в случае превышении планируемых нагрузок.

Более конкретно выделяют следующие виды нагрузочного тестирования:

Тестирование производительности – измеряется скорость работы системы при идеальных условиях и максимальной нагрузке.

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

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

Стресс тестирование – поведение системы при недостатке ресурсов (ресурсов процессора, дискового пространства, обрывов сети и т.п.).

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

Пиковая нагрузка – кратковременная работа сервера и web-приложения с превышением штатного количества пользователей.

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

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

План нагрузочного тестирования

1.Определение целей тестирования, разработка профилей нагрузки.

2.Установка и настройка bot-net для распределенного тестирования (при необходимости).

3.Запись CRUD-теста Selenium в качестве полезной нагрузки, для упрощения подготовки тест-плана.

4.Настройка и отладка нагрузочных тестов в JMeter.

5.Многократное воспроизведение нагрузочных тестов в соответствии с профилями нагрузки.

6.Анализ результатов и формирование отчѐта по разработанному шаблону.

127

Инструментарий для тестирования производительности

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

Существует распространѐнное ошибочное понимание того, что инструменты для нагрузочного тестирования системы — это инструменты такие же по принципу записи и воспроизведения как и инструменты для автоматизации регрессионного тестирования. Инструменты для нагрузочного тестирования работают на уровне протокола, тогда как инструменты для автоматизации регрессионного тестирования работают на уровне объектов графического пользовательского интерфейса.

Пример 2:

Имеется стандартный интернет-браузер, выполняющий функцию перехода по указанной ссылке при нажатии кнопки.

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

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

Приложение, База данных, Сеть,

Обработка на клиентской стороне, Балансировка нагрузки.

Наиболее популярные инструменты для нагрузочного тестирования представлены ниже.

Основные показатели (метрики) производительности

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

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

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

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

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

Virtual — объѐм виртуального адресного пространства, которое использует процесс. Этот объѐм подразумевает, как использование соответствующего дискового пространства так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти принадлежащей другому процессу.

Private — объѐм адресного пространства, занятого процессом и не разделяемого с другими процессами.

129

Working Set — набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остаѐтся мало, использованные страницы перемещаются из ОЗУ на жѐсткий диск (или другой накопитель, такой как Флеш-память), освобождая ОЗУ для загрузки других активных страниц памяти.

Shared — объѐм используемой процессом физической памяти, которая может использоваться совместно с другими процессами. Хотя память выделенная процессу должна быть изолированной, процессам, иногда, необходимо иметь возможность обмениваться информацией. Общая память является самым быстрым способом межпроцессного взаимодействия.

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

Потребление сетевых ресурсов

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

Пример 3:

Серверное приложение обрабатывая запрос пользователя, возвращает ему видео-поток, используя сетевой канал в 2 мегабит. Требование гласит, что сервер должен обрабатывать 5 запросов пользователей одновременно.

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

Работа с дисковой подсистемой (время ожидания ввода-вывода, I/O wait)

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

130

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

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

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

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

Apache JMeter

Apache JMeter (jakarta.apache.org/jmeter) является Java-приложением с открытым кодом, предназначен для нагрузочного тестирования не только вебприложений и их отдельных компонентов (скрипты, сервлеты, Java объекты и др.), но также FTP-серверов, баз данных (с использованием JDBC) и сети. Функциональность расширяется с помощью плагинов. Поддерживается SSL (через Java Secure Sockets Extension). Возможно проведение тестов как с использованием графического интерфейса, так и из командной строки. Использование Java подразумевает кроссплатформенность, поэтому JMeter уверенно работает в различных *nix-системах, в Windows от 98 и некоторых других ОС. Распространяется под Apache License.

В JMeter предусмотрены механизмы авторизации виртуальных пользователей, поддерживаются пользовательские сеансы, шаблоны, кэширование и последующий offline анализ результатов теста, функции позволяют сформировать следующий запрос, основываясь на ответе сервера на предыдущий. Есть возможность проводить распределенные тесты. В этом случае один из компьютеров является сервером (bin/jmeter-server.bat), который управляет клиентами и собирает итоговую информацию.

Для работы достаточно запустить ApacheJMeter.jar или в консоли jmeter.bat (Windows) или jmeter.sh (*nix).

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