CC BY
46
Шибанов С.В., Вишняков П.В., Лысенко Э.В.
МЕТОДИКА ТЕСТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ УПРАВЛЕНИЯ АКТИВНЫМИ БАЗАМИ ДАННЫХ
Понятие и свойства активных баз данных. База данных называется активной (АБД), если система управления базой данных (СУБД) по отношению к ней выполняет не только явно указанные пользователем действия, но и дополнительные действия в соответствии с правилами, заложенными в саму базу данных (БД) . Кроме того, система управления активной базой данных (СУАБД)должна отслеживать возникновение событий, описанных в АБД, и осуществлять их обработку посредством запуска процедур, затрагивающих как саму АБД, так и ее окружение.
В данном случае АБД являются не просто пассивным набором данных, но и хранилищем знаний по обработке и управлению данными [4-5] . Таким образом, СУАБД может стать не просто местом хранения и обработки информации, но также центром принятия решений и выработки управляющих воздействий.
Чтобы обеспечивать реагирующее поведение СУАБД должна поддерживать соответствующие модели описания и выполнения правил. Классическая модель описания активных правил основывается на правилах, которые содержат три компонента: событие(event), условие (condition) и действие(action) и называются
ECA-правилами (Event-Condition-Action) [2, 7]. Компонент Событие (event) описывает какое-либо собы-
тие, которое может произойти в СУБД или вне нее. Компонент Условие (condition) проверяет контекст, при котором событие произошло. Действие (action) описывает процедуру, которая должна быть выполнена правилом, если соответствующее событие произошло и условие оказалось истинным. Действия могут менять структуру базы данных или набора правил, выполнять некоторый вызов поведения внутри базы данных или внешний вызов, информировать пользователя или системного администратора о какой-либо ситуации, прерывать транзакцию или принимать альтернативную линию поведения.
Классическая модель ECA-правил не учитывает, что в реальных приложениях поведение объекта часто зависит от его состояния (state). Состояние - это абстракция значений и связей объекта, которая определяет отклик объекта на получаемые события. В конкретном состоянии обрабатываются только те события, для которых явным образом описано поведение, любые другие события игнорируются. Это свойство состояний особенно важно - оно позволяет наделить объекты системы свойством изменчивости - способности изменять свое поведение в зависимости от возникающих событий.
Модель, учитывающую состояние объекта называется расширенной моделью ECA-правил, моделью SECA-правилили SECA-моделью (State-Event-Condition-Action). Добавление в классическую модель ECA-правил понятия состояния сокращает количество необходимых правил и упрощает процесс разработки активной системы [7].
Выбор модели активных правил зависит от особенностей предметной области и логики выполнения активных правил. Применительно к техническим системам контроля и управления, по всей видимости, предпочтительней именно расширенная модель SECA-правил. Тем не менее, была разработана интегрированная модель активной базы данных [7], объединяющая классическую и расширенную модель активных правил (рисунок 1) .
Особенности архитектуры программных средств управления АБД.Реализация АБД возможна различными способами; в разрабатываемом проекте АБД представляет собой модульную надстройку над традиционными, пассивными СУБД (такими как MicrosoftSQLServer, Oracle, Cache и PostgreSQL).
Предлагаемая архитектура АБД основана на модульном принципе и состоит из двух основных компонентов :
универсальной надстройки над целевой СУБД- набора компонентов, обеспечивающих функциональность АБД, но при этом являющихся максимально общими по отношению к поддерживаемым моделям данных (реляционной, постреляционной, объектной) и конкретным реализациям СУБД (Oracle, SQLServer, PostgreSQL, Cache и др.);
уникальной надстройки над целевой СУБД- набора компонентов, функционально аналогичного предыдущему, но при этом максимально использующему преимущества каждой конкретной СУБД.
Оба описанных варианта построены на основе плагинов, позволяющих быстро подключать ту или иную реализацию каждой конкретной функции СУАБД. Выбранноеархитектурное решение, с одной стороны, позволяет добиться значительной гибкости и совместимости с наибольшим числом целевых СУБД, а с другой стороны - требует разработки специальной методики тестирования.
Описание предметной области тестового примера.У некоторой организации существуют склады, расположенные в различных городах. На этих складах хранятся определенное количество товаров с различными артикулами. Эти товары могут заказывать клиенты, которые также проживают по определенным адресам. Это важно, т. к. организация не может доставлять товары в другие города - т. е. клиент не может заказать товар, отсутствующий на складе в его городе. Каждый заказ именуется. С заказом связан список товаров, включенных в него. Каждому пункту этого списка соответствует артикул заказываемого товара на складе, количество и статус этого пункта. Заказ в целом также характеризуется статусом, равным наименьшему статусу среди всех его пунктов. Каждый клиент может оформлять несколько заказов. Кроме того, существует возможность оформить один заказ на несколько человек. Таким образом, предметную область можно представить следующей схемой (рис. 1).
В таблице 2 описана семантика связей между сущностями, представленными на рисунке 1.
Определим статусы заказов и их пунктов, как целочисленные поля с возможными значениями: 1 - заказ принят; 2 - заказ оплачен; 3 - заказ отправлен; 4 - заказ обработан;5 - заказ отменен. Последние два статуса - «обработан» и «отменен» назовем терминальными - после перехода эти статусы заказ или пункт заказа уже не могут двигаться дальше.
Для наполнения тестовой базы данных необходимой информацией определим совокупность методов для каждой сущности: добавление, модификация и удаление экземпляра сущности. В реляционных и постреляционных базах данных методы могут быть реализованы в виде запросов или хранимых процедур, в объектных-базах данных - в виде методов классов. Соответствующие методы для каждой сущности представлены в таблице 3.
В тестовой предметной области определим следующие бизнес-правила, которые должны быть отображены в ограничения базы данных средствами целевой СУБД:
статусы могут изменяться в сторону увеличения - только подряд (т.е. заказ сначала поступает, затем принимается, после - оплачивается и обрабатывается);
Таблица 1 - Спецификации атрибутов сущностей тестовой предметной области
Атрибут Описание Тип данных Диапазон значений Возможность null-значения
Сущность Клиент
Наимено-вание Наименование организации (для клиентов -юридических лиц) Строка n/a Да
Фамилия Фамилия (для клиентов - физических лиц) Строка n/a Да
Имя Имя (для клиентов - физических лиц) Строка n/a Да
Отчество Отчество (для клиентов - физических лиц) Строка n/a Да
Тип Физическое или юридическое лицо Целое 1/0 Нет
Сущность Заказ
Наимено-вание Наименование заказа в целом Строка n/a Да
Статус Статус заказа Целое 1-5 Нет
Дата Дата оформления Дата n/a Да
Сущность Пункт заказа
Количест- во Количество товара Число с плавающей запятой 0 - ... Нет
Статус Статус пункта заказа Целое 1-5 Нет
Сущность Артикул
Наимено-вание Описание товара Строка n/a Нет
Остаток Остаток на складе Число с плавающей запятой 0 - ... Нет
Сущность Адрес
Тип Тип компонента адреса Целое 0-9 Нет
Наименование Собственно компонент адреса Строка n/a Нет
Сущность Склад
Наименование | Наименование склада | Строка | n/a | Нет
Таблица 2 - Семантика связей между сущностями тестовой предметной области
Сущность 1 Описание Сущность 2 Кратность
Заказ Включает Пункт заказа 1: М
Заказ Оформлен Клиент М:М
Клиент Находится по Адрес 1: М
Пункт заказа Выписан на Артикул М : 1
Артикул Хранится на Склад 1: М
Склад Располо-жен по Адрес 1:1
Адрес Включает Адрес 1: М
Таблица 3 - Методы манипулирования экземплярами сущностей
Метод | Параметры
Сущность Клиент
Создать клиента Наименование; Фамилия; Имя; Отчество; Тип; Адрес
Изменить клиента Идентификатор; Наименование; Фамилия; Имя; Отчество; Тип; Адрес
Удалить клиента Идентификатор
Сущность Заказ
Добавить заказ | Наименование; Дата; Клиент
Сущность Пункт заказа
Добавить пункт заказа Идентификатор заказа; Артикул ;Количество
Сущность Артикул
Добавить артикул Наименование; Остаток; Склад
Изменить артикул Идентификатор; Наименование; Склад
Увеличить остаток Идентификатор; Добавляемое количество
Сущность Адрес
Добавить новый элемент Родитель; Тип; Наименование
Изменить элемент Идентификатор; Родитель; Тип;Наименование
Сущность Склад
Добавить склад Наименование; Адрес
Изменить склад Идентификатор; Наименование; Адрес
Удалить склад Идентификатор
Заказ (и пункт заказа) может быть отменен в любом состоянии, за исключением «Отправлен» и «Обработан»; Статус заказа в целом соответствует наименьшему из статусов его пунктов. Таким образом, если в заказе 3 пункта со статусами «Поступил», «Оплачен» и «Обработан», то статус заказа в целом - «Поступил»;
Пункт заказа не может стать «Отправлен», если количество товара на складе меньше, чем требуемое в пункте заказа;
Переход всех пунктов заказа к одному статусу вызывает переход к этому статусу всего заказа;
Новый заказ и новые пункты заказа могут иметь только статус «Поступил»;
Заказ может иметь 0 и более пунктов заказа;
Пункт должен относиться к какому-либо одному заказу;
Заказ не может быть создан «задним числом»;
Все товары, включенные в заказ, должны находиться на складах в том же городе, что и клиент;
Количество товара в заказе не может превышать количество товара на складе;
Количество товара может уменьшаться только из-за заказов;
Количество товара, включенного в пункт заказа, уменьшается на складе после того, как заказ, в который включен данный пункт, получает статус «Отправлен»;
Товар возвращается на склад, если заказ перестает быть «Оплачен»;
Клиент не может быть удален, пока у него есть заказы со статусом, отличным от терминальных;
Адрес склада не может быть изменен, пока существуют заказы на его товары в нетерминальных состояниях ;
Склад не может быть удален, пока его заказы на его товары имеют статус, отличный от терминальных;
Для клиентов - физических лиц поле «Наименование» должно содержать фамилию и инициалы клиента, например «Иванов И. И.»;
Каждый склад имеет уникальный адрес (т.е., например, по адресу «г. Иваново, ул. Ивановская 1» может быть расположен только один склад);
Каждый клиент имеет неуникальный адрес (т.е., например, по адресу «г. Иваново, ул. Ивановская 1» могут быть расположены один и более клиентов).
После определения сущностей, атрибутов сущностей, связей между сущностями, бизнес-правил предметной области определим набор активных правил. Сначала определим набор событий, которые могут порождаться и отслеживаться в тестовой базе данных.
Набор событий представлен в таблице 4. Выделенные события определяются основными бизнеспроцессами предметной области, связанными с формированием и обслуживанием заказов клиентов. При желании набор событий может быть расширен.
Информационными объектами, для которых отслеживаются те или иные события, являются Заказ и Пункт Заказа. Состояния этих информационных объектов представлены в таблице 5.
Таблица 4 - События в предметной области
№ | Описание | Тип | Параметры
Сущность Артикул
1 Новый товар добавлен Внутреннее Идентификатор события; Идентификатор добавленного товара
2 Количество товара на складе изменено Внутреннее Идентификатор события; Идентификатор товара; Старое количество; Новое количество
3 Товар закончился Внешнее Идентификатор события; Идентификатор товара
Сущность Заказ
Новый заказ создан Внутреннее Идентификатор события; Идентификатор заказа
Заказ отменен Внешнее Идентификатор события; Идентификатор заказа
Заказ оплачен Внешнее Идентификатор события; Идентификатор заказа
Заказ отправлен Внешнее Идентификатор события; Идентификатор заказа
Сущность Пункт заказа
Новый пункт заказа создан Внутреннее Идентификатор события; Идентификатор пункта
Состояние пункта изменено Внутреннее Идентификатор события; Идентификатор пункта; Старое состояние; Новое состояние
Сущность Клиент
Добавление нового клиента Внутреннее Идентификатор события; Идентификатор клиента
Изменение клиента Внутреннее Идентификатор события; Идентификатор клиента; Предыдущие значения измененных полей
Удаление клиента Внутреннее Идентификатор события; Идентификатор клиента Предыдущие значения полей
Сущность Склад
Добавление склада Внутреннее Идентификатор события; Идентификатор склада
Изменение склада Внутреннее Идентификатор события; Идентификатор склада; Предыдущие значения измененных полей
Удаление склада Внутреннее Идентификатор события; Идентификатор склада; Предыдущие значения полей
Таблица 5 - Состояния информационных объектов Заказ и Пункт Заказа предметной области
№ Описание Объект Характеризуется
1 Статус заказа Заказ Статус
2 Статус пункта заказа Пункт заказа Статус
Действия, реализующие реакции АБД на возникающие события, представлены в таблице 6.
Таблица 6 - Действия, определяющие реакции АБД на события в п эедметной области
№ Описание Связанное событие Дополнительные параметры контекста
1 Проверить пункт заказа Новый пункт заказа создан Адрес клиента Адрес склада
2 Отменить заказ Заказ отменен Идентификатор заказа
3 Уменьшить количество товара на складе Новый пункт заказа создан Идентификатор заказа, Количество товара в заказе
4 Вернуть товар на склад Состояние пункта изменено Параметры события
5 Изменить статус заказа Состояние пункта изменено Параметры события
6 Уведомить внешний сервис Все внешние Параметры события
7 Добавить запись в журнал Все Идентификатор события
Для повышения уровня абстракции, а также сокрытия непосредственной работы с базой данных от пользователя создается совокупность процедур модификации данных, не связанная с активной логикой (таблица 7) .
Методика тестирования программных средств управления активными базами данных. Поскольку АБД является базой данных, интегрирующей в себе не только данные, но и правила их обработки, а система управления активными базами данных отвечает за ее активное поведение, то тестирование программных средств предполагает оценку работоспособности и эффективности всех механизмов ведения и управления активными правилами.
Другой особенностью предлагаемой методики тестирования является поддержка принципа «разработка через тестирование», который заключается в том, что тестирование начинается как можно раньше, включает все стадии разработки программного обеспечения, обеспечивает не только проверку корректности, но и эффективности функционирования программных средств.
В первую очередь, необходимо определить категории пользователей системы, а также задачи, решаемые ими. Выделим две основных категории: Разработчик и Пользователь. Разработчик создает «логику» системы, определяет ЕСА и SECA-правила. Пользователь взаимодействует с системой косвенно,
Таблица 7 - Процедуры модификации данных
№ Назначение Входные параметры Описание
1 Работа со складом Идентификатор; Наименование; Дом; Улица; Город Если не указан идентификатор склада - процедура создает новый склад с учетом бизнес-логики, при указании идентификатора позволяет изменить данные существующего склада
2 Работа с артикулами товаров Склад; Артикул; Количество Процедура может использоваться для добавления нового товара на склад, либо для пополнения существующего - в этом случае указанный артикул должен соответствовать одному из артикулов на данном складе
3 Работа с клиентом Идентификатор клиента; Тип клиента; Фамилия , имя, от -чество; Наименование; Город; Улица; Процедура позволяет добавить нового клиента (в этом случае значение параметра «Идентификатор клиента» не инициализируется), либо обновить информацию о существующем клиенте, согласно описанным правилам. Кроме того, осуществляется привязка клиента к указанному адресу и его создание (если такой адрес в базе данных отсутствует )
Дом
4 Добавление нового заказа Наименование клиента; Наименование заказа Создает заказ на текущую дату и привязывает его к клиенту
5 Закрепление заказа за клиентом Наименование заказа; Наименование клиента Если заказ с приведенным описанием существует - выполняет привязку клиента к данному заказу
6 Оплата пункта заказа Идентификатор пункта заказа Переводит пункт заказа в состояние «Оплачен»
7 Отправка пункта заказа Идентификатор пункта заказа Переводит пункт заказа в состояние «Отправлен»
8 Отмена пункта заказа Идентификатор пункта заказа Переводит пункт заказа в состояние «Обработан»
9 Завершение работы с пунктом заказа Идентификатор пункта заказа Переводит пункт заказа в состояние «Отменен»
выполняя свои информационные задачи и изменяя данные в базе с помощью запросов. Таким образом, набор тестов, имитирующих действия этих категорий пользователей, будет различаться.
Тесты для Разработчика должны обеспечить проверку работоспособности программных средств ведения активных правил:
добавление, модификацию, удаление, включение и отключение отслеживаемых событий;
добавление, модификацию и удаление условий выполнения правила;
добавление, модификацию и удаление действий, выполняемых в случае возникновения события и истинности условий;
добавление, модификацию и удаление состояний информационных объектов;
добавление, модификацию, удаление и активация, а также установка контекста выполнения активных правил.
На первый взгляд, тесты для Разработчика реализуют проверку обычных операций добавления, удаления и модификации, пусть достаточно, специфичных данных. С одной стороны, это именно так. Но необходимо учитывать, что активные правила и их составляющие не просто данные, а метаданные, определяющие процесс функционирования АБД. Поэтому простая проверка корректности операций добавления, удаления и модификации будет достаточной только на начальном этапе разработки программных средств ведения активных правил. Но этого недостаточно для полномасштабного тестирования в контексте функционирования АБД.
Тесты для Пользователя представляют собой запросы (процедуры) модификации данных о тестовой предметной области, не связанные с активными правилами обработки данных. В процессе выполнения запросов (процедур) модификации данных осуществляется сбор тестовой информации о поведении АБД. На начальном этапе тестирования функционирования АБД осуществляется проверка возникновения и обработки событий, контроль условий и выполнение активных правил как реакции на возникающие события.
При этом база данных должна быть наполнена начальными сведениями. Должны присутствовать 15 адресов, созданных таким образом, чтобы они находились в 5 разных городах. Должны быть доступны 10 складов, по 2 в каждом городе. Товар должен соответствовать 50 уникальным артикулам по 2 экземпляра каждый, распределенные по 10 артикулов между всеми складами. В системе должно быть определено 15 клиентов - по 1 клиенту на каждый адрес. Для каждого клиента должны быть определены по 4 заказа. Должно быть определено по 4 пункта для каждого заказа, подобранные таким образом, чтобы промоделировать вариант нахождения клиента и склада с требуемым артикулом в разных городах.
На этапе нагрузочного тестирования имитируется реальное поведение программных средств управления АБД при максимальном (или даже превышающем максимальное) количестве транзакций к базе данных от потенциальных пользователей. В этом случае оценивается эффективность функционирования СУАБД, находятся «узкие» места, намечаются способы их устранения.
Функциональное тестирование может быть осуществлено, как один из этапов тестирования серверных программных средств, а именно - создание, изменение, удаление, активация и деактивация следующих структур АБД: информационных объектов и их состояний, событий, действий, а также активных правил.
Выделим следующие этапы тестирования:
Формирование заказа;
Движение заказа;
Работа с клиентом;
Работа со складом.
Рассмотрим содержание выделенных этапов подробнее:
1. Формирование заказа
1.1 Пользователь формирует заказ
1.2 Пользователь добавляет к заказу пункты. При этом при добавлении проверяется, в каких городах находятся пользователь и склад, к которому относится данный пункт. В том случае, если пользователь и склад находятся в разных городах - пункт заказа отменяется.
1.3 Пользователь видит заказ в статусе «Принят» и все его пункты в статусе «Принят»
2. Движение заказа
2.1 Пользователь создал заказ, содержащий несколько пунктов. Заказ и его пункты находятся в начальном состоянии «Принят».
2.2 Начинается обработка пунктов заказа - их статус начинает изменяться, заказ становится «Оплачен», «Отправлен» и, в завершении, «Обработан». Для части заказов (не более 20% от общего числа),
находящихся в различных статусах, выполняется переход в состояние «Отменен»
2.3 Все заказы и их пункты переходят в один из двух возможных статусов - «Обработан» или «Отменен» .
3. Работа с клиентом
3.1. Создается новый клиент А - физическое лицо
3.2. Изменяются параметры клиента А.
3.3. Создается новый клиент Б - юридическое лицо
3.4. Изменяются параметры клиента Б.
3.5 От лица клиента А размещается заказ из нескольких пунктов. Состояние пунктов изменяется таким образом, чтобы один из пунктов после изменения не находился в терминальном состоянии
3.6 Изменяем информацию клиента А - операция должна отмениться, т.к. у клиента присутствуют необработанные заказы
3.7 Удаляем клиента А из базы - операция должна отмениться, т.к. у клиента присутствуют необработанные заказы
3.8 Повторяем пункты 3.5 - 3.7 для клиента Б.
3.9 переводим все заказы клиента А в терминальные состояния
3.10 Изменяем информацию клиента А - операция завершается успешно
3.11 Удаляем клиента А из базы - операция завершается успешно
3.12 Повторяем операции 3.9 - 3.11 для клиента Б
4. Работа со складом.
4.1 Создается новый склад
4.2 Создаются заказы, пункты которых относятся к артикулам на созданном складе
4.3 Состояние заказов изменяется таким образом, чтобы один из пунктов после изменения не находился в терминальном состоянии
4.4 Изменяем название склада
4.5 Изменяем адрес склада - операция отменяется, т.к. для данного склада существуют заказы, находящиеся в нетерминальном состоянии
4.6 Удаляем склад - операция отменяется, т.к. для данного склада существуют заказы, находящиеся в нетерминальном состоянии
4.7 Переводим все пункты с данного склада в терминальное состояние
4.8 Изменяем адрес склада - операция завершается успешно
4.9 Удаляем склад - операция завершается успешно
Таким образом, тестирование АБД в рамках определенной предметной области сводится к выполнении. Указанных этапов.
Заключение.Рассматриваемая методика тестирования программных средств управления активными базами данных позволит получить оценки производительности для сравнения с существующими системами, а также сопоставить производительность различных вариантов серверных программных средств управления АБД.
ЛИТЕРАТУРА
1. Долгоруков А. Ю., Порай Д.С. Методика и инструментарий проведения нагрузочного тестирования
// Труды ИСА РАН 2006, Т. 23.
2. Шибанов, С.В. Реализация технологий активных баз данных в среде Microsoft SQL Server 2008 / С.В. Шибанов, Э.В. Лысенко, П.В. Вишняков // Технологии Microsoft в теории и практике программирования. Материалы конференции / Под ред. проф. В.П. Гергеля. - Нижний Новгород: Изд-во Нижегородского госуниверситета, 2010. - с. 55-57.
3. Лафлин Джейми Модульное тестирование: применение разработки через тестирование к проектам
баз данных / JamieLaflen / MSDNMagazine, VisualStudio 2008 Launchlssue, 2008 (http://msdn.microsoft.com/ru-ru/magazine/cc184 84 0.aspx)
