top of page

Уровень 17

Нагрузочное тестирование при помощи JMeter

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

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

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

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

​

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

 

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

 

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

 

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

​

5. Тестирование стабильности или надежности (Stability / Reliability Testing). 

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

Виды режимов работы

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

 

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

 

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

 

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

Нагрузочное тестирование включает:

1. Тестирование под рабочей нагрузкой

 

2. Тестирование под повышенной нагрузкой

 

3. Тестирование пиковых нагрузок

 

4. Тестирование на больших объемах данных

 

5. Тестирование «правильного умирания»

 

6. Тюнинг и игры с настройками

 

7. «Железные» вопросы

 

8. Оценка живучести систем

 

9. Рекомендации пациенту

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

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

​

1. Берем требования у заказчика

2. Анализируем их с аналитиком, берем статистические данные у него

3. Опрашиваем разработчика, узнаем реальные параметры и возможные пороги системы. Согласовываем с ним ТЗ нагрузки

4. Опрашиваем админов / devOps, на предмет актуальности собранных требование на сегодняшний день

5. Включаем мозги и создаем готовы документ

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

Виды тестовых серверов 

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

​

1. Локальный сервер. Развертывание вашего ПО на вашем компьютере. Удобно для функционального тестирования. Не применяется для нагрузочного тестирования.

​

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

​

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

​

4. Боевой сервер (Production, Продакшен). Сервер с которым непосредственно работают ваши клиенты или пользователи. На него выкатывается оттестированная версия (Pass QA). Крайне не рекомендуется проводить нагрузочное тестирование на продакшене. Вы легко можете его завалить нагрузкой и будет беда. Возможно использовать выделенный кластер боевого сервера, если от него будут отключены пользователи на время проведения тестов.

​

Тестовый стенд, или грабли, по которым мы ходим

От конфигурации тестового стенда в нагузочном тестировании зависит ООООЧЕНЬ много. В природе бывает всего три соотношения между тестовым и боевым сервером:

​

a. Тестовый стенд равен продакшену

 

b. Тестовый стенд архитектурно равен продакшену

 

c. Тестовый стенд  не равен продакшену

Работа с требованиями

На стадии проектирования.

  • Какая из архитектур системы лучше? Трех или четырехуровневая, где и как хранить файлы, обеспечат ли выбранный язык и БД необходимую производительность и т.д.

 

На стадии программирования.

  • Какая схема БД лучше? Стоит ли отказаться от нормализации БД в пользу производительности или наоборот; как делать GUI; что лучше триггера или внешние ключи.

 

  • Какой участок кода следует оптимизировать в первую очередь

 

На стадии тестирования:

  • Максимальная производительность системы

 

  • Определение увеличения времени отклика и длительность операций при увеличении нагрузки.

 

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

 

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

 

  • Пиковая нагрузка на систему.

 

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

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

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

Тестовый стенд равен продакшену

Самый простой и удобный случай. Наши действия:

​

  • Устанавливаем, проводим смок тестирование версию

  • Грузим в соответствии с планом

  • Тюним и доводим до ума

  • Идем в продакшен

Тестовый стенд архитектурно равен продакшену

В этом случае придётся повозится с настройкам и обработкой результатов тестов. Наши действия:

​

  • Думаем, как установить версию, где чего обрезать или сократить

  • Обрезаем и/или сокращаем Базы Данных если нужно

  • Устанавливаем, тестируем версию

  • Грузим в соответствии с планом

  • Тюним и доводим до ума

  • Проводим интерпретацию результатов

  • Идем в продакшен

Тестовый стенд не равен продакшену
Тестовый стенд

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

тестовые версии. Другое дело если вы имеете дело с большими комплексными системами как: почтовые серверы, соцсети, облачные хранилища, веб-платформы и прочее ... Тестирование таких приложений требует развёртывания целой сети тестовых машин. В итоге это приводит к образованию тестового кластера. Попытка развёртывания такого кластера на базе машин, физически стоящих в центре разработки, ведёт к созданию собственного дата-центра со всеми издержками такого решения. Хорошей альтернативой стало использование решений типа Amazon Web Services.

