понедельник, 4 марта 2013 г.

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

Структура статьи:

1. Основные понятия нагрузочного тестирования


Вводная статья в нагрузочное тестирование: http://blog.shumoos.com/archives/98. 
Нагрузочное тестирование (или тестирование производительности, Performance testing) - это автоматизированное тестирование, имитирующее работу определенного количества пользователей в приложении. Нагрузочное тестирование имеет целью выяснить граничные условия нагрузки на систему, при которой она продолжает работать стабильно и с приемлемым временем отклика, а также оценить способность системы правильно функционировать в случае превышении планируемых нагрузок.
Более конкретно выделяют следующие виды нагрузочного тестирования:
  • Тестирование производительности – измеряется скорость работы системы при идеальных условиях и максимальной нагрузке.
  • Нагрузочное тестирование – это те же тесты производительности, но в которых система подвергается различным нагрузкам.
  • Объемное тестирование – приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.
  • Стресс тестирование – поведение системы при недостатке ресурсов (ресурсов процессора, дискового пространства, обрывов сети и т.п.).
Штатный режим работы – приемлемые параметры режима работы приложения, например, количество одновременно работающих с web-приложением пользователей.
Пиковая нагрузка – кратковременная работа сервера и web-приложения с превышением штатного количества пользователей.
Тип подключения – равномерное (в течение некоторого периода) или пиковое (одновременное, быстрое) подключение пользователей к серверу web-приложения.
Профиль нагрузки (Load Profile) – это набор операций с различными интенсивностями нагрузки, определенный путем анализа требований к тестируемой системе.

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

  1. Определение целей тестирования, разработка профилей нагрузки.
  2. Установка и настройка bot-net для распределенного тестирования (при необходимости).
  3. Запись CRUD-теста Selenium в качестве полезной нагрузки, для упрощения подготовки тест-плана.
  4. Настройка и отладка нагрузочных тестов в JMeter.
  5. Многократное воспроизведение нагрузочных тестов в соответствии с профилями нагрузки.
  6. Анализ результатов и формирование отчёта по разработанному шаблону.

3. Проведение тестирования при помощи JMeter

Рекомендуется ознакомиться с вводными статьями по использованию JMeter:

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

  1. Скачать и установить JDK 6: http://www.oracle.com/technetwork/java/javase/downloads/index.html
  2. Добавить переменную окружения JAVA_HOME и установить ей значение - каталог с JDK, например, JAVA_HOME='c:\Program Files (x86)\Java\jdk1.6.0_27\'
  3. Добавить в значение переменной окружения Path строку: ;%JAVA_HOME%bin
  4. Скачать Apache JMeter по ссылке: http://jmeter.apache.org/download_jmeter.cgi и распаковать. Нежелательно переименовывать поддиректории JMeter.
  5. Добавить переменную окружения JMETER_HOME и установить ей значение - каталог с JMeter, например, JMETER_HOME='c:\apache-jmeter-2.7\'
  6. Добавить в значение переменной окружения Path строку: ;%JMETER_HOME%bin
  7. Скачать jp@gc-плагины по ссылке: http://code.google.com/p/jmeter-plugins/downloads/list, например, JMeterPlugins-0.5.3, и распаковать.
  8. Скопировать файл JMeterPlugins.jar из каталога с распакованным jp@gc-плагином в каталог %JMETER_HOME%lib\ext.
Для проверки работоспособности JMeter GUI и плагинов, можно запустить IDE из каталога %JMETER_HOME%bin, файл jmeter.bat (или jmeter.sh для Linux). Подключенные jp@gc-плагины должны быть доступны при добавлении в тест-план JMeter (пункт меню Edit - Add).
Дополнительные пользовательские настройки
Можно настроить некоторые параметры плагинов путем редактирования файла %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) соответствующего модуля.

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


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

Для использования модулей PerfMon Metrics Collectors из jp@gc-плагина, которые снимают показатели нагрузки на стороне сервера, необходимо также запустить сервер-агент JMeter на всех серверах, участвующих в измерении (сервера приложения, БД и прочих). Для этого требуется:
  1. Скопировать каталог serverAgent из каталога с jp@gc-плагинами на сервер, нагрузку на который требуется измерять.
  2. Для Windows-серверов запустить файл startAgent.bat. Для Linux-серверов запустить startAgent.sh, предварительно дав права на запуск командой
    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.

