Особенности тестирования производительности информационных систем планирования и анализа бюджета муниципального образования

Иван Савчук

Особенности тестирования производительности информационных систем планирования и анализа бюджета муниципального образования

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

Информатика

Дипломы

Вуз: Балтийский федеральный университет имени Иммануила Канта (БФУ им. И. Канта)

ID: 5f31b258cd3d3e0001b6a23c

UUID: 9b9f6940-bd78-0138-165a-0242ac180006

Язык: Русский

Опубликовано: больше 4 лет назад

Просмотры: 27

28.6

Иван Савчук

Комментировать 11

Рецензировать 1

Скачать - 2,5 МБ

Поделиться работой

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГООБРАЗОВАНИЯ РФ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БАЛТИЙСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ им. И. КАНТА» ИНСТИТУТ ФИЗИКО-МАТЕМАТИЧЕСКИХ НАУК И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Рекомендована к защите: методический руководитель направления подготовки доцент ИФМНиИТ _________________ Д.А. Савкин Допущена к защите: первый заместитель директора ИФМНиИТ, к. ф.-м. н., доцент ____________А.А. Шпилевой "____"______________ 2020 г. "____"______________2020 г. ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА Тема: «Особенности тестирования производительности информационных систем планирования и анализа бюджета муниципального образования» Направление подготовки: 01.04.02. «Прикладная математика и информатика» Магистерская программа: «Информационные системы в государственном и муниципальном управлении» Квалификация (степень): магистр ВКР защищена на оценку: ___________________ Выполнил: студент 2 курса ____________ И.В. Савчук Руководитель: к.ф.-м.н., доцент ИФМНиИТ _________ Б.Р. Мищук

Рецензент: Руководитель направления автоматизированного и нагрузочного тестирования ООО «БФТ» ____________ Е.А. Разиньков Калининград, 2020 Оглавление Введение.............................................................................. 3 1. Бюджетная система РФ..................................................6 1.1. Понятие бюджетного механизма.............................6 1.2. Структура бюджетного механизма РФ.....................8 1.3. Этапы и особенности распределения бюджета РФ ................................................................................................. 13 1.4. Использование электронной бюджетной системы17 Глава 2. Тестирование производительности...................21 3.1 Концепции производительности.............................21 3.2 Виды тестирования производительности...............23 3.3 Процесс тестирования производительности..........29 3.4 Инструменты для тестирования производительности, мониторинга и анализа результатов.32 Глава 3. Тестирование производительности системы «АЦК-Планирование»...............................................................43 3.1 Анализ проекта.........................................................43 3.2 Планирование теста производительности..............47 3.3 Настройка среды тестирования...............................50 3.4 Подготовка нагрузочных тестов..............................52 3.5 Запуск тестов............................................................61 3.6 Анализ результатов..................................................61 3.7 Оптимизация и завершение тестирования.............68 Заключение.......................................................................70 Список использованной литературы...............................72 Приложения......................................................................76 2

Введение Рынок российского программного обеспечения (ПО) быстро развивается, и не только в потребительском сегменте, но и в сфере госзакупок. Так, на 24 апреля 2019 года стало известно, что доля отечественного ПО в закупках госорганов составляет на апрель 2019 года 65%, в то время как в 2015 г. она достигала всего 20%. Такие данные привел заместитель главы Минкомсвязи Алексей Соколов[1]. Такой скачок Правительства стал следствием постановление РФ от 16 ноября 2015 г. № 1236 “Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд” [2] и подписанием Президентом России Федерального закона от 29 июня 2015 г. N 188-ФЗ "О внесении изменений в Федеральный закон "Об информации, информационных технологиях и о защите информации" и статью 14 Федерального закона "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд"[1]. Вследствие чего востребованность компании ООО финансовых "Бюджетные программных и финансовые продуктов технологии" возрастает с каждым годом, так же как возрастает и нагрузка на эти системы, когда с ними работает все больше людей. Любые ошибки в работе сложной финансовой системы в первую очередь могут привести к значительным финансовым проблемам и утрате доверия к поставщику ПО. По это 4

причине необходимо тщательное тестирование всей системы перед выдачей ее заказчику[16]. И наряду с функциональным тестированием не менее важно тестирование производительности, так как с системой впоследствии будут работать сотни и тысячи людей одновременно, создавать и обрабатывать электронные документы. И здесь важна как скорость работы, так и стабильность работы всей системы и ее отдельных компонентов. По расчетам Минкомсвязи, к 2024 г. доля российского ПО будет доведена до 90% в закупках госорганов, и до 70% — в закупках госкомпаний. На 2019 г. для госкомпаний запланирован показатель на уровне не менее 45%. Министерство также привело актуальные данные о Реестре отечественного ПО, который ведет с 2016 г. — на апрель 2019 года там насчитывается более 5,2 тыс. программных продуктов в 24 различных классах. Целью является данной выпускной разработка производительности схемы квалификационной комплексного информационной работы тестирования системы, предназначенной для планирования и анализа бюджета с целью улучшения качества программного комплекса «АЦКПланирование». Для достижения данной цели прославлены следующие задачи:  Изучить особенности электронного бюджетирования РФ; 5

 Исследовать инструменты производительности для тестирования и анализа результатов и провести комплексное тестирования;  Разработать схему тестирование производительности системы «АЦКПланирование»;  Проанализировать результаты тестирования производительности. Практическая значимость выпускной квалификационной работы определяется тем, что с разработанной уменьшаются время производительности, и а затраты также на повышается схемой тестирование качество и стабильность выпускаемого ПО. Выпускная квалификационная работа состоит из введения, трех глав, заключения, списка использованных источников и приложения. 6

1. Бюджетная система РФ 1.1. Понятие бюджетного механизма В отечественной экономической литературе вопросы формирования и функционирования бюджетного механизма недостаточно исследованы и обоснованы. Понятие «бюджетный механизм» часто отождествляют с финансовым механизмом, составной не совсем последнего, специфические правильно, бюджетному черты, поскольку, механизму связанные с являясь присущи особенностями функционирования бюджетных отношений, специфическими формами и методами мобилизации и использования бюджетных средств. Конечно, бюджетный механизм имеет отдельные черты финансового механизма. характеризуя сферу существующих Так, бюджетный использования отношений, выступает механизм, объективно составным звеном общей системы управления экономикой, занимая в ней свое место. Также обусловлен бюджетный реальным механизм, с одной существованием стороны, бюджетных отношений, с другой – обратно активно влияет на них. Наряду с общими чертами финансового и бюджетного механизма, последний имеет в собственности и свои особенности, выражающиеся в совокупности определенных видов бюджетных отношений, специфических методов мобилизации и использования бюджетных средств. Подходы к толкованию категории «бюджетный механизм» отмечаются разным уровнем детализации его 7

составляющих. В широком понимании бюджетный механизм – это «совокупность форм, методов, рычагов и инструментов использования государственного бюджета и влияния на социально-экономическое развитие". Сущность бюджетного механизма можно определить двумя подходами бюджетный к этому механизм функционирование Материальным являются понятию. можно самых потоки. одной стороны, понимать бюджетных отражением денежные С средств. финансовых Организация как отношений этих потоков, порядок их осуществления происходят за определенными правилами и направлениями. В этом случае бюджетный механизм отражает внутреннюю организацию функционирования финансовых ресурсов. С другой стороны, бюджетный механизм рассматривается как совокупность методов и форм, инструментов, приемов и рычагов влияния на состояние и развитие экономики. Этот подход отражает внешнее воздействие функционирования бюджета и характеризует финансовые ресурсы как фактор влияния на состояние экономики [9]. Д. В. Дементьев трактует бюджетный механизм как "совокупность форм и методов, рычагов и инструментов мобилизации и использования бюджетных средств" [10]. Курченко Л.Ф. рассматривает бюджетный механизм как категорию назвать управления: механизмом "Бюджетный управления механизм бюджетным можно процессом, реализации на практике функций и принципов бюджетной системы и бюджетной политики на базе норм бюджетноналогового права" [11]. 8

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

1.2. Структура бюджетного механизма РФ С целью более глубокого раскрытия сути бюджетного механизма целесообразно рассмотреть его функциональную структуру, то есть функции каждого элемента в системе. Исследуя бюджетный механизм, Ю. Пасечник определяет его составляющие (бюджетное планирование и регулирование, финансовые показатели, нормативы, лимиты, резервы, систему управления бюджетными средствами) и их сущность. Можно выделить некоторые составляющие, которые действуют как единое целое с характерным комплексом только им присущих черт. Прежде бюджетных всего, это ресурсов, блок что рычагов находит по свое мобилизации отражение в конкретных видах налогов и платежей. Следующий блок ориентирует на использование бюджетных ресурсов через принципы и методы бюджетного финансирования. И, наконец, блок бюджетного регулирования, обеспечивает функционирование всей бюджетной системы. В каждом из звеньев есть элементы: конкретные виды бюджетных расходов, доходов и поступлений (см. рисунок 1). 10

Рисунок 1. Структура бюджетного механизма Функционируют помощью звенья методов бюджетного (приемов), механизма способов, с условий, определяющих объем и движение бюджетных ресурсов. В структуре выделяться бюджетного отдельные механизма блоки, что также могут обусловлено функциональными особенностями управления бюджетными отношениями: – бюджетного планирования и бюджетного прогнозирования; – исполнения бюджета; – бюджетного контроля и т.д. [12]. Каждый из принципами, приемами), указанных блоков специфическими с помощью характеризуется методами которых (способами, решаются задачи, возникающие на каждой стадии бюджетного процесса: 11

1) механизм регионального бюджетного планирования. Он предназначен для осуществления бюджетного планирования на уровне региона и включает процессы составления, рассмотрения и утверждения бюджета, а также методологию и методику их осуществления. С помощью особых приемов и методов, используемых в блоке бюджетного планирования, составляется финансовый план, который отражает мобилизацию и расходование бюджетных средств на уровне региона. В РФ местный бюджет, также как и федеральный, планируется на один финансовый год. Основными принципами планирования бюджета по Бюджетному кодексу являются: – принцип преемственности; – принцип приоритетности; – принцип обоснованности. Порядок разработки проекта регионального бюджета определяется Правительством РФ. Основой для разработки проектов местных бюджетов на предстоящий финансовый год являются (см. рисунок 2): 12

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

финансовых ресурсов и маневрирования ими. Перечисленные звена бюджетного механизма, в свою очередь, содержат соответствующие элементы. Так, бюджетный механизм мобилизации денежных средств характеризуется налоговыми и неналоговыми методами поступления финансовых ресурсов, получает свое выражение в конкретных видах налогов – налога на добавленную стоимость, акцизного сбора, налога на прибыль и других. Механизм предоставления бюджетных средств учреждениям реализуется финансирования и Механизм предприятиям, с организациям помощью и соответствующего обеспечения денежными средствами. межбюджетного распределения и перераспределения финансовых ресурсов характеризуется закреплением доходов по надлежащим звеньями бюджетной системы и различными методами бюджетного регулирования — дотациями, субвенциями. Каждому структурному звену и элементу бюджетного механизма соответствуют свои функциональные особенности, они обусловлены теми задачами и целями, для решения которых они предназначены. Несмотря на относительную самостоятельность, механизма элементы функционируют как и звенья единое бюджетного целое. Именно взаимосвязь действия всех структурных звеньев и элементов обеспечивает синхронность функционирования бюджетного механизма в целом [15]. Научные подходы к пониманию бюджетного механизма требуют пересмотра экономическому и положению адаптации к социально- государства в современной среде, вследствие чего объективно возникла потребность 14

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

совокупностью инструментов, которые в целом формируют инструменты бюджетного механизма и к ним относят ставки налогов, нормативы, лимиты, резервы, штрафы, льготы, ставки заработной платы. Роль информационной составляющей является основой быстрой реакции на ситуацию и необходимости внесения коррективов в финансовый и бюджетный механизмы на современном внимания. этапе Это развития означает, ей что инструментами-регуляторами уделяется наряду с все больше традиционными бюджетной политики во внимание стали приниматься также новые информационные инструменты, в частности, открытость и доступность информации о состоянии бюджетной системы и социальноэкономических процессах в целом для каждого члена общества. Итак, бюджетный механизм включает взаимодействие бюджетных методов, инструментов и рычагов, с помощью которых определяются оптимальные объемы формирования и использования для обеспечения социально – экономического развития общества [2]. То есть, выступая составным звеном общей финансовой системы государства, выполнению двух бюджетный основных механизм функций: сводится к финансового регулирования экономикой и социальными процессами и финансового их обеспечения. Поэтому функционирования только одного бюджетного механизма не может обеспечить оптимального различных объема уровней и формирования их ресурсов рационального бюджетов использования, эффективность функционирования бюджетного механизма 16