Естественное желание сэкономить на аренде хостов или на покупке оборудования приводит к выбору таковых с заниженными относительно production инсталляции характеристиками. Заниженными в разы. И тут вступает в действие коэффициент пересчёта между синтетическими индексами производительности. Т.е. процессор в production будет в 2 раза быстрее, количество ядер будет в 4 раза больше, объём оперативной памяти будет в 6 раз больше, производительность дисковой подсистемы будет в 3,5 раза лучше, скорость сети будет в 100 раз больше. Сложим, поделим на количество показателей, умножим на некий поправочный коэффициент и получим коэффициент пересчёта, на который будем умножать результаты тестирования производительности. Можно придумать и более сложную формулу, например, назначить каждому показателю некий вес.

При ближайшем же рассмотрении такой подход оказывается пригодным лишь для подготовки тестовой наборов для будущего тестирования на инсталляции, близкой к production, и на обнаружение самых очевидных проблем производительности. (Что уже достаточно много и важно.) Почему? Да потому хотя бы, что при таком подходе совершенно не учитывается эффект bottlenecks.

​

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

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

Тестовый стенд не равен продакшену - применяем коэффициенты

В случае, когда тяжело сравнить железо и сервера подключены по одинаковому сетевому каналу, можно применить коэффициент определенный по какому-либо стандартному запросу. В этом случае вы делаете N запросов на сервер, и берете среднее время для боевого T и для тестового сервера t. Потом рассчитываете коэффициент по формуле k = T/t (боевой ÷  тестовый). Для корректировки результата, умножаете результат полученный на тестовом сервере на этот коэффициент R = k * t. 

Аналогично применяем коэффициенты при тестировании разных версий

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

Кому нужны результаты нагрузочного тестирования

  • Project или Release Manager

  • Capacity manager

  • Команде программистов

  • Вашему тимлиду

Это не глупые вопросы
Jmeter
Инструмент нагрузочного тестирования - Jmeter

Логично предположить, что для проведения perfomance testing необходим специально разработанный софт. Конечно, Чубака скажет, что тут-та можно изобрести звездолет, выучить по методичке язык программирования и написать свои нагрузочные скрипты. Но мы не будем предаваться этому унынию, а воспользуемся готовым, высококачественным программным продуктоом под названием Jmeter.

​

Почему именно эта программа поинтересуетесь вы?

Потому, что она:

​

а) Бесплатная

б) Активно поддерживается поставщиком, появляются новые более совершенные версии

г) Она отлично зарекомендовала себя в среде тестировщиков

д) Jmeter это java программа запускаемая на любой ОС

е) Имеет серверную часть, способную анализировать состояние сервера во время нагрузки

​

Итак вашему вниманию, предоставляется Apache JMeter — инструмент для проведения нагрузочного тестирования, разрабатываемый Apache Software Foundation.

Хотя изначально JMeter разрабатывался как средство тестирования web-приложений, в настоящее время он способен проводить нагрузочные тесты для JDBC-соединений, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP и TCP протоколов.

​

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

Планирование работы 

Нагрузочное тестирование перво-наперво начинается с планирования. План нагрузочного тестирования при помощи программы Jmeter состоит из:

​

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

 

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

 

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

 

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

 

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

 

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

Установка и настройка JMeter

 

1. Скачать и установить последнюю версию JDK (JDK 8)

​

2. Добавить переменную окружения JAVA_HOME и установить ей значение - каталог с JDK, например, JAVA_HOME='c:\Program Files (x86)\Java\jdk1.6.0_27\'. Как это сделать.

 

3. Добавить в значение переменной окружения Path строку: ;%JAVA_HOME%bin

 

4. Скачать Apache JMeter по ссылке и распаковать. Нежелательно переименовывать поддиректории JMeter.

 

5. Добавить переменную окружения JMETER_HOME и установить ей значение - каталог с JMeter, например, JMETER_HOME='c:\apache-jmeter-2.7\'

 

6. Добавить в значение переменной окружения Path строку: ;%JMETER_HOME%bin

 

7. Скачать jp@gc-плагины по ссылке, например, JMeterPlugins-0.5.3, и распаковать.

 

8. Скопировать файл JMeterPlugins.jar из каталога с распакованным jp@gc-плагином в каталог %JMETER_HOME%lib\ext.

Снятие показателей нагрузки
Практика
Снятие показателей
Снятие показателей нагрузки с сервера

Настройка jp@gc-плагина для использования PerfMon Metrics Collectors

Для использования модулей PerfMon Metrics Collectors из jp@gc-плагина, которые снимают показатели нагрузки на стороне сервера, необходимо также запустить сервер-агент JMeter на всех серверах, участвующих в измерении (сервера приложения, БД и прочих). Для этого требуется:

