Проектирование автоматизированной системы построения тестовых сценариев высоконагруженных информационных систем

Проектирование автоматизированной системы построения тестовых сценариев высоконагруженных информационных систем

Оглавление

Введение

. Современное состояние проблем тестирования высоконагруженных информационных систем(ВНИС)

.1 Процесс нагрузочного тестирования (НТ). Основные понятия и определения

.2 Анализ существующих подходов к реализации процесса тестирования ВНИС в различных областях

.3 Анализ существующих автоматизированных систем (АС) поддержки процесса тестирования

.4 Постановка задачи построения АС тестирования ВНИС

. Проектирование автоматизированной системы построения тестовых сценариев ВНИС

.1 Технологическая архитектура АС

.2 Информационно логическая модель данных

.3 Разработка алгоритмов формирования тестовых сценариев

.4 Математическая модель определения высоконагруженных операций

.5 Дизайн пользовательского интерфейса АС тестирования ВНИС

. Разработка АС построения тестовых сценариев ВНИС

.1 Обоснование выбора платформы для разработки АС

.2 Разработка программного обеспечения АС тестирования ВНИС

. Тестирование АС построения тестовых сценариев ВНИС

.1 Постановка задачи

.2 Тестирование АС построения тестовых сценариев ВНИС основываясь на данных банка

.3 Тестирование АС построения тестовых сценариев ВНИС основываясь на данные биллинговой компании

Заключение

Введение

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

Есть три основные цели этого исследования:

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

.        Спроектировать архитектуру автоматизированной системы генерации тестовых сценариев

.        Разработать автоматизированную систему генерации сценариев нагрузочного тестирования.

Основным инструментом для разработки автоматизированной системы построения тестовых сценариев высоконагруженных информационных систем был выбран Java VM. Java-платформа имеет такие преимущества, как: кроссплатформенность, объектная ориентация, встроенная модель безопасности, легкость добавления новых функций, легкость разработки.

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

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

1. Современное состояние проблем тестирования высоконагруженных информационных систем(ВНИС)

.1      Процесс нагрузочного тестирования (НТ). Основные понятия и определения

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

Нагрузочное тестирование (Load Testing) - автоматизированное тестирование, имитирующее работу необходимого и заранее определенного количества пользователей, тем самым создавая в системе условия, идентичные реальной нагрузке на общем ресурсе.

Существуют различные виды нагрузочного тестирования, преследующие различные цели:

·        Тестирование производительности (Performance Testing)

·        Стрессовое тестирование (Stress testing)

·        Тестирование стабильности (Stability / Reliability Testing)

Тестирование производительности проводится с целью определения масштабируемости системы под нагрузкой. Такое тестирование позволяет:

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

·        измерить время отклика системы при выполнении определенных операций в случае изменения интенсивности их инициации;

·        определить некоторые «узкие» места системы.

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

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

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

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

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

·        Анализ требований

·        Сбор информации о продукте

·        Проектирование модели нагрузочного тестирования

·        Конфигурация стенда для проведения тестовых испытаний

·        Проектирование модели нагрузки

·        Создание скриптов для нагрузочного тестирования

·        Создание типовых сценариев нагрузки

·        Тестовое испытание

·        Анализ результатов

·        Отчетная документация

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

Для каждого класса пользователей необходимо спроектировать свой сценарий работы. Каждый типовой сценарий работы пользователей содержит в себе:

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

·        данные, с которыми будет работать данный сценарий;

·        параметры производительности или оборудования, которые необходимо измерить на этапе проведения тестовых испытаний.

Основные используемые в работе термины и сокращения:

Виртуальный пользователь (Virtual User) - программный процесс, циклически выполняющий моделируемые операции

Итерация (Iteration) - это один повтор выполняемой в цикле операции

Интенсивность выполнения операции (Operation Intensity) - частота выполнения операции в единицу времени, в тестовом скрипте задается интервалом времени между итерациями

Нагрузка (Loading) - совокупное выполнение операций на общем ресурсе в единицу времени (тр./сек, хитов/сек)

Производительность (Performance) - количество выполняемых операций за период времени (N операций за M часов)

Масштабируемость приложения (Application Scalability) - пропорциональный рост производительности при увеличении нагрузки

Профиль нагрузки (Performance Profile) - это набор операций с заданными интенсивностями, полученный на основе сбора статистических данных либо определенный путем анализа требований к тестируемой системе

