Performance Testing Strategy Template by Egor B Eremeev

24 страниц
Дата: дд/мм/гггг
Версия: 0.5
Статус: предварительная версия
Заказчик:
Исполнитель:
Методика тестирования
производительности
Наименование проекта

НАИМЕНОВАНИЕ ПРОЕКТА
2
МЕТОДИКА ТЕСТИРОВАНИЯ ПРОИЗВОДИТЕЛЬНОСТИ
Листсогласования
№ Сторона Согласующий Дата
согласования
Форма
согласования
1
2
3
4
5

3
Листизменений
Версия Описание изменения Автор Дата
0.1 Документбыл создан.
Подготовлен Раздел 3 Модель нагрузки
Е. Еремеев
0.2 Подготовлены Приложение 1 Профиль нагрузки по
входящим КД, Приложение 2 Профиль нагрузки по
операциям пользователей
Е. Еремеев
0.3 Подготовлен Раздел 4 Проведение тестирования,
4.1Тестирование производительности
Е. Еремеев
0.4 Подготовлен Разделы
 4.2 Тестирование отказоустойчивости.
 4.3 Условия тестирования
 4.4 Требования к среде тестирования
 4.5 Измерение характеристик
Подготовлен Раздел 5 Структура нагрузочных
скриптов.
Е. Еремеев
0.5 Добавлен Раздел 6 Требования к Заказчику Е. Еремеев

4
Содержание
Лист согласования .................................................................................................................... 2
Лист изменений......................................................................................................................... 3
Термины,определения и сокращения.............................................................................................. 6
1. Цель разработки и область применения ...................................................................... 7
2. Общая информация ................................................................................................... 7
3. Модель нагрузки......................................................................................................... 7
3.1 Объекты на грузки ...................................................................................................... 8
3.2 Источники нагрузки..................................................................................................... 8
3.3 Процессы нагрузки ..................................................................................................... 8
3.4 Характеристики производительности........................................................................... 8
3.5 Характеристики отказоустойчивости ............................................................................ 9
3.6 Факторы, влияющие на измеряемые характеристики производительности и
отказоустойчивости ............................................................................................................... 10
4. Проведение тестирования ........................................................................................ 11
4.1 Тестирование производительности............................................................................ 11
4.1.1 Раунды нагрузочных тестов....................................................................................... 12
4.1.1.1 Раунд 0............................................................................................................. 14
4.1.1.2 Раунды 1-7........................................................................................................ 14
4.1.1.3 Раунд 8............................................................................................................. 14
4.2 Тестирование отказоустойчивости............................................................................. 15
4.2.1 Раунды нагрузочных тестов....................................................................................... 15
4.2.1.1 Раунд 1............................................................................................................. 16
4.2.1.2 Раунд 2............................................................................................................. 16
4.2.1.3 Раунд 3............................................................................................................. 16
4.2.1.4 Раунд 4............................................................................................................. 16
4.3 Условия тестирования .............................................................................................. 17
4.3.1.1 Конфигурация 1 - Отладка................................................................................. 17
4.3.1.2 Конфигурация 2- Тестирование Релиз 1 ............................................................. 17

5
4.3.1.3 Конфигурация 3- Тестирование Релиз 2 ............................................................. 18
4.3.1.4 Конфигурация 4- Тестирование стабильности..................................................... 19
4.4 Требования к среде тестирования ............................................................................. 20
4.4.1 Среда Web-кабинет .................................................................................................. 20
4.4.1.1 Каналы передачи .............................................................................................. 20
4.4.2 Среда инструментария тестирования ........................................................................ 21
4.4.2.1 Генераторы нагрузки ......................................................................................... 21
4.4.2.2 Каналы передачи .............................................................................................. 21
4.5 Измерение характеристик производительности.......................................................... 21
5. Структура нагрузочных скриптов............................................................................... 21
5.1 Инструментарий для разработки скриптов ................................................................. 22
5.1.1 Общие сведения....................................................................................................... 22
5.1.2 Настройка среды тестирования ................................................................................. 23
6. Требования к Заказчику............................................................................................ 23
7. Приложение 1 .......................................................................................................... 23
8. Приложение 2 .......................................................................................................... 23
9. Приложение 3 .......................................................................................................... 24

НАИМЕНОВАНИЕ ПРОЕКТА МЕТОДИКА ТЕСТИРОВАНИЯ ПРОИЗВОДИТЕЛЬНОСТИ
6
Термины, определения и сокращения