1. Скопировать каталог serverAgent из каталога с jp@gc-плагинами на сервер, нагрузку на который требуется измерять.

 

2. Для Windows-серверов запустить файл startAgent.bat. Для Linux-серверов запустить startAgent.sh, предварительно дав права на запуск командой

 

3. chmod a+x startAgent.sh

После запуска агента будут доступны модули PerfMon Metrics Collector Listener, для подключения к агентам. В них можно добавить несколько серверов для мониторинга. Один график может отображать различные виды метрик: загрузку процессоров, памяти, дисковой подсистемы, сетевых адаптеров и прочих).

Снятие показателей нагрузки с сервера

По умолчанию, JMeter не сохраняет некоторые данные, например, число потоков и число запросов, в JTL-файлы (в собственном формате JMeter). Если для подготовки отчетов планируется работать с файлами JTL, нужно в файле c настройками %JMETER-HOME%bin\jmeter.properties снять комментарий со строки, содержащей переменную jmeter.save.saveservice.thread_counts, удалив символ «#» в начале строки, и установить ей значение:

 

jmeter.save.saveservice.thread_counts=true

 

Это позволит отображать правильные графики из JTL-файлов, в которых используется указание числа потоков.

Нужно снять комментарий со строки, содержащей переменную jmeter.save.saveservice.sample_count

и установить её значение:

jmeter.save.saveservice.sample_count=true

​

Это позволит отображать правильные графики из JTL-файлов, в которых используется указание числа запросов.

После исправления файла с настройками нужно в JMeter GUI открыть окно конфигурации нужного плагина (кнопка Configure) и выбрать опцию Save Active Thread Counts.

 

Подготовка тест-плана JMeter

Для упрощения создания тест-плана JMeter нужно использовать комплект End-to-end-сценариев тестов в Selenium, действия в которых и будут использоваться для записи нагрузочных тестов. Все действия с тестами можно выполнять в ветке тестплана Thread Group. Thread group - переводится как группа потоков. При нагрузочном тестировании под каждое действие выделяется свой автономный поток, выполняемый компьютером параллельно с другими.

​

Чтобы добавить Thread  Group нужно из контекстного меню элемента Test Plan выбрать Add - Thread Group. Элемент Thread Group позволяет задавать параметры генерируемой на приложение нагрузки. Основными его параметрами являются:

 

1. Number of threads - количество потоков (имитируемых пользователей одновременно работающих с сайтом);

 

2. Ramp-up period  - промежуток времени, через который выполняется запуск очередного процесса;

 

3. Loop count - количество раз, которое будет выполняться сценарий внутри Thread Group;

 

4. Forever - сценарий будет выполняться всегда, пока не будет прерван явно;

 

5. Scheduler - планировщик времени работы сценария;

 

6. Action to be taken after a Sample Error - действие, выполняемое в случае, если запрос вызовет ошибку.

Подготовка JMeter к тесту
Подготовительные действия перед записью Запись тест-кейсов

Пока не будем добавлять HTTP Proxy Server в дерево теста. Обсудим, куда мы будем записывать полученные «шаги». Позже, когда мы добавим элемент в дерево, мы увидим, что есть несколько возможностей, куда именно записывать результаты. Их можно записать прямо в «катушку» (Thread), на «верстак» (Workbanch), либо в элемент «Recording Controller». Я советую воспользоваться последним способом. Во-первых, это позволит при необходимости отключить (ctrl+t) весь лог разом; во-вторых, так лучше отслеживается и формируется структура теста.

Все действия по добавлению и редактированию происходят по нажатию правой кнопки мыши в контекстном меню. Созданные элементы можно просто перетаскивать (drag and drop).

Итак: Test Plan -> Add -> Threads ->Thread Group; Thread Group -> Add -> Logic Controller -> Recording Controller.

Настоятельно рекомендую дать сразу всем элементам понятные имена.

Отладка скрипта

Отладка скрипта представляет собой удаление различных .jpg, .png и ссылок на сторонние ресурсы. У меня в скрипте больше половины таких сторонних ресурсов - это связи с различными социалками и ссылки на шрифты fonts.gstatic.com, также сайт it school. Всё это можно вычищать (клавишей delete). В целом, также можно вычистить .js. Главное найти запрос, который передает в своем теле учетные данные вашего пользователя. Ну и для красоты найти запрос, который ведет вас на страницу, на которой пользователь логинится. Таким образом, вместе они моделируют связку в действиях пользователя «зашел на страницу — залогинился».

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