Дымовое тестирование (Smoke test) - короткий цикл тестовых испытаний, выполняемый с целью подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение стартует и выполняет основные функции.

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

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

Высоконагруженная информационная система (ВНИС) - совокупность программно-аппаратных средств, отличающаяся высокими нагрузками.

Программное обеспечение (ПО) - совокупность программ, хранящихся на всех устройствах долговременной памяти компьютера(-ов).

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

1.2    Анализ существующих подходов к реализации процесса тестирования ВНИС в различных областях (банковской сфере, телекоммуникационных компаниях)

Проведя анализ существующих подходов к реализации процесса тестирования ВНИС в таких компаниях как: «Банк «Открытие»» и «Билайн», был выявлен следующий алгоритм проведения тестирования ПО при выпуске новой версии (рис. 1).

Рис. 1. Алгоритм проведения тестирования программного обеспечения

высоконагруженный информационный тестирование сценарий

Процесс тестирования ВНИС делится на 5 этапов, включая разработку. На первом этапе ведется разработка ПО и исправление ошибок, выявленных после проведения тестирования. Этап 2 - сборка пакета с проектом. На этапе 3 происходит установка пакета с дальнейшей сборкой проекта. Далее начинается процесс тестирования. На четвертом этапе специалистом по ручному тестированию проводится Smoke test. Если тест пройден успешно и не выявлено никаких ошибок, происходит переход на 5 этап, иначе найденные ошибки документально фиксируются, и проект отправляется на доработку на этап 1. Данный цикл повторяется до тех пор, пока Smoke test не будет пройден. На этапе 5 подключаются специалисты по нагрузочному тестированию и специалисты по автоматизации тестирования. Проводится нагрузочное тестирование надежности системы, регрессионное автоматизированное и ручное тестирование. Если все виды тестирования пройдены, то пакет с проектом попадает на «боевой» сервер, которым пользуется клиент ПО. Иначе пакет попадает на доработку к разработчикам.

1.3    Анализ существующих автоматизированных систем (АС) поддержки процесса тестирования

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

·        Инструменты функционального тестирования

·        Инструменты нагрузочного тестирования

·        Средства поддержки процесса тестирования

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

Инструменты нагрузочного тестирования

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

К данным инструментам можно отнести продукты таких компаний как HP и IBM.

IBM Rational Performance Tester <#"896997.files/image002.jpg">

Рис. 2. Технологическая архитектура АС

Технологическая архитектура АС включает в себя следующие компоненты (рис. 2.):

·        Клиентское приложение АС генерирования тестовых сценариев ВНИС

·        Сервер АС системы генерирования тестовых сценариев ВНИС

·        База данных установленная на сервер АС

Также, стоит отметить еще несколько стратегически важных компонент:

·        Корпоративный сервер

·        База данных корпоративного сервера

·        Тестовый сервер

·        База данных тестового сервера

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

Далее, через определенное компанией время, вся информация с корпоративного сервера попадает на тестовый сервер. На тестовом сервере работают специалисты по тестированию и контролю качества для решения своих задач.

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

Полученная статистика будет обработана и помещена на сервер АС в БДП. Также в БДП будет храниться все необходимая информация для генерирования тестовых сценариев:

·        Таблица с POST и GET запросами.

·        Таблица с необходимыми параметрами для запросов

·        Параметры, определяющие вид НТ.

Технические требования, предъявляемые к серверу АС:

.        Память - 8 Гб

.        Процессор - 2 ядра, 2,7 ГГц

.        Жесткий диск - 100 Гб

.        Тип рабочей станции - PC

.2 Информационно логическая модель данных

Сервер АС генерирования тестовых сценариев ВНИС и установленная на него БДП это - реляционная база данных, которая предназначена для хранения информации, необходимой для функционирования АС. За поддержку БДП отвечает специалист по нагрузочному тестированию.

Информационно логическая модель данных выглядит следующим образом:

Рис. 3. Информационно логическая модель данных

БДП содержит 5 основные таблицы:

.        MainBP (Main business process)

Таблица предназначена для хранения наименования запросов и id к записи в таблице BPRequests.

Рис. 4. Таблица MainBP

·        id - private key записи

·        name - название БП

·        req_id - foreign key записи к таблице BPRequests

.        BPRequests (Business process requests)

Таблица предназначена для хранения информации необходимой для формирования запроса.

