CC BY
46
метров, описывающих свойства объекта, воздействующие факторы, нежелательные состояния и т.д. Таким образом, ввод исходной информации в ЭС осуществляется через те же справочники, с помощью которых заполняется БД. Это обеспечивает возможность формирования продукционных правил из тех же кодов, которые отражают соответствующие поля БД. Часть полей, описывающих причинно-следственные зависимости, является условием продукционного правила, другая часть - заключением.
Алгоритм взаимодействия осуществляется следующим образом: через рабочую БД ЭС поступает информация, описывающая исследуемую ситуацию. Далее идет сравнение фактов с существующей информацией в БД по нежелательным состояниям (НС), выявляются активные продукции, по заключению которых ЭС определяет причины НС. Чем больше введено исходной информации, тем более точный ответ можно получить.
В заключение отметим, что авторами изложена концептуальная модель системы исследования безопасности СТС и отдельные принципы ее реализации.
На основе объектно-ориентированного подхода разработана модель объекта исследования как структура данных, включающая набор объектов, каждый из которых объединяет конкретную информацию и определенное поведение. В процессе исследования
безопасности модель объекта исследования доопределяется недостающими свойствами, параметрами и значениями параметров безопасности, соответствующими рассматриваемой СТС.
Дальнейшая детализация информационных компонентов, формирование баз знаний, определение расширяемого множества методов решения задач исследования позволит развивать автоматизированную систему исследования безопасности СТС.
Список литературы
1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++/ Пер. с англ. - М.: Бином, 1998. - 560 с.
2. Волков В.В., Мешков С.А., Норов А.Т. Концепция объектно-ориентированного подхода в автоматизации исследовательского проектирования // Программные продукты и системы. - 1996.- №1.- С.19-23.
3. Предупреждение крупных аварий / Пер. с англ. - Женева: Международное бюро труда, 1992.- 256 с.
4. Берман А.Ф. Деградация механических систем. - Новосибирск: Наука, 1998. - 320 с.
5. Берман А.Ф., Николайчук О.А. Структуризация процесса исследования безопасности сложных технических систем // Проблемы безопасности при чрезвычайных ситуациях. -1999. - Вып.6. - С.3-14.
6. Берман А.Ф., Николайчук О.А. Моделирование процесса исследования безопасности сложных технических систем // Проблемы безопасности при чрезвычайных ситуациях. -1999. - Вып.8. - С.185-195.
НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ В ДИАГНОСТИКЕ ПАРАМЕТРОВ ИНФОРМАЦИОННЫХ СИСТЕМ
Б.В. Палюх, С.Л. Котов, Н.Л. Ишиев
Выбор технических решений при внедрении новых компонентов информационных систем (ИС), контроль и обеспечение качества информационных процессов предприятия, оценка соответствия выработанным стандартам и требованиям - все эти действия являются неотъемлемой частью эволюционирования ИС, однако их выполнение невозможно без получения объективной информации о характеристиках программных средств и аппаратно-программных платформ. Причем наибольшее значение имеет получение не абстрактной информации о компоненте ИС, а характеристики его функционирования при решении конкретных задач в условиях эксплуатации, максимально приближенных к реальным, в определенном операционном окружении, на базе конкретных программно-аппаратных платформ.
Объективным источником информации о характеристиках компонентов ИС в конкретных условиях эксплуатации может служить только проведение испытаний, позволяющих определить качество и степень пригодности технических решений для исполнения требуемых задач в составе всей ИС.
Существуют различные виды испытаний в соответствии с частными целями их проведения. Наиболее распространенным является проведение нагру-
зочного тестирования в условиях эксплуатации, близких к реальным, с моделированием различных режимов нагрузки, имитирующих работу пользователей системы. Другим важным видом испытаний является аттестационное тестирование, позволяющее определить соответствие программных и аппаратных средств определенным стандартам, требованиям и спецификациям. Аттестационное тестирование чаще всего проводят при сертификации продукции информационных технологий. Оно основано на формальных тестовых комплектах, входящих в состав стандартов и спецификаций и позволяющих однозначно определить соответствие заданным требованиям.
Основные виды нагрузочных испытаний.
Оценка эксплуатационных показателей функционирования действующей ИС является сложным и дорогостоящим процессом, требующим организации работы и четкого взаимодействия большого числа пользователей для создания различных уровней нагрузки на систему. При этом возможно возникновение ситуаций, создающих реальную угрозу безопасности информации, особенно в режимах с пиковой нагрузкой на ИС. Кроме того, для постоянного отслеживания тренда показателей ИС работы по их
оценке требуется проводить с определенной периодичностью. Затраты на проведение работ на действующей ИС с учетом риска потери информации могут быть несоизмеримо выше экономической ценности полученных в результате экспериментов значений показателей работы ИС.
Решение проблемы измерения показателей функционирования ИС основано на применении специальных методов тестирования, позволяющих значительно снизить стоимость испытаний и обеспечить необходимый уровень безопасности информации.
Анализ зарубежного опыта в этой области подтверждает важность проведения различных видов тестирования на протяжении жизненного цикла программного обеспечения. Наиболее часто используются следующие виды тестирования:
- индивидуальное тестирование компонентов -выявление ошибок как в коде программы, так и в логике ее работы. Под компонентами обычно понимают не отдельные программные процедуры, а функционально завершенные и структурно самостоятельные модули системы;
- тестирование параллельного доступа к компонентам - применяется для систем, где множество пользователей или программ-клиентов имеют одновременный доступ к компонентам системы. Данный вид тестирования позволяет выявить проблемы в синхронизации выполнения требуемых действий и поддержке определенного независимого контекста работы для каждого пользователя;
- интегрированное тестирование - предусматривает комплексное тестирование нескольких компонентов с целью выявления проблем, возникающих при взаимодействии всех или нескольких специально выбранных компонентов системы. Интегрированное тестирование служит основой для заключения об оптимальности используемой программно-аппаратной платформы;
- тестирование производительности/работоспособности системы в условиях максимальной загрузки (стресс-тест) - предназначено для измерения максимальной производительности системы, а также выяснения ее поведения в условиях, приближенных к реальным;
- регрессионное тестирование - применяется в случае внесения изменений в готовое приложение или изменений условий эксплуатации и может включать в себя указанные выше виды тестирования. Целью регрессионного тестирования является контроль тренда показателей в зависимости от возникших изменений и анализ влияния изменений на характеристики системы.
На базе предложенных принципов тестирования разработан метод реализации процесса тестирования, обеспечивающий решение следующих практических задач:
1) проверка соответствия эксплуатационных показателей функционирования фрагментов ИС установленным требованиям;
2) испытания фрагментов ИС на пиковых нагрузках для выявления критичных частных компо-
нентов (как программных, так и аппаратных) для принятия решения о развитии (модернизации, замене) фрагмента ИС;
3) сравнительные испытания и оценка показателей производительности различных вариантов функционально эквивалентных компонентов на единой аппаратной платформе;
4) сравнительные испытания и оценка показателей производительности фрагмента ИС на различных аппаратных платформах с целью определения оптимальной платформы, ее конфигурации и параметров настройки.
Существующие подходы к тестированию ИС предусматривают, как правило, использование стандартного набора тестов (например, ТРС-А, ТРС-В и другие). Основным достоинством метода реализаций тестирования является возможность сравнения результатов, полученных для различных объектов испытаний различными испытателями.
Однако серьезным недостатком является низкая информативность получаемых результатов, их абстрактность, отсутствие смысловой связи с заданными объектами (документами и запросами конкретных видов) и режимами обработки. Набор стандартных тестов необходимо дополнить тестами, учитывающими конкретное применение ИС, а программно-аппаратная среда должна моделировать процессы обработки информации, близкие к реальным.
Решение данной задачи должно быть построено на концепции прототипов транзакций - тестовых заданий, моделирующих определенные функциональные операции, выполняемые реальным пользователем конкретной ИС. Примеры прототипов транзакций: перевод денежной суммы с одного банковского счета на другой, оформление прихода на склад новой партии товара, оформление авиабилета и др. Прототип транзакции является тестовым вариантом некоторого логически законченного действия, происходящего в ИС. В процессе проведения испытаний прототипы транзакций исполняются в различных условиях: на разных аппаратно-программных платформах с использованием различных вариантов технических решений, с изменением интенсивности нагрузки, числа имитируемых пользователей, параметров конфигурации и т.д. Условия испытаний определяются сеансом тестирования, в который также входит и совокупность выполняемых прототипов транзакций.
Решение задач нагрузочного тестирования с помощью комплекса «Сервер-Тест». Программный комплекс (ПК) «Сервер-Тест» - это программная среда для проведения различных типов испытаний. Для обеспечения универсальности комплекса за его пределы вынесены компоненты, специфичные как для конкретного объекта тестирования, так и для используемых тестов: алгоритмы тестов; информация о составе тестов; описания настроек тестов; средства, необходимые для изменения настроек пользователем; информация о правилах и ограничениях при подготовке тестовых транзакций.
Перечисленные компоненты объединяются в тестовый адаптер, содержащий информацию и алго-
ритмы, необходимые для проведения одного или нескольких тестов для одного или нескольких объектов тестирования. Таким образом, использование тестовых адаптеров обеспечивает абстракцию ПК «Сервер-Тест» от объекта тестирования и алгоритмов испытаний.
Тестовый адаптер является подключаемым модулем к исполняющей подсистеме. Он предназначен для адаптации ПК «Сервер-Тест» к объекту тестирования и проведения различных видов испытаний путем:
- добавления новых ролей;
- реализации новых вариантов существующих ролей;
- настройки пользователем параметров работы всего тестового адаптера и каждого отдельного варианта роли;
- выбора пользователем только необходимого набора тестов;
- выбора пользователем произвольного (но корректного) набора вариантов ролей.
С помощью тестовых адаптеров производится конфигурирование тестовых транзакций при подготовке сеанса тестирования; имитация нагрузки объекта тестирования при проведении сеанса тестирования; сбор статистики и мониторинг объекта тестирования во время сеанса тестирования.
Перечень настроек, алгоритмы имитации нагрузки объекта тестирования и состав измеряемой статистики определяются конкретным тестовым адаптером.
Мониторинг объекта тестирования может осуществляться путем использования средств, информирующих о состоянии объекта тестирования во время выполнения тестовых заданий, а также о некоторых подробностях выполнения заданий объектом тестирования. При проектировании тестового адаптера определяется, какая статистика будет собираться в результате выполнения того или иного тестового задания. Состав информации о функционировании объекта тестирования определяется тестовым адаптером на основе его настроек.
Тесты и роли. Понятие теста является ключевым в концептуальной модели тестирования, принятой в ПК «Сервер-Тест».
Каждый тест может быть разбит на несколько технологических участков, выполняемых различными пользователями и называемых ролями. Взаимодействие между ролями каждого теста описывается графом. Технологический цикл теста, разбитого на отдельные роли, может предполагать существование произвольного количества ветвлений и циклов.
Роль представляет собой отдельный участок технологической цепочки теста, работа которого описывается определенным набором параметров, а также списком входных и выходных данных. Одна роль может быть задействована в выполнении нескольких тестов. Каждая роль не обязательно должна быть реализована во всех тестах.
Роль определяется:
- форматом входных данных;
- параметрами, задающими ограничения по количеству пользователей, выполняющих данную роль;
- списком ролей, которым данная роль может передавать информацию при выполнении определенного теста.
Роль может быть ведущей (иметь возможность самостоятельной работы без входной информации). Ведущая роль может принимать тестовые данные от других ролей, но может и не обладать данной возможностью. Это зависит от решения разработчика при проектировании тестового адаптера.
Варианты ролей. Концепция тестовых адаптеров предусматривает возможность их эволюции и поэтапного расширения. Для этого в рамках одного тестового адаптера может быть реализовано несколько вариантов одной и той же роли. Возможны случаи, когда различные варианты одной роли поддерживают различные наборы тестов. Допускается параллельная работа нескольких различных вариантов одной и той же роли. Различные варианты роли должны использовать один и тот же формат входных данных, они не могут различаться по признаку ведущей роли, но могут различаться перечнем настроек, особенностями реализации и списком ролей, которым данная роль может пересылать информацию при выполнении определенного теста. Следовательно, при замене в транзакции одного варианта роли другим возможно изменение графа взаимосвязей между ролями в транзакции для ряда тестов. Возможность создания нескольких вариантов ролей позволяет:
- адаптировать существующие тестовые адаптеры для различных объектов тестирования.
- расширять состав ролей (например, если в первоначальной реализации тестового адаптера роль X только принимала сообщения или принимала и пересылала роли можно создать новый вариант роли X, пересылающий сообщения ролям У и /).
Тестовые транзакции. Транзакция является основной единицей выполнения в ПК «Сервер-Тест». В прототипе сеанса тестирования может использоваться несколько транзакций. Одна и та же транзакция может быть задействована в нескольких прототипах сеансов тестирования и, следовательно, использоваться в различных сеансах тестирования.
В состав тестовой транзакции входят:
- список тестов (тесты, включенные в транзакцию, должны относиться к одному тестовому адаптеру; порядок тестов, добавленных в транзакцию, задается пользователем и соблюдается при выполнении тестов исполняющей подсистемой во время проведения сеанса тестирования);
- список вариантов ролей (в транзакцию могут быть добавлены только варианты ролей, которые поддерживают хотя бы один тест из списка тестов транзакции).
Каждая транзакция обладает собственным набором конфигураций, создаваемых пользователем. Конфигурации транзакции относятся к одной или нескольким конфигурациям плана тестирования. Каждая конфигурация включает в себя настройки тесто-
вого адаптера всех вариантов ролей, входящих в транзакцию.
Отношения тестов и ролей в транзакции. При
реализации тестового адаптера тест является первичным понятием по отношению к роли, то есть роль реализует некоторые условия или этап выполнения теста. В рамках транзакции отношения тестов и ролей аналогичны.
В процессе конфигурирования основной настройкой транзакции является перечень тестов. Составление перечня тестов в транзакции - начальный этап ее формирования. В одну транзакцию могут быть добавлены только тесты, принадлежащие одному тестовому адаптеру. После завершения этого этапа производится добавление в транзакцию вариантов ролей, которые поддерживают хотя бы один из тестов, включенных в транзакцию ранее. В одну транзакцию могут быть добавлены несколько вариантов одной и той же роли тестового адаптера.
Выполнение тестовых транзакций производится в среде виртуальных машин вариантов ролей, создаваемых исполняющей подсистемой. Поскольку вариант роли может поддерживать не все тесты, входящие в состав транзакции, виртуальная машина варианта роли выполняет только те тесты, которые включены в транзакцию и поддерживаются вариантом роли. При выполнении тестов соблюдается их порядок в транзакции, заданный пользователем.
Если в транзакцию добавлены варианты роли, которые не поддерживают отдельные тесты, входящие в состав транзакции, то в процессе выполнения сеанса тестирования ни один из таких тестов выполняться не может. Транзакция, сконфигурированная подобным образом, считается подготовленной некорректно, и средства ПК «Сервер-Тест» не позволят запустить сеанс тестирования с использованием данной транзакции, пока ошибка не будет исправлена, то есть все тесты в транзакции будут задействованы,
а среди вариантов ролей, поддерживающих данные тесты, будет хотя бы одна ведущая.
В качестве основы исполнения тестов в ПК «Сервер-Тест» используется модель конвейерной обработки тестовых заданий, в которой тесты выполняются поэтапно. Выполнение различных этапов теста (ролей) происходит асинхронно и параллельно на различных станциях в сети. Последовательность выполнения ролей может быть не линейной, а представляющей граф: очередность выполнения ролей зависит от различных настроек и результатов выполнения работы определенной ролью.
Для каждого варианта роли заранее определен список смежных ролей, которым данный вариант роли способен посылать тестовые данные. При отправлении тестовых данных какой-либо роли необходимо соблюдать формат входных данных этой роли.
Реализация асинхронной конвейерной обработки тестовых заданий ПК «Сервер-Тест» предоставляет пользователю гибкие возможности по настройке и диагностике. Варианты ролей, входящие в состав транзакций, могут назначаться на различные группы станций, входящие в полигон испытаний. Средства ПК «Сервер-Тест» выполняют сбор статистической информации о нагрузке экземпляров каждого варианта роли в транзакции, на основе которой вычисляется среднее время ожидания тестовых данных в очередях экземпляров вариантов ролей. Анализ полученной информации позволяет сделать вывод о правильности настроек сеанса тестирования и внести необходимые исправления. Если среднее время ожидания тестовых данных в очередях экземпляров какого-либо варианта роли намного больше, чем у остальных, то необходимо внести изменения в настройки прототипа сеанса тестирования, определив вариант роли на дополнительные группы станций либо в настройки сеанса тестирования, увеличив число пользователей для данного варианта роли.
СТРУКТУРА ПРИЛОЖЕНИЯ ДЛЯ РАБОТЫ С БАЗАМИ ДАННЫХ
Ю.С. Литвинов, В.А. Масюков
Современные инструментальные средства разработки приложений для баз данных (БД) предоставляют широкие возможности для создания программных проектов любой сложности. Однако при этом возникает проблемы, связанные с выбором структуры приложений и рациональных способов их реализации. Важность решения этих проблем возрастает по мере роста объема и сложности проектов. Ошибки выбора структуры, а также методики их реализации приводят к резкому увеличению программного кода, в том числе многократного его дублирования, увеличению сроков разработки, ухудшают возможности сопровождения и модификации приложений, когда изменение, внесенное в один из объектов, может непредсказуемым образом повлиять на работу других объектов.
Для решения этих проблем была разработана, реализована в программных продуктах и исследована пятиуровневая модель организации данных (см. рисунок), предназначенная для построения клиент-серверных систем для работы с реляционными БД, ориентированных на конечного пользователя. Статья посвящена одному из возможных способов реализации данной модели.
Результаты исследований показывают, что любое отклонение от данной схемы отрицательно сказывается на качестве и характеристиках реализуемых приложений. Наиболее сложной оказалась задача выбора способа организации программного обеспечения промежуточного слоя и методики связывания всех уровней в единое целое, без чего схема не может нормально функционировать. Для решения дан-
