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

Лист согласования

От ЗАО «ВТБ 24»

Должность	Ф.И.О.	Подпись	Дата
Зам. нач. управления УТ, ДБИТ	Антохов Д.В.
Руководитель проекта Отдел системных проектов, УА ДБИТ	Сарвин Р.А.
Заместитель начальника управления, УКТ, ДБИТ	Шелков А. А.
Начальник отдела Отдел системных проектов, УА ДБИТ	Намм М. В.
Ведущий технолог Отдел технологий РКО ФЛ, УКТ, ДБИТ	Озеров А. А.

От «S&T»

Должность	Ф.И.О.	Подпись	Дата
Руководитель проекта	Хайруллина Ф.Ф.

Содержание

1 История изменений.. 7

2 Сокращения и терминология.. 9

2.1 Сокращения.. 9

2.2 Терминология.. 10

3 Введение.. 14

4 Цели тестирования: 15

4.1 Причины проведения нагрузочного тестирования.. 15

4.2 Цели проведения нагрузочного тестирования.. 15

4.2.1 Определение максимальной производительности Системы. 15

4.2.2 Проверка надежности. 15

4.2.3 Проверка исправления дефектов производительности. 16

4.2.4 Влияние открытия ОД в ТП на производительность Системы. 17

4.2.5 Влияние закрытия ОД в ТП на производительность Системы. 17

5 Ограничения тестирования.. 18

6 Объект тестирования.. 23

6.1 Общие сведения.. 23

6.2 Архитектура системы.. 24

6.3 Описание оборудования промышленного стенда. 35

7 Требования производительности.. 36

8 Стратегия тестирования.. 37

8.1 Определение максимальной производительности.. 37

8.2 Влияние открытия ОД в ТП на производительность Системы.. 38

8.3 Влияние закрытия ОД в ТП на производительность Системы.. 38

8.4 Тест надежности.. 39

8.5 Критерии успешного завершения нагрузочного тестирования.. 39

9 Тестовый стенд.. 40

9.1 Общие положения.. 40

9.2 Архитектура тестового стенда. 40

9.3 Требования к оборудованию тестового стенда. 41

9.4 Оценка соответствия промышленного и тестового стенда. 43

9.5 Конфигурация СПО и ППО.. 44

9.5.1 Сервер приложений Spectrum.. 44

9.5.2 Сервер СУБД.. 46

9.5.3 Сервер Oracle BI Publisher. 48

10 Моделирование нагрузки.. 50

10.1 Обзор. 50

10.2 Профили нагрузки.. 51

10.2.1 Описание Профиля Утро. 51

10.2.2 Описание Профиля День. 54

10.2.3 Описание Профиля Вечер. 56

10.3 Сценарии использования.. 58

10.3.1 Сценарий 1. 59

10.3.2 Сценарий 2. 59

10.3.3 Сценарий 3. 59

10.3.4 Сценарий 4. 59

10.3.5 Сценарий 5. 60

10.3.6 Сценарий 6. 60

10.3.7 Сценарий 7. 61

10.3.8 Сценарий 8. 61

10.4 Описание операций.. 62

UC 0. Вход в систему. 63

UC 1. Открытие ОД подразделения. 64

UC 2. Открытие смен сотрудниками. 64

UC 3. Вынесение из сейфа. 65

UC 4. Выдача аванса. 65

UC 5. Приём ценностей подотчетными кассирами. 66

UC 6. Подкрепление (интеграция с SC-наличность) 67

UC 7. Покупка валюты (ВОО) 69

UC 8. Платежи ФЛ в пользу ЮЛ.. 70

UC 9. Внесение наличных на ПК.. 72

UC 10. Инкассация (интеграция с SC-наличность) 74

UC 11. Возврат аванса подотчетными кассирами. 74

UC 12. Прием ценностей старшим кассиром.. 75

UC 13. Финальная сдача ценностей. 75

UC 14. Закрытие смены.. 76

UC 15. Занесение в сейф.. 77

UC 16. Свёртка реестров. 77