7
1. Цельразработкииобластьприменения
Данный документ описывает методику тестирования производительности и
отказоустойчивости разрабатываемого решения проекте Наименование проекта, а
именно документ описывает модель и средства создания нагрузки на систему во время
тестирования, характеристики производительности, измеряемые в ходе тестирования,
порядок подготовки и выполнения нагрузочных тестов.
Данный документ является дополнением и неотъемлемой частью документа Программа и
методика испытаний. Методика тестирования производительности, описанная в
настоящем документе, применяется на уровнях Системное тестирование и Приемочное
тестирование в соответствие с ПМИ.
2. Общаяинформация
Целью тестирования производительности и отказоустойчивости является получение
данных о характеристиках производительности и отказоустойчивости следующих систем:
 WEB-кабинет – в рамках определяемых Архитектурным документом.
Конкретная версия системы, в отношении проводится тестирование,
идентифицируется:
 Веткой исходного кода в репозитарии для настоящего проекта - <URL>, ветка <ID>
 Номером сборки из этой ветки установленной в текущий момент на тестовом
стенде
Процедура сборки и установки на тестовый стенд находится в зоне ответственности
Заказчика.
Тесты производительности и отказоустойчивости, учитывают аспекты, касающиеся
работы подсистем Web-кабинета, характер их взаимодействия в рамках бизнес-
процессов, а также характер интерфейсов взаимодействия WEB-кабинета с внешними
системами Заказчика.
Тестирование проводятся на специально подготовленной тестовой среде, которая будут
учитывать основные факторы, влияющие на демонстрируемую системой
производительность. Подробно эти факторы описаны в разделе Модель нагрузки
На тестовой среде работа пользователей и функционирование внешних систем через ИШ
будет имитироваться с помощью нагрузочных скриптов. Подробно инструментарий
тестирования описан в разделе Структура нагрузочных скриптов.
Тестирование производительности включает выполнение ряда тестов, часть из которых
выполняются последовательно, часть независимо друг от друга. Условия выполнения у
тестов могут быть различными. Также в каждом из тестов измерению подлежат
различные характеристики, в зависимости от целей теста и объектов нагрузки. Подробно
условия и порядок проведения тестов описаны в подразделах раздела Проведение
тестирования.
3. Модельнагрузки
Поскольку на тестовой среде не осуществляются реальные процессы работы с
тестируемыми системами, то стоит задача воспроизвести с помощью скриптов как можно
более приближенный к реальному (прогнозируемому) характер нагрузки на системы.
Модель нагрузки отражает основные принципы решения этой задачи.

8
3.1 Объектынагрузки
Объектами нагрузки в ходе тестирования являются следующие подсистемы WEB-
кабинета
 Презентационный модуль, с точкой входа нагрузки на Балансировщике нагрузки.
Прокси сервер осуществляющий https-дешифрование не включается в контур
нагрузки, ввиду того, что данное звено администрируется Заказчиком и не входит
в состав WEB-кабинета.
 Модуль бизнес-логики
 Модуль интеграции и бизнес-процессов
 Адаптеры систем, в частности адаптера модуля управления документами.
3.2 Источникинагрузки
Источником нагрузки являются
 Пользователи, работающие в WEB-кабинет
 Система, направляющая входящие сообщения о КД
3.3 Процессынагрузки
Процесс нагрузки на WEB- кабинет осуществляется:
 В ходе обработки Модулем интеграции и бизнес-процессов и Модулем бизнес-
логики уведомлений, поступающих в АРМ Депонента. Перечень уведомлений
приведен в документе Требования.
 В ходе обработки Презентационным модулем запросов пользователя и
подготовки данных для отображения на ЭФ.
 В Презентационном модуле, Модуле бизнес-логики и Модуле интеграции и
бизнес-процессов в ходе отправки депонентом инструкций по иностранным КД.
 В ходе обработки Презентационным модулем и Адаптером модуля управления
документами вложенных файлов
3.4 Характеристикипроизводительности
Производительность WEB-кабинет складывается как совокупность характеристик
демонстрирующих возможности систем в различных аспектах. Некоторые из
характеристик могут быть взаимозависимыми. В рамках модели рассматриваются
следующие характеристики представленные ниже. Правила их расчета и средства
измерения описаны в этом разделе:
Код Характеристика
Описание Единица
измерения и
критерий оценки
ХП1 Правильность
обработки данных
Это способность систем сохранять
функциональную работоспособность в
процессе нагрузки. То есть каждой
бизнес операции инициированной или
пользователем, или внешней системой
должны быть получены конечные
Доля ошибок от
общего числа
обработанных
сообщенийзапросов
не должна
превышать 5%