3.2.2. Настройка стандартного монитора состояния сервера Monitor Results

Для использования стандартного монитора состояния сервера Monitor Results, который показывает загрузку сервера в процессе тестирования, необходимо:
  1. Добавить в тестплан модуль монитора (Add Listener - Monitor Results).
  2. Добавить в начало ветки Thread Group с командами теста, элемент HTTP Authorization Manager для авторизации в админке web-сервера (Add - Config Element - HTTP Authorization Manager).
  3. Добавить новую строку авторизации (кнопка Add) с параметрами: Base Url - ip web-сервера, например, http://10.10.31.14:8080, Username - логин пользователя web-сервера, Password - пароль. Нажать Save.
  4. Добавить в ветку Thread Group, после элемента HTTP Authorization Manager, новый HTTP Request, для настройки монитора.
  5. Указать параметры HTTP Request: Server Name or IP - путь к web-серверу, Port Number - порт web-сервера, например, 8080, Path - путь к служебной страничке web-сервера, например, для Tomcat нужно указать /manager/status, в таблицу Parameters добавить строку и указать в столбце Name: XML, в столбце Value: true, внизу странички запроса выделить чекбокс Use as Monitor.
После этого, при запуске теста, в элементе Monitor Results будут отображаться данные о состоянии сервера при нагрузке. Monitor Results работает только для Tomcat 5 или более поздней версии.
Есть две основных вклади для монитора:
  • Health - показывает состояние одного или нескольких серверов на текущий момент измерений. Здесь указыавется загрузка сервера и его состояния (Healthy - нормальное состояние, Active - сервер обрабатывает полученные данные, Warning - сервер перегружен, Dead - от сервера нет отклика).
  • Performance - тиковый график, который показывает производительность на одном сервере в течение последних 1000 операций.
Этот монитор может использоваться для определения момента окончания тестирования, например, когда он перегружен. Либо для определения момента пиковой загрузки. Как правило, сервер "падает" если не хватает памяти или достигнуто максимальное число потоков. Именно на это и указывает параметр Health. Если линии на графиках Performance имеют резкие скачки, это может указывать на недостатки текущей производительности. Параметры Busy Time, Max Time монитор получает с сервисной странички Tomcat: /manager/status. Они указывают на максимальное время обработки операций сервером и текущие показатели времени обработки по измерениям Tomcat. Там же указываются данные о числе потоков Busy Thread, Max Thread. Чем ближе текущее время отклика к максимально допустимому, тем меньше производительность сервера и больше вероятность его отказа.

3.2.3. Распределенное многопоточное тестирование нагрузки при помощи JMeter bot-net

Настройки для Windows-серверов JMeter, которые должны дублировать нагрузку:
  1. Запустить файл %JAVA_HOME%bin\rmiregistry.exe
  2. В файле %JMETER_HOME%bin\jmeter.properties снять комментарий со строки server.rmi.create=false, удалив символ «#» вначале строки.
  3. Запустить %JMETER_HOME%bin\jmeter-server.bat
При каждом запуске теста необходимо предварительно запускать всех агентов. Агенты должны находиться в одной локальной сети с клиентом JMeter.
Настройки для клиента JMeter, который принимает результаты измерений:
  1. В файле %JMETER_HOME%bin\jmeter.properties указать хосты в строке remote_hosts. Например: remote_hosts=10.18.11.101, 10.18.11.233, 10.18.11.81
  2. Перезапустить JMeter.
  3. Выбрать пункт меню Run - Remote Start или Run - Remote Start All. Remote Start запускает одного выбранного агента, Remote Start All запускает всех указанных агентов сразу.
Для запуска нескольких потоков тестов из консоли необходимо:
  1. В тестплане JMeter в настройках Thread Group указать значение Number of Threads(users) равным ${__P(group1.threads)}
  2. Скопировать тестплан в каталог %JMETER_HOME%bin и запустить тест, например, командой:
    jmeter.sh -n -t tp.jmx -Jgroup1.threads=3
Аналогичные действия выполняются для Linux-серверов JMeter.

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