UC 17. Закрытие ОД.. 79

UC 18. Сверка дня. 79

UC 19. РКО. Внутрибанковский перевод со счета (Profile) клиента на карту (Way4). 80

UC 20. РКО. Внутрибанковский перевод с карты (Way4) клиента на свои счета (Profile) 81

UC 21. РКО. Внутрибанковский перевод со счета (Profile) клиента на карту (Way4) 3-х лиц. 82

UC 22. РКО. Внутрибанковский перевод со счета (Profile) клиента на счета (Profile) 3-х лиц. 84

UC 23. РКО. Внутрибанковский перевод со счета (Profile) клиента на свои счета (Телебанк) 85

UC 24. РКО. Внутрибанковский перевод со счета (Бисквит) клиента на свои счета (Profile) 86

UC 25. РКО. Внутрибанковский перевод со счета (Телебанк) клиента на свои счета (Profile) 88

UC 26. РКО. Внутрибанковский перевод со счета (Profile) клиента на свои счета (Бисквит) 89

UC 27. РКО. Внутрибанковский перевод со счета (Profile) клиента на счета (Бисквит) 3-х лиц. 90

UC 28. РКО. Внутрибанковский перевод со счета (Profile) клиента на счета (Телебанк) 3-х лиц. 92

UC 29. РКО. Внутрибанковский перевод со счета (Бисквит) клиента на счета (Profile) 3-х лиц. 93

UC 30. РКО. Внутрибанковский перевод со счета (Телебанк) клиента на счета (Profile) 3-х лиц. 94

UC 31. РКО. Внутрибанковский перевод со счета (Profile) клиента на свои счета (Profile) 96

UC 32. РКО. Внешний перевод (межбанковский) 97

UC 33. РКО. Внешний перевод (международный) 99

UC 34. РКО. Внесение наличных на МС.. 101

UC 35. РКО. Снятие наличных с МС.. 102

UC 36. DBC. Загрузка TCD.. 101

UC 37. DBC. Выгрузка TCD.. 102

UC 38. DBC. Выдача ДС. Подтверждение расходной операции из БИСквита. 102

UC 39. DBC. Выдача ДС с ПК.. 101

10.5 Описание работы АС и заглушек. 103

11 Наполнение базы данных.. 105

11.1 Скрипты наполнения.. 108

12 Планируемые тесты... 144

12.1 Перечень типов тестов в данном тестировании.. 144

12.2 Критерии успешности проведения тестов. 145

12.2.1 Критерии по временам отклика тестируемых операций. 145

12.2.2 Критерии по использованию ресурсов системы.. 148

13 Мониторинг. 149

13.1 Описание средств мониторинга. 149

13.2 Мониторинг Unix-серверов. 149

13.3 Мониторинг Windows-серверов. 150

13.4 Описание измерений бизнес-характеристик. 150

14 Требования к банку.. 152

15 Материалы, подлежащие сдаче.. 153

16 Оценка точности проведения НТ.. 155

Приложение 1. Распределение операций.. 160

Приложение 2. Прогноз роста таблиц бд.. 161

Приложение 3. Эмулятор Sonic.. 162

Приложение 4. Инструкция по использованию эмулятора Sonic.. 164

История изменений

