Scientific journal
Modern high technologies
ISSN 1812-7320
"Перечень" ВАК
ИФ РИНЦ = 0,899

METHODICAL FOUNDATIONS OF LOAD TESTING OF THE BANKING NOTIFICATION SYSTEM

Chernikov B.V. 1, 4 Solomatnikova A.A. 2, 3 Borisova E.A. 4
1 LLC «Gazprom VNIIGAZ»
2 Moscow Institute of Electronic Technology
3 LLC «Aplana»
4 Plekhanov Russian University of Economics
Economic and social development of society increases the role of banks in human life. The number of services provided by banks is growing annually. Along with the growth of services, the number of bank customers who are attracted by certain services is growing. One of such services is the notification system, which is provided by the general bank service of sending messages to bank customers through various communication channels. The main problem of the growth in the number of services provided by the bank is the need to constantly refine and improve the customer notification system. The second problem that arises from the first one is an increase in the load on the server and network equipment due to the constant increase in the number of users, which may eventually lead to system malfunctions, performance drops, and, as a result, bank loss of reputation. Thus, ensuring the stable operation of the system with an increase in the number of customers is a necessity. Load testing of the notification banking system can allow solving this problem. However, before load testing it is necessary to conduct a large amount of preparatory operations. The analysis of various parameters, the collection of information about the system, the creation of a test procedure and a test circuit are just a small list of those preparations that are carried out before testing. This article is an introductory part of a scientific study, which will be devoted to the development of methods and algorithms for load testing, which will reduce the amount of operations performed before testing and systematize them.
banking notification system
load testing
test circuit
testing methodology

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

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

Основной проблемой увеличения количества предоставляемых банками услуг является необходимость постоянного совершенствования системы оповещения клиентов посредством различных каналов связи [1]. Связано это как с тем, что банки постоянно конкурируют в стремлении улучшить свой функционал и добавить новые возможности в систему банковской нотификации, так и с тем, что техническое развитие в мире тоже не стоит на месте, появляются новые устройства, приспособления и возможности. Если их не учитывать, то пользователи, которые следят за новинками в мире техники и используют их, просто не захотят пользоваться устаревшими технологиями. Поэтому для качественной, быстрой и удобной доставки сообщений и уведомлений каждый банк выбирает свои системы, протоколы и интерфейс, с которыми он работает, учитывая мнение и ожидания пользователей. Доставляемый клиентам контент тоже может быть различных типов: это могут быть текстовые и голосовые сообщения, графические рассылки или мультимедийные сообщения, которые принимают форму SMS (Short Message Service), MMS (Multimedia Messaging Service), факсов (например, система получает электронное письмо и отправляет его как факс), звонки (в том числе и с интерактивным меню, синтезом и распознаванием речи), электронная почта, системы обмена мгновенными сообщениями через интернет (Telegram, WhatsApp, Viber и другие). Кроме того, при передаче могут применяться комбинации различных способов, что в свою очередь требует комбинации каналов обработки нотификационных сообщений на приемной стороне. Все это требует постоянного обновления систем, как на уровне добавления новых функций, так и замены целых блоков программ на новые.

В работе [2] компания Dell EMC объявляет результаты исследования ESG 2017 IT Transformation Maturity Curve, проведенного аналитической компанией Enterprise Strategy Group (ESG): «В ходе опроса руководителей одной тысячи организаций из разных стран выявлено четыре этапа зрелости, достигнутой ими в области трансформации информационных технологий (ИТ):

– этап 1 – «Отстающие» (12 %). Организации на данном этапе отстают по многим, если не по всем, результатам оценки ИТ-трансформации в исследовании ESG;

– этап 2 – «Начинающие» (42 %). Организации демонстрируют прогресс в области ИТ-трансформации, но с минимальным внедрением современных технологий центров обработки данных;

– этап 3 – «Развивающиеся» (41 %). Организации демонстрируют приверженность трансформации ИТ и показывают средний уровень развертывания современных технологий центров обработки данных и методов доставки ИТ-услуг;

– этап 4 – «Трансформированные» (5 %). Наиболее продвинутые организации в области ИТ-трансформации.

Большинство респондентов (71 %) согласны с тем, что ИТ-трансформация необходима для сохранения конкурентоспособности бизнеса. 85 % из числа «трансформированных» компаний считают, что их организации находятся в «очень сильной» или «сильной» позиции, чтобы конкурировать и преуспевать на своем рынке в течение следующих нескольких лет, в отличие от 43 % наименее зрелых компаний».

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

Компания Riverbed Technology провела первое международное исследование Riverbed Global Application Survey 2015. Согласно данному исследованию 71 % респондентов во всём мире не понимают, почему корпоративные приложения их компании работают медленно. В отдельно взятых регионах ситуация еще хуже: в странах Европы, Африки и Ближнего Востока уже 76 % респондентов ответили так, а в странах Азии – 75 %. Данный факт говорит о том, что ИТ-специалисты изолированы от руководителей бизнеса. В попытках решить свои проблемы со скоростью работы приложений 35 % опрошенных использовали несанкционированные приложения, 25 % дольше задерживались на обеде, 28 % оправдывали срывы сроков корпоративными приложениями, 23 % уходили раньше с работы [4].

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

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

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