Авторизация

Если вам для тестирования нужно авторизоваться на сервере. Для этого добавим в верхушку дерева HTTP Autorization Manager (Thread Group – Add – Config Elements – HTTP Autorization Manager). Он интуитивно понятен. Записываем туда адрес нашего ресурса обязательно с http://, имя пользователя и пароль.

 

Если Менеджер Авторизации нужен для авторизации на сервере, то абсолютно точно при авторизации на сайте используются куки. Добавляем Cookie Manager после Менеджера Авторизации (TestPlan – Add – Config Elements — HTTP Cookie Manager). Этот элемент необходимо добавлять, пожалуй, всегда, если речь идет о том, что пользователю нужно залогиниться.

Отладка скрипта
Запись отчетов

Для визуализации и логирования результатов тестирования в JMeter реализованы Слушатели (Listeners). Слушатели могут быть нескольких типов:

  • Graph Full Results - отображение результатов теста в виде графика;

 

  • Graph Results - отображение основных (отклонения, средние величины) результатов теста в виде графика;

 

  • Spline Visualizer  - отображение результатов теста в виде графика с усредненными (сглаженными) значениями.

 

  • А так же Summary report , View results in Table

 

В группу потоков Thread Group необходимо добавить элемент Listener. Для этого из контекстного меню Thread Group нужно выбрать Add - Listener. Раскрывается список слушателей. Среди них должны присутствовать как стандартные, так и дополнительные графические jp@gc-плагины от Google для отрисовки графиков.

Рекомендуемый минимальный набор модулей для тест-плана

Рекомендуется включать в каждый новый тест-план следующие модули (по каждому из которых имеется система онлайн-помощи, достаточно нажать кнопку Help on this plugin):

 

1. В ветку WorkBench добавить HTTP Test Script reocorder, для первоначальной записи тестовый сценариев, если приложение работает с протоколом HTTP.

 

2. В ветку Test Plan добавить рандомайзер Uniform Random Timer со значением 100-200 мс.

 

3. В ветку Test Plan добавить HTTP Request Defaults для настройки запросов по умолчанию, если приложение работает с протоколом HTTP.

 

4. В ветку Test Plan добавить HTTP Cookie Manager, если приложение использует cookie.

 

5. В ветку Test Plan добавить нужное число Thread Group, которые выступают в качестве отдельных тест-кейсов, в которые нужно записывать данные от прокси-сервера.

 

6. В ветку Thread Group добавить стандартные табличные отчеты о результатах тестирования: Summary Report, View Results in Table, View Results Tree.

 

7. В ветку Thread Group добавить стандартные графические отчеты о результатах тестирования: Graph Results, Spline Visualizer.

 

8. В ветку Thread Group добавить графические отчеты jp@gc-плагина: jp@gc - Response Times Percentiles (показывает процентили доступа к данным), jp@gc - Response Times vs Threads(показывает изменение времени отклика в зависимости от числа запущенных потоков), jp@gc - PerfMon Metrics Collector (для получения данных по загрузке CPU, Memory, Swap, Disk I/O,Network I/O и других со стороны сервера от агентов JMeter).

 

9. В конец ветки Test Plan добавить Monitor Results для отслеживания состояния сервера во

время проведения теста.

Рекомендуемый набор модулей
Добавляем файл лога

  1. Правым кликом на Thread Group добавляем Access Log Sampler (Thread Group->Add->Sampler->Access Log Sampler)

  2. Заполняем данный для access.log

    1. Вбиваем адрес сервера (только доменное имя)

    2. Выбираем протокол: HTTP или HTTPS, вводится большими буквами

    3. Порт ставим 80

    4. Указываем путь к файлу access.log на вашем ПК

Альтернатива для Jmeter

HP Loadrunner - мощная тулза, пользующаяся признанием в некоторых компаниях. Явный ее минус в том что она дорогая. 

 

Siege - альтернативная бесплатная программа, аналогичная jmeter, можете прочитать ее подробное описание

​

Load impact - программа для нагрузочного через web интерфейс. Сервер сделает за вас все сам, на как всегда в таких случаях никакой гибкости.

​

Loadstorm - также тестирование через web сервис.

Практика и ДЗ

Вот инструкция для твоего практического задания:

​