Дата	Версия	Описание	Автор
13.02.2014	1.0	Начальная версия	Телегина Н. П.
14.02.2014	1.1	Был доработан профиль нагузки (Приложение 2)	Телегина Н. П.
19.03.2014	1.6	Изменены разделы 6.1, 6.2, 6.3, 8.1.1, 8.2.1, 8.2.2, 8.2.3, 8.5, 10.1, 10.2.1, 11.4, Приложение 1, Приложение 2, Приложение 3	Телегина Н. П.
12.08.2014	1.7	МНТ актуализирована в части профиля и	Ауров И.Н.
10.10.2014	1.8	Включены разделы 10 и «Приложение 3» - эмулятор ЕФР.	Исаев С.В.
22.10.2014	1.9	Скорректированы формулировки. Доработан профиль. Доработаны разделы по наполнению БД, профилю тестирования и описание заглушки ЕФР.	Исаев С.В.
27.10.2014	1.10	Исправлены замечания.	Исаев С.В.
28.10.2014	1.11	Исправлены замечания в части ЕФР, дефектов производительности, наполнения БД. Дополнены ограничения тестирования.	Исаев С.В.
05.11.2014	1.12	Исправлены замечания в части профиля НТ и описания операций, скорректированы разделы 4.2, 7,8.	Исаев С.В.
18.11.2014	1.15	Скорректированы описания UC и профилей.	Исаев С.В.
21.11.2014	1.16	Скорректированы описания UC и профилей согласно замечаниям от компании Спектр.	Исаев С.В.
28.11.2014	1.17	Скорректированы описания UC и профилей согласно замечаниям от компании Спектр. Дополнен раздел ограничения.	Исаев С.В.
02.12.2014	1.18	Исправлены формулировки в описаниях кейсов. Поправлены ссылки на разделы внутри документа.	Исаев С.В.
20.02.2015	1.22	Добавлена информация по DBC	Титов В.В.
06.03.2015	1.23	Изменены названия ТК DBC, актуализированны дефекты. Добавлено описание интеграционных потоков данных. Актуализированы данные по наполнению БД. Исправлены таблицы 11.1 и 11.2 в соответствии со Приложением 2.	Титов В.В.
17.03.2015	1.24	Испарвленны кейсы по ТК DBC, обновлен файл с расчетом нагрузки из приложения 1, исправленна версия тестируемой системы Спектрум.	Титов В.В.
13.04.2015	1.25	Исправлены ТК. Изменены требования к оборудованию стенда. Добавлены ограничения тестирования.	Титов В.В.

Сокращения и терминология

Сокращения

UC	сценарий использования (пользовательский сценарий) (use case)
UI	пользовательский интерфейс (user interface)
VU	виртуальный пользователь (virtual user)
АС	автоматизированная система
БД	база данных
ВП	виртуальный пользователь (virtual user)
КПТ	комитет по процессам и технологиям
КТС	комплекс технических средств
МНТ	методика нагрузочного тестирования
НТ	нагрузочное тестирование
ОС	операционная система
ПО	программное обеспечение
ППО	прикладное программное обеспечение
ПТС	программно-технические средства
СНТ	Средства нагрузочного тестирования.
СПО	системное программное обеспечение
ТЗ	техническое задание
ЕФР	Единое фронт решение
ОД	операционный день
ТП	точка продаж
DBC	Delta BranchCash
TCD	электронный кассир, работающий только на выдачу
TCR	электронный кассир-рециркулятор
ЭК	электронный кассир вне зависимости от используемой технологии (ТСD или TCR)

Терминология

