Автоматизация и управление технологическими процессами и производствами 97

Список литературы:
1. Арутюнян А.А. Основы энергосбережения. – М.: ЗАО «Энергосер-
вис», 2007.
2. Тубинис В.В. Автоматизация учета электрической энергии в России
и за рубежом // Я электрик! – 2007. – № 6.
3. Тубинис В.В. Новые автоматизированные системы учета электро-
энергии для бытовых потребителей со сбором информации от электросчет-
чиков по силовой сети // Вестник Главгосэнергонадзора России. – 1998. – № 1.
4. Тубинис В.В. Создание автоматизированной системы учета и управ-
ления потреблением электроэнергии в Италии // Электро. – 2004. – № 4.

ПРИМЕР РАЗРАБОТКИ ТЕСТОВОГО ПЛАНА

НА БАЗЕ ШАБЛОНА RUP

© Галимова Е.Ю.
Северо-Западный институт печати Санкт-Петербургского
государственного университета технологии и дизайна, г. Санкт-Петербург

В данной статье рассматривается процедура составления тест-плана

(плана тестирования программного средства) по шаблону RUP, создан-
ному компанией IBM Rational Software в соответствии с ISO 12207, ISO
9000 и моделью CMM. Шаблон конкретизируется для случая малой
фирмы, не использующей автоматизированные средства тестирования.

Подход к написанию тест-плана

Тестовый план (Test Plan) – это документ, описывающий весь объем ра-
бот по тестированию программного продукта, начиная с описания объекта,
стратегии, расписания, критериев начала и окончания тестирования, до не-
обходимого в процессе работы оборудования, специальных знаний, а также
оценки рисков с вариантами их разрешения [1]. Перед составлением тесто-
вого плана необходимо разобраться, каковы результаты, ожидаемые от тес-
тирования проекта. Для этого нужно ответить на следующие вопросы:
– Будет ли тестирование проводиться на протяжении всего цикла
разработки?
– Определена ли и документирована общая стратегия тестирования?
– Является ли процесс тестирования четко определенным, задоку-
ментированным, понятным и принятым командами разработчиков
и менеджеров?
– Имеются ли четко определенные требования к проекту?


Ассистент.
98 ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

– Являются ли методы, техники, стандарты тестирования и управ-

ление тестированием четко определенным в соответствии со стра-
тегией тестирования?
– Существует ли контроль качества и управление конфигурацией
программного обеспечения (ПО) и подходят ли они для поддер-
жания тестовой стратегии?
– Достаточно ли обучены, квалифицированы и мотивированы пред-
полагаемые тестировщики проекта?
– Достаточны ли ресурсы, зарезервированные для тестирования?
– Выделены ли ресурсы в начале жизненного цикла проект, чтобы
подготовится к тестированию [2]?
Формат офрмления тест-плана
Каждая методология или стандарт предлагают свои форматы оформ-
ления планов тестирования. Остановимся на шаблоне тест-плана от Ratio-
nal Unified Process (RUP). RUP – это методология разработки ПО, создан-
ная компанией IBM Rational Software. Это одна из наиболее совершенных
технологий, претендующих на роль мирового корпоративного стандарта.
Она в значительной степени соответствует стандартам и нормативным до-
кументам, связанным с процессами жизненного цикла ПО и оценкой тех-
нологической зрелости организаций-разработчиков (ISO 12207, ISO 9000,
CMM) [3]. ISO 9000 – это серия международных стандартов, описываю-
щих тербования к системе менеджмента качества организаций и предпри-
ятий. ISO 12207 – это стандарт, описывающий процессы жизненного цикла
ПО. CMM – это модель зрелости процессов разработки, созданная Softwa-
re Engineering Institute (SEI). CMM, по сравнению с ISO, обеспечивает бо-
лее детализированный подход к процессу разработки ПО.
Вернемся к методологии RUP, ее основными принципами являются:
– Итерационный подход к созданию ПО, т.е. разработка системы идет
в виде ряда краткосрочных проектов меньшего объема и фиксиро-
ванной длительности (итераций) [3].
– Управление проектом идет на основе функциональных требова-
ний к системе.
– Построение системы на базе архитектуры ПО, последняя создает-
ся максимально надежной и гибко, облегчающей параллельную
разработку.
В рамках методологии RUP разработан шаблон тест-планов (оригинал
взят из работы [4]). Рассмотрим его основные части:
1. Введение.
1.1. Цель – в этом разделе описывается существующая проектная ин-
формация и компоненты ПО, которые должны быть проверены.
Автоматизация и управление технологическими процессами и производствами 99