9
результаты (например,
зарегистрированы новые КД, выгружены
сообщения с инструкциями по КД и т.д.).
ХП2.1 Интенсивность
обработки входящих
сообщений с
уведомлениями о КД.
Количество сообщений с
уведомлениями о КД в единицу времени
при которой удовлетворяется ХП1, т.е.
не превышается порог допустимой доли
ошибок в обработке сообщений,
запросов.
Кол-во уведомлений
в час
не должно быть
меньше Vmin =
ХП2.2 Время обработки
входящего сообщения
с уведомлением о КД
Среднее и максимальное время
отработки задействованных сервисов
Модуля бизнес-логики и Модуля
интеграции и бизнес-процессов
мсек
больше Tmax =
ХП3.1 Число одновременно
работающих
пользователей в АРМ
Депонента
Количество пользователей с ролью
Депонент одновременно выполняющих в
WEB-кабинет действия на ЭФ
«Корпоративные действия», группе
закладок «Параметры КД», ЭФ ЖЦ
Инструкций, при которой
удовлетворяется ХП1, т.е. не
превышается порог допустимой доли
запросов.
Количество
пользователей
меньше Nmin =
ХП3.2 Время отклика ЭФ
«Корпоративные
действия» и группе
закладок «Параметры
КД», ЭФ в ЖЦ
инструкций
Это время между оправкой
пользовательского запроса из прокси-
сервером осуществляющем
дешифрацию https на Балансировщик
нагрузки WEB-кабинет получением от
него ответа.
мсек
больше Tmax =
ХП4 Интенсивность
формирования
исходящих сообщений
с Инструкциями.
Количество сообщений с инструкциями
по КД в единицу времени, при которой
удовлетворяется ХП1, т.е. не
превышается порог допустимой доли
запросов.
Количество
сообщений в час
меньше Vmin =
ХП5 Использование
аппаратных ресурсов
Список характеристик отражающих
степень использования WEB-кабинет
аппаратных ресурсов в процессе
нагрузки см. в Приложении 3.
см. в Приложении 3.
ХП6 Стабильность
системы
Способность системы в течение полного
характерного периода и в заданном
режиме нагрузки демонстрировать
удовлетворение ХП1, т.е. не
превышение порога допустимой доли
запросов.
Полный
характерный период
= 21 час
3.5 Характеристикиотказоустойчивости
Отказоустойчивость WEB-кабинет проявляется как совокупность характеристик,
демонстрирующих возможности системы сохранять доступность и функциональность в

10
условиях отказов ее отдельных компонентов. Некоторые из характеристик могут быть
взаимозависимыми. В рамках модели рассматриваются следующие характеристики
представленные ниже. Правила их расчета и средства измерения описаны в этом
разделе:
Код Характеристика
Описание Единица
измерения и
критерий оценки
ХО1 Правильность
обработки данных
Это способность систем сохранять
функциональную работоспособность в
условиях отказа компонентов. То есть
каждой бизнес операции
инициированной или пользователем,
или внешней системой должны быть
получены конечные результаты
(например, зарегистрированы новые КД,
выгружены сообщения с инструкциями
по КД и т.д.).
Доля ошибок от
общего числа
обработанных
сообщенийзапросов
не должна
превышать 5%
3.6 Факторы,влияющиенаизмеряемыехарактеристикипроизводительностии
отказоустойчивости
Процессы нагрузки могут протекать в существенно различных условиях, при этом
демонстрируемая системой производительность также будет существенно различаться.
Поэтому говорить о какой-либо определенной производительности системы имеет смысл,
только однозначно зафиксировав такие условия и лишь затем измеряя характеристики
производительности и отказоустойчивости. Для этого в целях нагрузочного тестирования
фиксируется Режим нагрузки, определяемый заданием значений следующих параметров:
Код Параметр
режима нагрузки
Описание Накладываемые условия
П1 Готовность кода
систем
Если часть функциональности не
реализована, либо в ней имеются
дефекты, то невозможно
говорить о производительности в
отношении этих частей систем.
Тестирование
проводится в отношении бизнес
операций, по которым
функциональность не будет
менять после проведения
тестов.
П2 Характерный
период нагрузки.
Время непрерывной работы
систем, в течение которого
 бизнес-процессы проходят
свой полный жизненный
цикл.
 измеренные характеристики
производительности лежат в
интервале ±3σ от среднего
значения
Полный характерный период =
21 час
Измеренные характеристики
производительности лежат в
интервале ±3σ от среднего
значения
П3 Профиль нагрузки
по входящим КД
Набор входящих сообщений о КД
и распределение их в течение
характерного периода нагрузки
Задается Картой загрузки КД в
Приложении 1.
Карта загрузки отражает, ,
набор КД по видам и типам и их,
распределение по времени