Термин	Определение
Use Case (cценарий использования)	Логически связанная последовательность операций. Например, заведение клиента и открытие счета
Средства нагрузочного тестирования	Скрипты, сценарии создания нагрузки, средства подготовки БД, средства подготовки тестовых данных, эмуляторы, средства мониторинга и обработки протоколов (в случае их разработки).
Виртуальный пользователь	Программный процесс, эмулирующий действия физического пользователя Системы
Модель нагрузки	Набор профилей нагрузки, наиболее точно характеризующих работу системы, с выраженной зависимостью нагрузки относительно основных бизнес-характеристик использования системы.
Профиль нагрузки	Набор операций с заданными интенсивностями, полученный на основе сбора статистических данных либо определенный путем анализа требований к тестируемой системе
Нагрузка	Совокупное выполнение операций на общем ресурсе (тр./сек, хитов/сек).
Уровень нагрузки	Основной показатель нагрузки (обычно суммарная интенсивность поступающих на обработку операций), относительно которого в соответствии с заданным профилем нагрузки определяется интенсивность каждого отдельного вида операций.
Операция	Совокупность действий, необходимых для выполнения бизнес-задачи. Операция состоит из набора шагов. Например: вход в систему, покупка/ продажа иностранной валюты в руб.
Максимальная производительность	Наивысшая интенсивность выполнения операций обслуживаемых системой с соблюдением требуемого качества обслуживания (удовлетворяет SLA).
Время отклика	Время, которое требуется системе на то, чтобы отреагировать на ввод данных. Время отклика системы измеряется как интервал времени между действием пользователя (нажатием на кнопку) и началом отображения пользователю полученной по запросу информации.
Интенсивность выполнения операции	Количество операций, выполняемых в единицу времени. Обычно измеряется в оп/час, оп/мин, оп/сек.
Производительность	Количество выполняемых операций за период времени (N операций за M часов).
Старший кассир	Заведующий кассой или иной кассовый работник, являющийся заведующим кассой по должности или исполняющий обязанности заведующего кассой согласно должностной инструкции и ОРД по Банку/Филиалу/РОО в течение рабочего дня - смены с учетом режима обслуживания клиентов, определенного ОРД Банка.
Кассир (данные функции могут выполняться Старшим кассиром)	РаботникТП, осуществляющий согласно должностной инструкции кассовые операции с наличными деньгами и другими ценностями, в том числе с монетами из Драгоценных металлов, с которым заключен договор о полной материальной ответственности в соответствии с законодательством Российской Федерации. Принимает/передает монеты от/к Старшего кассира, подтверждает операцию по продаже монет клиенту.
Операционист-кассир	Вся операционная + кассирская деятельность
Кассир-операционист	Кассир + переводы
Контролер	Сотрудник ТП, осуществляющий дополнительный контроль операций.
Администратор группы резерва	Сотрудник ТП, осуществляющий изменение привязки сотрудника группы резерва к ТП Доступ предусмотрен к изменению ТП, обновлению должности и данных по физ.лицу пользователя. Предоставляется Руководящему сотруднику в Отделе резерва сотрудников Фронт линии.
SC-Наличность	ИАС «SC-Наличность» - Информационно-аналитическая система для оптимизации потоков денежной наличности в банке.
АБС БИСквит	Автоматизированная банковская система «БИСКВИТ»
ИС «Спектрум» (Spectrum)	Информационная система УФО Spectrum, организационно технологической платформа для обеспечения процессов кассового обслуживания клиентов Банка
Транзакционный сервис	Функционал, осуществляющий выполнение клиентских операций, обеспечивая целостность распределённых транзакций (свойства ACID).
Распределенная транзакция	Под распределённой транзакцией понимается выполнение такой операции, которая затрагивает более одной учётной системы.
ИС ЕФР (Siebel)	Программное обеспечение, предназначенное для автоматизации работы подразделений и систем Банка, непосредственно контактирующих с клиентом.
Sonic	По, средство унификации обмена сообщениями между различными системами посредством очередей JMS.
HP Perfomance Centre	ПО, позволяющее выполнять сквозные измерения производительности, диагностировать узкие места приложений и систем, а также настраивать их для повышения производительности с применением единого центра управления. Встроенные функции нагрузочного тестирования, тестирования производительности и стресс-тестирования работоспособности приложений позволяют уменьшить расходы и время, необходимые для тестирования и развертывания новых приложений и систем в производственной среде.
Delta BranchCash	Delta BranchCash представляет из себя «Клиент-серверное» решение, обеспечивающее поддержку проведения стандартного набора операций по приёму и выдаче наличных денежных средств в различных бизнес процессах Банка с применением используемых в Банке ЭК.

Введение

Для оценки производительности ИС «Спектрум» совместно с функционалом «Транзакционный сервис» (в дальнейшем «Системы») необходимо проведение нагрузочных испытаний, включающих в себя нагрузочное тестирование производительности и тестирование стабильности. В качестве объекта тестирования выступает ИС «Спектрум» с транзакционными сервисами и отобранными операциями.

4 Цели тестирования:

Проверка надежности.

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

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

Ограничения тестирования