может быть достигнута взаимодействия механизма. всех согласованного составляющих Чрезвычайно согласования путем важным мероприятий по хозяйственного является обеспечение совершенствованию всех составляющих хозяйственного механизма, направленных на повышение эффективности общественного производства. 1.3. Этапы и особенности распределения бюджета РФ Бюджетная система РФ предоставляет средства, с помощью которых правительство решает, сколько денег потратить и на что потратить, и как собрать деньги, которые оно решило потратить. бюджетная система Правительство После принятия обеспечивает использует этих их бюджетную решений выполнение. систему для определения распределения ресурсов между его основными функциями, такими как обеспечение национальной обороны, развитие торговли и оказание медицинской помощи, а также для определения целей и масштабов отдельных программ, проектов и видов деятельности. Хотя бюджетная система сосредоточена федеральная бюджетную на рублях, занятость, систему. другие также Решения, ресурсы, такие контролируются принятые в как через бюджетном процессе, затрагивают нацию в целом, государственные и местные органы власти и отдельных россиян. бюджетные решения имеют всемирное значение. 17 Многие

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

Минэкономразвития РФ и ЦБ РФ, синхронно с подготовкой сценарных условий, представляют рекомендации по направлениям бюджетной политики. 2 этап. После того, как Правительством РФ будут одобрены сценарные условия и направления бюджетной политики, Минэкономразвития РФ доводит их до субъектов РФ и органов исполнительной власти РФ. Федеральные ведомства и министерства начинают подготавливать свои предложения, принимая во внимание отраслевые особенности. Так, Федеральной комиссией по рынку ценных бумаг подготавливаются предложения по развитию рынка ценных бумаг; Министерством здравоохранения и социального развития определяются главные направления по развитию социальных процессов, политики доходов, обеспечения занятости и т.п. Система органов исполнительной власти субъектов РФ представляет федеральным органам, которые выступают в качестве государственных заказчиков федеральных целевых программ, рекомендации по их осуществлению на территории определенных субъектов РФ. Для того, чтобы спрогнозировать консолидированный бюджет, они также представляют по показателям бюджетной классификации отчеты о результатах исполнения бюджетов за прошлый год и ратифицированные бюджеты на следующий год. Минэкономразвития РФ всю эту информацию обобщает и передает в Правительство РФ. В то же время Минэкономразвития РФ передает в Минфин РФ главные показатели по прогнозу российского социально- экономического развития в целом и по государственным 19

субъектам, а также список межгосударственных и федеральных целевых программ, которые предлагаются к финансированию из бюджета государства, указывая проект сводной бюджетной заявки, а также источники и объемы финансирования. 3 этап. После того, как Правительство РФ рассмотрит всю информацию, Минэкономразвития РФ передает органам исполнительной власти РФ и субъектам РФ уточненную информацию по предварительному прогнозу, необходимую для разработки региональных и отраслевых прогнозов, а также для того, ассигнования чтобы по спроектировать инвестиционным бюджетные программам и федеральным целевым. 4 этап. Исполнительные органы власти и субъектов РФ, а также государственные заказчики федеральных целевых программ передают уточненные прогнозы по социальноэкономическому развитию отраслей экономики и регионов в Минэкономразвития РФ принимая во внимание результаты предварительного рассмотрения, оценку экономического состояния, возможные варианты стабилизации экономики, а также уточняются расходы на осуществление государственных целевых программ отталкиваясь от объемов их финансирования, которые уточнены в федеральном бюджете. 5 этап. Минэкономразвития Правительство конечный экономическому развитию РФ прогноз РФ, передает по проект в социальнопо сводному финансовому балансу с разбивкой по субъектам РФ; объемы поставок продукции для федеральных 20 нужд; список

первостепенных социально-экономических проблем (задач), которые должны решиться в следующем году, и государственных целевых программ, которые предлагаются к финансированию за счет государственного бюджета; проект по развитию экономического государственного сектора и пр. В соответствии с прогнозом Правительством РФ происходит утверждение основных показателей:  объема и динамики ВВП;  прогноза инфляции;  объемов производства и реализации продукции, работ и услуг;  объемов инвестиций в основной капитал по всем источникам финансирования;  расчетов фонда заработной платы;  объемов доходов (прибыли);  показателей импорта и экспорта;  прогноза ставок рефинансирования ЦБ РФ и курса рубля;  проектировок главных характеристик по сводному финансовому балансу. 1.4. Использование электронной бюджетной системы Использование ИКТ (информационно- коммуникационных технологий) в государственном секторе охватывает все виды государственной деятельности, включая бюджетную сферу. Термин «электронное бюджетирование» используется для обозначения любого 21 приложения или

инструмента ИКТ, которые используются для бюджетных функций, процедур или услуг в течение бюджетного цикла (планирование, составление бюджета, ассигнования, контроль и оценка финансовых ресурсов). Электронное бюджетирование включает в себя три различных, хотя и связанных, профиля: первый и основной состоит из оцифровки бюджетных процедур; второй связан с распространением бюджетной информации на публике в открытом формате (открытые данные); третий касается использования комплексных баз данных (БД) бюджетной информации для формирования политики (большие данные). Автоматизированные решения, позволяющие государственным учреждениям планировать, исполнять и контролировать бюджет, обычно называются системами финансового управления и информации (ИСФМ). ИСФМ помогает лицам, принимающим решения, соблюдать финансовые правила и стандарты отчетности. Кроме того, платформы ИСФМ касающейся облегчают бюджетной потенциально могут раскрытие процедуры, оказать и, информации, следовательно, благотворное влияние на подотчетность и участие правительства. Есть много инструментов в примеров использования бюджетной процедуре. электронных Интересное использование электронных инструментов можно наблюдать в области составления бюджета на основе участия - то есть процесса, в котором члены сообщества принимают непосредственное участие в принятии решений о том, как расходовать часть государственного бюджета. Использование 22

ИКТ в бюджетировании с участием населения в основном направлено на расширение участия граждан. Первое преимущество, бюджетных процедур связанное — это с оцифровкой экономия средств. Проектирование государственных услуг (включая бюджет) в цифровом формате может сэкономить от 6,5 до 10 миллиардов евро в год. Например, оцифровка процедур государственных закупок может сократить расходы на государственное управление на 15-20%, при этом экономия составит около 100 млрд. евро в год. Вторым преимуществом электронного бюджетирования является снижение административного бремени. Это бремя состоит из затрат, которые несут граждане и бизнес, когда они обязаны выполнять установленные бюрократические государственным требования, регулированием. Ожидается, что внедрение цифровых процедур поможет установить процедуры, повысить эффективность и сократить предприятий. Реализация административную расходы для политики граждан и единовременной регистрации означает, что пользователи будут вводить свою личную информацию в административных целях. Более того, снижение административного бремени влияет на удовлетворенность граждан государственными услугами. Второе значение электронного бюджетирования заключается в распространении бюджетной информации через Интернет чувствительный государственные в открытом формате. политический вопрос. деньги собираются 23 и Это То, очень как распределяются,

является предметом общего интереса: на всех влияет принятие решений, касающихся фискальной / бюджетной политики. Как следствие, распространение информации о распределении государственных средств играет жизненно важную роль в преодолении дефицита отчетности государственных учреждений. Цифровые технологии считаются повышения прозрачности решением для вопросах. «Открытые данные» — потенциальным в бюджетных это концепция, используемая для обозначения наборов данных, которые можно свободно использовать и распространять без какихлибо юридических Поскольку или технологических доступность ограничений. Интернета продолжает увеличиваться, ожидается, что спрос на увеличение объемов (и качества) информации, касающейся деятельности органов государственной власти, будет усиливаться. Эти запросы на информацию будут включать данные о бюджетах, которые включают бюджетные данные, а также другие компоненты правительственной финансовой деятельности, такие как дополнительные бюджетные средства, налоговые расходы и условные обязательства. Это также демонстрируется растущим использованием термина «открытые бюджетные данные» и его лексических вариантов в Интернете и социальных сетях [12]. Большинство средства правительств в наращивание разработки инструментов вложили потенциала для выпуска бюджетном цикле в открытом формате. 24 и значительные технологии для информации о

По данным Всемирного банка, в мире существует 48 стран, где гражданское возможность общество и воспользоваться граждане имеют информацией о государственных финансах, публикуемой в Интернете, для мониторинга бюджета и обеспечения подотчетности своих правительств. Однако прогресс неравномерен. Всемирный банк сообщает, что «правительства стран с высоким и средним уровнем дохода динамически публикуют бюджетные данные в различных форматах, в основном из централизованных систем». В Европе примеры Германии и Великобритании являются образцовыми. В Германии система государственного прозрачности и бюджета публикации подлежит на всех обязательной административных уровнях. Например, штат Баден-Вюртемберг публикует и связывает все документы, связанные с бюджетным процессом. С другой стороны, страны с низким уровнем дохода, как правило, публикуют статические бюджетные данные, в основном через документы, размещаемые на вебсайтах государственных финансов. Но несмотря на то, что цифровизация активно проникает в государственную экономику, имеет полную государственную и президентскую поддержку, проводится активная деятельность в области мобильной государственной идеи в СМИ, имеет место постоянное обсуждение самых результативных методов и способов организации процесса на разных совещаниях крайне медленно. технологических и форумах, цифровизация Существует проблем и большое проблем, непосредственно связаны с интеграцией. 25 проходит количество которые

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

Глава 2. Тестирование производительности Создание успешного продукта зависит от двух основных компонентов - функциональности и производительности. К «Функциональности» относится набор возможностей, которые приложение предоставляет своим пользователям, включая транзакции, которые оно делает, и информацию, которую оно делает доступной. «Производительность» относится к способности системы совершать транзакции, а также быстро и точно предоставлять информацию, несмотря на высокое многопользовательское взаимодействие или ограниченные аппаратные ресурсы. Сбой приложения из-за проблем с производительностью можно предотвратить с помощью тестирования производительности перед выпуском программного продукта. 3.1 Концепции производительности Тестирование производительности — это набор типов тестирования, предназначенных пользовательских запросов к для системе воссоздания и сравнения ожидаемых результатов с полученными показателями, а также для определения скорости процедур, стабильности, надежности и масштабируемости системы в целом. Полученные результаты позволяют находить узкие места в системе. Узкие компонент в места — системы, это единственная которая 27 точка сдерживает или всю

производительность[7]. Например, даже самый быстрый компьютер будет плохо работать в современной сети, если пропускная способность меньше 1 мегабита в секунду. Низкая скорость передачи данных может быть присуща аппаратному обеспечению , но также может возникать из-за проблем, связанных с программным обеспечением. Таким образом, тестирование производительности позволяет выявить уязвимости с пропускной способностью приложения, временем загрузки, обработкой больших объемов данных и предотвращать их в приложении[30]. Тестирование производительности сильно помогает в разработке ПО, например[5]:  Повышает надежность: тестирование производительности помогает избежать взаимных блокировок, улучшить время отклика; проверяет масштабируемость, отказоустойчивость, восстановление после сбоев и т. д.  Сокращает времени выхода продукта на рынок: тестирование сокращает производительности время выхода на значительно рынок крупных корпоративных приложений. В целом, если 98% критических блоков были успешно протестированы, то считается, что пора выпустить на рынок.  Локализовать «узкие места» системы. Такие как утечки памяти; ошибки, связанные с накоплением данных; ограничения пропускной способности сетевого канала; нерациональное использование аппаратных ресурсов и др. 28

 Тестирование повысить производительности безопасность переполнения ресурсов как памяти для помогает ПО путем обнаружения и других уязвимостей веб-приложений, так и для настольных;  Произвести сравнительный анализ. К примеру, проверить работу системы на разных операционных системах с различными конфигурациями аппаратных характеристик и т.д.;  Позволяет проверить масштабируемость приложения, чтобы точно предсказать требуемые аппаратные характеристики системы и сети, что, в свою очередь, поможет избежать проблем в будущем при расширении инфраструктуры. Ресурсные аспекты, такие как использование ЦП, оперативной памяти, когерентность кэша, согласованность данных, пропускная способность сети, также отслеживаются и регистрируются как часть тестирования производительности. Кроме того, время отклика веб-сервера, сервера приложения и сервера БД также учитываются. В совокупности производительность системы воспринимается как показатель качества с точки зрения времени отклика, пропускной способности, доступности, надежности, безопасности, масштабируемости и расширяемости. 3.2 Виды тестирования производительности 29