11
поступления в WEB-кабинет.
П4 Профиль нагрузки
по операциям
пользователей
Распределение числа
одновременно работающих
пользователей в течение
характерного периода нагрузки и
их распределение по
выполнению операций на ЭФ
«Корпоративные действия»,
группе закладок «Параметры КД»
и ЭФ ЖЦ направления
Инструкций
Задается Картой операций в
Приложении 2.
Карта операций задает,
распределение пользователей
по времени входа, по
операциям, выполняемым
после подключения. Также
задает распределение
выполняемых пользователями
операций по времени.
П5 Состояние
настроек систем.
Включают настройки
балансировщиков, WL, SOA Suite,
БД и др.
Тестирование будут
проводиться с настройками
максимально совпадающими с
настройками при эксплуатации
WEB-кабинет.
П6 Состояние и
содержимое БД
WEB-кабинет,
SOA Suite и БД
Хранилища
документов
Объем БД существенно может
повлиять на производительность
в отношении как
пользовательских, так и
внутрисистемных операции.
Также приближенность данных к
реальным (атрибуты КД,
состояния счетов, связи между
сущностями и т.п.) даст более
адекватную оценку
производительности.
На уровне Системного
тестирования и Приемочного
будут разные состояния БД. Для
уровня Приемочного
тестирования целесообразно
чтобы БД содержали данные
мигрированные из реальных
систем. Мигрированы будут?
П8 Сетевые
конфигурации
систем
Расположение серверов систем,
рабочих станций пользователей и
внешних систем на различных
площадках, их взаимодействие
по внутрисетевым интернет
каналам.
Варианты для выполнения
тестирования будут
определены позднее
Параметры П2 (Характерный период нагрузки), П3 (Карты загрузки КД), П4 (Карты
операций) в совокупности образуют профиль нагрузки. Профиль нагрузки отражает,
общее время выполнения операций, набор операций, распределение во времени объема
выполняемых операций.
Таким образом, моделирование реального (прогнозируемого) характера нагрузки на WEB-
кабинет осуществляется заданием соответствующего профиля нагрузки и П1, П6, П7 и П8.
4. Проведениетестирования
4.1 Тестированиепроизводительности
Моделирование процессов нагрузки производится путем циклического выполнения
виртуальными пользователями (программными процессами) набора пользовательских
сценариев.
Ключевым параметром, характеризующим подаваемую нагрузку с точки зрения
моделирования процесса нагрузки, является интенсивность выполнения
пользовательских сценариев. Интенсивность удобна тем, что показывая, сколько

12
операций в единицу времени инициируется в тестируемой системе, она одновременно
определяет, и то количество ресурсов системы, которое ей требуется для их выполнения.
Другими словами, регулировать количество ресурсов системы потребляемых в единицу
времени и исследовать характеристики производительности естественным образом
удобно, изменяя интенсивность выполнения сценариев.
В процессе тестирования изменение суммарной интенсивности выполнения сценариев
всеми виртуальными пользователями (моделируемая нагрузка на Систему) будет
производиться путем изменения количества виртуальных пользователей, выполняющих
сценарии. Такой подход допустим для условий тестирования, в которых заданная
интенсивность выполнения сценариев не превышает максимальную интенсивность
выдерживаемую системой без деградации характеристик производительности. Это
условия стабилизировавшейся нагрузки. В таких условиях увеличение количества
виртуальных пользователей, выполняющих сценарии одновременно, влечет
пропорциональное увеличение суммарной интенсивности.
Поскольку максимальная интенсивность неизвестна до проведения тестирования, и
собственно ее определение есть одна из характеристик производительности, то
проведение раундов тестирования предусмотренных данной методикой требует задания
расчётной интенсивность, которая будет предположительно меньше максимальной и
может по ходу получения результатов тестирования уточняться.
Расчет интенсивности для раунда будет производиться, исходя из известных данных о
временах отклика системы на операции сценария и величины задержки между двумя
последовательными итерациями (между окончанием выполнения предыдущего и
началом выполнения следующего сценария). Опять же, поскольку, фактические времена
отклика системы сами зависят от складывающейся нагрузки, а значит от задаваемой
интенсивности, то расчет будет итерационным:
1. Время отклика системы измеряется при выполнении сценария одним виртуальным
пользователем в течение времени, дающем статистически достоверные значения
2. Величина задержки выбирается так, чтобы кратно превышать время отклика
3. Выбирается начальное число виртуальных пользователей N
4. Рассчитывается интенсивность как N/(Время отклика + Величина задержки)
5. Время отклика системы измеряется при этой интенсивности
6. Оценивается изменение времени отклика системы
 если оно не испытало резких скачков, то величина задержки и число
виртуальных пользователей принимаются как начальные значения для
последующих тестов
 если оно испытало резкие скачки, то величина задержки кратно
увеличивается и проводится тест с новой расчетной интенсивностью
Таким образом, основываясь на требованиях профилей нагрузки, в процессе
моделирования нагрузки будут задаваться число виртуальных пользователей,
выполняющих одновременно сценарии, и для каждого виртуального пользователя будет
регулироваться величина задержки между выполнением сценариев с учетом фактических
времен отклика системы на составляющие сценарий операции. Тем самым будет
регулироваться общая интенсивность выполнения сценариев, нагрузка на систему и
характер использования рабочими процессами пользователей ресурсов системы.
4.1.1 Раундынагрузочныхтестов
Нагрузочное тестирование проводится в несколько раундов. На каждом раунде
выполняются следующие действия:
1. Создание Конфигурации условий тестирования для Раунда, в частности
a. Подготавливается среда тестирования