Для упрощения создания тест-плана JMeter нужно использовать комплект End-to-end-сценариев тестов в Selenium, действия в которых и будут использоваться для записи нагрузочных тестов. Все действия с тестами можно выполнять в ветке тестплана Thread Group.
Чтобы добавить Thread  Group нужно из контекстного меню элемента Test Plan выбрать Add - Thread Group. Элемент Thread Group позволяет задавать параметры генерируемой на приложение нагрузки. Основными его параметрами являются:
  • Number of threads - количество имитируемых пользователей одновременно работающих с сайтом;
  • Ramp-up period  - промежуток времени, через который выполняется запуск очередного процесса;
  • Loop count - количество раз, которое будет выполняться сценарий внутри Thread Group;
  • Forever - сценарий будет выполняться всегда, пока не будет прерван явно;
  • Scheduler - планировщик времени работы сценария;
  • Action to be taken after a Sample Error - действие, выполняемое в случае, если запрос вызовет ошибку.
Только внутрь элемента Thread Group можно добавлять элементы запросов типа HTTP Request, FTP Request, Web Service Request и т.п. Кроме того, в Thread Group можно добавлять различные контроллеры. Например, Recording Controller (контекстное меню Thread Group: Add - Logic Controller - Recording Controller). Данный элемент можно выбирать в модуле прокси-сервера.
Запись тест-кейсов в JMeter осуществляется с помощью элемента HTTP Proxy Server. Для работы с ним необходимо:
  • в контекстном меню элемента тест-плана WorkBench выбрать Add - Non-Test Elements - HTTP Proxy Server;
  • указать порт прокси-сервера в поле Port;
  • в браузере установить настройки прокси-сервера какие же, как и для HTTP Proxy Server (например, в Mozilla выбрать Tools - Options - Network - Settings... - Connection Settings);
  • нажать кнопку Start для записи команд нагрузочного теста в элементе HTTP Proxy Server;
  • указать в качестве Target Controller некоторый Thread Group или Recording Controller, которые выступают в качестве тест-кейса;
  • пройти тест-сценарий;
  • нажать кнопку Stop в элементе HTTP Proxy Server.
Для визуализации и логирования результатов тестирования в JMeter реализованы Слушатели (Listeners). Слушатели могут быть нескольких типов:
  • Graph Full Results - отображение результатов теста в виде графика;
  • Graph Results - отображение основных (отклонения, средние величины) результатов теста в виде графика;
  • Spline Visualizer  - отображение результатов теста в виде графика с усредненными (сглаженными) значениями.
Для этого в группу потоков Thread Group необходимо добавить элемент Listener. Для этого из контекстного меню Thread Group нужно выбрать Add - Listener. Раскрывается список слушателей. Среди них должны присутствовать как стандартные, так и дополнительные графические jp@gc-плагины от Google для отрисовки графиков.
Для оптимизации ввода повторяющихся данных (например, если необходимо протестировать несколько сервисов, размещенных на одном сайте) существует возможность задать настройки по умолчанию. Для этого в группу потоков Thread Group необходимо добавить элемент HTTP Request Defaults. Для этого из контекстного меню нужно выбрать Add - Config Element - HTTP Request Defaults. Все последующие элементы HTTP Request будут брать указанные здесь настройки по умолчанию. В этих настройках можно задать:
  • Server Name or IP - адрес веб-сервера (URL или IP-адрес);
  • Port Number - порт веб-сервера (по умолчанию 80);
  • Protocol (default http) - протокол (по умолчанию HTTP);
  • Path - путь к запускаемому файлу на сервере;
  • Send Parameters with request - передаваемые параметры и их значения.
Чтобы сохранять cookie для каждой новой сессии работы с приложением, необходимо добавить в ThreadGroup элемент HTTP Cookie Manager.
В начало тестплана можно добавить случайную задержку Uniform Random Timer 0-1000 миллисекунд, которая помогает сгладить графики и имитирует различную скорость отправки запросов от пользователя. Сценарий в результате работает так: ждет случайное количество миллисекунд, читает строку из теста, делает HTTP-запрос, передает результаты обработчикам, снова ждет, читает следующую строчку и так далее.

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

Рекомендуется включать в каждый новый тест-план следующие модули (по каждому из которых имеется система онлайн-помощи, достаточно нажать кнопку Help on this plugin):
  1. В ветку WorkBench добавить HTTP Proxy Server, для первоначальной записи тестовый сценариев, если приложение работает с протоколом 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 для отслеживания состояния сервера во время проведения теста.