1.2. Исходные условия – здесь дается вводное описание компонентов,

приложений и систем, которые будут тестироваться, и их задач. Описываются
основные функции, свойства, архитектура и краткая история проекта.
1.3. Область действия – описание стадий тестирования (например, Юнит,
Интеграционное или Системное) и типов тестирования, таких как Функ-
циональное или Нагрузочное. Создание списков функций, которые будут
тестироваться и которые тестироваться не будут. Выработка предложений к
дизайну, разработке и выполнению тестирования. Формирование списка
рисков и ограничений, которые могут повлиять на дизайн, разработку и вы-
полнение тестов.
1.4. Идентификация проекта – здесь дается список документации и прав
доступа, которые будут использоваться для разработки тест-плана.
2. Требования к тесту – это список функциональных и нефункциональ-
ных требований, которые будут протестированы.
3. Стратегия тестирования (общие правила и принципы, способствую-
щие достижению цели, то есть выполнению эффективного и качественного
тестирования) [5].
3.1. Типы тестирования.
3.1.1. Тестирование данных и целостности базы данных (БД) – тести-
руются данные и БД независимо от пользовательского интерфейса. Произ-
водится ввод данных и работа с ними непосредственно в БД.
3.1.2. Функциональное тестирование – проводится в целях проверки
способности программного продукта в определенных условиях решать за-
дачи, нужные пользователям. Основано на спецификации, то есть на функ-
циях, которые должна выполнить система.
3.1.3. Тестирование бизнес-цикла – должно эмулировать действия, вы-
полняемые в проекте в течение определенного временного интервала, на-
пример, одного года.
3.1.4. Тестирование пользовательского интерфейса – это обнаружение
ошибок в интерфейсе и поиск ошибок в функциях через интерфейс.
3.1.5. Анализ профиля производительности – осуществляется для опре-
деления функций условий проведения тестирования производительности,
таких как рабочая нагрузка и конфигурация аппаратных средств.
3.1.6. Нагрузочное тестирование – тестирование отклика системы на
изменение нагрузки в пределах допустимых значений.
3.1.7. Стрессовое тестирование – позволяет проверить, насколько сис-
тема работоспособна в условиях нагрузки, выходящей за пределы допусти-
мых значений.
3.1.8. Объемное тестирование – тестирование на больших объемах дан-
ных до достижения условий, при которых система перестает работать.
3.1.9. Тестирование контроля безопасности и доступа – это стратегия
тестирования, используемая для проверки безопасности системы, а также
100 ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

для анализа рисков, связанных с обеспечением целостного подхода к защите

приложения, атак хакеров, вирусов, несанкционированного доступа к кон-
фиденциальным данным [6].
3.1.10. Тестирование на отказ и восстановление – проверка способности
системы к восстановлению после возможных сбоев.
3.1.11. Конфигурационное тестирование – проверка работоспособности
системы при ее различных конфигурациях.
3.1.12. Инсталляционное тестирование – направленно на проверку ус-
пешной инсталляции и настройки, а также обновления или удаления про-
граммного обеспечения [6].
3.2. Инструменты – список программных инструментов, которые будут
использоваться при тестировании системы (инструменты управления тес-
тированием, система отслеживания ошибок, инструменты автоматизации
функционального тестирования, инструменты автоматизации тестирования
производительности, утилиты покрытия кода, проектный менеджмент, ин-
струменты системы управления БД).
4. Ресурсы (рекомендуемые для проекта).
4.1. Роли – это роли сотрудников, которые будут участвовать в процессе
тестирования (например, тест-менеджер, тест-разработчик, тестировщик,
администратор БД, конструктор, реализующий иерархию тестовых классов).
4.2. Система – это системные ресурсы, необходимые в процессе тести-
рования (например, сервер БД, сеть, персональные компьютеры).
5. Контрольные точки – процесс тестирования делится на несколько
этапов. В этом случае может производиться оценка степени выполнения каж-
дого этапа. Контрольные точки разработки проекта: план тестирования,
разработка тестов, инструменты тестирования, выполнение тестирования,
оценка тестирования. Для каждой контрольной точки указывается объем
работ, дата начала, дата окончания.
6. Конечный результат (список документов, инструментов и отчетов, ко-
торые должны быть созданы, с указанием кем и когда).
6.1. Модель тестирования – это представление того, что и как будет тес-
тироваться. Модель включает набор контрольных задач, методик испыта-
ния, сценариев испытаний и ожидаемых результатов (test cases), тестовых
скриптов и описаний взаимодействий тестов [7].
6.2. Журнал тестирования – описание инструментов и методов, исполь-
зуемых для фиксации тестовых событий.
6.3. Отчеты об ошибках – описание инструментов и методов, исполь-
зуемых для отслеживания, описания и систематизации ошибок.
Модификация шаблона тест-плана для конкретной задачи
Модифицируем данный шаблон тест-плана для нужд коммерческой
фирмы со штатом 50 сотрудников, отделом тестирования численностью 3
Автоматизация и управление технологическими процессами и производствами 101