13
b. Задаются Профиль нагрузки по входящим КД и Профиль нагрузки по
операциям пользователей.
c. Задается Интенсивность выполнения сценариев профиля, заданием
числа виртуальных пользователей и величин задержки.
2. Запуск скриптов, имитирующих выполнение пользователем операций и скриптов,
имитирующих внешние системы.
3. Сбор данных по характеристикам производительности.
В целях получения данных о характеристиках производительности WEB-кабинет будут
проведены следующие раунды тестов:
Раунд Цель раунда Профили
нагрузки
Конфигурация
условий
тестирования
Раунд 0 Отладка нагрузочных скриптов и получения
предварительных данных о производительности
Web-кабинет для их анализа разработчиками, в
частности определения времени выполнения
одной итерации для каждого скрипта в Системе,
не испытывающей нагрузку.
LO-0.0
LO-0.1.1
LO-0.1.2
LO-0.2
LO-0.3
LO-0.4
LO-0.5
LM-0.1
LM-0.2
LM-0.3
LM-0.4
Конфигурация 1 -
Отладка
Раунд 1 Получения данных о максимальной
интенсивности обработки входящих сообщений
с уведомлениями о КД.
LM-1.1 Конфигурация 2-
Релиз 1
Раунд 2 Получения данных о времени обработки
входящего сообщения с уведомлением о КД
LM-1.2 Конфигурация 2-
Релиз 1
Раунд 3 Получение данных о времени отклика ЭФ
«Корпоративные действия» и группе закладок
«Параметры КД»
LO-1.1 Конфигурация 2-
Релиз 1
Раунд 4 Получения данных о максимальном числе
одновременно работающих пользователей в
АРМ Депонента
LO-1.2
LO-1.3
Конфигурация 2-
Релиз 1
Раунд 5 Получение данных о времени отклика ЭФ в ЖЦ
инструкций
TBD Конфигурация 3-
Релиз 2
Раунд 6 Получении данных о максимальном числе
одновременно работающих пользователей
подающих инструкции
Релиз 2
Раунд 7 Получение данных о максимальной
интенсивности формирования исходящих
сообщений с Инструкциями.
Релиз 2
Раунд 8 Получение данных о соответствие ХП6
Стабильность системы
LM-1.1
LO-1.1
Конфигурация 4-
стабильности

14
4.1.1.1 Раунд0
Раунд предназначен для отладки нагрузочных скриптов и получения предварительных
данных о производительности Web-кабинет для их анализа разработчиками.
Выполняются измерения времен отклика по операциям пользователей без нагрузки, т.е.
при выполнении операции в один поток и далее выполняется процедура определения
начальных значений величин задержки и числа виртуальных пользователей, как описано
в Разделе 4:
1. Время отклика системы измеряется при выполнении сценария одним виртуальным
пользователем в течение времени, дающем статистически достоверные значения
2. Величина задержки выбирается так, чтобы в 5 раз превышать время отклика
3. Выбирается начальное число виртуальных пользователей N=100
4. Рассчитывается интенсивность как N/(Время отклика + Величина задержки)
5. Время отклика системы измеряется при этой интенсивности
 если оно не испытало резких скачков, то величина задержки и число
виртуальных пользователей принимаются как начальные значения для
последующих тестов
 если оно испытало резкие скачки, то величина задержки кратно
увеличивается и проводится тест с новой расчетной интенсивностью
4.1.1.2 Раунды1-7
Раунды предназначены для измерения характеристик производительности согласно
профилям нагрузки.
Процедура определения максимальных значений интенсивности и числа пользователей
предполагается итерационной:
1. Задаются начальные величины задержки и число виртуальных пользователей,
определенные в Раунде 0
2. Выполняются тесты
 если оно не испытало резких скачков, то число виртуальных пользователей
увеличивается на 100 и проводится следующая итерация
 если оно испытало резкие скачки, то
 если число виртуальных пользователей не превысило Nmin для
профиля, то величина задержки кратно увеличивается и
проводится тест с новой расчетной интенсивностью
 если число виртуальных пользователей уже превысило Nmin, то
Раунд завершен. Число виртуальных пользователей на
предыдущей итерации принимается за ХП2.1, ХП3.1, ХП4, при этом
фиксируются в отчет времена отклика и величина задержки, при
которых эти значения наблюдались.
Характерный период выполнения итерации задан в Конфигурация 1 и 2.
4.1.1.3 Раунд8
Раунд предназначен для получения данных о соответствие ХП6 Стабильность системы.

