Научный журнал

Современные наукоемкие технологии

ISSN 1812-7320

"Перечень" ВАК

ИФ РИНЦ = 0,940

• Авторы
• Резюме
• Файлы
• Ключевые слова
• Литература

Черников Б.В. 1, 4 Соломатникова А.А. 2, 3 Борисова Е.А. 4

---

1 ООО «Газпром ВНИИГАЗ»

2 НИУ «Московский институт электронной техники»

3 ООО «Аплана»

4 Российский экономический университет им. Г.В. Плеханова

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

Статья в формате PDF

0 KB

банковская система нотификации

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

тестовый контур

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

1. Перова Г.И. Современные технологии обслуживания клиентов в банковской сфере // Среднерусский вестник общественных наук. 2013. № 2. C. 182–186.

2. IT Transformation Maturity Curve // The Enterprise Strategy Group, Inc., 2017. [Electronic resource]. URL: https://www.emc.com/collateral/analyst-reports/esg-dellemc-it-transformation-maturity-report.pdf (date of access: 25.03.2019).

3. Кудряшов В.С., Птицын Е.Ю. Перспективы развития интернет-банкинга как услуги коммерческого банка // Juvenis scientia. 2017. № 6. С. 18–21.

4. Riverbed Global Application Survey, 2015. [Electronic resource]. URL: https://www.riverbed.com/document/fpo/media-cms/0739_RVBD_AppPerformanceGap_SurveyReport.pdf (date of access: 25.03.2019).

5. Куликов С. Тестирование программного обеспечения. 2-е изд. 2016. 298 с. [Электронный ресурс]. URL: http://svyatoslav.biz/software_testing_book_download (дата обращения: 25.03.2019).

6. Блэк Р. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. М.: Лори, 2011. 544 с.

7. Molyneaux I. The Art of Application Performance Testing: From Strategy to Tools // Sebastopol, CA, USA: O’Reilly Media, Inc. 2015. 278 р.

8. Савин Р. Tестирование dot com или Пособие по жестокому обращению с багами в интернет-стартапах. М.: ДЕЛО, 2007. 311 c.

9. Fatema K. et al. A survey of Cloud monitoring tools: Taxonomy, capabilities and objectives. Journal of Parallel and Distributed Computing. 2014. № 10. Т. 74. Р. 2918–2933.

10. Темичев А.А., Файзрахманов Р.А. Подбор параметров нагрузочного тестирования систем мониторинга с использованием нечеткой логики // Эл. науч. журн. «Инженерный вестник Дона». 2015. № 3. Т. 37. С. 38.

11. Мясников С.О., Намиот Д.Е. Инструменты нагрузочного тестирования // Прикладная информатика. 2018. Т. 13. № 1 (73). С. 92–102.

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

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

Основной проблемой увеличения количества предоставляемых банками услуг является необходимость постоянного совершенствования системы оповещения клиентов посредством различных каналов связи [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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Библиографическая ссылка