1. Проверить, что на ПК установлена Java, в наше время она водится почти на любой машине. Если нет то скорее устанавливайте.

 

2. Установить себе программу JMeter

​

3. Создать access log сайта software-testing.ru/ Если access log пока пустой, нам ничто не мешает его слегка пополнить, пройдя сайт попавшимся под руку краулером, например HTTrack или Xenu. Если веб-сервер - IIS, то предварительно нужно переключить формат лога в NCSA, понимаемый парсером JMeter-а. Брать лог из-под работающего сервера (когда он туда пишет) не стоит, лучше взять уже закрытый, скажем, вчерашний, или приостановить веб-сервер на время выемки лога. Лог стоит посмотреть текстовым редактором на предмет корректности. Помощь в выполнении задания ты получишь от магистра дальше.

 

Результатом работы будут скриншоты графиков, таблиц

и лог файл с записями работы JMeter. Все нужно

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

​

Также необходимо провести базовый анализ ваших

результатов: 

в какой момент времени и при каком количестве

пользователей остановится рост производительности throughtputs, когда появятся первые http ошибки и когда 

они превысят порог в 3%. Вот пример отчета: скопируй его себе.

​

​

И конечно ты с нетерпением ждешь теста уровня

Генерируем log файл (список тестируемых страниц)

В данном задании, чтобы упростить его, мы не будет пользоваться каким либо сценарием, а просто нагрузим комплект доступных страниц сайта. Для этого необходимо добыть список список (карту) URL сайта. Так как современные сайты стали использовать защиту от сканирования, удобно пользоваться сканерами через аддон браузера. Например Link Klipper для  Сhrome. Это приложение просканирует доменный адрес и выдаст примерно такой список:

http://software-testing.ru/user/forgot.php
http://software-testing.ru//user/user_add.php
https://top100.rambler.ru/top100/
http://software-testing.ru/app/
https://www.facebook.com/gorod.dp.ua/
...

 

Ccылки на внешние сайты, аналогичные красным стоит удалить, иначе они испортят результат тестирования недостоверными данными. Затем делаем глобальную замену части «http://test.local» на «" GET» (с кавычкой и пробелом), получаем

"GET /index.php

"GET /news/event-12.php

...

​

Лучше пользоваться Notepad++ для подобной операции, так как ворд добавляет спецсимволы.

​

Обратите внимание, что доменное имя не указывается в ссылке, а только адрес внутренней ссылки. Сам же домен указывается в настройках Jmeter. Каждая ссылка должны быть с новой строки, документ в обычном текстовом формате.

Редактируем тест план

1. Открываем ApacheJMeter.jar

 

2. Слева наблюдаем дерево из 2 узлов: TestPlan и Workbench (про второй сразу забываем, он нам не понадобится). На Test Plan кликаем правым кликом и говорим Add->Thread Group (в интерфейсе можно увидеть много фишек разной степени полезности, но мы сейчас не отвлекаемся, а кратчайшим путем идем к нашему тесту, потом, если захотим — будем изучать обширные возможности JMeter подробнее).

Практическое задание
Генерируем log файл
Добавляем файл лога
Добавляем генераторы отчетов

Теперь добавляем в тест средства отображения:

    1. Thread Group->Add->Listener->View Results in Table

 

    2. Thread Group->Add->Listener->Graph Results

 

    3. Thread Group->Add->Listener->Aggregate Report

Во View Results in Table надо заполнить поле Filename (если не указывать путь, лог-файл образуется рядом с jmeter.bat). Создавать лог необходимо для отладки, так как JMeter в своем GUI толковой информации об ошибках не выводит.

 

Тест-план готов, переходим к его тестированию :) и отладке (ничего-ничего, он может и с первого раза заработать).

File->Save, и так каждый раз после внесения изменений в тест-план. Это важно, JMeter другой раз виснет, и тест приходится восстанавливать по памяти.

Run->Clear All (на первый раз можно не делать, но потом все равно понадобится).

Run->Start.

И идем смотреть во View Results in Table. Если нам повезло, там будет одна строчка, с зеленой галочкой в колонке Status.

Результат подготовки
Результат подготовки

Запускаем (File->Save, Run->Clear All, Run->Start). Идем смотреть во View Results in Table. Должно получиться как-то так:

Запускаем наконец-то тест