1) Проект по нагрузочному тестированию не предполагает функционального тестирования функционала «Транзакционный сервис» ИС «Спектрум» и не описывает методы и способы выявления функциональных дефектов, но все обнаруженные в ходе проведения тестирования дефекты будут зарегистрированы в отчете и переданы специалистам Разработчика системы.

2) Системы Бисквит; SC "Наличность"; ЦОП; Way4; Delta BranchCash; «ДБО «Telebank»; УСБС; Profile на тестовом стенде будут заменены эмуляторами. Времена отклика эмуляторов основываются на информации, полученной от специалистов Заказчика (требования к временам отклика операций со смежными системами). Если в промышленной эксплуатации времена отклика при обращении к смежным системам будут отличаться от времен отклика установленных в эмуляторе, то точность тестирования может не прогнозируемо изменяться.

3) Интеграция с системой ЕФР будет реализована через скрипты HP Load Runner, при этом обращение будет происходить исключительно в web-интерфейс Spectrum. Согласно информации от Заказчика, данные операции могут выполняться в обход Siebel’я или эмулятора его компонент путем загрузки соответствующих XML с контекстом операции через интерфейс Spectrum - вместо получения XML со стороны веб-сервиса Siebel.

4) В промышленной среде ИС «Спектрум» взаимодействует со смежными системами через набор брокеров, в тестовой среде используется один брокер. В случае, если пропускная способность брокера окажется «узким местом», то точность нагрузочного тестирования может не прогнозируемо изменяться.

5) В случае выявления в процессе тестирования «узких мест» в работе Системы, и невозможности продолжения тестов до момента их исправления, ППО должно быть доработано силами специалистов Разработчика Системы.

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

7) На тестовом стенде не предполагается эмуляция систем «Ирбис» и PS-POS терминалов, поскольку данные системы не оказывают существенного влияния на тестируемую систему или не взаимодействуют с ней напрямую.

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

9) Расчет прогноза роста БД был построен на данных в период тиражирования системы. Наполнение БД исходя из темпов тиража соответствует наполнению БД к 2021г.

Таблица 5.1 Негативные риски проекта

№	Описание риска	Влияние на	Вероятность возникновения	Действия по предотвращению
	Задержка выпуска ПО.	Сроки проекта	Низкая	Мониторинг контрольных точек проекта. Информирование заинтересованных лиц о невозможности проведения работ по разработке скриптов и проведения тестирования. Инициация запроса на изменение сроков проекта
	Неготовность\не предоставление тестового стенда для написания скриптов	Сроки проекта	Низкая	Мониторинг контрольных точек проекта. Информирование заинтересованных лиц о несоблюдении сроков проведения тестирования. Эскалация с целью предоставления стенда. Инициация запроса на изменение сроков проекта
3.	Сотрудникам Исполнителя не переданы необходимые данные для написания тестовых примеров и эмуляторов смежных систем или переданные файлы некорректны.	Сроки проекта	Средняя	Мониторинг контрольных точек проекта. Информирование заинтересованных лиц о несоблюдении сроков проведения тестирования. Эскалация с целью увеличения активности по подготовке файлов. Инициация запроса на изменение сроков проекта
3.	Непредоставление доступа к тестовой БД	Сроки проекта	Средняя	Мониторинг контрольных точек проекта. Информирование заинтересованных лиц о несоблюдении сроков проекта. Эскалация с целью предоставления доступа к БД. Инициация запроса на изменение сроков проекта
	Значительное изменение требований в ходе проекта	Сроки и\или стоимость	Средняя	Информирование и согласование с Исполнителем потенциально возможных изменений требований. Инициация запроса на изменение сроков и\или стоимости проекта
	КТС для проведения тестирования значительно отличается от продуктивной среды	Точность результатов	Низкая	Информирование и согласование между Исполнителем и Заказчиком изменения нагрузочного профиля тестирования и утверждение коэффициента экстраполяции полученных результатов.
	АРМ на территории Заказчика для сотрудников Исполнителя не подготовлены в срок	Сроки проекта	Средняя	Мониторинг контрольных точек проекта. Информирование Заказчика о несоблюдении сроков проведения тестирования. Инициация запроса на изменение сроков проекта