Рис. 5. Таблица BPRequest

·        id - private key записи

·        type - тип посылаемого запроса GET/POST

·        http - путь к ресурсу

·        json - параметры необходимые для формирования запроса в формате Json

.        BPsTable (Business process statistics)

Таблица предназначена для хранения статистики по всем существующим БП за последнюю неделю. Это количество запросов к данному БП и процент от общего количества запросов за неделю.

Рис. 6. Таблица BPsTable

·        id - foreign key записи к таблице MainBP

·        percentOfNumber - процент от общего количества запросов за неделю

.        NewBP (New business process)

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

Рис. 7. Таблица NewBP

·        id - foreign key записи к таблице MainBP

·        numberOfBF - количество бизнес-функций внутри БП

·        numberOfLC - количество строк кода БП

·        durationOfOp - время выполнения БП в секундах

·        numberOfCDB - количество обращений к базе данных

·        avTimeofCDB - среднее время выполнения одного запроса к базе данных.

·        popularityRate - коэффициент популярности

.        FinalTable

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

Рис. 8. Таблица FinalTable

·        id - foreign key записи к таблице MainBP

·        name - название БП

·        amountOfRequestPerHour - количество запросов в час

·        percentOfNumber - процент от общего количества запросов за неделю

·        type - тип посылаемого запроса GET/POST

·        http - путь к ресурсу

·        json - параметры необходимые для формирования запроса в формате Json

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

Также в БДП присутствует 2 хранимые процедуры. Первая служит для работы с таблицей NewBP, и определяет относится ли данный БП к высоконагруженной операции. Вторая, для формирования итоговой таблицы FinalTable. В разделе 2.4 данной главы находится описание математической модели для определения высоконагруженных операций.

Сами скрипты для создания БДП, таблиц и скрипты хранимых процедур будут описаны в главе 3 данной работы.

2.3 Разработка алгоритмов формирования тестовых сценариев

Для генерирования тестового сценария для НТ ВНИС прежде всего необходимо создать и заполнить базу данных приложения.

Создание базы данных приложения:

·        Создание всех таблиц описанных в пункте 2.2 "База данных приложения" данной главы

·        Заполнение таблиц MainBP, BPRequest, BPsTable, NewBP. Для заполнения данных таблиц необходимо написать скрипт и создать в БДП хранимую процедуру, которая автоматически будет выполнять данную задачу. На текущем этапе работы невозможно написать данную процедуру в связи с тем, что необходимо обращаться к корпоративной БД, которая уникальна, и невозможно заранее предугадать ее архитектуру.

)        В случае появления новых БП, по которым отсутствует информация по количеству запросов к данному БП за последнюю неделю

а)      Используя полученную математическую модель, описанную в пункте 2.4 данной главы определить относится ли она к высоконагруженным операциям

)        Формирования итоговой таблицы FinalTable со статистикой для пользователя

а)      Название БП

б)      Процент от общего количества БП за последнюю неделю

в)      Количество запросов данного БП в час.

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

)        Пользователю предоставляется возможность выбора необходимых БП для проведения НТ.

)        Пользователь выбирает вид НТ (Тест надежности, Поиск максимальной производительности, Регрессионное тестирование)

)        Формирование исполняемого .jmx файла.

)        Запуск НТ

)        Формирование отчета о тестировании.

)        Вывод отчета о тестировании на экран.

2.4 Математическая модель определения высоконагруженных операций

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

Основными анализируемыми параметрами выступают:

·        количество бизнес-приложений, участвующих в реализации бизнес-процесса

·        время выполнения процесса (или операций, участвующих в процессе)

·        количество обращений к базе данных

·        среднее время выполнения одного запроса к базе данных

·        коэффициент популярности (передает Product Owner)

Рассмотрим в качестве математической модели бизнес процесса, реализуемого в корпоративной информационной системе, следующий набор:

= {B, O, P} (1),

где: B={b_i } - множество бизнес-приложений b_i, входящих в состав бизнес-процесса, где i=1, …,N.= {o_k } - множество информационных объектов, участвующих в реализации бизнес-процесса, где k=1, …,K.- коэффициент популярности БП, определяемый экспертным путем.= <B, O> - граф, определяющий топологию выполняемого бизнес процесса (неориентированный, без петель, не имеющий кратных ребер), с матрицей смежности A = [a_ml], где (a_ml = o_k, если бизнес-приложение b_m использует результат выполнения бизнес-приложения b_l над o_k - информационными объектами и a_(ml ) = 0, если не использует).