15
Выполнение операций профилей производится в течение полного характерного периода
определённого в Конфигурации 4.
Число виртуальных пользователей и временные задержки устанавливаются равными тем
значениям, которые были измеренным в Раундах 1-7.
4.2 Тестированиеотказоустойчивости
4.2.1 Раундынагрузочныхтестов
Тестирование отказоустойчивости проводится в несколько раундов. На каждом раунде
выполняются следующие действия:
1. Создание Конфигурации условий тестирования для Раунда, в частности
a. Подготавливается среда тестирования
b. Задаются Профиль нагрузки по входящим КД и Профиль нагрузки по
операциям пользователей.
c. Задается Интенсивность выполнения сценариев профиля, заданием
числа виртуальных пользователей и величин задержки.
2. Запуск скриптов, имитирующих выполнение пользователем операций и скриптов,
имитирующих внешние системы.
3. Эмуляция отказа компонентов Web-кабинет.
4. Восстановление работоспособности компонентов Web-кабинет.
5. Сбор данных по характеристикам отказоустойчивости.
В целях получения данных о характеристиках отказоустойчивости WEB-кабинет будут
проведены следующие раунды тестов:
Раунд Цель раунда Профили
нагрузки
Конфигурация
условий
тестирования
Раунд 1 Эмуляция отказа всех кроме одного
управляемых серверов кластера WebLogic,
обеспечивающего работу Презентационного
модуля.
Релиз 2
обеспечивающего работу Модуля бизнес логики.
Релиз 2
обеспечивающего работу Интеграционного слоя.
Релиз 2
Раунд 4 Эмуляция отказа всех управляемых серверов
кластера WebLogic, обеспечивающего работу
Интеграционного слоя.
Релиз 2

16
4.2.1.1 Раунд1
Раунд предназначен для выявления проблем с сохранением доступности и
работоспособности Web-кабинет при отказах на уровне Презентационного модуля.
Эмуляция отказа производится путем остановки всех кроме одного управляемых
серверов WebLogic в каждом из кластеров.
После создания ситуации отказа с Web-кабинет продолжается работа по Профиль
нагрузки по операциям пользователей LO-1.1 в течение 15 минут. Далее
восстанавливается работа управляемых серверов и продолжается работа по профилю
операций.
4.2.1.2 Раунд2
работоспособности Web-кабинет при отказах на уровне Модуля бизнес-логики.
Эмуляция отказа производится путем остановки всех кроме одного управляемых
серверов WebLogic в кластере.
операций.
4.2.1.3 Раунд3
работоспособности Web-кабинет при отказах на уровне Интеграционного слоя, а именно
недоступности композитного приложения обеспечивающего обработку входящих и
исходящих сообщений.
Эмуляция отказа производится путем остановки композитного приложения на всех кроме
одного управляемых серверах WebLogic в кластере SOA.
операций.
4.2.1.4 Раунд4
работоспособности Web-кабинет при отказах на уровне Интеграционного слоя, а именно
недоступности композитного приложения обеспечивающего обработку входящих и
исходящих сообщений.
Эмуляция отказа производится путем остановки композитного приложения на всех
управляемых серверах WebLogic в кластере SOA.

17
операций.
4.3 Условиятестирования
В ходе проведения раундов тестирования производительности будут создаваться
следующие конфигурации условий тестирования, путем задания параметров
определенных в модели нагрузки:
4.3.1.1 Конфигурация1-Отладка
систем
На стенде развернута
функциональность Релиза 1
Отсутствие дефектов
Критичности 1 и 2
бизнес-процессы проходят свой
полный жизненный цикл..
5 – 30 мин
БД и др.
Конфигурация настроек стенда
TEST2
Точка входа нагрузки на
Балансировщик. Прокси сервер
осуществляющий https-
дешифрование не включается в
контур нагрузки
WEB-кабинет,
SOA Suite и БД
Хранилища
TEST2
БД Web-кабинет не содержат
мигрированные из реальных
систем данные.
П8 Сетевые
систем
каналам.
Генераторы нагрузки с
виртуальных рабочих станций
разработчиков в офисной
подсети.
Тестируемая система – стенд
TEST2
4.3.1.2 Конфигурация2-ТестированиеРелиз1
Код Параметр Описание Накладываемые условия

18
систем
функциональность Релиза 1
30 мин – 4 часа
БД и др.
TEST2
WEB-кабинет,
SOA Suite и БД
Хранилища
TEST2
БД Web-кабинет, SOA Suite и
БД хранилища документов НЕ
содержат мигрированные из
реальных систем данные.
П8 Сетевые
систем
каналам.
подсети.
TEST2
4.3.1.3 Конфигурация3-ТестированиеРелиз2
систем
функциональность Релиза 1 и
Релиза 2
30 мин – 4 часа
П5 Состояние Включают настройки