7.	Недооценка Исполнителем работ по проекту	Сроки и\или стоимость проекта	Низкая	Проведение повторной оценки работ проекта. Инициация запроса на изменение сроков и\или стоимости проекта.
	Не утверждена Заказчиком в установленные сроки разработанная документация по проекту	Сроки проекта	Средняя	Сокращение числа лиц согласующих документацию до минимально необходимого числа. Участие сотрудников Заказчика в разработке документации. Инициация запроса на изменение проекта в случае срыва плановых сроков согласования.

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

Общие сведения

Объектом тестирования является система «Спектрум» с функционалом транзакционного сервиса.

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

Тестирование будет проводится с учетом операций ЕФР (РКО), представленных в профиле нагрузки (п.9.4 Описание операций). Все операции будут эмулированы с помощью HP Perfomance Сentre v. 12 и через работу отдельно разработанных эмуляторов внешних систем.

Транзакционный сервис осуществляет выполнение клиентских операций, обеспечивая целостность распределённых транзакций (свойства ACID). Под распределённой транзакцией понимается выполнение такой операции, которая затрагивает более одной учётной системы.

Кроме того, Транзакционный сервис минимизирует риск изменения существенных параметров финансовой операции (например, размер комиссии) в процессе обслуживания клиента.

Выполнение финансовых операций включает в себя два действия:

1) подготовка операции, включающая в себя обогащение операции расчётными данными;

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

Транзакционный сервис принимает запросы на исполнение операций от фронтальных систем. Для выполнения транзакций он обращается к системам исполнения, вызывая бизнес-сервисы УСБС-Front.

Системы исполнения (продуктовые, учётные и мидл-офисные системы), участвующие в проведении операции, определяются Транзакционным сервисом, исходя из входных параметров операции.

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

Архитектура системы

На рис. 6.2.1 приведена общая схема развертывания комплекса объекта тестирования

Рисунок 6.2.1 Общая схема комплекса тестирования

Таблица 6.1 Состав комплекса ИС «Спектрум»

Компонент	Назначение
Тонкий клиент	Браузер, через который пользователь получает доступ к системе
Сервер приложений Spectrum	ПО Spectrum. Сервера приложений Spectrum отвечающие за исполнение бизнес логики системы
Oracle RDBMS	Реляционная СУБД под управлением Oracle RDBMS
Oracle BI Publisher	Сервер отчетности и печатных форм. Используется ПО Oracle BI Publisher
HTTP Load Balancing для серверов приложений Spectrum	Балансировщик нагрузки между серверами приложений Spectrum
HTTP Load Balancing для серверов Oracle BI Publisher	Балансировщик нагрузки между серверами Oracle BI Publisher

На рис 6.2.2 приведена схема интеграционного взаимодействия ИС «Спектрум».

Рисунок 6.2.2 приведена схема интеграционного взаимодействия ИС «Спектрум»

Работоспособность функционала «Транзакционный сервис» зависит так же от работы смежных систем. Состав и описание смежных систем приведен в таблице 6.2

Таблица 6.2 Смежные системы транзакционного сервиса

#№	Наименование системы	Краткое описание	Протокол	Тип связи[1]	Наличие на стенде
21.	УФО «Spectrum»	Кассовые операции	прямые вызовы соответствующих java-классов ТС	двунаправленный	да
32.	Телебанк	сервис дистанционного обслуживания	SOAP over HTTP	двунаправленный	Эмулятор
43.	Account Engine – Агрегатор		файл	двунаправленный	Эмулятор
44.	УСБС-Front	интеграционный слой, изолирующий потребителей сервисов от особенностей их технической реализации. Шина, с помощью которой осуществляется взаимодействия системы с IT-ландшафтом банка в рамках того или иного бизнес-процесса.	SOAP over HTTP	двунаправленный	Эмулятор
65.	Delta BranchCash	управление устройствами электронных кассиров.	SOAP over HTTP	двунаправленная	Эмулятор