В качестве примера можно рассмотреть бизнес-процесс «Оплата мобильного телефона». Схема процесса приведена на рисунке 9.

Рис. 9 Схема процесс «Оплата мобильного телефона»

На рисунке 10 представлена схема топологии данного бизнес-процесса в виде графа

Рис. 10 Граф топологии бизнес-процесса

Обозначим w_ij - количество операций «запись», которые выполняются в соответствии с передачей сообщений между приложениями i и j. Обозначим r_ij - количество операций «запись», которые выполняются в соответствии с передачей сообщений между приложениями i и j.

Тогда для заданного бизнес-процесса l∈L c заданной топологией q∈Q показатель нагруженности LC_l будет вычисляться следующим образом:

Так как события инициирующие, заданный бизнес-процесс, имеют случайный характер, то можно предположить, что каждое бизнес-приложение b_i в бизнес-процессе l генерирует операции чтения и записи информационных объектов независимо от других бизнес-приложений и эти операции имеют Пуассоновское распределение с параметрами: μ_rb и μ_wb, соответственно.

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

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

В соответствии с предложенной моделью были разработаны алгоритмы генерации сценариев тестирования ВНИС, которые легли в основу разрабатываемой системы.

2.5 Дизайн пользовательского интерфейса АС тестирования ВНИС

В рамках проекта был разработан интерфейс системы. Пользователь начинает работу с начальной страницы (рис. 9), на которой указано название системы и кнопка начала работы операции сбора статистики.

Рис. 11 Главное окно автоматизированной системы

На следующем экране (рис. 10) пользователь выбирает вид тестирования. После сбора статистики, система предлагает пользователю на выбор высоконагруженные бизнес-операции, которые предлагается включить в сценарий тестирования. Отметив все необходимые бизнес-процессы и нажав на кнопку «Сгенерировать сценарий», пользователь получает готовые тестовый сценарий в формате XML (рис. 11), который можно скопировать или сохранить нажатием на соответствующие кнопки.

Рис. 12 Окно выбора бизнес-процессов

Рис. 13 Окно с готовым тестовым сценарием

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

3. Разработка АС построения тестовых сценариев ВНИС

.1 Обоснование выбора платформы для разработки АС

Для разработки АС построения тестовых сценариев ВНИС был выбран Java VM. Выбор основывается на следующих определяющих факторах:

·        Java - кроссплатформенный язык программирования. Другими словами, программы, могут писаться, далее собираться и компилироваться под любой операционной системой.

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

·        Java - свободная платформа с открытым исходным кодом. Также существует огромное множество подключаемых библиотек сторонних компаний, таких как Google или Yandex.

Немалым фактором является огромное количество IDE (Integrated Development Environment), что делает работу более удобной и приятной

В качестве framework был выбран Maven. Maven - это фреймворк для автоматической сборки проектов на основе описания их структуры в файлах на языке POM (Project Object Model).

3.2 Разработка программного обеспечения АС тестирования ВНИС

Самая важная часть в разработки АС генерации тестовых сценариев для ВНИС заключается в создании БДП, именно там присутствует основная часть логики генерации тестовых сценариев.

Скрипт для создания БДП:

Рис. 14 Скрипт создания базы данных AutomationSystemDB

Далее необходимо создать таблицы в БДП.

·        Скрипт создания таблицы BPRequest:

Рис. 15 Скрипт создания таблицы BPRequest

·        Скрипт создания таблицы MainBP:

Рис. 16 Скрипт создания таблицы MainBP

·        Скрипт создания таблицы BPsTable:

Рис. 17 Скрипт создания таблицы BPsTable

·        Скрипт создания таблицы NewBP:

Рис. 18 Скрипт создания таблицы NewBP

·        Скрипт создания таблицы FinalTable:

Рис. 19 Скрипт создания таблицы FinalTable

Следующий шаг - это написание хранимой процедуры. Первая хранимая процедура отвечает за определение относится ли БП к высоконагруженному или нет. Логика данной процедуры была описана в пункте 2.4. «Математическая модель определения высоконагруженных операций.» главы 2.

·        Скрипт хранимой процедуры dbo.[setFinalTableFromNewBP]:

Рис. 20 Скрипт создания хранимой процедуры dbo.[setFinalTableFromNewBP]