Прежде чем начать тест, добавим в начало сценария случайную задержку (Uniform Random Timer) 0-1000 миллисекунд, она обычно помогает несколько сгладить графики. Сценарий в результате работает так: ждет случайное количество миллисекунд, читает строку из лога, делает HTTP запрос, передает результаты листенерам, снова ждет, читает следующую строчку, и так далее.

 

Делаем первый, пристрелочный, тест. В свойствах группы потоков поставим: Number of Threads (users): 100, Ramp-Up Period (in seconds): 100. Мы собираемся натравить на сайт 100 виртуальных юзеров, вводя их в бой по одному в течении 100 секунд, то есть по юзеру в секунду. Цифры 100 и 100 я взял откуда-то с потолка, но надо же с чего-то начать.

 

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

File->Save, Run->Clear All, Run->Start и идем смотреть Graph Results. Видим, скажем, такую картинку

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

О чем говорит нам этот график? Среднее время отклика (Average) растет, а скорость обработки (Throughput) не меняется. Это значит, что где-то на сервере операции становятся в очередь, и производительности не хватает, чтобы обслужить все запросы. Зайдя браузером на сайт, убедимся, что он еле ворочается или вообще не респондит. Зачем зря мучить несчастного? Run->Stop. Ну вот, сайт снова ожил. Неудачная идея во время такого теста — отвлечься ненадолго и, вернувшись через несколько часов (как это бывает), обнаружить, что сайт полдня лежал.

 

В качестве содержательного результата мы получили одно число — максимальное значение Throughput (183 запроса в минуту). Можно считать его пределом производительности. Для начала этого числа может быть достаточно, например, уже ясно, что 100 000 хостов в сутки наш сайт не потянет.

Запуск теста
Анализ результатов теста

Проведем аналогичный тесты для другого сайте. Сейчас мы разберемся как точно понять когда наступает момент, перегрузки сервера. С помощью листенера View Table in Tree. Можно установить что первые сбои и 503 ошибки в система произошли при запущенных 31-34 потоках. Следовательно критичное количество активных пользователей для сервера примерно 35. Но при этом нужно понимать что активность тестовых пользователей значительно привышает активность реальных людей. Вряд ли кто то будет переходить по сайту со скоростью 1 страница в 2 секунды.

Анализ графика нагрузки

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

​

На Graph results можно посмотреть графики “отзывчивости” сервера

 

Значения предоставлены в миллисекундах:

Data — время отклика на каждый выполненный запрос.

 

Average — среднее время отклика сервера, объективный график нагрузки.

 

Throughput  — скорость выполнения самого запроса.

 

Median — значение медианы (используется в статистике, этими данными можно не пользоваться).

 

Deviation — погрешность, стандартное отклонение.

 

Кстати, пока jMeter “висит” – процесс тестирования обычно продолжается, что чревато неприятными последствиями, если тестируете рабочий сервер.

 

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

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

Анализ результатов теста

В Summary Report можно увидеть обобщённые данные и частоту сбоев при количестве пользователей


Нас интересуют тут такие метрики:

 

Samples - количество текущих потоков. Определит точку отсчета перегруза

 

Average - Средняя время отклика укажет на время срабатывания сайта во время нагрузки

 

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

 

Throughtput - скорость обработки запросов

​

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

Анализ реузльтатов
Итог. Ключевые моменты в анализе нагрузки

1. Сигналом о наступлении перегруженности сервера является то что среднее время отклика (Average) растет, а скорость обработки (Throughput) не меняется. Это значит, что где-то на сервере операции становятся в очередь и производительности не хватает, чтобы обслужить все запросы. Этот момент можно увидеть на графике Graf Results. В таком случае в выводах N-ном количестве пользователей. 

 

2. Второй метрикой является появление серверных ошибок - 503, 505, 404 и пр. Это значит, что сервер кроме того, что ставит запросы в очередь и не успевает их обрабатывать, начал часть запросов просто отклонять. Это уже критический перегруз. Его можно наблюдать в таблице View Results. В отчете указываем этот момент.

 

3. Третьей метрикой является процент ошибок при определенном количестве пользователей. Этот параметр находится в Summary Report. Его мы сравниваем с требованиями и вносим в отчет. В требованиях долен быть указан допустимый порог ошибок.

​

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

 

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

Акт выполненных работ по нагрузочному тестированию

Результаты нагрузочного тестирования обобщаются в акте выполненных работ. Если вам придётся выполнять нагрузочное тестирование на рабочем месте - воспользуйтесь этим шаблоном. В практическом задании заполнять этот отчет не нужно. Этот документ имеет следующую структуру:

​

1. Титульный лист "Акт выполненных работ по нагрузочному тестированию" с указанием:

Тестируемое приложение: указываем официальное название приложения.

Тестирование проводил: указываем инженеров, участвующих в тестировании.

Дата и время тестирования.

​

Этап тестирования: например, 1, 2, 3 этапы означают, какой по счёту раз проводится тестирование приложения, после внесения в него или в инфраструктуру изменений, или после изменения требований к производительности.

Версия документа: например, 1.0, которая указывает текущую модификацию акта в пределах одного этапа тестирования;

Дата составления отчета: указывается дата составления текущей версии документа.

Ответственное лицо: указывается ответственный за проведение тестирования и составление отчета (РП или нач. отдела).

2. Содержание.

 

3. Введение.

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

Указывается, какие основные функции, подсистемы или модули приложения тестировались.

Используемые инструменты тестирования: перечисляется весь инструментарий для проведения тестирования, например, apache-jmeter-2.7, JMeterPlugins-0.5.2, Selenium IDE-1.8.1.

Приложения: все артефакты тестирования, например, тест-план JMeter, .jtl-файлы с результатами, графики результатов измерений, скриншоты и т.п.

 

4. Цели и задачи. Например:

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

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

 

5. Термины и определения, используемые в отчете.

 

6. Инфраструктура Приложения.

IP-адрес: указывается ip-адрес или адреса серверов, где развернут тестовый стенд Приложения.

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

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

Инвентаризация ресурсов Приложения. В табличном виде описываются ресурсы приложения, представленные выше на схеме. Таблица включает в себя столбцы: № п/п, Ресурс, Hardware, Software.

 

7. Показатели производительности. Указываются измеряемые на данном этапе показатели и используемые для этого метрики. Например, показатели приведенные выше.

 

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

 

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

 

10. Описание методики тестирования. Кратко описываются подходы к проведению тестирования, рассказывается о подготовке тестового стенда, например, описание структуры bot-net, описание полезной нагрузки, принцип подбора тестов.

 

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

 

12. Анализ результатов тестирования, сведение результатов измерений в обобщенные таблицы, их сравнение с результатами предыдущего этапа тестирования (при необходимости). Сравнение результатов может быть приведено на графиках-гистограммах.

 

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

 

Акт выполненных работ
Дополнительные настройки которые могут понадобится

Можно настроить некоторые параметры плагинов путем редактирования файла %JMETER_HOME%bin\user.properties и добавить следующие строки в его конце:

# Включить или отключить градиент краски для графиков. Значение истина или ложь, по умолчанию это истина.

jmeterPlugin.drawGradient = True

 

# Глобально отключить окончательное обнуление линий на всех графиках. Значение истина или ложь, по умолчанию является ложным.

jmeterPlugin.neverDrawFinalZeroingLines = True

 

# Глобально отключить  отображение оси абсцисс  X  во всех интересующих графиках. Значение истина или ложь, по умолчанию является ложным.

jmeterPlugin.neverDrawCurrentX = True

 

# Включение или отключение  масштабирования оси Y для удобства чтения. Значение истина или ложь, по умолчанию это истина.

jmeterPlugin.optimizeYAxis = True

 

# Использовать относительное время во времени на основных графиках. Значение истина или ложь, по умолчанию это истина.

jmeterPlugin.useRelativeTime = True

 

# Выводить CSV разделитель. По умолчанию ',' если десятичный разделитель -  '.' ';'. В противном случае указать

Дополнительные настрйоки
Дополнительные настройки которые могут понадобится

 

JmeterPlugin.csvSeparator =;

 

# Выводить CSV формат времени (см.http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html)

jmeterPlugin.csvTimeFormat=HH:mm:ss

 

# Префикс или нет пунктов плагина в меню JMeter. Значение истина или ложь, по умолчанию это истина.

jmeterPlugin.prefixPlugins = True

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

Опции drawGradient, neverDrawFinalZeroingLines, neverDrawCurrentX, useRelativeTime могут быть динамически изменены с помощью панели настроек (SettingsPanel) соответствующего модуля.

​

Полезная литература:

Как надо и не надо проводить нагрузочное тестирование

​

Уровень 18

Для перехода на уровень 18, необходимо набрать минимум 16,8 баллов (60%)  за задания уровня 17.

​

bottom of page