Фронтальные системы, за исключением УФО «Спектрум», используют сервисы ТС(initoperation,execoperation) для выполения финансовых операций. С системами исполнения (продуктовые, учётные и мидл-офисные системы) ТС взаимодействует путем вызова соответствующих сервисов УСБС, которые описываются в сценариях выполнения операций. В связи с тем, что ТС и УФО «Спектрум» реализованы на едином инстансе, при выполнении операций сервисы УСБС вызываются напрямую, без использования сервисов ТС.

Системы исполнения (продуктовые, учётные и мидлофисные системы), участвующие в проведении операции, определяются Транзакционным сервисом, исходя из входных параметров операции.

Последовательность вызовов сервисов УСБС определяется типом и подтипом операции и промежуточными результатами исполнения операции.

Ниже, в таблице 6.3 приведен список смежных систем относительно ИС Спектрум.

Таблица 6.3 Смежные системы ИС Спектрум

#№	Наименование системы	Краткое описание	Протокол	Тип связи	Наличие на тестовом стенде
11.	CIF	мастер-система клиентских данных, используемая для хранения клиентских данных и идентификации клиента.	FTP	двунаправленная	да
2.	АБС Бисквит в части:
3.	Модуль «Главная книга»	отражение проводок по документам клиентов	Sonic/JMS	двунаправленная	эмулятор
4.	Модули «Кредиты», «Вклады», «РКО»	инициация операций по продуктам клиентов физических и юридических лиц, выполняемых с участием операциониста и контроллера подразделения Банка.	Sonic/JMS	двунаправленная	эмулятор
55.	SC-Наличность	подкрепление касс в ДО, заказ наличности и ценностей в кассах подразделений Банка.	Sonic/JMS	двунаправленная	эмулятор
7.	PS-POS терминалы	устройства проведения операций по банковской карте клиента других банков эмитентов.	THEM-on-US	однонаправленная	нет
	Way4	процессинг карточных операций.	HTTP(S)	однонаправленная	эмулятор
	ЦОП	обработка платежей и расчет комиссий по платежам в пользу контрагентов по договорам с Банком.	Sonic/JMS	однонаправленная	эмулятор
	ДБО «Telebank», Ирбис	шаблоны платежей в пользу контрагентов по договорам	Sonic/JMS	однонаправленная	эмулятор
	Sonic ESB	эксплуатируемая в настоящее время в Банке интеграционная шина	Sonic/JMS HTTP(S)	однонаправленная	да

Описание интеграционных потоков системного окружения ИС Спектрум приведено в таблице 6.4

Таблица 6.4 Описание интеграционных Потоков данных системного окружения ИС Спектрум

Номер потока	Описание потока	Система-источник	Система-приемник	Тип обмена	Механизм интеграции	Комментарии
	Потоки данных между системами Бисквит и Spectrum
1.	Документы на подтверждение	Бисквит	Spectrum	On-line	Sonic	Для «двухруких операций»
2.	Подтвержденные документы	Spectrum	Бисквит	On-line	Sonic
3.	Отражение на счетах	Spectrum	Бисквит	On-line	Sonic
4.	Откат операции	Spectrum	Бисквит	On-line	Sonic
5.	Снятие с подтверждения	Бисквит	Spectrum	On-line	Sonic
6.	Получение счета доходов	Spectrum	Бисквит	On-line	Sonic
7.	Сумма покрытия по чеку	Spectrum	Бисквит	On-line	Sonic
	Потоки данных между системами Spectrum и SC "Наличность"
8.	Наличие ценностей на конец дня	Spectrum	SC "Наличность	On-line	Sonic
9.	Загрузка из "SC Наличность" в «Spectrum» документов по инкассации.	SC "Наличность"	Spectrum	On-line	Sonic
	Потоки данных между системами Spectrum и ЦОП