19
настроек систем. БД и др. TEST2
WEB-кабинет,
SOA Suite и БД
Хранилища
TEST2
П8 Сетевые
систем
каналам.
подсети.
TEST2
4.3.1.4 Конфигурация4-Тестированиестабильности
систем
функциональность Релиза 1 и
Релиза 2
21 час
БД и др.
TEST2
WEB-кабинет,
SOA Suite и БД
Хранилища
TEST2

20
П8 Сетевые
систем
каналам.
подсети.
TEST2
4.4 Требованияксредетестирования
4.4.1 СредаWeb-кабинет
Аппаратные ресурсы, планируемые при эксплуатации, зафиксированы в документе
Архитектурный документ. В целях проведения тестирования производительности и
отказоустойчивости подготовлена тестовая среда TEST2 с аппаратными ресурсами меньшими,
чем при промышленной эксплуатации.
Данные по аппаратным ресурсам приведены в таблице.
Таким образом, данные по характеристикам производительности, полученным на TEST2,
потребуют либо экстраполяции относительно аппаратных ресурсов, либо доведения доступных
ресурсов до значений согласно архитектуре Web-кабинет.
Требования Архитектурногодокумента Стенд TEST2
Сервер Размещается Ресурсы на
каждый
контейнер
Сервер Размещается Ресурсы на
каждый
контейнер
4.4.1.1 Каналыпередачи
Пропускная способность:
 Между серверами из раздела выше и системами -
 Соединений с системой хранения данных по оптическому каналу -.

21
4.4.2 Средаинструментариятестирования
4.4.2.1 Генераторынагрузки
Сервер Количество Размещается Ресурсы на каждый
сервер
LoadGen1 5 Генератор нагрузки CPU – 4 ядра
RAM – 8Gb
HDD – 50Gb
4.4.2.2 Каналыпередачи
Пропускная способность от серверов генераторов нагрузки до серверов http_srv1
(балансировщик) Web-кабинет:
 для тестов с числом пользователей = для первого года эксплуатации – не менее 1
Гбит/сек,
 для тестов с числом пользователей = после первого года эксплуатации –10
Гбит/сек;
4.5 Измерениехарактеристикпроизводительности
1. Средствами JMeter измеряются:
 Правильность обработки данных (ошибки возвращаемые пользователю).
 Время отклика Web-кабинет на запросы пользователя.
 Время отклика web-сервисов Web-кабинет при загрузке входящих сообщений.
 Максимальное число пользователей одновременно работающих в Web-
кабинет
Процедура измерения - стандартное использование JMeter
2. Средствами системы XXX измеряются:
 Использование аппаратных ресурсов.
Процедура измерения - стандартное использование системы XXX.
5. Структуранагрузочныхскриптов
Скрипты должны обеспечить создание процессов нагрузки.
Для этого скрипты реализуется со следующей структурой:
1. Скрипты, имитирующие выполнение пользователем сценария, состоящего из
последовательности отдельных операций в интерфейсе Web-кабинета.
На каждый пользовательский сценарий согласно профили нагрузки создается
скрипт, который состоит из последовательности запросов к серверу Web-кабинет,
эмулирующих действия на отдельных экранных формах
Каждый скрипт параметризован в разрезе:

22
 Пользователя-депонента от имени, которого выполняется операция Web-
кабинет
Конкретные значения параметров будут заданы заранее подготовленным
датапулом пользователей-депонентов.
Датапул пользователей-депонентов должен содержать перечень таких
пользователей, для которых загружены сообщения о КД скриптами из п.2
2. Скрипты, имитирующие загрузку входящих сообщений по сценариям согласно
профилю нагрузки.
На каждый сценарий согласно профилю, создается отдельный скрипт,
последовательно загружающий отдельные входящие сообщения.
Каждый скрипт параметризован в разрезе:
 Пользователя-депонента, на которого поступают входящие сообщения о
КД
 Атрибутов КД: референс КД, даты Вариантов КД, остатков по ЦБ и др.