Нагрузочное тестирование – это исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов (определение «запаса прочности»). Нагрузочное тестирование проводится в рамках тестирования производительности. Тестирование производительности – исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке [5]. Перед началом нагрузочного тестирования необходимо провести значительный объем подготовительных работ (рис. 1).

chern1.tif

Рис. 1. Структура процесса подготовки к нагрузочному тестированию

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

– производительность конкурирующих приложений;

– общепринятые критерии производительности, соответствующие системе;

– производительность эксплуатируемой версии приложения, с целью определения требующих профилирования функций, процессов, операций и т.д.;

– экспертное мнение разработчиков, системных администраторов и администраторов баз данных относительно конфигурации аппаратно-программного обеспечения системы с целью определения теоретических пределов работы системы;

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

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

– перечень тестируемых операций;

– интенсивность выполнения операций;

– зависимость изменения интенсивности выполнения операций от времени.

В список тестируемых задач должны войти операции, критичные с точки зрения как процессов ведения бизнеса, так и с технической точки зрения [6].

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

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

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

Особенности создания тестового контура

Если система нотификации уже является рабочей, а не только что написанной и готовой после различных тестов впервые запуститься для использования, то проводить любое тестирование на ней нельзя, особенно нагрузочное. Причиной этого является то, что нагрузочное тестирование является своего рода DDoS-атакой (Distributed Denial of Service) на систему. В связи с этим проведение тестирования во время, когда реальные пользователи работают с системой, приведет к тому, что у этих пользователей работа будет идти некорректно. Им будет казаться, что у системы есть ошибки и снижение производительности при работе и стоит, наверное, поискать другой банк, который своевременно и правильно будет уведомлять их о состоянии счетов или других услугах, которые они ждали. Поэтому для тестирования нужно собрать тестовый контур. Нужно изучить технические характеристики серверов промышленного стенда и постараться воссоздать их. Если такой возможности нет, и характеристики по каким-то причинам отличаются (как в таблице), то необходимо сравнить их и рассчитать расхождение между показателями на тестовом и промышленном стендах.

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

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

Особенности разработки и испытания нагрузочных скриптов

Одной из основных проблем нагрузочного тестирования является вопрос – какие тесты проводить и нужны ли конкретные тесты тестируемой системе [7]. В случаях, когда на все виды тестирования просто не хватает времени и нужно выбирать несколько приоритетных видов, следует учесть, какое тестирование необходимо именно в конкретной ситуации.

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

– количество операций за определенный период времени;

– время отклика системы;

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

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

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

Как и для тест-кейсов, в структуре нагрузочных скриптов стоит соблюдать трехзвенную архитектуру написания (рис. 2):

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

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

– третье звено отвечает за корректное завершение теста.

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

Назначение

Стенд

Кол-во

Характеристики

Соотношение ( %)

Кол-во серверов

CPU (кол-во ядер)

Memory

HDD

Серверы

приложений

Пром.

5

5 CPU 16

5 RAM GB

3 HDD 100 GB

2 HDD 110 GB

100

100

100

96

Тест.

5

5 CPU 16

5 RAM 8 GB

5 HDD 100 GB

Сервер СУБД

Пром.

2

2 CPU 64

2 RAM 192 GB

2 HDD 136 GB +

2 HDD 2TB Backup +

2 HDD 3TB Archive +

2 HDD 2TB Data

50

22

33

7

Тест.

1

CPU 28

RAM 128 GB

HDD 60 GB +

HDD 1000 GB для БД

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

chern2.tif

Рис. 2. Структура скриптов нагрузочного тестирования

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

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

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

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

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

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

Если встроенных средств мониторинга не предусмотрено, то следует подключать сторонние средства или указывать в ограничениях тестирования, мониторинг чего будет или не будет производиться. В ограничения тестирования должно попадать все, что выходит за рамки тестирования или не соответствует каким-либо параметрам [10].

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

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

После проведения тестов надо вернуться к анализу, но уже – результатов. Многие средства нагрузочного тестирования собирают обширные результаты, которые потом можно перевести в графики для наглядности результатов [11]. Если по этим результатам выявились какие-то отклонения работы системы и эти отклонения разработчики могут быстро поправить, для следующей итерации тестирования не требуется пересобирать данные, переписывать скрипты или заново наполнять базу. Если же отклонения признаны несущественными или оперативно не могут быть исправлены, то результаты вносятся в отчет, и для повторного тестирования (которое будет проводиться через значительный отрезок времени) нужно снова собирать, анализировать и писать с самого начала.

Направления последующего исследования

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

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

1. Проанализировать существующие системы нотификации банков.

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

3. На основе разработанной методики сформировать алгоритм нагрузочного тестирования.

4. Провести тестирование и проанализировать результаты.

Заключение

1. Обоснован порядок проведения нагрузочного тестирования банковских систем нотификации.

2. Рассмотрены подготовительные этапы нагрузочного тестирования. Значительный объем подготовительных работ требует много времени на его проведение, следовательно, для ускорения процесса проведения тестирования необходимо автоматизировать проводимые операции.

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

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

5. Сформулированы цели и задачи на последующее исследование.