10.	Сообщение на проверку возможности проведения платежа (CheckingRq)	Spectrum	ЦОП	On-line	Sonic
11.	Сообщение на проведение платежа (PayingRq)	Spectrum	ЦОП	On-line	Sonic
12.	Сообщение на аннулирование платежа (RejectRq)	Spectrum	ЦОП	On-line	Sonic
13.	Отправка файла полученных платежей (ФПП)	Spectrum	ЦОП	On-line	Sonic
	Потоки данных между системами Spectrum и системой «Сервер TCD/TCR. ПО «Delta BranchCash» »
14.	Запросы по выполнению операций (Загрузка, выгрузка, выдача наличных)	Spectrum	DBC	On-line	SOAP
	Потоки данных между системами Spectrum и Way4
15.	Определение принадлежности карты	Spectrum	Sonic ESB	On-line	Sonic
16.	Проведение операции по карте	Spectrum	Sonic ESB	On-line	Sonic
17.	Запуск проведения операции по карте	Spectrum	Way4	On-line	Вызов команды операционной системы
18.	Авторизация для проведения операции	Spectrum	Way4	On-line	Вызов команды операционной системы
	Потоки данных между системами Spectrum и PC-POS
19.	Определение принадлежности карты	Spectrum	Sonic ESB	On-line	Sonic
20.	Запросы серверу приложений со стороны кассира	PS-POS	Spectrum	On-Line	HTTP(s)
	Потоки данных между системой Spectrum и Общим файловым ресурсом
21.	Сохранение проводок	Spectrum	Общий файловый ресурс	Off-Line	(s)FTP
22.	Формирование файла подтвержденных платежей	Spectrum	Общий файловый ресурс	Off-Line	(s)FTP
23.	Получение курсов конверсии	Общий файловый ресурс	Spectrum	Off-Line	(s)FTP
24.	Копирование сканов документов	Бисквит	Общий файловый ресурс	Off-Line	NFS
25.	Получение сканов документов	Общий файловый ресурс	Spectrum	Off-Line	NFS
	Потоки данных между системами Spectrum и LTW TP
26.	Запрос статуса загрузки курсов	LTW TP	Spectrum	On-Line	SOAP
27.	Команда на загрузку курсов	LTW TP	Spectrum	On-Line	SOAP
	Потоки данных между системами Spectrum и ЕФР
28.	Инициация взаимодействия	ЕФР	Spectrum	On-Line	SOAP	SpectrumStartService
29.	Восстановление контекста операции	Spectrum	ЕФР	On-Line	SOAP	SiebelGetOperationInfo

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

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

В части пользователей:

· Количество пользователей — 25 000;

· Количество одновременно работающих пользователей – 15 000, при этом 8 000 могут войти в систему одновременно в течение 20 минут;

В части объемов БД:

· Количество клиентских записей — 15 000 000;

· Количество клиентских счетов —50 000 000;

· Количество клиентских договоров —20 000 000;

В части выполнения операций:

· Время формирования оперативной отчетности — не более 1 минуты;

· Время перехода между экранными формами (в штатном рабочем режиме, без учёта времени ожидания ответа сервисной шины, без учёта сетевого взаимодействия и поиска бизнес-данных) — не более 1 секунды;

· Количество операций транзакционного сервиса – 850 000 в сутки;

· Выдерживать пиковую нагрузку по операциям транзакционного сервиса – 25 операций в секунду.

· Количество кассовых операций Клиентов ФЛ – 160000 в месяц;

· Количество кассовых операций по обслуживанию бизнеса и внутренних операций – 8335 в месяц.

Стратегия тестирования

В соответствии с целями нагрузочного тестирования функционала «Транзакционный сервис» ИС «Спектрум» планируется провести тест определения максимальной производительности Системы и тест надежности работы Системы.

Тест надежности

Тест проводится на профилие нагрузки «День».

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

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

Критериями успешного прохождения системой теста являются:

1) Отсутствие деградации производительности системы в ходе теста

2) Отсутствие «утечки» памяти в течение теста

При длительном тесте надежности буд