Значения атрибутов автогенерируются, либо берутся из заранее
составленных дата-пулов.
3. Для исходящих сообщений имитируется выгрузка в очередь внешней системы.
Тестовая очередь может быть настроена на серверах интеграционного слоя, web-
сервис выполняющий функцию отправки должен быть сконфигурирован на
тестовую очередь.
5.1 Инструментарийдляразработкискриптов
В качестве инструмента разработки скриптов и проведения тестирования выбран Apache
JMeter.
5.1.1 Общиесведения
JMeter — это Java-инструмент, созданный в рамках проекта организации Apache по
разработке программного обеспечения с открытым исходным кодом. Он предназначен
для выполнения запросов к серверу и сбора полученных результатов. JMeter
поддерживает HTML, XML, SOAP, JDBC и запросы других типов. Он может формировать
множество параллельных потоков, а, значит, моделировать множество клиентов,
обращающихся к системе. Он позволяет создавать планы тестирования вручную или
записывая запросы сеанса одного клиента через посредническое приложение. Планы
можно обогащать логикой программирования, такой как условное исполнение, обработка
ответов с использованием регулярных выражений и т. д.
JMeter продолжает активно разрабатываться; периодически выпускаются новые версии.
Хотя заявляется обратная совместимость новых версий, настоятельно рекомендуется
использовать самую последнюю версию, содержащую исправления, улучшения
производительности и более широкие функциональные возможности. За подробной
информацией об использовании JMeter и назначении каждого из элементов плана
обратитесь к документации по JMeter.
В JMeter используется концепция группы потоков (Thread Group) для моделирования
набора клиентов, который проходит через определенную последовательность этапов.
Один клиент представляется одним потоком, проходящим последовательные циклы через
определенные этапы. Количество клиентских потоков в группе потоков можно
настраивать. Один план тестирования может определять множество групп потоков,
которые затем могут выполняться на разных экземплярах JMeter на отдельных системах.
Однако в настоящее время невозможно ветвление множества потоков из этапа плана;

23
такая функциональность могла бы потребоваться, например, для моделирования
запросов типа AJAX на HTML-страницах.
5.1.2 Настройкасредытестирования
Выполнение теста JMeter имеет ряд требований в отношении самого инструмента.
В процессе тестирования приложение JMeter моделирует клиентов, одновременно
подключающихся к тестируемой системе, например, с использованием HTTP-клиента.
JMeter порождает поток для каждого моделируемого клиентского сеанса (одновременного
пользователя), поэтому потребуются ресурсы процессоров и оперативной памяти,
достаточные для исключения узких мест на стороне JMeter. Платформы с поддержкой
ускоренной поточной обработки, такие как Linux, как правило, лучше справляются с этой
задачей. Больший объем памяти также положительно сказывается на
производительности JMeter, поскольку позволяет выполнять переключение контекста в
памяти. Как правило, процессора с тактовой частотой не менее 1,5 ГГц и оперативной
памяти объемом не менее 2 ГБ достаточно для поддержки работы JMeter в сценарии
моделирования около 30 клиентов. Фактические потребности зависят от количества
моделируемых клиентов. Эта рекомендация основывается на опыте, а не на
официальном широкомасштабном тестировании.
Для максимально эффективного тестирования приложение JMeter рекомендуется
выполнять на отдельной машине, где не установлены компоненты тестируемой системы
или базы данных. Как уже отмечалось, в зависимости от количества пользователей,
которое вы хотите смоделировать, может существовать большое количество потоков и
используемых сокетов, что может оказывать значительное влияние на
производительность машины. Если система также занята выполнением компонентов
самой тестируемой системы, отвлекать ресурсы на выполнение JMeter неразумно.
6. Требованияк Заказчику
В разделе приведены требования к обеспечению процесса тестирования со Заказчика
специфичные для процесса тестирования производительности и отказоустойчивости.
1. Предоставить сервера для размещения генераторов нагрузки в соответствие с
разделом 4.4.2 и предоставить доступ к ним с рабочих мест, предоставленных
Исполнителю;
2. Предоставить права для возможности мониторинга серверов среды тестирования в
части показателей из Приложения 3;
3. Исключить несогласованные изменения конфигурации тестовой среды на
протяжении периода выполнения тестирования производительности.
7. Приложение1
Профиль нагрузки построен исходя из цели обеспечить в тестах покрытие всех
реализованных входящих сообщений. Распределение виртуальных пользователей по
сценариям профиля равномерное и не учитывает никаких специфических требований.
Профиль нагрузки построен исходя из цели обеспечить в тестах покрытие операций на
всех новых или измененных экранных формах, которые реализуются принципиально
разными компонентами Web-кабинет. Информация о реализации получена от

24
разработчиков. Распределение виртуальных пользователей по сценариям профиля
преимущественно равномерное и не учитывает никаких специфических требований.
1. Средний процент загрузки процессора серверов БД
2. Использование памяти серверов БД, Мб
3. Чтение данных дисковой подсистемы серверов БД Мб/сек.
4. Запись данных на дисковую подсистему сервера БД Мб/сек.
5. Среднее время задержки на дисковой подсистеме БД мсек.
6. Средний процент загрузки процессоров серверов WebLogic
7. Использование памяти серверов WebLogic, Мб.
8. Загрузка канала между рабочими станциями пользователей и Web-кабинет

Performance Testing Strategy Template by Egor B Eremeev

Recommended

Recommended

More Related Content

Similar to Performance Testing Strategy Template by Egor B Eremeev

Similar to Performance Testing Strategy Template by Egor B Eremeev (20)

Performance Testing Strategy Template by Egor B Eremeev