Вторая хранимая процедура выбирает первые 20 БП, которых значение поля percentOfNumber - процент от общего количества запросов за неделю, является наивысшим.

·        Скрипт хранимой процедуры dbo.[setFinalTableFromMainBP]:

Рис. 21 Скрипт создания хранимой процедуры dbo.[setFinalTableFromMainBP]

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

В результате работ 3го этапа данного исследования получены следующие результаты: сознана БДП, в которой заключена основная часть логики генерации тестовых сценариев, созданы необходимые для корректной работы таблицы и хранимые процедуры, отвечающие за определение высоконагруженных операций и выборку наиболее высоконагруженных бизнес-процессов. Также разработана АС генерации тестовых сценариев, инструментом и платформой для разработки которого выступает Java. Разработанная АС выступает в роли интерфейса для взаимодействия между клиентом и сервером.

4. Тестирование АС построения тестовых сценариев ВНИС

.1 Постановка задачи

Для того, чтобы убедиться в корректной работе АС построения тестовых сценариев ВНИС необходимо провести функциональное тестирование следующих компонент:

·        Хранимая процедура dbo.[setFinalTableFromMainBP]

·        Хранимая процедура dbo.[setFinalTableFromNewBP]

·        Скрипт генерирования тестового сценария

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

.2 Тестирование АС построения тестовых сценариев ВНИС основываясь на данных банка

Перед проведением тестирования были заполнены следующие таблицы в БДП:

·        BPRequest

·        MainBP

·        BPsTable

·        NewBP

Таблица FinalTable пустая.

Убедимся в работоспособности двух хранимых процедур. Результат работы - заполненная таблица FinalTable, необходимая для генерирования тестового сценария в формате .jmx.

Щаг 1. Выполняем хранимую процедуру dbo.[setFinalTableFromMainBP]

Щаг 2. Выполняем хранимую процедуру dbo.[setFinalTableFromNewBP]

Результат выполнения:

Рис. 22 Результат выполнения хранимых процедур

Шаг 3. Выбираем вид тестирования «Поиск максимальной производительности».

Шаг 4. Выбираем бизнес-процессы для которых, необходимо сгенерировать тестовый сценарий. Выбираем «Оплата услуг» и «Получение списка карт».

Шаг 5. Выполняем скрипт для генерирования тестового сценария.

Результат выполнения:

Рис. 23 Результат выполнения скрипта

Рис. 24 Результат выполнения скрипта

В результате тестирования «АС построения тестовых сценариев ВНИС» на основе данных тестового сервера банка, дефектов выявлено не было.

4.3 Тестирование АС построения тестовых сценариев ВНИС основываясь на данные биллинговой компании

Проделаем те же самые шаги, что и при тестировании на тестовых данных банка.

Очистим таблицу FinalTable и заполним следующие таблицы данными с тестового сервера биллинговой компании:

·        BPRequest

·        MainBP

·        BPsTable

·        NewBP

Убедимся в работоспособности двух хранимых процедур. Результат работы - заполненная таблица FinalTable, необходимая для генерирования тестового сценария в формате .jmx.

Щаг 1. Выполняем хранимую процедуру dbo.[setFinalTableFromMainBP]

Щаг 2. Выполняем хранимую процедуру dbo.[setFinalTableFromNewBP]

Результат выполнения:

Рис. 25 Результат выполнения хранимых процедур

Шаг 3. Выбираем вид тестирования «Тестирование стабильности».

Шаг 4. Выбираем бизнес-процессы для которых, необходимо сгенерировать тестовый сценарий. Выбираем «Логин» и «Домашний интернет»

Шаг 5. Выполняем скрипт для генерирования тестового сценария.

Результат выполнения:

Рис. 26 Результат выполнения скрипта

Рис. 27 Результат выполнения скрипта

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

Заключение

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

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

.        Спроектирована АС построения тестовых сценариев ВНИС. А именно: разработана технологическая архитектура АС, выявлены требования к разрабатываемой АС, проработаны информационно-логическая модель данных.

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

.        Разработаны алгоритмы формирования тестовых сценариев.

.        Разработан дизайн пользовательского интерфейса АС.

.        Разработана АС генерации тестовых сценариев ВНИС.

.        Проведено тестирование разработанной АС и оценена эффективность.

Проведенная работа полностью соответствует техническому заданию на ВКР.

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