Существует множество производительности. видов Классификация видов тестирования тестирования производительности строится на основе того, какие цели преследует определенный вид тестирования[17]. Как правило тестирование производительности преследует не одну, а несколько целей. Это связано с тем, что многие типы тестирования в ходе его проведения совмещаются с другими целями или повторяются несколько раз на протяжении всего цикла тестирования. Однако тестирование производительности, в отличие от остальных типов тестирования, проводится только после полного функционального тестирования[33]. В ходе тестирования производительности ошибки функциональности не исправляются. правило, Для данного выделяется вида отдельный тестирования, нагрузочный как стенд, являющийся копией промышленного стенда. Таким образом, основная классификация видов тестирования производительности представлена на рисунке 3: Рисунок 3. Классификация видов тестирования производительности 30

На основе классификации из Рисунка 4 можно выделить основные виды тестирования производительности, которые проводятся чаще всего. Основные типы тестирования, а также вопросы, которые они решают можно представить в виде таблицы 1[14]: Таблица 1. Вида тестирования производительности Вид тестирования Вопрос, на тестирование Нагрузочное тестирование (Load Testing) Тестирование стабильности (Stability Testing) Стрессовое тестирование (Stress Testing) Тестирование масштабируемости (Scalability Testing) Конфигурационное тестирование (Configuration Testing) Нагрузочное наиболее Достаточно система? который ли быстро отвечает работает Достаточно ли надежно работает система на долгом интервале времени? Что произойдет незапланированной нагрузке? при Как будет увеличиваться нагрузка на компоненты системы при увеличении числа пользователей? Какая будет производительность при изменении конфигурации системы? тестирование (load testing) является распространенным подвидом тестирования производительности. Данный вид тестирования проводится для оценки поведения системы при постоянном и неуклонном увеличении нагрузки до момента достижения порогового предела, который называют точкой насыщения. Точки насыщения — это уровень нагрузки, при котором дальнейшее наращивание числа пользователей ведёт к увеличению времени отклика системы либо ухудшению стабильности 31

системы, но не к увеличению в единицу времени количества полезных операций, обработанных системой. Основная цель нагрузочного тестирования состоит в определении максимальной нагрузки, которую может выдержать система, а также в выявлении «узких мест» приложения, влияющих на производительность[13]. График увеличения нагрузки на систему за некоторый период времени (профиль нагрузки) в случае нагрузочного тестирования представлен на рисунке 4: Рисунок 4. Профиль нагрузки для нагрузочного тестирования При проведении нагрузочного тестирования общая производительность всей системы определяется следующими факторами [23]:  скоростью работы программного обеспечения; 32

 скоростью работы аппаратного обеспечения;  скоростью работы сети. Атрибуты, которые отслеживаются для более точного измерения производительности и выявления «узких мест» при нагрузочном тестировании, включают производительность, время выполнения пропускную критически в себя пиковую способность важных серверов, транзакций при определенных уровнях нагрузки, максимальное количество одновременно работающих пользователей и границы приемлемой производительности при увеличении нагрузки. Тестирование стабильности (stability testing) выполняется, чтобы убедиться, что программное обеспечение способно выдерживать ожидаемую нагрузку в течение длительного периода времени без какого-либо ухудшения времени отклика / пропускной способности[23]. Продолжительность прогонов определяются в соответствии с требованиями проекта. То есть в данном типе тестирования моделируется длительная работа пользователей для выявления перспективы долгосрочной беспрерывной работы системы, при этом сама нагрузка может иметь среднее значение (см. рисунок 5). 33

Рисунок 5. Профиль нагрузки для тестирования стабильности Основная цель этого типа тестирования – выявить и предотвратить возможные утечки памяти, непредвиденные ограничения на транзакций, количества проблемы с выполнения оборудованием некоторых серверов (перезапуск сервером или ПО), отсутствие сбоев в работе сетевого оборудования через длительный период времени[27]. Стрессовое тестирование (Stress Testing) проводится для оценки производительности системы при работе под нагрузкой, близкой превышающей ее. к пороговому Стресс-тест значению, создает нагрузку или на аппаратные ресурсы, такие как ЦП, ОЗУ, диск, сеть и позволяет определить потенциальный предел приложения при некоторых ограниченных ресурсах. 34

При стрессовом тестировании на систему в течение небольшого периода времени подается огромная нагрузка, которая, после достижения некоторого значения, начинает снижаться (см. рисунок 6) Рисунок 6. Профиль нагрузки для стресс-теста Таким образом, можно выяснить, какие компоненты системы выйдут из строя первыми в экстремальных условиях, сможет ли система после этого восстановиться, проверить корректность логирования ошибок при большой нагрузке и своевременность оповещения о их возникновении. Тестирование масштабируемости (Scalability Testing) проводится для определения эффективности работы приложения и проверки возможности его масштабирования под любым видом нагрузки. В ходе данного тестирования проверяются следующие виды масштабирования[5]: 35

 вертикальное масштабирование, увеличивают при производительности компонентов системы (добавление котором отдельных оперативной памяти, замена процессора или диска и т.д.);  горизонтальное масштабирование, целью которого является распределение количество параллельно нагрузки на работающих большее серверов, выполняющих одни и те же функции; Проведение (configuration конфигурационного testing) тестирования помогает определить производительность системы и ее отдельных компонентов на разных аппаратных убедиться что аппаратного работать выбрать на и программных конфигурациях обеспечения с одинаковой программного компоненты системы производительностью. оптимальную тестировании конфигурациях, конфигурацию. проверяется работа А При серверов и будут также данном на разных операционных системах, под управлением разных СУБД, если это web-приложение, то на разных браузерах. Таки образом, представляет собой конфигурационное метод, который тестирования оценивает производительность программного обеспечения, аппаратных составляющих серверов с учетом различных конфигураций системы. 3.3 Процесс тестирования производительности 36

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

