Лекции / Лекция 6. Нагрузочное тестирование

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

Тестирование методом анализа данных на стороне клиента (Client

Capture)

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

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

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

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

Тестирование методом анализа сетевого трафика (Network Sniffing)

Тестирование основано на извлечении информации о производительности приложений из сетевого трафика. Для этого в сети устанавливаются специальные зонды (как правило, аппаратные), которые в режиме реального времени захватывают сетевой трафик, анализируют его и "извлекают" данные о времени реакции приложений, доступности приложения и т.п. Зонды выпускаются производителями аппаратных анализаторов сетевых протоколов, однако возможно использование и open-source ПО, такого как wireshark и/или tcpdump.

Тестирование методом анализа сетевого трафика имеет следующие недостатки:

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

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

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

-использование многопоточности

-использование распределенных вычислений.

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

Инструменты формирования нагрузки и сбора статистики при выполнении нагрузочного тестирования

Сбор статистики при выполнении нагрузочного тестирования может быть выполнен:

-с использованием общего ПО для сбора статистики, например, Cacti (cacti.org), Nagios (nagios.org), Zabbix (zabbix.com), mrtg (oss.oetiker.ch),

Mozilla Firefox (Инструменты – Дополнения – Расширения – Firebug), Google Chrome (Настройка и управление – Дополнительные инструменты – Диспетчер задач, Инструменты разработчика) и др.

-с использованием общесистемного ПО ОС GNU Linux (top, vmstat, iotop, iostat, sysstat, sar, sockstat, sysstat и др.)

-с использованием ПО, специально разработанного для формирования нагрузки

(ab, httperf, для web-серверов, Jmeter, Grinder для java-серверов, dnsperf – для dns-серверов, iperf, netperf – для сети и др.)

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

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

Создание и отладка тестовых скриптов

На данном этапе осуществляются:

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

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

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

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

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

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

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

Методика проверки нагрузочных и функциональных требований

Оцениваемые характеристики:

Проверка осуществляется на соответствие требованиям п. 4.1, 4.2, 4.5 и 4.6 ТЗ на ОКР «НаименованиеОКР».

При проведении проверки оцениваются:

-функциональные характеристики системы;

-нагрузочные характеристики системы;

-отказоустойчивость работы системы.

Порядок проведения проверки:

-до начала проверки в течение не менее пяти рабочих дней на сервере syslog выполняется сбор событий от соответствующих источников событий для получения среднего количества поступления событий в соответствующие периоды времени для каждого источника событий

-перед началом проверки осуществляется настройка и выполнение синхронизации времени на узлах системы от серверов точного времени

-проверка проводится в рабочий день в рабочее время в течение не менее трех и не более пяти рабочих дней

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

Методика проверки нагрузочных и функциональных требований

(продолжение)

-с учетом полученных до начала испытаний средних значений количества поступления событий в соответствующие периоды времени для каждого рабочего дня испытаний будут определены перечни подключаемых источников событий и составлены графики подключаемой нагрузки для достижения среднего совокупного количества событий, подаваемых на вход системы, например, 1 000, 5 000, 10 000, 15 000, 20 000, 25 000 и 30 000 событий в секунду в различные периоды времени на соответствующие узлы с изменением количества источников событий каждые ~2 часа.

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

-после достижения требуемого среднего количества событий на заданном интервале тестирования в установившемся режиме работы систем, например, в середине каждого двухчасового интервала осуществляется выполнение функциональных сценариев для системы под нагрузкой, например, проверки пользовательских интерфейсов, в соответствии с сценариями 7.1 – 7.3 основной ПМИ и/или другие проверки из основной ПМИ по усмотрению специалистов - участников тестирования

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

Методика проверки нагрузочных и функциональных требований

(продолжение)

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

функциональных задач в течение, например, 5 мин. после выполнения запроса на решение функциональной задачи, получение результатов решения функциональны задач, не соответствующих ожидаемым, полное заполнение поступающими событиями объема памяти на диске выделенного для кеша поступающих событий, потери поступающих событий ввиду полного заполнения кеша и/или по др. причина Фиксация не стабильной работы системы осуществляется в протоколе учетом времени наступления события, формулированием описания нестабильности и, по возможности, одновременной проверкой требуемой сетевой доступности между узлами системы (наличие сетевой связности от соответствующих ip-адресов узлов системы на соответствующие сокеты соответствующих ip-адресов соответствующих других узлов системы и пр.). Оценка стабильности работы системы оценивается экспертным методом.

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

- при проведении проверок выполняется сбор статистических характеристик узло системы с использованием средств мониторинга VMware и/или средств мониторинг операционных систем и/или средств мониторинга системы для получения следующих значений:

-среднее количество поступающих событий в секунду;

-количество источников событий;

-количество событий, обработанных системой;

-количество событий, ожидающих обработки в очередях системы;

-процент использования ядер процессоров;

-процент использования оперативной памяти;

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

-сбор статистических характеристик осуществляется с периодичностью каждые 10 15 мин. методом непосредственного просмотра соответствующих средних значений в интерфейсе VMware, интерфейсах операционных систем, интерфейсах системы с занесением их в журнал учета (xls-файл).

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

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

Методика проверки нагрузочных и функциональных требований

(завершение)

Оценка результатов проверки:

Требования п. 4.1, 4.2, 4.5 и 4.6 ТЗ на ОКР «НаименованиеОКР» считать выполненными, если:

-полученные статистические значения событий в секунду, обработанных соответствующей системой, подобны (коррелируют) статистическим значениям событий в секунду, поступивших на ее вход;

-достигнуто заданное значение количества событий в секунду, подаваемых на вход системы и обрабатываемых системой в соответствующий интервал времени;

-полученное максимальное фактическое значение количества событий, подаваемых на вход системы и обрабатываемых системой составляет 30 000 (±500) событий в секунду;

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