Приведённый набор модулей добавлен в шаблон тест-плана jmeter_test_plan_template.jmx, который можно скачать по адресу:


3.4. Отладка, тестирование и сохранение результатов

В записанный через прокси-сервер тест-план попадает много "лишних" обращений, таких как запросы к другим серверам, поиск ненужных элементов, картинок и т.п. Эти запросы можно убрать из тестплана и оставить только те запросы (часто *.rpc), которые нужны для проверки нагрузки на конкретный объект тестирования (подсистему, модуль, отдельную страничку и т.п.).
Кроме того, тест-план нужно перезаписывать каждый раз заново, если приложение изменялось, так как запросы также могут измениться.
Процесс отладки
  1. При внесении изменений в тест-план, его необходимо сохранять через пункт меню File - Save.
  2. Для запуска и прогонки теста нужно выбрать пункт меню Run - Start, предварительно указав в настройках Thread Group число пользователей 1.
  3. После прогонки теста результат можно посмотреть в модуле View Results in Table. В случае успеха в таблице будет поле Status с зеленой галочкой, иначе - в Status будет ошибка.
  4. При ошибках нужно перейти в модуль View Results Tree и выяснить, какие запросы вызывают ошибку. Затем, если возможно, соответствующий запрос нужно исправить или удалить из тест-кейса.
  5. Для очистки результатов предыдущего тестирования нужно выбрать пункт меню Run - Clear All.
  6. Повторять предыдущие шаги до тех пор, пока тест не будет пройдет успешно.
Сохранение результатов тестирования
Для того, чтобы можно было повторно использовать результаты тестов, необходимо перед их запуском в некотором элементе мониторинга в поле Filename указать имя лог-файла. Для сохранения результатов нагрузочного теста можно выбрать файлы формата *.jtl или *.csv. В элементах мониторинга jp@gc - PerfMon Metrics Collector можно также сохранить графики через контекстное меню на вкладке Сhart.
После прогона нагрузочного теста результаты сохраняться в лог-файле, который затем можно загрузить при помощи кнопки Browse в соответствующем элементе мониторинга.
Тест, с указанием лог-файла, можно запускать в консоли. Для запуска теста в консоли на Windows-машине можно использовать команду:
jmeter.bat -n -t tp.jmx -l log.jtl
где tp.jmx - файл с некоторым тест-планом, log.jtl - некоторый лог-файл.
Для запуска теста в консоли на Linux-машине можно использовать команду:
jmeter.sh -n -t tp.jmx -l log.jtl
После запуска теста с помощью этих команд, сохраняются также и результаты мониторинга на стороне сервера от элементов jp@gc - PerfMon Metrics Collector в файл с расширением *.jppm
Для того чтобы загрузить результаты теста в GUI, необходимо скопировать файл с тест-планом, лог-файл от Jmeter в каталог bin и запустить JMeter:
jmeter.sh -t tp.jmx
Лог-файл можно загрузить при помощи кнопки Browse в соответствующем элементе мониторинга.
Посмотреть список всех возможных опций запуска JMeter в консольном режиме возможно командой:
jmeter -h

4. Профили нагрузки и измеряемые показатели

Возможно использовать варианты следующих профилей нагрузки:
  1. Один пользователь в системе. Может быть проведен с целью определения базовых показателей работы системы без нагрузкии и использоваться для сравнения.
  2. Штатный режим работы. Одновременная работа в системе максимального требуемого числа пользователей.
  3. Пиковая нагрузка. Скачкообразное увеличение нагрузки с кратковременным превышением максимального требуемого числа пользователей.
  4. Равномерное увеличение нагрузки. Имитация постепенного увеличения количества подключений с превышением максимального требуемого числа пользователей.