Рисунок 7. Схема тестирования производительности - Анализ проекта. На данном этапе проводится большая работа по сбору информации о продукте, который необходимо протестировать. Изучается компоненты, подвергаемые нагрузочному определяются нефункциональные производительности системы система и ее тестированию, требования (количество к одновременно работающих пользователей, скорость ответа на запросы и т.д.). Проводится анализ функционала системы и на его основе формируются тестирования. Так сценарии же для выбирается нагрузочного инструмент для проведения нагрузочного тестирования. - Планирование теста производительности. После того, как проведен анализ информационной системы, определены сценарии и требования к данным, следующим шагом будет описание видов и стратегий тестирования системы и формирование профиля нагрузки на их основе. Выбор стратегий тестирования будет в значительной степени определяться характером приложения и количеством времени, доступным для тестирования производительности. - Настройка среды тестирования. Перед началом процесса тестирования следует ознакомится с деталями аппаратного и программного обеспечения. На этом этапе производится настройка серверов системы в соответствии с техническим заданием: конфигурация серверов настраивается (количество и аппаратная процессоров, оперативная память, выбирается система хранения данных, а 38

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

- Анализ результатов. На этом этапе собирается воедино вся полученная во время теста информация. После анализа может нагрузочный потребоваться скрипт: изменение внесение профиля изменения нагрузки в или отдельных сценариев в нагрузочном скрипте. После внесения всех изменений необходимо заново подготовить нагрузочный тест и его запуск. - Оптимизация и завершение тестирования. После выполнения всех нагрузочных тестов формируется отчет о нагрузочном поведение тестировании, информационной перечисляются все в котором системы найденные отображается под нагрузкой, дефекты, а также формируются рекомендации к оптимизации программных компонентов. И после оптимизации и исправления недочетов необходимо заново произвести нагрузочное тестирование. 3.4 Инструменты для тестирования производительности, мониторинга и анализа результатов Для проведения необходимы тестирования специализированные производительности инструменты. Главной задачей таких инструментов является генерация нагрузки на систему путем отправки запросов к серверу, тем самым имитируя работу реальных пользователей. Существует множество инструментов для проведения нагрузочного тестирования. Выбор конкретного инструмента 40

зависит от многих определенного лицензии, факторов: протокола требования поддержка передачи к инструментом данных, стоимость оборудованию, поддержка платформы и многое другое[8]. Одним из самых простых инструментов для тестирования производительности HTTP-серверов является ApacheBench (AB). Это однопоточная программа, запускаемая из командной строки[31]. AB входит в состав Apache HTTP Server и подойдет для простого тестирования любого веб-сервиса. По окончанию тестирования AB выводит в консоль отчет, в котором выводится время выполнения запроса, количество переданной информации, перцентили и количество успешных запросов. С его помощью не получится провести сложное тестирование системы, состоящее из нескольких сценариев, поэтому его используют в основном для быстрой поверки производительности сервера. Гораздо более продвинутым инструментом генерации нагрузки Apache будет JMeter. Это один из самых популярных и часто используемых инструментов генерации нагрузки. Этот инструмент развивается с 1999 года, имеет большой функционал и возможность интеграции с множеством сервисов[4]. Благодаря наличию графической оболочки, работать с этим инструментом не составляет особого труда, все расположено интуитивно понятно. Благодаря тому, что он написан на языке Java является платформо-независимым приложением, имеет встроенный proxy-сервер, сценариев, что сильно поддерживает упрощает и ускоряет многопоточную 41 запись генерацию

нагрузки и большое количество протоколов передачи данных, среды которых HTTP, TCP, SOAP, FTP, LDPA и др. JMeter имеет огромную пользовательскую базу, большое количество плагинов, расширяющих его функционал, а также возможность создания своих плагинов через API. Данный инструмент специально разрабатывался для использования специалистами по выполняющим нагрузочному тестированию, масштабные интеграционные сложные, нагрузочные тесты. Однако из разрабатываемое того факта, более двух это Java десятков приложение, лет вытекает и основной его минус – относительно невысокая скорость работы по сравнению с современными инструментами для нагрузочного тестирования и необходимость выделения большого количества ресурсов для генерации нагрузки, особенно это касается потребления ОЗУ. Также JMeter имеет скудный функционал по построению отчетов о проведенном тестировании, но это решается подключением дополнительных инструментов. Но не смотря на все это, Apache JMeter идеально подходит для тестирования больших и сложных бизнес-приложений, написанных на Java[4]. Более современным инструментом является Gatling очень мощный инструмент для нагрузочного тестирования, написанный на языке Scala. Он разработан для простоты использования, высокой удобства нагрузки. архитектуре, что обслуживания Gatling построен позволило и на реализовать достижения асинхронной генерацию виртуальных пользователей в качестве сообщений, а не 42

потоков[19]. Такой подход позволяет сэкономить генерировать достаточно большую нагрузку, задействую не так много аппаратных ресурсов. Как и JMeter является кроссплатформенным приложением, поддерживает многопоточность. Из коробки Gatling умеет строить информативные графические отчеты, имеет совместимость с любыми платформами непрерывной интеграции, так как запуск теста происходит в командной строке. Также он поддерживает выгрузку метрик в InfluxDB, что позволяет сильно расширить возможности мониторинга и анализа результатов[19]. Однако данный инструмент не имеет графического интерфейса (только в платной корпоративной версии), а тесты создаются в виде исходного кода. А с выходом новых версий может сильно измениться создаст проблемы с обратной API приложения, что совместимостью ранее созданных тестов. Tsung – это распределённая система нагрузочного и стресс-тестирования, написанная на языке Erlang. Tsung предлагает большой функционал для тестирования приложений по протоколу http, но он так же умеет работать и с многими другими протоколами. Благодаря тому что он написан на языке Erlang это, наверное, один из самых высокопроизводительных тестирования, он инструментов отлично подходит для нагрузочного для тестирования масштабируемости клиент-серверных приложений[26]. Так же имеет функционал характеристик серверов, для мониторинга но не 43 имеет аппаратных собственного

графического интерфейса и подходит только для работы на операционных систем Linux/Unix. Yandex.Tank — это расширяемый инструмент нагрузочного тестирования и анализа производительности веб-сервисов и приложений с открытым исходным кодом. В основе инструмента лежит высокопроизводительный асинхронный hit-based генератор HTTP-запросов phantom: он был переделан «научили» из работать одноименного в режиме веб-сервера, клиента[25]. который Yandex.Tank построен на модульной архитектуре, благодаря чему он может использовать в качестве генератора нагрузки Apache JMeter или Pandora, а собираемые метрики можно выгружать сразу в сервис Yandex.Overload для дальнейшего хранения и анализа результатов[22], или в базу данных InfluxDB для самостоятельного построения отчетов. Так же Yandex.Tank поддерживает настраиваемый и расширяемый мониторинг аппаратных характеристик серверов, работающий через SSH, которые так же выгружаются для построения детального отчета о проведенном нагрузочном тесте. Однако недостаточно просто нагрузить систему, необходимо так же собрать большое количество данных во время теста инструментов и для проанализировать нагрузочного их. Большинство тестирования могут отслеживать основные метрики производительности (время ответа на запрос, процент успешно выполненных запросов, количество активных пользователей, количество запросов в единицу времени, пропускная способность сети и др.), часть из этих инструментов имеет встроенный функционал для построении отчетов на основании собранных данных, но для 44

качественного анализа производительности любой системы необходимо отслеживать также аппаратные характеристики серверов (использование процессора, оперативной памяти, нагрузка на диск и т.д.) и активность СУБД[6]. Для мониторинга потребления аппаратные характеристики серверов можно использовать встроенные инструменты операционной системы, но для дальнейшего анализа эти данные должны быть собранные. Для решения проблемы мониторинга аппаратные характеристик серверов существуют Главным как платные, отличием так и платных бесплатные инструментов решения. является относительная простота установки, настройки отдельных компонентов мониторинга, система помощи и поддержки. Однако в плане функциональных возможностей они почти не отличаются от программного обеспечения с открытым исходным кодом, поэтому они не рассматриваются. Одной популярных систем мониторинга с открытым исходным кодом предназначенный Zabbix. является для программно-аппаратных Это администраторов комплексов. Он продукт, крупных подходит для мониторинга как крупных бизнес-систем, так и для средних и малых[34]. Zabbix достаточно прост в освоении, имеет обширный функционал и гибкую настройку (см. рисунок 8). 45

Рисунок 8. Интерфейс Zabbix Для хранения метрик используются SQL базы данных, такие как MySQL, Oracle, PostgreSQL, SQLite и др. В систему уже встроен мониторинг стандартных метрик, среди которых:  нагрузка на центральный процессор, в том числе отдельными процессами;  использование оперативной памяти;  нагрузка на жёсткий диск;  объём свободной физической памяти;  сетевая активность. 46

Zabbix может не только мониторить аппаратные характеристики серверов, но оповещать при отклонении метрик от нормы. Для этого используются специальные условия – триггеры[29]. В случае отсутствия функционала для мониторинга специфических метрик его можно написать самостоятельно с помощью API. Данный инструмент существует и развивается уже более 20 лет и имеет больше сообщество и множество дополнительных плагинов, среди которых имеются плагины для активности работы СУБД, но по информативности эти плагины не сравняться со специально предназначенными для этого инструментами. Другим инструментом мониторинга активности серверов является Grafana. Это ПО во многом похоже на Zabbix, однако имеет ряд значительных отличий. Во-первых, Grafana представляет из себя средство для визуализации и анализа данных. Grafana позволяет создавать дашборды с панелями, каждая из которых отображает определенные показатели в течение установленного периода времени. Каждый дашборд универсален, поэтому его можно настроить для конкретного проекта или с учетом любых потребностей разработки и/или бизнеса. Также имеется большое количество уже готовых дашбордов, которые можно бесплатно скачать в сети Интернет. Во-вторых, Grafana извлекает данные из базы данных временных рядов, которая специально оптимизирована для хранения метрик через пары времен и значений. В отличие от реляционных баз данных базы данных временных рядов используют индексацию данных, объединённых со временем, и, как следствие, скорость загрузки не уменьшается со 47

временем и остается достаточно стабильной (от 50 до 100 тыс. строк в секунду)[28]. Grafana включает встроенный анализатор запросов Graphite, который сильно упрощает процесс управления запросами. В Grafana встроена поддержка Prometheus приложение, оповещений. используемое А для мониторинга благодаря поддержке событий и Elasticsearch извлекаемые данные можно сразу обрабатывать и сроить панели, отображающие среднее значение, минимальное/максимальное, перцентили, среднеквадратичное отклонение и многое другое. Таким образом, Grafana является мощным инструментом для визуализации данных любым удобным способом. А при подключении дополнительных плагинов, Grafana может отображать метрики производительности (см. рисунок 9), но это поддерживают далеко не все инструменты для нагрузочного тестирования. Например, в Apache JMeter для подобной интеграции есть удобные плагины[20]. 48

Рисунок 9. Мониторинг метрик производительности в Grafana Хоть Grafana и производительности, может визуализировать собираемые метрики инструментом нагрузочного тестирования во время прогона теста, сбор аппаратных производить можно характеристик отдельно, избежать инструментов[32]: Yandex.Overload. что придется создает используя Apache Модульная сложности, связку JMeter, настраивать их которые нескольких Yandex.Tank архитектура и и Yandex.Tank позволяет использовать различные генераторы нагрузок, в том числе Apache JMeter. Во время выполнения тестового прогона Yandex.Tank собирает аппаратные метрики тестируемых серверов по протоколу SSH, выводит результаты в консоль (см. рисунок 10) и самое главное можно настроить отправку всех собираемых им данных в мониторинга и анализа производительности Yandex.Overload, которые отображает эти метрики в виде графиков и таблиц (см. рисунок 11). 49

Рисунок 10. Консольный вывод метрик в Yandex.Tank Рисунок 11. Отображение метрик в Yandex.Overload Так же существуют исключительно для инструменты, мониторинга предназначение активности СУБД. Например, для Oracle это приложение Oracle Enterprise Manager. И хотя в первую очередь Oracle Enterprise Manager – это инструмент аппаратным для обеспечение, управления программным разрабатываемым и корпорацией Oracle[21], он имеет web-интерфейс для управления всеми функциями СУБД, а также для мониторинга текущего состояния системы. С его помощью можно отслеживать нагрузку на сервере, просматривать активные сессии, скорость выполнения запросов и потребляемые ими ресурсы, обнаружение блокировок данных рисунок 12). 50 и многое другое (см.

Рисунок 12. Вкладка производительности базы данных Также инструмент в состав для Oracle создания Enterprise детальных Manager отчетов входит Automatic Workload Repository (AWR). AWR используется для сбора статистики производительности, включая[18]:  Ожидание событий, используемых для выявления проблем с производительностью.  Статистика временной модели, показывающая количество времени БД, связанного с процессом;  Статистика активных сессий (ASH);  Статистика использования объектов БД;  Ресурсоемкие SQL операторы. Для бесплатных СУБД, таких как PostgreSQL, имеется специализированное программное обеспечение с открытым исходным кодом для мониторинга и анализа активности и 51

производительности – PoWA (PostgreSQL Workload Analyzer). По сути, PoWA представляет из себя расширение, которое собирает статистику производительности и предоставляет ее в виде графиков в реальном времени[24]. С его помощью можно получить график выполнения запросов, блок хитов/прочтений, а также диаграмму затрат времени на выполнения запроса за выбранный период времени. Более того, при помощи POWA можно получить детальное описание по конкретному выполняемому запросу (см. рисунок 13). Рисунок 13. Web-интерфейс PoWA 52

Глава 3. Тестирование производительности системы «АЦК-Планирование» 3.1 Анализ проекта «АЦК-Планирование» финансово-экономических – это органов, система автоматизации предназначенная для исполнения бюджета и управления бюджетным процессом в субъектах РФ и муниципальных образованиях. Программный комплекс «АЦК-Планирование» предназначен для автоматизации процесса планирования бюджета региона (муниципального образования) на очередной финансовый год и плановый период в соответствии с действующим законодательством и новейшими тенденциями бюджетной реформы. Система используется для автоматизации деятельности всех структурных подразделений финансового органа, включая его территориальные подразделения, участников бюджетного процесса, в том числе главных распорядителей бюджетных средств, распорядителей бюджетных средств, получателей бюджетных средств, бюджетных и автономных учреждений. Система информационного предусматривает взаимодействия возможность финансового органа с территориальными органами Федерального казначейства и кредитными организациями, осуществляющими кассовое обслуживание счетов бюджета, лицевых счетов участников бюджетного процесса, счетов по учету операций бюджетных 53

и автономных учреждений – лицевых счетов бюджетных и автономных учреждений соответственно (см. рисунок 14). Рисунок 14. Схема управления планированием финансов «АЦК-Планирование» имеет огромный функционал объединяет в себе множество опций, например:  Формирование проекта бюджета;  Расчет проекта бюджета;  Формирование бюджета в проектном представлении;  Планирование изменения в бюджете в течение года;  Интеграция с ФНС; 54

 Финансово-экономический анализ параметров бюджета;  Мониторинг исполнения бюджетных программ;  Взаимодействие с государственной системой «Электронный бюджет»;  Возможность работы в режиме удаленного доступа с использованием WEB-интерфейса. В состав информационной системы «АЦК-Планирование» входят следующие элементы:  система управления базой данных (СУБД);  сервер приложений;  система лицензионной защиты;  клиентское приложение. Такая схема обеспечивает равномерное распределение вычислительной нагрузки в локальной сети и хорошую масштабируемость системы в целом. Для хранения, модификации и обработки информации используется СУБД производственного назначения, что гарантирует высокую скорость доступа к информации, ее целостность и непротиворечивость; дает возможность создания резервных копий данных и восстановления их в случае необходимости. К серверу БД предъявляются особые требования по производительности, безопасности и надежности. Основная часть бизнес-логики обработки данных сконцентрирована на сервере приложений, что позволяет 55

централизованно хранить выполняемые процедуры, а также синхронизировать их работу в случае многопоточного доступа к данным. Сервер приложений системы «АЦКПланирование» написан с использованием языка программирования Java и предназначен для выполнения в среде виртуальной обеспечивается операционной машины его Java (JRE/JDK). независимость системы и от высокая Тем самым используемой надежность в эксплуатации. Он построен по типовой схеме монитора объектных транзакций (OMT) без запоминания промежуточного состояния и осуществляет обработку запросов клиентов и передачу этих запросов базе данных системы, а также получение данных из базы и передача их клиенту. Сервер приложения выступает промежуточным звеном между базой данных и клиентами, обеспечивая тем самым защиту данных и распределение нагрузки. Доступ к данным, хранящимся в БД, осуществляется сервером приложений посредством драйверов JDBC, что обеспечивает независимость от используемой операционной системы и высокую надежность серверной части. Клиентское приложение предназначено для подготовки и отправки заданий на сервер приложений, а также представления данных, полученных от сервера приложений, в доступной для восприятия конечным пользователем форме. Система лицензионной предотвращения защиты предназначена несанкционированного 56 для использования и

проверки подлинности модулей в процессе работы защищенной системы. Также в состав системы дополнительно входят различные служебные программы (утилиты), использование которых носит вспомогательный характер. Например, для работы с системой «АЦК-Планирование» через WEB -интерфейс требуется WEB-сервер, который является промежуточным звеном между клиентами и сервером приложений, осуществляет обработку запросов клиентов и передачу этих запросов серверу приложений, а также получение данных от сервера приложений и передачу их клиентам. В ходе тестирования сценарии, должны оформляемые выполняться отдельными бизнес- скриптами нагрузочного тестирования (см. приложение 1). Для текущего тестирования производительности сервер лицензионной защиты можно используется только в исключить, момент так включения как он сервера приложения. Конфигурацию серверов приложения БД для нагрузочного тестирования и тестирования стабильности было решено выбрать для обеспечения одновременной работы 250 пользователей. В результате анализа для информационной системы были предъявлены следующие требования к производительности тестируемого ПО: 1. Операции входа в систему не более 10 секунд для 95% случаев. 2. Сохранения документа не более 5 секунд для 95% случаев. 57

3. Время перевода статуса документа не более 5 секунд в 95% случаев. 4. Время вывода списка отфильтрованных документов не более 60 секунд. 5. Время вывода отчета не более 60 секунд Для создания нагрузки со стороны пользователей на систему, будет использоваться специализированных связка из инструментов нескольких нагрузочного тестирования: Apache JMeter, Yandex.Tank и Yandex.Overload. Yandex.Tank будет использован в качестве инструмента для записи сценариев Yandex.Tank основной будет задачей и генерации выступать которого нагрузки на промежуточным будет сбор систему. звеном, аппаратных характеристик со всех нагружаемых серверов, сбор метрик производительности и отправка всех этих данных в сервис для мониторинга и анализа результатов тестирования Yandex.Overload. Мониторинг активности на сервере БД будет выполняться с помощью Oracle Enterprise Manager и PoWA для СУБД Oracle и PostgreSQL соответственно. 3.2 Планирование теста производительности Для комплексного производительности и всестороннего системы «АЦК-Планирование» необходимо: 1. Провести нагрузочное тестирование; 58 тестирования

2. На основании результатов нагрузочного тестирования сформировать профиль нагрузки для тестирования стабильности в течение 1-2 часов; 3. Проверить масштабируемость системы при работе с двумя и тремя серверами приложений; 4. Сравнить производительность при работе системы на СУБД PostgreSQL 10 и PostgreSQL 11 со старыми и новыми драйверами JDBC; Для тестирования необходимо создать рабочий дамп базы данных, который будет восстанавливаться перед каждым запуском нагрузочных тестов, также перед каждым запуском необходимо производить тестирования сбор должна статистики. содержать все БД для данные, присутствующие в базе настоящей информационной системы. В нагрузочном скрипте настроить случайную задержку от 500 мс до 1000 мс между каждым запросом, а также задержку от 10000 мс до 15000 мс после выполнения каждого сценария там самым обеспечивая максимально возможное приближение к имитации работы реальных пользователей. Для тестирования необходимо создать тестовых пользователей, которые будут привязаны к организациям. Всю нагрузку распределить между организациями как это указано в таблице 2: Таблица 2. Распределение нагрузки 59

Наименование организации % от общего Сценарии числа пользователей Сценарий 1 Сценарий 8 Минфин РК Сценарий 10 36,03 Сценарий 4 Сценарий 6 Сценарий 2 Сценарий 7 Минэкономики Республики Коми Сценарий 9 18,79 Сценарий 11 Сценарий 6 Сценарий 3 Минобрнауки Республики Коми Сценарий 5 Сценарий 9 18,44 Сценарий 4 Сценарий 6 Сценарий 4 Минздрав Коми Республики Сценарий 3 Сценарий 6 13,62 Сценарий 5 Сценарий 10 Сценарий 6 Сценарий 4 ГАУ РК "ЦИТ" Сценарий 9 Сценарий 2 Сценарий 7 60 13,12

3.3 Настройка среды тестирования Для выбранных стратегий тестирования понадобится создание и настройка шести серверов. Для проведения нагрузочного, конфигурационного тестирования и тестирования стабильности потребуется один сервер приложения, один сервер БД и сервер генерации нагрузки. Для тестирования масштабируемости потребуется дополнительно еще два сервера приложения и отдельный сервер для балансировки нагрузки. Все сервера должны работать под управлением операционной системы Linux CentOS 6.8. На всех серверах должно быть установлено ПО Java 8 и серверный агент для сбора аппаратных метрик Telegraf. Сервер БД для проведения нагрузочного тестирования и тестирования стабильности необходимо сконфигурировать для достижения одновременной работы 250 пользователей в соответствии с системными требованиями из технического задания: 2x4Core 3GHz Intel Xeon 64 bit, 32 Гб оперативной памяти и сетевое соединение со скоростью 2 Гбит. Для тестирования масштабируемости его аппаратные характеристики будет увеличены вдвое для одновременной работы в конфигурации с двумя и тремя серверами приложений. на данном сервере должны быть установленный объектно-реляционные СУБД Oracle 11.2.0.0, PostgreSQL 10.10 и PostgreSQL 11.5. Дополнительно для мониторинга и 61

анализа активности СУБД PostgreSQL необходимо установить инструмент PoWA. На все серверы приложений должно быть установлено ПО, которые будет обрабатывать запросы пользователей, а также отправлять и принимать запросы от сервера БД. Конфигурация всех серверов приложений в отдельности настраивается для одновременной работы 250 пользователей в соответствии с системными требованиями из технического задания: 4x4Core 3GHz Intel Xeon 64 bit, 64 Гб оперативной памяти и сетевое соединение со скоростью от 2 до 4 Гбит. Дополнительно для сравнения производительности при работе системы на СУБД PostgreSQL 10 и PostgreSQL 11 со старыми и новыми драйверами JDBC, необходимо скачать свежие версии JDBC драйверов для СУБД PostgreSQL с официального сайта и переместить в папку с бинарными файлами приложения. На сервер генерации нагрузки необходимо установить Apache JMeter и Yandex.Tank. Настроить SSH-соединение со всеми остальными серверами для мониторинга потребление аппаратных характеристик во время тестов через Telegraf. Так как это сервер, который будет имитировать работу одновременно помощью большого Apache JMeter, количества для него пользователей следует с выделить увеличенные ресурсы: 4x4Core 3GHz Intel Xeon 64 bit, 256 Гб оперативной памяти и сетевое соединение со скоростью 6 Гбит. Последний сервер – это сервер балансировки нагрузки. Единственной его задачей будет принимать запросы от 62

сервера генерации нагрузки и распределять ее равномерно между серверами приложений. Для этого на сервер необходимо установить Nginx – бесплатное ПО с открытым исходным кодом, одной из функций которого является балансировка нагрузки для HTTP -серверов. Для работы этого сервера потребуется минимальная конфигурация: 1x2Core 3GHz Intel Xeon 64 bit, 8 Гб оперативной памяти и сетевое соединение со скоростью 1 Гбит. После создания серверов, необходимого ПО взаимодействия серверов выполнить надо установку установки проверить приложений базы из и настройки корректность и сервера дампа БД, реальной информационной системы, при необходимости обновить эту базу и проверить работу SSH-соединения между серверами. 3.4 Подготовка нагрузочных тестов. Имея рабочую среду тестирования, можно приступать к ознакомлению с функционалом информационной системы «АЦК-Планирование», выполнить вручную каждый сценарий в отдельности, понять, как работает система и какие контроли возникают при обработке электронных документов. Нагрузочный скрипт Apache JMeter имеет туже структуру, что и файл формата XML. Главным элементом является «Test Plan». Внутри этого элемента уже содержатся все необходимые элементы для конфигурации, различные контроллеры, группы потоков приложение 2). 63 и сами запросы (см.

Для записи сценариев Apache JMeter имеет встроенный proxy-сервер, с перехватывать любые тестировании помощью которого http-запросы. производительности можно Главная это легко задача имитация в работы пользователей. А в реальных условиях с системой работает много разных пользователей, и даже если они работают с одинаковым классом документов, данные внутри этих документов разные. Но при создании сценариев в тексте запроса только те данные, которые были введены в момент записи, и для того, чтобы сделать имитацию максимально приближенной к реальности вариативность данных, необходимо иначе обеспечить возникнут взаимные блокировки и долгое выполнение SQL-запросов на сервере БД. Для этого все параметризировать, записанные т.е. сценарии представить необходимо наиболее важные данные в виде переменных, которые будут выбираться из подготовленного массива данных. В качестве массива данных может выступать обычный csv файл, в который выгрузили некоторые данные пользователей и из БД. пароли, Это могут различные коды быть имена бюджетных классификаторов, идентификаторы записей и т.д. Для работы с такими данными в Apache JMeter есть специальный конфигурационный элемент «CSV Data Set Config» (см. рисунок 15): 64

Рисунок 15. Элемент «CSV Data Set Config» Так же некоторые переменные можно делать глобальными и давать им значения непосредственно в самом скрипте, для этого используется конфигурационный элемент «User Defined Variables» (см. рисунок 16): Рисунок 16. Элемент «User Defined Variables» После выполнения запроса на создание нового элемента в системе «АЦК-Планирование» уникальный идентификатор генерируется автоматически непосредственно в базе данных и содержится в ответе на подобный запрос. Этот идентификатор необходим для дальнейших запросов, и чтобы его извлечь, записать в некоторую 65 переменную и

использовать в экстракторы данных. эффективных экстракторов Extractor», дальнейшем которые в Один Jmeter из наиболее является извлекает предусмотренный быстрых «Regular данные по и Expression регулярному выражению и сразу записывает их в переменную(см. рисунок 17): Рисунок 17. Элемент «Regular Expression Extractor» Чтобы находить ошибки при работе виртуальных пользователей, в случае, когда http-запрос возвращается с кодом 200 (успешное выполнение), но фактически возвращается ответ с текстом ошибки сервера приложения или сервера БД, можно добавить элемент для проверки текста ответа «Response Assertion». Этот элемент можно настроить так, что он будет проверять возвращаемый httpзапросом текст шаблонов. В на наличие случае или отсутствие тестирования текстовых системы «АЦК- Планирование» ответ на запрос не должен содержать текста «error:» (см. рисунок 18): 66

Рисунок 18. Элемент «Response Assertion» Если во время тестов ошибки в работе системы находятся, то для удобства их можно сохранять в отдельные файлы с помощью элемента «Save Responses to a file», в котором также можно настроить сохранение ответа только ошибочных http-запросов, префикс к имени файлов и штамп временной метки как часть имени такого файла (см. рисунок 19): Рисунок 19. Элемент «Save Responses to a file» Также в нагрузочном скрипте должны присутствовать случайные задержки между каждым http-запросом и после выхода пользователя из системы. Это реализуется с помощью 67

таймера «Uniform Random Timer», в котором настраивается постоянная задержка и максимальная случайная задержка в миллисекундах (см. рисунок 20): Рисунок 20. Элемент «Uniform Random Timer» Так как скрипт нагрузочного теста имеет вложенную структуру, нет необходимости добавлять таймер к каждому http-запросу в отдельности, достаточно расположить этот конфигурационный элемент выше в иерархии, и автоматически применяться ко всем запросам. он будет Но для реализации задержки после выхода из системы, этот элемент необходимо поместить внутрь запроса. Вследствие того, что сервер приложений системы «АЦКПланирование» построен по схеме монитора объектных транзакций без запоминания промежуточного состояния, выполнение http-запросов на создание новых документов и их обработку происходит асинхронно. Т.е. в ответ на http-запрос на создание или обработку документа приходит не результат выполнение, а идентификатор данной задачи, по которому клиентское приложение отслеживает процесс выполнения данного запроса. И реализовать подобную специфическую 68

задачу в Apache JMeter можно решить с использованием логических контроллеров «If Controller» и «While Controller», в которых пишутся условия проверки статуса асинхронного задания и завершения цикла. А для измерения общего времени выполнения создания или обработки нового документа используется контроллер «transaction Controller», в который помещаются логические контроллеры и httpзапросы (см. рисунок 21): Рисунок 21. Реализация асинхронной обработки ЭД Для распределения пользователей в соответствии с требованиями из таблицы 2 можно использовать контроллер пропускной способности «Throughput Controller». В данном контроллере пользователей, настраивается которые количество выполнят виртуальных вложенные в сценарии в процентном соотношении (см. рисунок 22) 69 него

Рисунок 22. Элемент «Throughput Controller» Таким проверки, образом, после обеспечения записи всех необходимой сценариев, их вариативности и настройки всех элементов, добавляется элемент, отвечающий за создание виртуальных пользователей – «Stepping Thread Group». В нем настраивается профиль нагрузки – количество виртуальных пользователей (потоков) и время выполнения нагрузочного теста в соответствии с типом проводимого тестирования производительности. В случае нагрузочного тестирования, виртуальные пользователи будут вводиться в систему методом линейного нарастания в течение 66 минут для достижения 1000 одновременно работающих пользователей (см. рисунок 23). Рисунок 23. Профиль нагрузочного тестирования В соответствии с конфигурацией серверов, для тестирования стабильности выбрана конфигурация нагрузки для достижения 250 одновременно работающих пользователей. Данное число пользователей будет введено в 70

систему методом линейного нарастания в течение 10 минут, и затем в течение 60 минут будет происходить непрерывная работа всех пользователей (см. рисунок профиль будет применяться при 24). Такой же конфигурационном тестировании. Рисунок 24. Профиль тестирования стабильности Для тестирования тестирования масштабируемости масштабируемости достижения 400 (см. рисунок будет профиль изменен 25) и 500 (см. рисунок для 26) одновременно работающих на протяжении 120 минут для двух и трех серверов приложения соответственно. 71

Рисунок 25. Профиль тестирования стабильности для двух серверов приложений Рисунок 26. Профиль тестирования стабильности для трех серверов приложений Таким образом, полностью готовый скрипт выглядит следующим образом (см. рисунок 27): 72

Рисунок 27. Готовый скрипт для нагрузочного тестирования 3.5 Запуск тестов. После формирования нагрузочного и подготовки тестирования тестированию следует системы. скрипта для приступать При к тестировании производительности всегда выполняются следующие шаги: 1. Восстановление базы данных из ранее созданного дампа и сбор статистики; 2. Запуск серверов приложений; 3. Настройка сбора статистики на сервере генерации нагрузки; 4. Запуск теста производительности; 5. Мониторинг основных аппаратных ресурсов всех севров. А также метрик производительности на протяжении всего теста; 6. После завершения теста, сохранение логов на всех серверах; 7. Удаление базы данных. 3.6 Анализ результатов. При первом запуске нагрузочного тестирования, система показала крайне низкую производительность (см. рисунок 28): 73

Рисунок 28. График производительности системы На графике сиреневая линия отображает изменение количества виртуальных пользователей по времени. Зеленые, жёлтые, оранжевые и красные кривые отображают прирост транзакций в секунду. После подключения 500 виртуальных пользователей количество HTTP-запросов в секунду (http-request per second RPS) замерло на уровне 150. При детальном анализе активности БД был выявлен sql-запрос, который сильно нагружал сервер базы данных, вследствие чего все остальные запросы простаивали. Анализ логов СУБД помог выявить причину большой активности одного запроса, им оказалcя deadlock в данном запросе. После создания соответствующего дефекта с детальным описание причины низкой производительности, оперативно выпущен отделом патч, разработки добавляющий был возможность отключения механизма генерации номеров ЭД, который и вызывал проблемный sql-запрос. 74

После обновления сервера приложения, принудительного отключения механизма генерации номеров, производительность системы резко возросла (см. рисунок 29): Рисунок 29. График производительности системы после патча По итогам нагрузочного тестирования была определена точка насыщения, которая наступила в момент одновременной работы 734 пользователь со скоростью 890 RPS. После наступления точки насыщения рост производительности остановился, из-за того, что сервер БД был загружен выполнением большого количества запросов, направленных на построение форм списков, что привело к падению производительности и повышенной активности на процессор (см. рисунок 30): 75

Рисунок 30. График нагрузки на процессор сервера БД После нагрузочного теста был запущен тест стабильности, который проверил, подходит ли система под критерии производительности, заявленные в ТЗ. Результаты оказались положительными: поставленной система нагрузкой, показав справилась с равномерную производительность на протяжении всего теста (см. рисунок 31): 76

Рисунок 31. График производительности системы при тестировании стабильности Следующим этапом тестировании производительности была проверка масштабируемости системы при работе с двумя и тремя серверами приложений. В соответствии с ТЗ, система, состоящая из двух серверов приложений и одного сервера БД, должна обеспечивать 400 пользователей с непрерывную работу до выполнением всех требования к производительности. В случае работы системы, состоящей из трех серверов приложений и одного сервера БД, должна обеспечиваться работа до 500 с выполнением тех же требований к производительности. По результатам нагрузочного тестирования производительность системы при работе с двумя (см. рисунок 32) и тремя (см. рисунок 33) были найдены точки насыщения для каждой конфигурации: Рисунок 32. График производительности системы для нагрузочного теста при работе системы, состоящей из двух серверов приложений 77

Рисунок 33. График производительности системы для нагрузочного теста при работе системы, состоящей из трех серверов приложений В случае конфигурации системы из двух серверов приложений точка насыщения наступила при достижении одновременной работы 783 пользователь со скоростью 914 RPS. Для трех серверов приложений точка насыщения наступила при достижении одновременной работы 897 пользователь со скоростью 864 RPS. После нагрузочного тестирования системы в требуемой конфигурации так же были выполнены прогоны тестирования стабильности для двух (см. рисунок рисунок 35) северов приложений: 78 34) и для трех (см.

Рисунок 34. График производительности системы для теста стабильности при работе системы, состоящей из двух серверов приложений Рисунок 35. График производительности системы для теста стабильности при работе системы, состоящей из трех серверов приложений Последней задачей было сравнение производительность при работе системы на СУБД PostgreSQL 10 и PostgreSQL 11 со старыми и новыми драйверами 79 JDBC. Графики

производительности, полученные в ходе тестирования изображены на рисунках 36-39. Рисунок 36. График производительности системы при работе на СУБД PostgreSQL 10 со старым драйвером JDBC Рисунок 37. График производительности системы при работе на СУБД PostgreSQL 10 с новым драйвером JDBC 80

Рисунок 38. График производительности системы при работе на СУБД PostgreSQL 11 со старым драйвером JDBC Рисунок 35. График производительности системы при работе на СУБД PostgreSQL 11 с новым драйвером JDBC 3.7 Оптимизация и завершение тестирования Таким образом, при тестировании системы в конфигурации 1 сервер приложения и 1 сервер БД был обнаружен блокирующий запрос в механизме генерации номеров для ЭД. Но при принудительном отключении этого 81

механизма, система справляется с поставленной нагрузкой и способна обеспечить пользователей комфортную при штатном работу 250 режиме нагрузки и более (обычная работа) со временем доступа к данным менее 2 секунд, как заявлено в технических требованиях, а также имеет большой запас производительности для работы во время пиковой нагрузки. Тестирование системы в конфигурации 2 сервера приложений так же показала неплохую производительность, соответствующая заявленным требованиям. Однако при тестировании стабильности системы в конфигурации трех серверов приложений производительность была неравномерной, на графике заметны провалы, связанные с повышенной активностью на сервере БД. Это свидетельствует о плохой оптимизации программного кода, вследствие чего время обработки некоторых классов ЭД сильно возрастает и превышает максимально допустимое время, указанное в требованиях. Также во время проведения конфигурационного тестирования балы замечена периодическая просадка в производительности, и аномальная нагрузка на сервер БД. Многопоточное тестирование каждого сценария в отдельности выявило еще 2 взаимные блокировки. Сравнение производительность при работе системы на СУБД PostgreSQL 10 и PostgreSQL 11 со старыми и новыми драйверами JDBC не показало улучшений. Но при работе с новыми драйверами были обнаружены ошибки, связанные с отсутствием некоторых методов в новой версии драйверов. Для получения полноценного 82 результата следует

предварительно оптимизировать приложение под работу с новыми драйверами JDBC. 83

Заключение В ходе работы выполнения была выпускной разработана схема квалификационной схемы комплексного тестирования производительности информационной системы, предназначенной для планирования и анализа бюджета. Для достижения цели были выполнены следующие задачи, сформулированные во введении:  Изучены особенности электронного бюджетирования РФ;  Исследованы инструменты производительности и для тестирования анализа результатов проведено комплексное тестирования;  Разработана схема и тестирование производительности системы «АЦКПланирование»;  Проанализированы результаты тестирования производительности. Перед разработкой схемы была исследована бюджетная система РФ, особенности система ее производительности электронного использование, и бюджетирования изучена исследованы и концепция основные виды тестирования производительности. Следуя разработанной комплексное схеме, тестирование было проведено производительности программного комплекса «АЦК-Планирование», в результате которого были обнаружены и исправлены уязвимости в производительности системы. 84 критические

Разработанная схема успешно применяется в компании «БФТ» и показывает свою эффективность не только на информационных системах, предназначенной для планирования и анализа бюджета, но и на многих друг, в том числе не относящимся к информационным системам финансового управления. Результаты выпускной квалификационной работы были апробированы в виде научной стать, опубликованной в международном научном журнале «Молодой ученый» №18 (308), май 2020 г. (см. приложение 3). 85

Список использованной литературы 1. Федеральный закон от 29 июня 2015 г. № 188-ФЗ «О внесении изменений в Федеральный закон "Об информации, информационных технологиях и о защите информации" и статью 14 Федерального закона "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» // Информационносправочная система «Консультант Плюс». 2. Постановление Правительства РФ от 16 ноября 2015 г. № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд» // Информационносправочная система «Консультант Плюс». 3. Агеева Е. В. Цифровизация финансово-кредитной сферы в современной России. Монография / Агеева Е. В. , Афанасова М. А. , Баландина А. С. , Балашова Н. В. , Баннова К. А. — М.: Директ-Медиа, 2019. - 407с. 4. Antonio Gomes Rodrigues, Bruno Demion (Milamber), Philippe Mouawad. Master Apache JMeter - From Load Testing to DevOps: Master performance testing with JMeter. Packt Publishing. 2019. - 468 p. 5. Meier J.D., Carlos Farre, Prashant Bansode, Scott Barber, and Dennis Rea. Performance Testing Guidance for Web Applications. Microsoft Press. 2007. - 288 p. 6. Philipp K. Janert. Data Analysis with Open Source Tools. O'Reilly Media. 2010. - 583 p. 86

7. The Art of Application Performance Testing. Molyneaux Ian. O'Reilly Media. 2009. - 158 p. 8. The Art of Application Performance Testing: From Strategy to Tools. Molyneaux Ian. O'Reilly Media. 2014. - 278 p. 9. Дадашева А.З., Финансы. Учебник. - М. : Вузовский учебник, НИЦ ИНФРА-М, 2016. - 393 с. 10. Дементьев Д.В., Бюджетная система Российской Федерации. Учебник. — М.: КНОРУС, 2017. - 332 с. 11. Курченко Л.Ф., Бюджетная система Российской Федерации. Субфедеральный и местный уровни: учебное пособие. — М.: Дашков и К, 2016. - 252 с. 12. Нешитой А.С., Бюджетная система Российской Федерации: учебник для бакалавров. — М.: Дашков и К, 2015. - 310 с. 13. Sarojadevi H. Performance Testing: Methodologies and Tools. Journal of information engineering and applications, 2011, 5 - pp. 5-13. 14. Мясников С. О., Намиот Д. Е. Инструменты нагрузочного тестирования // Прикладная информатика. — 2018. — Т. 13, № 1. — С. 92–102. 15. Пешкова Х.В., Бюджетное устройство государства как основа ведения публичного хозяйства // Финансовое право. - 2012. - №4. - С. 14-27. 16. Савчук И. производительности В., Особенности финансовых тестирования приложений, предназначенных для исполнения бюджета и управления бюджетным процессом в субъектах РФ и муниципальных образованиях // Молодой ученый. — 2020. — № 18 (308). — С. 24-25. 87

17. International Software Qualifications Board (2018). Сертифицированный тестировщик - Программа обучения Базового уровня. Тестирование производительности. Russian Software Testing Qualifications Board. Web: https://www.rstqb.org/ru/istqb-downloads.html 18. Automatic Workload Repository (AWR) in Oracle Database 10g [Электронный ресурс] Oracle-Base - Режим доступа: https://oracle-base.com/articles/10g/automatic- workload-repository-10g (дата обращения: 22.05.2020) 19. GATLING [Электронный ресурс] Gatling - Режим доступа: https://gatling.io/docs/current/ (дата обращения: 15.03.2020) 20. JMeter – How To Save Test Results To A Database [Электронный ресурс] Vinsguru - Режим доступа: https://www.testautomationguru.com/jmeter-save-results-to-adatabase/ (дата обращения: 20.05.2020) 21. Oracle Enterprise Manager [Электронный ресурс] Patches IT Community - Режим доступа: https://oracle- patches.com/oracle/products/2941-oracle-enterprise-manager-2 (дата обращения: 22.05.2020) 22. Overload [Электронный ресурс] GitHub - Режим доступа: https://github.com/yandex/yandex-tank/wiki/Overload (дата обращения: 14.05.2020) 23. performance SearchSoftwareQuality testing [Электронный - Режим ресурс] доступа: https://searchsoftwarequality.techtarget.com/definition/performa nce-testing (дата обращения: 29.04.2020) 24. POWA — анализатор нагрузки СУБД PostgreSQL на основе pg_stat_statements [Электронный ресурс] nixp - Режим 88

доступа: https://www.nixp.ru/news/12712.html (дата обращения: 22.05.2020) 25. Tank [Электронный ресурс] Yandex Technologies Режим доступа: https://tech.yandex.com/tank/ (дата обращения: 14.05.2020) 26. Tsung — цунами ручного приготовления [Электронный ресурс] Блог Ивана Увтуховичв. Заметки из жизни DevOps-консультанта - Режим http://evtuhovich.ru/blog/2014/04/02/tsung (дата доступа: обращения: 06.05.2020) 27. Types of Performance Testing [Электронный ресурс] Software Testing Blog by Cigniti Technologies - Blog on Software Testing industry by leading Independent Software Testing Company Cigniti Technologies. - Режим доступа: https://www.cigniti.com/blog/types-of-performance-testing/ (дата обращения: 30.04.2020) 28. What is Grafana? [Электронный ресурс] GrafanaLabs - Режим доступа: https://grafana.com/docs/grafana/latest/getting-started/what-isgrafana/ (дата обращения: 19.05.2020) 29. Zabbix — мощный инструмент для мониторинга ИТинфраструктуры [Электронный ресурс] SysAdminTips.ru - Советы и подсказки системного администратора доступа: - Режим https://sysadmintips.ru/zabbix-instrument-dlya- monitoringa-it-infrastruktury.html (дата обращения: 18.05.2020) 30. Введение [Электронный в исследование ресурс] ХАБР 89 - производительности Режим доступа:

https://habr.com/ru/company/yamoney/blog/433436/ (дата обращения: 20.04.2020) 31. Использование нагрузки на Apache веб-сервер университета Bench для [Электронный SEDICOMM - тестирования ресурс] Режим Блог доступа: https://www.performance-lab.ru/blog/load-testing/testirovanieproizvoditelnosti (дата обращения: 08.05.2020) 32. Нагрузочное тестирование c Yandex.Tank и JMeter [Электронный ресурс] GitHub Gist - Режим доступа: https://gist.github.com/sameoldmadness/9abeef4c2125bc760ba2f 09ee1150330 (дата обращения: 21.05.2020) 33. Нагрузочное тестирование vs Тестирование производительности [Электронный ресурс] PerfomanceLab Режим доступа: https://bftcom.com/products/upravlenie- gosudarstvennymi-finansami/byudzhetnoe-planirovanie/? sphrase_id=6394 (дата обращения: 23.04.2020) 34. Система мониторинга Zabbix для начинающих [Электронный ресурс] Блог компании EternalHost - Режим доступа: https://eternalhost.net/blog/sistemnoe- administrirovanie/zabbix-chto-eto (дата обращения: 15.05.2020) 35. 90

Приложения Приложение 1 Бизнес-сценарии для нагрузочного тестирования Сценарий 1. Создание бюджетной заявки (БЗ) Сценарий 2. Обработка БЗ 1. Запуск клиента «АЦК-Планирование» и авторизация; В меню сверху раскрыть выпадающий список "Расходы"; 2. В списке "Расходы" открыть пункт меню "Бюджетные заявки"; 3. В открывшейся форме нажать на кнопку создания нового документа "Новый"; 4. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 5. В дереве бланков расходов справочника выбрать бланк расходов с типом "Смета" у которого есть вышестоящий бланк и его тип "Роспись" и нажать на кнопку ОК; 6. В форме создания новой БЗ нажать на кнопку создания новой строки документа "Новый"; 7. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 8. Выбрать из списка доступное расходное обязательство и нажать на кнопку "Выбрать"; 9. В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него положительную сумму; 10.В форме создания новой строки документа нажать кнопку "ОК"; 11.В форме создания новой бюджетной заявки нажать кнопку "Применить"; 12.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация ; 2. В меню сверху раскрыть выпадающий список "Расходы"; 3. В списке "Расходы" открыть пункт меню "Бюджетные заявки"; 4. В открывшейся форме нажать на кнопку создания нового документа "Новый"; 5. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 6. В дереве бланков расходов справочника выбрать 91

Сценарий 3. Создание сводной бюджетной заявки (СБЗ) бланк расходов с типом "Смета" у которого есть вышестоящий бланк и его тип "Роспись" и нажать на кнопку ОК; 7. В форме создания новой БЗ нажать на кнопку создания новой строки документа "Новый"; 8. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 9. Выбрать из списка доступное расходное обязательство и нажать на кнопку "Выбрать"; 10.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него положительную сумму; 11.В форме создания новой строки документа нажать кнопку "ОК"; 12.В форме создания новой бюджетной заявки нажать кнопку "Применить"; 13.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Обработать"; 14.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 15.В форме создания новой бюджетной заявки нажать кнопку "ОК"; 16.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация; 2. В меню сверху раскрыть выпадающий список "Расходы"; 3. В списке "Расходы" открыть пункт меню "Бюджетные заявки"; 4. В открывшейся форме нажать на кнопку создания нового документа "Новый"; 5. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 6. В дереве бланков расходов справочника выбрать бланк расходов с типом "Смета" у которого есть вышестоящий бланк и его тип "Роспись" и нажать на кнопку ОК; 7. В форме создания новой БЗ нажать на кнопку создания новой строки документа "Новый"; 8. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 9. Выбрать из списка доступное расходное обязательство и нажать на кнопку "Выбрать"; 10.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в 92

Сценарий 4. Обработка СБЗ него положительную сумму; 11.В форме создания новой строки документа нажать кнопку "ОК"; 12.В форме создания новой бюджетной заявки нажать кнопку "Применить"; 13.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Обработать"; 14.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 15.В форме создания новой бюджетной заявки нажать кнопку "ОК"; 16.В списке "Расходы" открыть пункт меню "Распорядитель" "Формирование сводных бюджетных заявок"; 17.В открывшемся АРМ-е, в блоке формирования в поле "Бланк расходов" выбрать бланк расходов с типом "Роспись", являющийся вышестоящим для созданной бюджетной заявки; 18.В гриде со списком документов выбрать созданный документ и нажать на кнопку "Сформировать"; 19.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация ; 2. В меню сверху раскрыть выпадающий список "Расходы"; 3. В списке "Расходы" открыть пункт меню "Бюджетные заявки"; 4. В открывшейся форме нажать на кнопку создания нового документа "Новый"; 5. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 6. В дереве бланков расходов справочника выбрать бланк расходов с типом "Смета" у которого есть вышестоящий бланк и его тип "Роспись" и нажать на кнопку ОК; 7. В форме создания новой БЗ нажать на кнопку создания новой строки документа "Новый"; 8. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 9. Выбрать из списка доступное расходное обязательство и нажать на кнопку "Выбрать"; 10.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него положительную сумму; 11.В форме создания новой строки документа нажать кнопку "ОК"; 93

Сценарий 5. Создание двух бюджетных заявок на изменение ассигнований (БЗнАИ) 12.В форме создания новой бюджетной заявки нажать кнопку "Применить"; 13.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Обработать"; 14.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 15.В форме создания новой бюджетной заявки нажать кнопку "ОК"; 16.В списке "Расходы" открыть пункт меню "Распорядитель" "Формирование сводных бюджетных заявок"; 17.В открывшемся АРМ-е, в блоке формирования в поле "Бланк расходов" выбрать бланк расходов с типом "Роспись", являющийся вышестоящим для созданной бюджетной заявки; 18.В гриде со списком документов выбрать созданный документ и нажать на кнопку "Сформировать"; 19.В открывшемся окне редактирования сводной бюджетной заявки нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 20.В форме редактирования сводной бюджетной заявки нажать кнопку "Действие" и выбрать действие "Завершить обработку"; 21.В форме редактирования сводной бюджетной заявки нажать кнопку "Действие" и выбрать действие "Утвердить"; 22.В открывшемся окне подтверждения утверждения документа нажимаем кнопку "ОК"; 23.В открывшейся форме утверждения документа в поле "Дата" выбираем дату равную дате документа Сводная бюджетная заявка; 24.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация ; 2. В списке "Расходы" открыть пункт меню "Бюджетные заявки на изменение ассигнований"; 3. В открывшейся форме нажать на кнопку создания нового документа "Новый"; 4. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов" В дереве справочника бланков расходов, выбрать бланк расходов с типом "Смета" аналогичный выбранному в БЗ; 5. В поле "Версия" вызвать справочник "Версии планирования расходов"; 6. Выбрать версию, имеющую признак "Актуальная", нажать кнопку "Выбрать"; 94

7. В форме создания новой БЗнИА нажать на кнопку создания новой строки документа "Новый"; 8. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 9. Выбрать из списка расходное обязательство аналогичное выбранному в БЗ; 10.Перевести курсор на поле "Проект изменений на очередной плановый/текущий период" и вызвать форму "Проект изменений на очередной плановый/текущий период"; 11.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него отрицательную сумму, по модулю равную сумме, указанной в БЗ; 12.В форме создания новой строки документа нажать кнопку "ОК"; 13.В форме создания новой бюджетной заявки на изменение ассигнований нажать кнопку "Применить"; 14.В форме списка БЗнИА нажать на кнопку создания нового документа "Новый"; 15.В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 16.В дереве бланков расходов справочника бланков расходов выбрать бланк расходов с типом "Смета" аналогичный выбранному в БЗ; 17.В поле "Версия" вызвать справочник "Версии планирования расходов"; 18.Выбрать версию, имеющую признак "Актуальная", нажать кнопку "Выбрать"; 19.В форме создания новой БЗнИА нажать на кнопку создания новой строки документа "Новый"; 20.В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 21.Выбрать из списка доступное расходное обязательство отличное от выбранного в БЗ; 22.В поле КФСР вызвать справочник "Функциональная классификация расходов" выбрать из списка доступный код нижнего уровня; 23.Перевести курсор на поле "Проект изменений на очередной плановый/текущий период" и вызвать форму "Проект изменений на очередной плановый/текущей период"; 24.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него положительную сумму равную сумме, 95

Сценарий 6. Обработка БЗнИА двух указанной в БЗ; 25.В форме создания новой строки документа нажать кнопку "ОК"; 26.В форме создания новой бюджетной заявки нажать кнопку "Применить"; 27.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация ; 2. В списке "Расходы" открыть пункт меню "Бюджетные заявки на изменение ассигнований" 3. В открывшейся форме нажать на кнопку создания нового документа "Новый"; 4. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 5. В дереве справочника бланков расходов, выбрать бланк расходов с типом "Смета" аналогичный выбранному в БЗ; 6. В поле "Версия" вызвать справочник "Версии планирования расходов"; 7. Выбрать версию, имеющую признак "Актуальная", нажать кнопку "Выбрать"; 8. В форме создания новой БЗнИА нажать на кнопку создания новой строки документа "Новый"; 9. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 10.Выбрать из списка расходное обязательство аналогичное выбранному в БЗ; 11.Перевести курсор на поле "Проект изменений на очередной плановый/текущий период" и вызвать форму "Проект изменений на очередной плановый/текущий период"; 12.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него отрицательную сумму, по модулю равную сумме, указанной в БЗ; 13.В форме создания новой строки документа нажать кнопку "ОК"; 14.В форме создания новой бюджетной заявки на изменение ассигнований нажать кнопку "Применить"; 15.В форме создания новой бюджетной заявки на изменение ассигнование нажать кнопку "Действие" и выбрать действие "Обработать"; 16.В форме создания новой бюджетной заявки на изменение ассигнований нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 17.В форме создания новой бюджетной заявки на 96

Сценарий 7. Создание сводной бюджетной заявки на изменение ассигнований (СБЗнАИ) изменение ассигнований нажать кнопку "ОК"; 18.В форме списка БЗнИА нажать на кнопку создания нового документа "Новый"; 19.В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов" 20.В дереве бланков расходов справочника бланков расходов выбрать бланк расходов с типом "Смета" аналогичный выбранному в БЗ; 21.В поле "Версия" вызвать справочник "Версии планирования расходов"; 22.Выбрать версию, имеющую признак "Актуальная", нажать кнопку "Выбрать"; 23.В форме создания новой БЗнИА нажать на кнопку создания новой строки документа "Новый"; 24.В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 25.Выбрать из списка доступное расходное обязательство отличное от выбранного в БЗ; 26.В поле КФСР вызвать справочник "Функциональная классификация расходов" выбрать из списка доступный код нижнего уровня; 27.Перевести курсор на поле "Проект изменений на очередной плановый/текущий период" и вызвать форму "Проект изменений на очередной плановый/ткущий период"; 28.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него положительную сумму равную сумме, указанной в БЗ; 29.В форме создания новой строки документа нажать кнопку "ОК"; 30.В форме создания новой бюджетной заявки нажать кнопку "Применить"; 31.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Обработать"; 32.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 33.В форме создания новой бюджетной заявки нажать кнопку "ОК"; 34.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация; 2. В списке "Расходы" открыть пункт меню "Бюджетные заявки на изменение ассигнований"; 3. В открывшейся форме нажать на кнопку создания нового документа "Новый"; 97

4. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 5. В дереве справочника бланков расходов, выбрать бланк расходов с типом "Смета" аналогичный выбранному в БЗ; 6. В поле "Версия" вызвать справочник "Версии планирования расходов"; 7. Выбрать версию, имеющую признак "Актуальная", нажать кнопку "Выбрать"; 8. В форме создания новой БЗнИА нажать на кнопку создания новой строки документа "Новый"; 9. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 10.Выбрать из списка расходное обязательство аналогичное выбранному в БЗ; 11.Перевести курсор на поле "Проект изменений на очередной плановый/текущий период" и вызвать форму "Проект изменений на очередной плановый/текущий период"; 12.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него отрицательную сумму, по модулю равную сумме, указанной в БЗ; 13.В форме создания новой строки документа нажать кнопку "ОК"; 14.В форме создания новой бюджетной заявки на изменение ассигнований нажать кнопку "Применить"; 15.В форме создания новой бюджетной заявки на изменение ассигнование нажать кнопку "Действие" и выбрать действие "Обработать"; 16.В форме создания новой бюджетной заявки на изменение ассигнований нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 17.В форме создания новой бюджетной заявки на изменение ассигнований нажать кнопку "ОК"; 18.В списке "Расходы" открыть пункт меню "Распорядитель" "Формирование сводных бюджетных заявок"; 19.В открывшемся АРМ-е в блоке формирования в поле "Бланк расходов" выбрать бланк расходов с типом "Роспись", являющийся вышестоящим для созданной бюджетной заявки; 20.В открывшемся АРМ в блоке формирования в поле "Тип документа" выбрать сводную бюджетную заявку на изменение ассигнований; 21.В гриде со списком документов выбрать созданный 98

Сценарий 8. Обработка БЗнАИ документ и нажать на кнопку "Сформировать"; 22.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация; 2. В форме списка БЗнИА нажать на кнопку создания нового документа "Новый"; 3. В открывшейся форме в поле "Бланк расходов" вызвать "Справочник бланков расходов"; 4. В дереве бланков расходов справочника бланков расходов выбрать бланк расходов с типом "Смета" аналогичный выбранному в БЗ; 5. В поле "Версия" вызвать справочник "Версии планирования расходов"; 6. Выбрать версию, имеющую признак "Актуальная", нажать кнопку "Выбрать"; 7. В форме создания новой БЗнИА нажать на кнопку создания новой строки документа "Новый"; 8. В открывшейся форме в поле "Наименование полномочия, расходного обязательства" вызвать справочник "Расходные обязательства"; 9. Выбрать из списка доступное расходное обязательство отличное от выбранного в БЗ; 10.В поле КФСР вызвать справочник "Функциональная классификация расходов" выбрать из списка доступный код нижнего уровня; 11.Перевести курсор на поле "Проект изменений на очередной плановый/текущий период" и вызвать форму "Проект изменений на очередной плановый/текущей период"; 12.В форме создания новой строки документа перейти на поле "Сумма (1-ый год планирования)" и внести в него положительную сумму равную сумме, указанной в БЗ; 13.В форме создания новой строки документа нажать кнопку "ОК"; 14.В форме создания новой бюджетной заявки нажать кнопку "Применить"; 15.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Обработать"; 16.В форме создания новой бюджетной заявки нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 17.В форме создания новой бюджетной заявки нажать кнопку "ОК"; 18.В списке "Расходы" открыть пункт меню "Распорядитель" "Формирование сводных бюджетных заявок"; 19.В открывшемся АРМ в блоке формирования в поле 99

Сценарий 9. План Финансовохозяйственной деятельности (ПФХД) Сценарий 10. Цепочка документов ГП/ПП/ОМ и БЗ из нее "Бланк расходов" выбрать бланк расходов с типом "Роспись", являющийся вышестоящим для созданной бюджетной заявки; 20.В открывшемся АРМ в блоке формирования в поле "Тип документа" выбрать сводную бюджетную заявку на изменение ассигнований; 21.В гриде со списком документов выбрать созданный документ и нажать на кнопку "Сформировать"; 22.В открывшемся окне редактирования сводной бюджетной заявки нажать кнопку "Действие" и выбрать действие "Направить на согласование"; 23.В форме редактирования сводной бюджетной заявки нажать кнопку "Действие" и выбрать действие "Завершить обработку"; 24.В форме редактирования сводной бюджетной заявки нажать кнопку "Действие" и выбрать действие "Утвердить"; 25.В открывшемся окне подтверждения утверждения документа нажимаем кнопку "ОК"; 26.В открывшейся форме утверждения документа в поле "Дата" выбираем равную даты документа Сводная бюджетная заявка; 27.Выход из системы. 1. Запуск клиента «АЦК-Планирование» и авторизация; 2. Создание организации; 3. Создание Структуры ПФХД; 4. Создание ПФХД; 5. Обработка ПФХД; 6. Выход из системы. 1. Вход в меню «Главная – Планирование бюджета – Расходы – Формирование бюджета программноцелевым способом – ВЦП/АЦП/Основное мероприятие»; 2. Создание нового документа «Государственная (муниципальная) программа»; 3. Заполнение обязательных полей; 4. Из ЭД ГП (закладка "Перечень подпрограмм и основных мероприятия") создаётся ЭД Подпрограмма; 5. Из ЭД Подпрограмма (закладка "Перечень ВЦП/АЦП/Основных мероприятия") создаётся ЭД Основное Мероприятие (ОМ); 6. В ЭД ОМ на закладке «Мероприятия» формируется перечень Мероприятий, в разрезе которых формируются расходные строки; 7. На основании расходной строки формируется ЭД «Бюджетная заявка» (БЗ) по кнопке «Отобразить значения в бюджетных заявках» вкладки 100

Сценарий 11. Государственное (муниципальное) задание (ГмЗ) 8. 9. 1. 2. 3. 4. 5. 6. «Мероприятия» ЭД ОМ; Обработка ЭД ГП до статуса «Утверждено»; Выход из системы. Запуск клиента «АЦК-Планирование» и авторизация; Вход в меню «Главная – Планирование бюджета – Расходы – Бюджетные услуги – Государственное (муниципальное) задание» Создание нового документа «Государственное (муниципальное) задание (ГмЗ)»; Заполнение обязательных полей; Перевод ЭД ГМЗ на статус «Утверждено»; Выход из системы. 101

Приложение 2 XML структура скрипта нагрузочного теста, созданного с помощью Apache JMeter <?xml version="1.0" encoding="UTF-8"?> <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.0 r1840935"> <hashTree> <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true"> <stringProp name="TestPlan.comments"></stringProp> <boolProp name="TestPlan.functional_mode">false</boolProp> <boolProp name="TestPlan.serialize_threadgroups">false</boolProp> <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"> <collectionProp name="Arguments.arguments"/> </elementProp> <stringProp name="TestPlan.user_define_classpath"></stringProp> </TestPlan> <hashTree> <Arguments guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"> <collectionProp name="Arguments.arguments"> <elementProp name="address" elementType="Argument"> <stringProp name="Argument.name">address</stringProp> <stringProp name="Argument.value"></stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> <elementProp name="pass" elementType="Argument"> <stringProp name="Argument.name">pass</stringProp> <stringProp name="Argument.value">v</stringProp> <stringProp name="Argument.metadata">=</stringProp> <stringProp name="Argument.desc">Пустой пароль </stringProp> </elementProp> <elementProp name="sysuserid" elementType="Argument"> <stringProp name="Argument.name">sysuserid</stringProp> <stringProp name="Argument.value"></stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> <elementProp name="actversion_id" elementType="Argument"> <stringProp name="Argument.name">actversion_id</stringProp> <stringProp name="Argument.value"></stringProp> <stringProp name="Argument.desc">Актуальная версия расходов</stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> <elementProp name="variant_id" elementType="Argument"> <stringProp name="Argument.name">variant_id</stringProp> <stringProp name="Argument.value"></stringProp> <stringProp name="Argument.desc">Вариант </stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> </Arguments> <hashTree/> <CSVDataSet guiclass="TestBeanGUI" testclass="CSVDataSet" testname="pldirection.csv" enabled="true"> 102

<stringProp name="filename"></stringProp> <stringProp name="fileEncoding">UTF-8</stringProp> <stringProp name="variableNames">pldirection_id</stringProp> <boolProp name="ignoreFirstLine">false</boolProp> <stringProp name="delimiter">;</stringProp> <boolProp name="quotedData">false</boolProp> <boolProp name="recycle">true</boolProp> <boolProp name="stopThread">false</boolProp> <stringProp name="shareMode">shareMode.all</stringProp> </CSVDataSet> <hashTree/> <ResultSaver guiclass="ResultSaverGui" testclass="ResultSaver" testname="Сохранение ошибок сервера в файл" enabled="true"> <stringProp name="FileSaver.filename">pl_fail_</stringProp> <boolProp name="FileSaver.errorsonly">true</boolProp> <boolProp name="FileSaver.skipautonumber">false</boolProp> <boolProp name="FileSaver.skipsuffix">false</boolProp> <boolProp name="FileSaver.successonly">false</boolProp> <boolProp name="FileSaver.addTimstamp">true</boolProp> </ResultSaver> <hashTree/> <ResponseAssertion guiclass="AssertionGui" testclass="ResponseAssertion" testname="error" enabled="true"> <collectionProp name="Asserion.test_strings"> <stringProp name="-1294635214">error:</stringProp> </collectionProp> <stringProp name="Assertion.test_field">Assertion.response_data</stringProp> <boolProp name="Assertion.assume_success">false</boolProp> <intProp name="Assertion.test_type">6</intProp> <stringProp name="Assertion.custom_message"></stringProp> </ResponseAssertion> <hashTree/> <kg.apc.jmeter.threads.SteppingThreadGroup guiclass="kg.apc.jmeter.threads.SteppingThreadGroupGui" testclass="kg.apc.jmeter.threads.SteppingThreadGroup" testname="STRESS" enabled="true"> <stringProp name="ThreadGroup.on_sample_error">startnextloop</stringProp> <stringProp name="ThreadGroup.num_threads">250</stringProp> <stringProp name="Threads initial delay">0</stringProp> <stringProp name="Start users count">5</stringProp> <stringProp name="Start users count burst">0</stringProp> <stringProp name="Start users period">4</stringProp> <stringProp name="Stop users count">250</stringProp> <stringProp name="Stop users period">1</stringProp> <stringProp name="flighttime">3600</stringProp> <stringProp name="rampUp">8</stringProp> <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true"> <boolProp name="LoopController.continue_forever">false</boolProp> <intProp name="LoopController.loops">-1</intProp> </elementProp> </kg.apc.jmeter.threads.SteppingThreadGroup> <hashTree> <CounterConfig guiclass="CounterConfigGui" testclass="CounterConfig" testname="Counter" enabled="true"> <stringProp name="CounterConfig.start">0</stringProp> <stringProp name="CounterConfig.end">4999</stringProp> <stringProp name="CounterConfig.incr">1</stringProp> 103

<stringProp name="CounterConfig.name">login</stringProp> <stringProp name="CounterConfig.format">0</stringProp> <boolProp name="CounterConfig.per_user">false</boolProp> </CounterConfig> <hashTree/> <UniformRandomTimer guiclass="UniformRandomTimerGui" testclass="UniformRandomTimer" testname="Uniform Random Timer" enabled="true"> <stringProp name="ConstantTimer.delay">500</stringProp> <stringProp name="RandomTimer.range">500</stringProp> </UniformRandomTimer> <hashTree/> <ThroughputController guiclass="ThroughputControllerGui" testclass="ThroughputController" testname="Минфин РК" enabled="true"> <intProp name="ThroughputController.style">1</intProp> <boolProp name="ThroughputController.perThread">false</boolProp> <intProp name="ThroughputController.maxThroughput">1</intProp> <FloatProperty> <name>ThroughputController.percentThroughput</name> <value>36.03</value> <savedValue>0.0</savedValue> </FloatProperty> </ThroughputController> <hashTree> <GenericController guiclass="LogicControllerGui" testclass="GenericController" testname="Сценарий 1" enabled="true"/> <hashTree> <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="check_sessions_count - nobody" enabled="true"> <boolProp name="HTTPSampler.postBodyRaw">true</boolProp> <elementProp name="HTTPsampler.Arguments" elementType="Arguments"> <collectionProp name="Arguments.arguments"> <elementProp name="" elementType="HTTPArgument"> <boolProp name="HTTPArgument.always_encode">false</boolProp> <stringProp name="Argument.value"></stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> </collectionProp> </elementProp> <stringProp name="HTTPSampler.domain">${address}</stringProp> <stringProp name="HTTPSampler.port">${port}</stringProp> <stringProp name="HTTPSampler.protocol">http</stringProp> <stringProp name="HTTPSampler.contentEncoding"></stringProp> <stringProp name="HTTPSampler.path">/exec</stringProp> <stringProp name="HTTPSampler.method">POST</stringProp> <boolProp name="HTTPSampler.follow_redirects">true</boolProp> <boolProp name="HTTPSampler.auto_redirects">false</boolProp> <boolProp name="HTTPSampler.use_keepalive">true</boolProp> <boolProp name="HTTPSampler.DO_MULTIPART_POST">false</boolProp> <stringProp name="HTTPSampler.embedded_url_re"></stringProp> <stringProp name="HTTPSampler.connect_timeout"></stringProp> <stringProp name="HTTPSampler.response_timeout"></stringProp> </HTTPSamplerProxy> <hashTree> <HeaderManager guiclass="HeaderPanel" testclass="HeaderManager" testname="HTTP Header Manager" enabled="true"> <collectionProp name="HeaderManager.headers"> <elementProp name="method" elementType="Header"> 104

<stringProp name="Header.name">method</stringProp> <stringProp name="Header.value">job_process</stringProp> </elementProp> <elementProp name="Content-Type" elementType="Header"> <stringProp name="Header.name">Content-Type</stringProp> <stringProp name="Header.value">application/octetstream</stringProp> </elementProp> <elementProp name="sessionid" elementType="Header"> <stringProp name="Header.name">sessionid</stringProp> <stringProp name="Header.value"></stringProp> </elementProp> <elementProp name="Accept-Encoding" elementType="Header"> <stringProp name="Header.name">Accept-Encoding</stringProp> <stringProp name="Header.value">identity</stringProp> </elementProp> <elementProp name="Accept" elementType="Header"> <stringProp name="Header.name">Accept</stringProp> <stringProp name="Header.value">*/*</stringProp> </elementProp> <elementProp name="User-Agent" elementType="Header"> <stringProp name="Header.name">User-Agent</stringProp> <stringProp name="Header.value">Mozilla/3.0 (compatible; Indy Library)</stringProp> </elementProp> </collectionProp> </HeaderManager> </hashTree> </hashTree> </hashTree> </hashTree> </hashTree> </hashTree> </jmeterTestPlan> 105