человека (начальник отдела и два тестировщика), не использующим автома-

тизированные средства тестирования. Предположим, что тестируется при-
ложение «Дисконтные карты постоянных покупателей», работающее с БД.
Специалист, готовящий план тестирования, должен излагать идеи, вы-
воды и решения таким образом, чтобы тестировщики, прочитавшие план,
четко понимали, что от них требуется. Хорошо, когда план тестирования –
это итог обсуждений с ключевыми участниками проекта. В данном при-
мере тест-план разрабатывается начальником отдела тестирования. По-
вторим и конкретизируем описанный выше формат тест-плана:
1. Введение.
1.1. Цель – проведение детального тестирования приложения.
1.2. Исходные условия – приложение тестируется целиком. Задачи: де-
лать запросы к БД для получения информации о дисконтных картах и о вла-
дельце дисконтной карты, вносить изменения в информацию по уже суще-
ствующим дисконтным картам, добавлять новые дисконтные карты в БД.
1.3. Область действия: системное тестирование методом «черного ящика».
2. Список функциональных требований будет сформирован на осно-
вании предоставленной спецификации.
3. Стратегия тестирования.
3.1. Типы тестирования.
3.1.1. Тестирование данных и целостности БД – проводит отдел разра-
ботки, т.к. отдел тестирования работает по методу «черного ящика».
3.1.2. Функциональное тестирование – проводит отдел тестирования.
3.1.3. Тестирование бизнес-цикла – не проводим, т.к. оно целесообраз-
но для более масштабных проектов.
3.1.4. Тестирование пользовательского интерфейса – проводит отдел
тестирования.
3.1.5. Анализ профиля производительности не проводится, т.к. не осу-
ществляется тестирование производительности из-за отсутствия средств
автоматизации.
3.1.6. Нагрузочное тестирование – не производится из-за отсутствия
средств автоматизации.
3.1.7. Стрессовое тестирование – не производится из-за отсутствия
средств автоматизации.
3.1.8. Объемное тестирование – проводит отдел разработки, а именно
разработчик БД, в силу ограниченности временных и человеческих ресурсов.
3.1.9. Тестирование контроля безопасности и доступа – не проводим, т.к.
для данного приложения оно не имеет высокого приоритета. Данное тести-
рование необходимо проводить для программных систем, сбои в работе
которых могут повлиять на жизнь и здоровье людей, и для интернет прило-
жений, поскольку последние часто подвержены атакам хакеров.
3.1.10. Тестирование на отказ и восстановление – частично проводит
отдел тестированя (проверка сбоев, возникающих на компьютерах пользо-
102 ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

вателей). Отдел разработки проводит тестирование на восстановление после