При нагрузочном тестировании серверов можно измерять следующие показатели.
Измеряемые при помощи JMeter:
  1. Среднее время прохождения набора тестов – время, в течение которого проходили отобранные тесты.
  2. Число операций – количество операций выполненных сервером, фактически это количество принятых от JMeter и обработанных пакетов данных.
  3. Число потоков – число открытых JMeter потоков при подключении к серверу, фактически это количество подключившихся пользователей.
  4. Среднее время доступа к данным – время, в течение которого JMeter получает отклик от сервера web-приложения на отправленный запрос и начинает принимать ответные данные. Фактически это время ожидания пользователем ответных результатов от web-приложения на свои запросы.
  5. 90-й процентиль времени доступа к данным – это такое значение времени доступа в мс., что при распределении времени доступа по возрастанию для всех принятых данных, 90% времени доступа попадает ниже этого значения. Таким образом, время доступа к «большинству» загружаемых при проведении тестов данных находится ниже 90-го процентиля.
  6. Максимальная общая загрузка процессоров – максимальная общая загруженность процессоров сервера во время выполнения группы тестов, %.
  7. Максимальная общая загрузка памяти – максимальная общая загруженность памяти сервера во время выполнения группы тестов, Мб.
  8. Ошибки подключения (отказы) – отношение числа успешных, выполненных запросов, к числу отказов в обработке запросов, %.
Измеряемые при помощи serverAgent, установленного на тестируемом сервере:
  1. Загрузка процессора (CPU) – график загруженности процессоров сервера (Combined CPU usage) во время выполнения теста, %.
  2. Загрузка памяти (Memory) – график загруженности оперативной памяти сервера (Combined CPU usage) во время выполнения теста, Мб.
  3. Загрузка файла подкачки (Swap) – график загруженности системного файла подкачки сервера (Number of pages/sec) во время выполнения теста, страниц/сек.
  4. Загрузка дисковой подсистемы (Disks I/O) – график загруженности жесткого диска сервера (Number of disks access/sec) во время выполнения теста, кол во обращений/сек.
  5. Загрузка сети (Networks I/O) – график загруженности сетевого адаптера сервера (Number of Kbytes/sec) во время выполнения теста, Кб/сек.
Измеряемые при помощи Monitor Results, который использует данные Busy Time, Max Time, Busy Thread, Max Thread, Used Memory, Total Memory, Max Memory, полученные от сервисной странички Tomcat:
  1. Относительный показатель производительности "Здоровье" (Health) – динамика изменения параметра Health во время выполнения теста, который показывает отношение текущего времени обработки операций к максимальному, Busy Time / Max Time, %.
  2. Относительный показатель производительности "Загрузка" (Load) – динамика изменения параметра Load во время выполнения теста,  который который вычисляется по формуле: 50*(Busy Time / Max Time) + 50*(Used Memory / Max Memory), %.
  3. Относительный показатель производительности "Память" (Memory) – динамика изменения параметра Memory во время выполнения теста, который показывает отношение используемой памяти к выделенной Tomcat (Used Memory / Total Memory), %.
  4. Относительный показатель производительности "Доступность подключений" (Thread) – динамика изменения параметра Thread во время выполнения теста, который показывает отношение текущего количества занятых потоков к максимальному, Busy Thread / Max Thread, %.
Используя средства СУБД, дополнительно для серверов БД можно измерять показатели:
  1. Интенсивность SQL-запросов (операции SELECT, INSERT, UPDATE, DELETE) в единицу времени, запросов/сек.
  2. Текущее количество открытых подключений, кол-во.
  3. Задержка репликации, мс.
  4. Частота обращения к кешу БД, кол-во обращений/сек.
Используя программы профилировщики и сборщики статистики на прикладном уровне можно измерять показатели:
  1. Генерирование страниц приложения, сек.
  2. Статистика обращения к страницам.

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

Результаты нагрузочного тестирования обобщаются в акте выполненных работ. Этот документ имеет следующую структуру:
  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. Общие выводы и рекомендации. По результатам нагрузочного тестирования и анализа данных делается вывод о работоспособности приложения под нагрузкой. Например, при каком количестве потоков (подключений пользователей) и режиме нагрузки, оно показывает устойчивую работоспособность. Приводятся рекомендации по обеспечению приемлемой работы пользователей. Выносятся предложения для повышения производительности приложения и обеспечения комфортной работы требуемого числа пользователей.
Шаблон акта выполненных работ Performance_testing_Step_1_ver_1_0_Template.doc, содержащий указанную структуру, можно скачать здесь:
https://docs.google.com/open?id=0B-1rf8K04ZS5cFRDQmd0RV9UVU0
Пример одного из отчётов perfomance_testing_example_2011.pdf, созданный на основе данной структуры, можно скачать здесь:
https://docs.google.com/open?id=0B-1rf8K04ZS5bFpMSFc3OGNKN2s
    Автор: на
    Ярлыки: , , , ,