О
верификации программного обеспечения систем контроля и управления электроснабжением
О.В. Высотин,
с.н.с., к.т.н.,
В.В. Петухов,
вед.
инж.,
ИПУ РАН, г. Москва
В докладе проведен анализ методов верификации ПО и рассмотрены основные аспекты, возникающие
при верификации ПО СКУ ЭЧ.
In the report the
analysis of methods of verification is carried out ON and the main aspects
arising at verification of PO SKU of ECh are
considered.
Основу
современных СКУ ЭЧ составляют программно-технические
комплексы. СКУ ЭЧ характеризуются сложностью как технических, так и программных
средств Для разработки программного обеспечения
предлагается использовать средства CASE-технологий.
Базовым
понятием процесса разработки программного обеспечения является понятие
жизненного цикла программного обеспечения (ЖЦ ПО). ЖЦ
ПО - это непрерывный процесс, который начинается с момента принятия решения о
необходимости его создания и заканчивается в момент его полного изъятия из
эксплуатации, а также модели его развития. Сформулированы общие требования к
методологии и технологии проектирования больших систем.
ЖЦ
ПО состоит из пяти фаз:
· анализа и планирования требований;
· проектирования;
· построения;
· внедрения;
· эксплуатации.
На
каждой из этих фаз должно быть обеспечено качество проекта, которое связано с
проблемами верификации, проверки и тестирования ПО.
Верификация - это процесс для
определения, выполняют ли программные средства и их компоненты требования,
наложенные на них в последовательных этапах ЖЦ ПО.
Анализ, просмотры (обзоры) и тестирование
от требований являются важнейшей частью верификации и установления корректности
программ. Основная цель верификации ПО
состоит в том, чтобы обнаружить, зарегистрировать и
устранить дефекты и ошибки, которые внесены во время последовательной
разработки или модификации программ. Для
эффективности затрат ресурсов при ее реализации, верификация должна быть
интегрирована как можно раньше с процессами проектирования, разработки и
сопровождения. Обычно она проводится сверху вниз, начиная от общих требований,
заданных в техническом задании и/или спецификации на всю информационную систему
до детальных требований на программные модули и их взаимодействие [1].
Назначение верификации ПО -
последовательно проверить, что в реализованном комплексе программ:
§ общие требования к
информационной системе, предназначенные для программной реализации, корректно
переработаны в спецификацию требований высокого уровня к комплексу программ,
удовлетворяющих исходным системным требованиям;
§ требования высокого уровня
правильно переработаны в архитектуру ПО и в спецификации требований к функциональным компонентам
низкого уровня, которые удовлетворяют требованиям высокого уровня;
§ спецификации
требований к функциональным компонентам ПО, расположенным между компонентами
высокого и низкого уровня, каждый раз удовлетворяют требованиям более высокого
уровня;
§
архитектура ПО и спецификации требований к компонентам низкого уровня
корректно переработаны в, удовлетворяющие им, исходные тексты программных и
информационных модулей;
§ исполняемый объектный код
удовлетворяет требованиям к исходному тексту программных компонентов.
Кроме того, верификации на соответствие
спецификации требований на конкретный проект программного средства подлежат
требования к технологическому обеспечению ЖЦ ПС, а также требования к
эксплуатационной и технологической документации.
Цели верификации ПО
достигаются посредством последовательного
выполнения комбинации из просмотров, анализов, разработки тестовых сценариев и
процедур и последующего выполнения этих процедур. Тестовые сценарии
предназначены для проверки внутренней непротиворечивости и полноты реализации
требований. Выполнение тестовых процедур должно обеспечивать демонстрацию
соответствия испытываемых программ исходным требованиям. Информация о процессе
верификации включает требования к системе, требования к ПО и к его архитектуре,
данные о прослеживаемости последовательного
преобразования требований, исходный текст программ, исполняемый объектный код,
План верификации ПО, План квалификационного тестирования ПО.
Результаты верификации должны быть включены в документы: выполненные процедуры
верификации ПО.
Рассмотрена
методология проведения верификации ПО СКУ ЭЧ.
В ходе работы над проектом по созданию СКУ ЭЧ было
создано большое количество проектной документации. Основное ее назначение –
координация совместных действий большого количества разработчиков в течение
более или менее длительных промежутков времени – в процессе первоначальной
разработки системы, в процессе выполнения работ по ее модификации, в процессе
сопровождения. Структурный состав проектной документации в большинстве проектов
практически одинаков – это требования к системе различного уровня (системные,
функциональные и структурные), описание ее архитектуры, программный код, тесты
и документы, сопровождающие процесс внедрения (руководства по установке,
настройке, пользовательские руководства).
Поскольку верификация программной системы (в
оптимистичном случае) выполняется в течение всего жизненного цикла разработки
достаточно большим коллективом разработчиков, при тестировании создается
тестовая документация. Основное ее назначение, помимо синхронизации действий тестировщиков различных уровней – обеспечение гарантий
того, что тестирование выполняется в соответствии с выбранными критериями
оценки качества, а также того, что все аспекты поведения системы
протестированы. Кроме того, тестовая документация используется при внесении
изменений в систему для проверки того, что как старая, так и новая
функциональность работает корректно.
Перед началом верификации
менеджером тестирования (test manager)
создается документ, называемый планом верификации (или планом тестирования. План тестирования –
организационный документ, содержащий требования к тому, как должно выполняться
тестирование в данном конкретном проекте. В нем определяются
общие подходы к согласованию процессов разработки и верификации, определяются
методики проведения верификации, состав тестовой документации и ее взаимосвязь
с документацией разработчиков, сроки различных этапов верификации, различные
роли и квалификация тестировщиков, необходимые для
выполнения всех работ по тестированию, требования к инструментам тестирования и
тестовым стендам, оцениваются риски и приводятся пути для их преодоления.
В данном документе также определяются требования
собственно к тестовой документации – тест-требованиям,
тест-планам, отчетам о выполнении тестирования.
Согласно этим требованиям по системным и
функциональным требованиям разработчиками тестов (test procedure developers) создаются тест-требования
– документы, в которых подробно описано то, какие аспекты поведения системы
должны быть протестированы. На основании описания архитектуры создаются
низкоуровневые тест-требования,
в которых описываются аспекты поведения конкретной программной реализации
системы, которые необходимо протестировать.
На основании тест-требований
разработчиками тестов (test developers) создаются тест-планы – документы, которые
содержат подробное пошаговое описание того, как должны быть протестированы тест-требования.
На основании тест-требований
и проектной документации разработчиков также создается тестовое окружение,
необходимое для корректного выполнения тестов на тестовых стендах – драйверы,
заглушки, настроечные файлы и т.п.
По результатам выполнения
тестов тестировщиками (testers) создаются отчеты о
выполнении тестирования (они могут создаваться либо автоматически, либо
вручную), которые содержат информацию о том, какие несоответствия требованиям
были выявлены в результате тестирования, а также отчеты о покрытии, содержащие
информацию о том, какая доля программного кода системы была задействована в
результате выполнения тестирования.
По несоответствиям создаются отчеты о проблемах –
документы, которые направляются на анализ в группу разработчиков с целью
определения причины возникновения несоответствия.
Изменения в систему вносились только после
всестороннего изучения этих отчетов и локализации проблем, вызвавших
несоответствие требованиям. Для того, чтобы процесс
изменений не вышел из под контроля и любое изменение протоколировалось (и
связывалось с тестами, обнаружившими проблему), создается запрос на изменение
системы. После завершения всех работ по запросу на изменение процесс тестирования
повторяется до тех пор, пока не будет достигнут
приемлемый уровень качества программной системы.
Литература
1. Бойченко А.В., Кондратьев В.К., Липаев В.В. Основы
открытых информационных систем. М.:МЭСИ
2. Синицын С.В., Налютин Н.Ю. Верификация
программного обеспечения. Курс лекций. М.: МИФИ 2006 157 с.