сбоев центральной БД.
3.1.11. Конфигурационное тестирование – проводит отдел тестирования.
3.1.12. Инсталляционное тестирование – проводит отдел тестирования.
3.2. Инструменты: Borland StarTeam (автоматизированная система
управления конфигурацией и изменениями) – используется для система-
тизации отчетов об ошибках.
4. Ресурсы.
4.1. Роли: разработчик тестов, тестировщик.
4.2. Система: сервер БД, сеть, персональные компьютеры.
5. Контрольные точки.
План тестирования: 16 часов.
Разработка тестов: 176 часов.
Инструменты тестирования: 8 часов.
Выполнение тестирования: 176 часов.
Оценка тестирования: 16 часов.
Критерии окончания тестирования: отдел тестирования выполнил все
запланированные тесты; отдел тестирования удостоверился, что все отче-
ты об ошибках в StarTeam либо закрыты, либо отложены; группа управле-
ния проектом согласна, что программный продукт, как это определено в
процессе системного тестирования, будет удовлетворять ожиданиям за-
казчиков и пользователей.
1. Конечный результат.
1.1. Модель: спецификация и набор тест-кейсов.
1.2. Журнал тестирования: ручное тестирование, метод черного ящика.
1.3. Отчеты об ошибках: в StarTeam.
Процесс составления тест-плана по шаблону RUP помогает написать
структурированный документ, который дает ответы на вопросы: когда, как
и кем будет проводиться тестирование, каковы его цели и результаты.
Шаблон RUP – весьма гибкий документ, позволяющий создавать планы
тестирования под множество программных продуктов и разные команды
разработчиков. Пользуясь готовыми шаблонами, можно существенно сэ-
кономить время на разработку документации по тестированию.

Список литературы:
1. Тест План (План тестирования) [Электронный ресурс]. – Режим
доступа: http://www.protesting.ru/testing/plan.html.
2. Guidelines for Successful Acquisition and Management of Software-In-
tensive Systems: Weapon Systems, Command and Control Systems, Manage-
ment Information Systems – Condensed Version 4.0 February 2003 [Элек-
тронный ресурс]. – Режим доступа: www.stsc.hill.af.mil/resources/tech_docs.
3. IBM Rational Unified Process (RUP) [Электронный ресурс]. – Режим
доступа: http://www.interface.ru/home.asp?artId=5154.
Автоматизация и управление технологическими процессами и производствами 103

4. Test Plan Template RUP [Электронный ресурс]. – Режим доступа:

http://www.protesting.ru/documentation/test_plan_template_rup.zip.
5. Рекс Блэк. Ключевые процессы тестирования. – М.: Издательство
«Лори», 2011.
6. Виды тестирования программного обеспечения [Электронный ре-
сурс]. – Режим доступа: http://www.protesting.ru/testing/testtypes.html.
7. RUP. Тестирование [Электронный ресурс] // Цикл статей по моде-
лированию программных систем. – Режим доступа: www.informicus.ru/de-
fault.aspx?SECTION=6&id=73&subdivisionid=16.

УПРАВЛЕНИЕ XML-ДАННЫМИ НА ОСНОВЕ

ДИНАМИЧЕСКИХ DOM-ОБЪЕКТОВ

© Гусаренко А.С.
Уфимский государственный авиационный технический университет,
г. Уфа

В статье рассматривается задача управления XML данными на осно-

ве динамических DOM-объектов. Приводятся архитектура, структура,
функциональность, особенности реализации. Динамические DOM-объек-
ты, динамическая модель, xml-данные, интерпретация динамических
моделей, xml-технологии, базы данных.

1. Состояние вопроса, актуальность

Работа традиционных интернет-приложений [12-14] базируется на при-

менении реляционных баз данных. Такой подход позволяет хранить данные
и формировать их с помощью языка запросов SQL, а затем использовать для
отображения статического контента (например, HTML). Основным недос-
татком этого подхода является смешивание логики бизнес-процесса с логи-
кой взаимодействия приложения с реляционной СУБД, а также различаю-
щихся версий SQL. При управлении данными с помощью динамических
DOM-объектов в ситуационно-ориентированных СУБД [10, 11], возможно,
избежать проблем при работе с данными и понизить требования к размеще-
нию веб-приложений. При традиционном подходе управления xml-данными
минусом является, обработка данных вручную. В предлагаемом решении эти
функции берѐт на себя интерпретатор встроенных динамических моделей [9].


Младший научный сотрудник кафедры Автоматизированных систем управления, аспирант.
Научный руководитель: Миронов В.В., старший научный сотрудник кафедры Автоматизи-
рованных систем управления, доктор технических наук, профессор.