CC BY
108
Вишняков П. В., Шибанов С. В.
Пензенский государственный университет
СИСТЕМА ТЕСТИРОВАНИЯ СЕРВЕРНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ АКТИВНЫХ БАЗ ДАННЫХ
Введение и постановка задачи
Тестирование работоспособности и оценка производительности - неотъемлемая часть процессакак разработки нового, так и развития существующего программного обеспечения. Оно позволяет не только обеспечить корректность, но и сравнить приложение с уже существующими аналогами для оценки его эффективности. Это справедливо не только для настольных, но и для серверных приложений, например для активных баз данных - АБД [1]. База данных называется активной (АБД), если система управления базой данных (СУБД) по отношению к ней выполняет не только явно указанные пользователем действия, но и дополнительные действия в соответствии с правилами, заложенными в саму базу данных (БД). Кроме того, система управления активной базой данных (СУАБД) должна отслеживать возникновение событий, описанных в АБД, и осуществлять их обработку посредством запуска процедур, затрагивающих как саму АБД, так и ее окружение. Таким образом, поскольку отличительная особенность АБД - сложная серверная логика, сравнительное тестирование особенно актуально, т.к. необходимо быть уверенным в том, что затраченные усилия окупятся при дальнейшей эксплуатации [2].
Одним из наиболее распространенных средств тестирования производительности клиент-серверных СУБД являются эталонные тесты TPC [3-4] (TransactionPerformanceCouncil - международный Совет по производительности обработки транзакций), а именно - тест TPC-C/S. Данный тест симулирует компьютерную среду, в которой большое число пользователей выполняют транзакции с использованием дан-ных,хранящихся в СУБД. Подобная бизнес активность характерна для систем ввода заказов, вне зависимости от области деятельности, будь это система управления предприятием или заказ авиабилетов. Этот тест включает симуляцию ввода заказов, выдачу накладных, внесение информации о плате-жах,проверку состояния заказов и отслеживании состояния склада. Нагрузка на систему и структура базы данных выбраны такими, что они не являются специфичными для какой либо конкретной отрасли, но отражают усредненный бизнес по управлению, продажам или дистрибуции неких товаров или услуг.
Следует отметить, что тесты TPC-C в свое время были большим шагом вперед в области оценки производительности OLTP транзакций. Однако быстрое развитие технологий выявило ряд ограничений и недостатков этих тестов, как архитектурного, так и методологического характера.
Архитектурные ограничения и недостатки TPC-C/S:
Тесты TPC-Cявляются классическими тестами в архитектуре клиент-сервер,в которых в качестве клиента используется клиентская часть приложения, написанная на каком либо языке программирования и размещенная на настольном компьютере под управлением какой-либо 32-х разрядной версии Windows.Это ограничение не учитывает все более популярные типы современных клиентов: браузеры, мобильные телефоны, мобильные компьютеры (PDA), кассовые терминалы, ридеры штрих кода и др. Кроме того, полученные показатели одновременно оценивают не только производительность серверной логики, но и производительность интерфейсов приложения для доступа к базе данных.
Тестирование проводится в двухуровневой архитектуре клиент-сервер.Не используется все более популярная трехуровневая архитектура(клиент -сервер приложений - сервер).
Не тестируется поддержка индустриальных стандартов SOAP/XML.
В тесте отсутствуют очень распространенные в современных иерархических базах данных транзакции требующие операцию двухфазногокоммита (2-phase commit).
В тестах отсутствуют необходимые операции по резервному копированию - восстановлению данных, являющиеся важной частью реальных бизнес систем. Тесты не оценивают возможности быстрого восстановления системы после сбоев.
Отсутствует поддержка использования исполняемых модулей на современных языках программирования Java и C#.
Методологические ограничения и недостатки TPC-C/S:
В тестах TPC-C все пользователи имеют равные права. Не поддерживаются опции защиты содержимого базы данных, включая шифрование и расширенный контроль доступа.
Ограниченность модели данных. В тестах TPC-C используется структура данных, состоящая только из 9 таблиц. Многие реальные приложения большую часть времени также используют сравнительно небольшое количество таблиц, но для более реалистичного приближения необходимо, в небольшом числе случаев, использовать более сложную модель данных. Кроме того, в реальных приложениях может использоваться больше триггеров и правил для обеспечения целостности данных.
В тестах TPC-C используется пять типов транзакций отражающих основные бизнес операции реальных систем. Эти транзакции отражают только основные бизнес операции. В реальных бизнес процессах всегда присутствуют более редкие, но значительно более требовательные к ресурсам операции, такие как заказ запасных частей к существующему оборудованию и т.п. Подобные запросы часто возникают в ситуациях, когда предлагаемый товар состоит из нескольких частей,которые в свою очередь также могут состоять из нескольких компонентов. Эти запросы не столь сложны, как в системах поддержки принятия решений, но они часто встречаются в реальных системах, в то время как в тестах TPC-C они отсутствуют .
Типы данных, используемые в тестах, ограничены. Не используются изображения, тексты и другие мультимедийные данные.
Увеличение размеров базы данных при увеличении бизнеса в тестах TPC-C построено по линейному закону. Т. е. добавление еще одного склада приводит к пропорциональному росту объема данных во всех таблицах базы данных и добавлению 10 дополнительных пользователей. В реальном приложении это может не соответствовать действительности.
С точки зрения АБД, среди перечисленных ограничений наиболее важны п.п. 1, 2, 4 и 8.
Преодолеть ограничения пунктов 1 и 2 возможно путем переноса системы тестирования на сервер базы данных (в случае двухуровневой архитектуры) или сервер приложений (в случае трехуровневой архитектуры). Ограничение 4 преодолевается самой системой -в силу особенностей правил активной базы данных. Ограничение 8 также преодолевается за счет специфики АБД - наличия сложной серверной логики.
2. Модульная архитектура серверных программных средств управления АБД
Серверное программное обеспечение управления АБД имеет модульную архитектуру. Модули могут быть активированы независимо друг от друга и реализовывать различную функциональность, например -различные варианты реализации активных правил. Система тестирования также является одним из модулей, что позволяет преодолеть отмеченные выше ограничения TPC-C/S.
Поскольку модули системы располагаются на сервере, они полностью независимы от каналов связи с клиентом, от способа взаимодействия клиента с СУБД и от клиента в целом. Единственной задачей
клиента остается запуск тестирования и получение данных после его окончания. Для хранения результатов тестирования может использоваться как централизованная база метаданных АБД, так и база данных тестируемой системы. Таким образом обеспечивается централизованноехранениерезультатов тестирования для последующего анализа (в том числе - и серверными средствами, например, с помощью OLAP-технологий), тогда как в эталонном тесте TPC-C вывод и обработкарезультатов тестирования осуществляется клиентским приложением.
Кроме того, т.к. система проведения и поддержки тестирования представляет собой модуль серверного ПО управления АБД, она может быть развернута как в двухуровневой, так и в трехуровневой архитектуре (в зависимости от конфигурации сервера АБД).
Производительность серверных программных средств может быть оценена по одному из двух сценариев :
Тестирование на основе исторических данных;
Тестирование в изолированной среде.
Тестирование на основе исторических данных характерно для тестирования целостных информационных систем. Оно позволяет избежать генерации тестовых данных посредством использования данных, накопленных в ходе предшествующей эксплуатации системы, но обладает недостатком - накопление данных при эксплуатации системы не позволяет одинаково протестировать все ее компоненты.
При тестировании в изолированной среде могут быть оценены все компоненты, однако для тестирования необходимо получить набор тестовых данных. Такой подход применяется при оценке производительности систем управления информационными системами (СУБД или СУАБД); в частности, такой подход используется в тесте TPC-C/S.
Поскольку тестирующая система является модулем, она может использоваться для тестирования как в изолированной среде, так и для тестирования на основе исторических данных - в этом случае модуль тестирования подключается к серверному программному обеспечению управления АБД существующей информационной системы.
3. Компоненты системы тестирования
Система тестирования серверного программного обеспечения активных баз данных включает:
Профиль нагрузки;
Модуль проведения тестирования;
Средства накопления и хранения результатов тестирования.
3.1 Профиль нагрузки.
Профиль нагрузки - это набор параметров, на основе которого генерируется тестовый набор данных. Он является количественным описанием тестирования применительно к конкретной тестовой области - первоначальное число тестовых данных, динамику их изменения, а также динамику роста. Описание профиля содержится в базе шаблонов во вспомогательной сущности, данные в которой хранятся в парах ключ - значение (таблица 1).
Таблица 1. Описание сущности Профиль нагрузки
Столбец Описание
Наименование Наименование профиля нагрузки, понятное пользователю
Комментарий Текстовое описание профиля
Параметр Имя параметра профиля
Значение Значение параметра профиля
Использование пар «ключ - значение» (вместо традиционной схемы распределения значения по
столбцам) позволяет варьировать число и тип параметров профиля, не меняя структуру сущности. Таким образом, данная сущность может быть вынесена из предметной области и помещена в базу шаблонов, что позволит использовать эту сущность для централизованного хранения необходимого числа профилей нагрузки, используемых не только в различных ситуациях, но и в различных предметных областях.
3.2 Модуль проведения тестирования
Тестирующий модульявляется заменой клиентского приложения тестирования и состоит из компонентов нескольких типов, а именно централизованного средства управления тестированием и распределенных средств накопления данных.
В качестве средства управления тестированием может выступать серверная хранимая процедура (в реляционных СУБД) или метод класса (в объектных СУБД). Ееосновными задачами являются:
Первоначальная генерация тестовых данных;
Итерационная модификация данных согласно профилю нагрузки;
Очистка модели от тестовых данных.
Распределенные средства накопления данных могут представлять собой триггеры (для реляционных СУБД), функции обратного вызова или методы классов (для объектных СУБД) или же правила (для СУБД типа Postgres, обладающих поддержкой правил). Их задача - протоколирование процесса тестирования. На каждую исследуемую операцию необходимо два таких компонента - один из них регистрирует время начала операции, второй - время ее окончания.Однако не во всех СУБД существует возможность явного указания очередности срабатывания правил, триггеров или обработчиков событий. В данном случае управление порядком срабатывания осуществляется каркасом модульной системы, которая получает сигнал о наступлении интересующего события, после чего выполняет необходимые действия в требуемом порядке.
При этом средства накопления данных могут подключаться и отключаться в рамках одного и того же профиля нагрузки.Например, для выявления потенциальных узких мест в системе и их детального анализа вплоть до отдельного элемента бизнес-логики - процедуры или метода.
Генерация тестовых данных непосредственно в АБД позволяет решить ряд задач, а именно:
Получение набора семантически непротиворечивых данных заданного объема;
Управление тестированием посредством модификации созданных данных.
3.3 Средства накопления и хранения результатов тестирования.
Накопление результатов осуществляется модулем проведения тестирования непосредственно в процессе тестирования.
Для хранения результатов на сервере предлагается использовать сущности Тест(таблица 2) и Операция (таблица 3), связанные отношением 1:М (рисунок 1).
Сущность Тест является родительской и предоставляет общую информацию о тестовом запуске, а именно - наименование и описание теста, время его начала и окончания, а также продолжительность.
Таблица 2. Описание структуры сущности Тест Атрибут
Описание
Наименование Название теста, понятное пользователю
Комментарий Текстовый комментарий, содержащий подробное описание теста
Время начала Время начала теста
Время окончания Время окончания теста
Продолжительность Продолжительность выполнения теста
Операцией может быть, как активное правило, так и его часть и даже отдельный оператор (выборка) .
Таблица 3. Описание структуры сущности Операция
Атрибут Описание
Операция Имя процедуры и операции (системное)
Время начала Время начала выполнения
Время окончания Время окончания выполнения
Продолжительность Продолжительность выполнения операции
С каждым экземпляром сущности Тест связаны один или несколько экземпляров сущности Операция -действий, выполняемых серверной бизнес-логикой.
Наименование Комментарий Время начала Время окончания Продолжительность
Рисунок 1 Отношение сущностей Операция и Тест
АтрибутПродолжительность обоих сущностей является вычисляемым - его значение проставляется обработчиком после того, как появились значения в полях Время Начала и Время окончания.
Данные сущности могут быть помещены как в тестируемую базу данных, так и в базу активных метаданных. Во втором случае обеспечивается централизованное хранение результатов тестирования для различных конфигураций серверных модулей (и в целом - для различных баз данных)
3.4 Изменения в базах данных.
Для каждого события, обрабатываемого правилами активной базы данных, должны быть созданы по два дополнительных обработчика (триггера). Эти обработчики активируются, соответственно, до и после выполнения правила и записывают временные отметки в поля «Время начала» и «Время окончания». Использование этих обработчиков (в отличие от внедрения их функционала в существующие пра-вила/триггеры) также соответствует модульной архитектуре серверных программных средств - независимые триггеры могут быть гибко подключены или отключены.
4. Методика проведения тестирования
Тестирование в рамках модульной архитектуры серверного программного обеспечения АБД организуется в несколько этапов.
Этап 1. Рассматриваемая предметная область разворачивается в базах данных двух типов: активной и пассивной с соблюдением следующих правил:
Активная база данных использует только правила, которые полностью заменяют пассивную логику (триггеры для реляционных СУБД и обработчики событий для объектных СУБД).
Правила активной базы данных преобразуются в пассивную логику по следующей схеме (таблица 3).
Таблица 3. Схема преобразования пассивной БД в активную БД
Этап 2. На данном этапе определяется профиль нагрузки для выбранной конфигурации и предметной области. Профиль может быть выбран как среди уже существующих в базе шаблонов, так и создан с нуля согласно предварительным расчетам.
Этап 3.Третий этап связан с генерацией первоначального набора тестовых данных согласно параметрам профиля нагрузки, определенным на этапе 2.
Этап 4.Четвертый этап - собственно проведение тестирования.
Этап 5.Выполняется очистка баз данных от тестовых данных.
Этап 6 (необязательный). Передача данных о тестировании на клиентское приложение.
5. Заключение
В данной статье рассмотрена система проведения и поддержкитестирования в рамках модульной архитектуры серверного программного обеспечения АБД. Были показаны ее преимущества по сравнению с традиционной реализацией тестирования, в том числе - TPC-C, а также описана методика подготовки баз данных к тестированию и проведения тестирования с использованием системы тестирования в рамках модульной архитектуры.
ЛИТЕРАТУРА
1. Шибанов С.В., Лысенко Э.В. Концептуальные особенности систем управления активными базами
данных// Альманах современной науки и образования. - Тамбов: Грамота, №11 (42), 2010. - Ч. 2. -
С. 106-114.
2. Шибанов С. В., Вишняков П. В. Тестирование серверных программных средств управления активными
базами данных// Математическое и программное обеспечение систем в промышленной и социальной сферах: междунар. сб. науч. трудов. - Магнитогорск: Изд-во Магнитогорск.гос. техн. ун-та им. Г.И.
Носова, 2011. - Ч. I. - С. 52-59.
3. М.Р. Когаловский Энциклопедия баз данных. М.: Финансы и Статистика, 2002.
Активная база данных Пассивная база данных
Правила Триггеры
Пассивная логика Пассивная логика
Данные Данные
Операция
Операция Время начала Время окончания Продолжительность
4. Оценка производительности программно-аппаратных решений. Проблема выбора.
ElashkinResearch, 2003 г (http://elashkin.com/attach.asp?a no=72).
//
