Очень часто путают два понятия валидация и верификация. Кроме того, часто путают валидацию требований к системе с валидацией самой системы. Я предлагаю разобраться в этом вопросе.

В статье я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

Пусть у нас есть проектируемый функциональный объект. Пусть этот объект рассматривается нами как часть конструкции другого функционального Объекта. Пусть есть описание конструкции Объекта, такое, что в нем присутствует описание объекта. В таком описании объект имеет описание как целого, то есть, описаны его интерфейсы взаимодействия с другими объектами в рамках конструкции Объекта. Пусть дано описание объекта как конструкции. Пусть есть информационный объект, содержащий требования к оформлению описания объекта как конструкции. Пусть есть свод знаний, который содержит правила вывода, на основании которых из описания объекта как целого получается описание объекта как конструкции. Свод знаний – это то, чему учат конструкторов в институтах – много, очень много знаний. Они позволяют на основе знанию об объекте спроектировать его конструкцию.

Итак, можно начинать. Мы можем утверждать, что если правильно описан объект как целое, если свод знаний верен, и если правила вывода были соблюдены, то полученное описание конструкции объекта, будет верным. То есть, на основе этого описания будет построен функциональный объект, соответствующий реальным условиям эксплуатации. Какие могут возникнуть риски:

1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.

2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.

3. Неверный свод знаний. Нас учили приоритету массы над остальными параметрами, а оказалось, что надо было наращивать скорость.

4. Неправильное применение правил вывода к описанию объекта. Логические ошибки, что-то пропущено в требованиях к конструкции объекта, нарушена трассировка требований.

5. Неполная запись полученных выводов о конструкции системы. Все учли, все рассчитали, но забыли написать.

6. Созданная система не соответствует описанию.

Понятно, что все артефакты проекта появляются, как правило, в завершенном своем виде только к концу проекта и то не всегда. Но, если предположить, что разработка водопадная, то риски такие, как я описал. Проверка каждого риска – это определенная операция, которой можно дать название. Если кому интересно, можно попытаться придумать и озвучить эти термины.

Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.

Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация - это в том числе проверка описания на непротиворечивость, полноту и понятность.

Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.

Санкт-Петербургский

Государственный Электротехнический Университет

Кафедра МОЭВМ

по дисциплине

“Процесс разработки программных изделий”

“Верификация ПО”

Санкт-Петербург

Цель верификации………………………………………………………………… стр. 3

Вводные замечания……………………………………………………………….. стр. 3

Специальные и общие целевые задачи………………………………………….. стр. 4

Ожидаемая практика по целевым задачам……………………………………… стр. 4

SG1 Подготовка к верификации………………………………………………..... стр. 4

SG2 Проведение экспертиз (экспертного оценивания)………………………… стр. 7

SG3 Осуществление верификации……………………………………………..... стр. 9

Приложение 1. Обзор средств автоматизации процесса верификации……….. стр. 11

Приложение 2. Основные современные подходы к верификации…………….. стр. 12

Список использованной литературы…………………………………………….. стр. 14

Интегрированнаяя модель совершенства и зрелости

Верификация (Уровень зрелости 3)

Цель

Цель верификации - обеспечение гарантий того, что отобранное промежуточное программное изделие или конечная продукция отвечает специфицированным требованиям.

1. Водные замечания

Верификация программных продуктов представляет собой проверку готового продукта или его промежуточных версий на соответствие исходным требованиям. При этом подразумевается не только тестирование самой программы, но и аудит проекта, пользовательской и технической документации и т.д.

Цель верификации программных систем - это определение и выдача отчетов об ошибках, которые могут быть допущены на этапах жизненного цикла. Основные задачи верификации:

определение соответствия высокоуровневых требований требованиям к системе;

учет высокоуровневых требований в архитектуре системы;

соблюдение архитектуры и требований к ней в исходном коде;

определение соответствия исполняемого кода требованиям к системе;

определение средств, используемых для решения вышеперечисленных задач, которые технически корректны и достаточно полны.

Верификация включает в себя верификацию готовой продукции и верификацию промежуточных продукций относительно всех отобранных требований, включающих в себя требования заказчика, требования к готовой продукции и требования к ее отдельным компонентам.

Верификация по своей сути является инкрементальным (нарастающим) процессом с момента своего возникновения на протяжении всей разработки продукции и проведения всех работ по продукции. Верификация начинается с верификации требований, затем следует верификация всех промежуточных продукций на различных стадиях их разработки и изготовления и заканчивается верификацией конечной продукции.

Верификация промежуточных продукций на каждой стадии их разработки и изготовления существенно повышает вероятность того, что конечная продукция будет удовлетворять требованиям заказчика, требованиям к готовой продукции и требованиям к ее отдельным компонентам.

Верификация и Валидация процессов есть суть родственные процессы, направленные, однако, на получение разного результата. Цель Валидации состоит в том, чтобы продемонстрировать, что готовая продукция действительно удовлетворяет своему исходному предназначению. Верификация же направлена на то, чтобы удостовериться в том, что продукция в точности соответствует определенным требованиям. Другими словами, Верификация гарантирует, что “вы делаете это правильно ”, а Валидация то, что “вы делаете правильную вещь ”.

Для оценки эффективности затрат и выполняемых работ верификация должна как можно раньше реализовываться в соответствующих процессах (таких как поставка, разработка, эксплуатация или сопровождение). Данный процесс может включать анализ, проверку и испытание (тестирование).

Данный процесс может выполняться с различными степенями независимости исполнителей. Степень независимости исполнителей может распределяться как между различными субъектами в самой организации, так и субъектами в другой организации, с различными степенями распределения обязанностей. Данный процесс называется процессом независимой верификации , если организа­ция-исполнитель не зависит от поставщика, разработчика, оператора или персонала сопровожде­ния.

Экспертные оценки (экспертизы ) являются важной составляющей верификации как хорошо зарекомендовавшее себя средство эффективного устранения дефектов. Важным выводом из этого является необходимость в развитии более глубокого понимания и осмысления рабочих версий продукта, а также используемых рабочих процессов для выявления возможных дефектов и создания в случае необходимости возможности для внесения улучшений.

Экспертизы включают в себя методическое исследование производимых работ экспертами, с целью выявить дефекты и другие требуемые изменения.

Основными методами экспертного оценивания являются:

осмотр

сквозной структурный контроль

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Реферат

Методы верификации и тестирования программного обеспечения

Введение

Человеку свойственно ошибаться. Ошибки всегда были и всегда будут. В айтишной среде ходит шутка, что если программа с первого раза запустилась и сразу заработала, то нужно искать ошибку.

Вместе с развитием вычислительной техники, с её проникновением во все сферы жизни, растёт и количество ошибок в программах. Причём, рост ошибок непропорционален росту количества программ. Каждый год ряды программистов пополняются быдлокодерами (и имя им - легион), которые развивают сферу ошибок в геометрической прогрессии.

Ошибки заметны далеко не в каждой сфере. Например, никому нет дела до ошибок и уязвимостей в браузерах типа «амиго». Да и потери от подобных ошибок незначительны: максимум, что может потерять рядовой пользователь, это учётные записи в соцсетях, полторы тысячи бездарных фотографий с отдыха и коллекцию порнушки.

Но есть сферы, в которых ошибки программирования могут привести к самым печальным последствиям. Один из первых случаев, который мне удалось найти, - это космический аппарат Mariner 1, который был уничтожен 22 июля 1962 года на 293 секунде после старта из-за ошибки в программе бортового компьютера. Это хорошо, что тогда погибших не было.

А что будет, если бортовой компютер Boeing-747, с четырьмя сотнями пассажиров на борту, выбросит exception?.

Вот для таких сфер, которые можно назвать «серьёзными», и придуманы методы верификации и тестирования.

В некоторой зарубежной литературе процессы верификации и тестирования отождествляются, а кое-где тестирование рассматривается, как один из методов верификации. Данную работу я буду выполнять в меру своего понимания, отдельно рассматривать процессы верификации и тестирования. Также, справедливости ради, затрону тему валидации ПО.

1. Определения

Жизненный цикл (ЖЦ) программного обеспечения. Под этим термином понимается интервал времени, начиная от идеи создания программного обеспечения с необходимым функционалом для решения определённых задач до полного прекращения использования последней версии этой программы.

Артефакты жизненного цикла программного обеспечения (ПО). Сюда входят самые разные информационные материалы, связанные с созданием ПО. Это техническое задание, описание архитектуры, исходный код, пользовательская документация и другие документы. Материалы, которые использовались при разработке, но не были зафиксированы в доступной форме (например, комментарии в коде и ругань разработчиков в чате) артефактами не являются.

2. Верификация

Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам. В частности, верификация проверяет соответствие между нормами стандартов, описанием требований (техническим заданием) к ПО, проектными решениями, исходным кодом, пользовательской документацией и функционированием самого ПО. Кроме того, проверяется, что требования, проектные решения, документация и код оформлены в соответствии с нормами и стандартами, принятыми в данной стране, отрасли и организации при разработке ПО, а также - что при их создании выполнялись все указанные в стандартах операции, в нужной последовательности. Обнаруживаемые при верификации ошибки и дефекты являются расхождениями или противоречиями между несколькими из перечисленных документов, между документами и реальной работой программы, между нормами стандартов и реальным процессами разработки и сопровождения ПО. При этом принятие решения о том, какой именно документ подлежит исправлению (может быть, и оба) является отдельной задачей.

Выше приведено официальное определение верификации. На самом деле, всё намного проще: верификация определяет, правильно ли мы делаем программу .

Таким образом, основными методами верификации являются экспертиза и инспекция.

программа экспертиза верификация

3. Валидация

В процессе валидации проверяется соответствие любых создаваемых или используемыв ходе разработки и сопровождения ПО артефактов нуждам и потребностям пользователей и заказчиков этого ПО, с учётом законов предметной области и ограничений контекста использования ПО.

И снова за множеством слов скрывается очень простая задача: в процессе валидации проверяется, нужен ли определённый функционал программы данным пользователям / заказчикам. Отвечает ли программный продукт пожеланиям заказчиков и конечных пользователей.

4. Тестирование

Тестирование - это процесс обнаружения ошибок в ПО путём исполнения кода программной системы на тестовых данных, сбора рабочих характеристик в динамике выполнения в конкретной операционной среде, выявления различных ошибок, дефектов, отказов и изъянов, вызванных нерегулярными и аномальными ситуациями или аварийным прекращением работы ПО.

Исторически первым видом тестирования была отладка.

Отладка - это проверка описания программного объекта на языке программирования с целью обнаружения в нём ошибок и последующее их устранение. Ошибки обнаруживаются компилятором при их синтаксическом контроле. После отладки проводится верификация по проверке правильности кода и валидация по проверке соответствия продукта заданным требованиям.

1. Статические методы тестирования

Статические методы используются при проведении инспекций и рассмотрении спецификаций компонентов без их выполнения. Техника статического анализа заключается в методическом просмотре и анализе структуры программ, а также в доказательстве их правильности. Статический анализ направлен на анализ документов, разработанных на всех этапах ЖЦ и заключается в инспекции исходного кода и сквозного контроля программы.

Инспекция ПО - это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программ) на процессах ЖЦ. Просмотры и инспекции результатов проектирования и соответствия их требованиям заказчика обеспечивают более высокое качество создаваемых программных систем.

2. Динамические методы тестирования

Метод «чёрного ящика». При использовании этого метода, используется информация о решаемой задаче, но ничего неизвестно о структуре программы. Цель тестирования по этому принципу - выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.

Методы тестирования по этому принципу используются для тестирования функций, реализованных в программе, путём проверки несоответствия между реальным поведением функций и ожидаемым поведением с учётом спецификаций требований. Во время подготовки к этому тестированию строятся таблицы условий, причинно-следственные графы 1 и области разбивки. Кроме того, подготавливаются тестовые наборы, учитывающие параметры и условия среды, которые влияют на поведение функций.

Метод «белого ящика».

Данный метод позволяет исследовать внутреннюю структуру программы, причём обнаружение всех ошибок в программе является критерием исчерпывающего тестирования маршрутов потоков передач управления, среди которых рассматриваются:

Критерий покрытия операторов - набор тестов в совокупности должен обеспечить прохождение каждого оператора не менее одного раза;

Критерий тестирования ветвей (aka покрытие решений или покрытие переходов) - набор тестов в совокупности должен обеспечить прохождение каждой ветви или выхода хотя бы один раз.

3. Функциональное тестирование

Цель функционального тестирования - обнаружение несоответствий между реальным поведением реализованных функций и ожидаемым поведением в соответствии со спецификацией и исходными требованиями. Функциональноые тесты должны охватывать все реализованные функции с учётом наиболее вероятных типов ошибок. Тестовые сценарии, объединяющие отдельные тесты, ориентированы на проверку качества решения функциональных задач.

Функциональные тесты создаются по спецификациям функций, проектной информации и по тексту на языке программирования и применяются для определения полноты реализации функциональных задач и их соответствия исходным требованиям.

В задачи функционального тестирования входят:

Идентификация множества функциональных требований;

Идентификация внешних функций и построение последовательностей функций в соответствии с их использованием в программной системе;

Идентификация множества входных данных каждой функции и определение областей их изменения;

Построение тестовых наборов и сценариев тестирования функций;

Выявление и представление всех функциональных требований с помощью тестовых наборов и проведение тестирования ошибок в программе и при взаимодействии со средой.

Тесты, создаваемые по проектной информации, связаны со структурами данных, алгоритмами, интерфейсами между отдельными компонентами и применяются для тестирования компонентов и их интерфейсов. Основная цель - обеспечение полноты и согласованности реализованных функций и интерфейсов между ними.

5. Типы ошибок по стандарту ANSI/IEEE -7 29 -8 3

Ошибка (error) - состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе её разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению.

Дефект (fault) в программе - следствие ошибок разработчика на любом из этапов разработки, которые могут содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может, быть обнаружен дефект или сбой.

Отказ (failure) - это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования. Отказ может быть результатом следующих причин:

Ошибочная спецификация или пропущенное требование, означающее, что спецификация точно не отражает того, что предполагал пользователь;

Спецификация может содержать требование, которое невозможно выполнить на данной аппаратуре и программном обеспечении;

Проект программы может содержать ошибки (например, база данных спроектирована без средств защиты от несанкционированного доступа пользователя, а требуется защита);

Программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или он реализован неполностью.

Заключение

Российские ГОСТы, касающиеся верификации и тестирования ПО, являются переводом «буржуйских» стандартов, таких как ISO 12207, ANSI/IEEE-729-83 и других (очень их много). Проблема заключается в том, что эти международные стандарты по-разному рассматривают вопросы тестирования и верификации. Не сказать, чтоб они совсем уж противоречили друг другу, но недоумение вызвать могут.

Все эти стандарты формулировались в 80-х годах прошлого столетия для космической промышленности США. В последующие годы они исправлялись и переиздавались, но разногласия и противоречия в документах оставались.

Вывод: структуру методов верификации, валидации и тестирования следует воспринимать, как условную.

Список используемой литературы

1. Свободная энциклопедия wikipedia.org

2. Кулямин В.В. Методы верификации программного обеспечения М.: Институт системного программирования, 2008

3. Лаврищева Е., Петрухин В. Лекция «Методы проверки и тестирования программ и систем»: НОУ «ИНТУИТ» http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130

Размещено на Allbest.ru

Подобные документы

Жизненный цикл программного обеспечения - непрерывный процесс, который начинается с принятия решения о необходимости создания ПО и заканчивается при полном изъятия его из эксплуатации. Подход к определению жизненного цикла ПО Райли, по Леману и по Боэму.

реферат , добавлен 11.01.2009


Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.

презентация , добавлен 11.05.2015


История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.

курсовая работа , добавлен 16.12.2015


Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.

курсовая работа , добавлен 22.03.2015


Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.

презентация , добавлен 19.09.2016


История возникновения тестирования программного обеспечения, основные цели и особенности его проведения. Виды и типы тестирования, уровни его автоматизации. Использование и исследование необходимых технологий. Полный цикл прогона всей системы мониторинга.

дипломная работа , добавлен 03.05.2018


Основные международные стандарты в области информационных технологий. Международный стандарт ISO/IEC 9126. Качество и жизненный цикл. Характеристика внутренних и внешних атрибутов качества. Анализ функциональных возможностей программного обеспечения.

доклад , добавлен 13.06.2017


Цели и задачи программной инженерии. Понятие программного обеспечения. Шесть принципов эффективного использования программного обеспечения. Виды программного обеспечения: общесистемное, сетевое и прикладное. Принципы построения программного обеспечения.

курсовая работа , добавлен 29.06.2010


Общая характеристика основных моделей жизненного цикла: каскадная, инкрементная, спиральная. Стадия как часть процесса создания программного обеспечения, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта.

презентация , добавлен 27.12.2013


Информатизация России. Рынок программных средств. Основные задачи стандартизации, сертификации и лицензирования в сфере информатизации. Совокупность инженерных методов и средств создания программного обеспечения. Жизненный цикл программного обеспечения.

Верификация (подтверждение правильности) – состоит в проверке и доказательстве корректности разработанной программы по отношению к совокупности формальных утверждений, представленных в спецификации и полностью определяющей связь между входными и выходными данными этой программы. При этом отношения между переменными н входе и выходе программы анализируется не в виде значений, как при тестировании, а в виде описаний их свойств, проявляющихся при любых процессах обработок этих переменных контролируемой в программе.

Верификация программы в принципе исключает необходимость её тестирования и отладки, так как при этом на более высоком уровне понятий и описаний всех переменных, устанавливается корректность процессов, их обработка и преобразования.

Сущность каждой программы можно представить описаниями отношений между входными и выходными данными. Эти отношения формализуются 1 программной спецификации. В реальных разработках формализация этих взаимосвязей является неплохой, и часть отношений уточняется в процессе разработок программ. Такие не полностью определённые недостаточны для доказательства корректности программ. Только при полной и точной формализации всех условий и связей между входными и результирующими данными появляется возможность их использования для автоматической верификации.

Метод индуктивных утверждений.

Для изучения этого метода программа снабжается утверждениями о свойствах её переменных в нкоторых точках:

a) Входные переменные не меняются в процессе исполнения программ;

b) Описываются состояния переменных в промежуточных точках;

c) Выходные переменные описываются с помощью отношениями между переменными после завершения программы.

Верификация состоит в последовательной демонстрации того, что из входных переменных и преобразований, выполненных на первом шаге следует истинность утверждения, сформированного в следующей промежуточной точке.

Для верификации программ необходимо три языка:

· Язык записи текстов программ;

· Язык формулировки условий верификации;

· Язык формирования и доказательства корректности.

Так как эти языки различаются в значительной степени, то это обстоятельство является одним из применения верификации.

Доказательство корректности имеет следующие преимущества:

1. Представляет собой чёткий формализованный процесс.

2. Требует анализа. Процесс доказательства корректностидает возможность рассматривать части программ, которое в противном случае анализируется лишь случайно.

3. проясняет промежуточные результаты вычислений. Выписывании выражений заставляет программиста четко сформировать свои предположения о результатах вычислений в выбранных точках программы.

4. Выявляет зависимости. В процессе доказательства программ начинает понимать какие предположения о входных данных не явно испытывается в различных частях программы.

Недостатки метода:

1. Сложность; даже для небольших простых программ выкладки очень сложны, что может привести к ошибкам.

2. Ошибки, Из-за сложности метода легко допустить ошибки и при формировании доказываемых утверждений и при доказательстве.

3. Трудности работы с массивами.

4. Отсутствие мощного математического аппарата.

5. Высокая трудоёмкость.Для проверки программы требуется затраты труда, чем для её написания (в 2 – 6 раз).

6. Отсутствие выразительности. Часто нелегко сформировать выгодно утверждение для того что интуитивно представляетсяочень простым вычислением:

7. Трудность понимания.

8. Необходимостьобучения. Для применении этого метода требуется длительное обучение и тренировка.

Программные системы в настоящее время присутствуют повсеместно: практически любые электронные устройства содержат программное обеспечение (ПО) того или иного вида. Без соответствующего программного обеспечения в современном мире невозможно представить индустриальное производство, школы и университеты, систему здравоохранения, финансовые и правительственные учреждения. Многие пользователи применяют ПО для самообразования, для развлечений и т.д. Создание спецификации требований, разработка, модификация и сопровождение таких систем ПО составляет суть технической дисциплины инженерия программного обеспечения (software engineering, SE).

Даже простые системы ПО обладают высокой степенью сложности, поэтому при их разработке приходится применять весь арсенал технических и инженерных методов. Следовательно, инженерия программного обеспечения – это инженерная дисциплина, где специалисты используют теорию и методы компьютерных наук для успешного решения разного рода нестандартных задач. Но, конечно, не каждый проект ПО завершается успешно в силу различных причин. Прогресс заметен: за последние 30 лет ПО очень сильно усложнилось, появились программы, предлагающие пользователям очень большие сервисные возможности для работы с ними.

Следует отметить, что инженерия программного обеспечения развивается в основном в соответствии с постановкой новых задач построения больших пользовательских систем ПО для промышленности, правительства и оборонного ведомства. С другой стороны, в настоящее время сфера программного обеспечения очень широка: от игр на специализированных игровых консолях, а также программных продуктов для персональных компьютеров до очень больших масштабируемых распределенных систем.

При создании программного продукта перед инженером встает множество вопросов различного рода, таких как, например, требования к ПО, модели систем, спецификации ПО, надежность создаваемого продукта, и т.д. В данной работе рассматриваются одни из самых сложных шагов в создании любого программного продукта – верификация и аттестация. В работе дается общее представление о верификации и аттестации программного обеспечения, читатель знакомится с методами статической верификации, динамической верификации, методами аттестации критических систем.

1. Общие сведения о верификации и аттестации ПО.

1.1. Введение в верификацию и аттестацию

Верификацией и аттестацией называются процессы проверки и анализа, в ходе которых проверяется соответствие программного обеспечения своей спецификации и требованиям заказчиков. Верификация и аттестация охватывают весь цикл жизни ПО – они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тестирования программной системы.

Верификация и аттестация – абсолютно разные понятия, однако часто их путают. Для того, чтобы различать их, выведем главное различие между этими терминами. Верификация отвечает на вопрос, правильно ли создана система, а аттестация отвечает на вопрос, правильно ли работает система. Из этого следует, что верификация проверяет соответствие ПО системной спецификации, в частности функциональным и нефункциональным требованиям. Аттестация – это более общий процесс. Во время аттестации цель инженера – доказать заказчику, что продукт оправдывает ожидания последнего. Аттестация проводится после верификации.

На ранних этапах разработки ПО очень важна аттестация системных требований. В требованиях очень часто встречаются ошибки, недочеты, упущения, что может привести к несоответствию продукта замыслу заказчика. Инженер должен справляться с этой проблемой. Однако, как известно, сложно искоренить все погрешности в требованиях. Отдельные ошибки могут обнаружиться лишь тогда, когда программный продукт реализован.

В процессах верификации и аттестации используются две основные методики проверки и анализа систем: инспектирование ПО и тестирование ПО. Инспектирование ПО подразумевает анализ и проверку различных представлений системы, например, документации. Инспектирование происходит на всех этапах разработки программной системы. Параллельно с инспектированием может проводиться автоматический анализ исходного кода программ и соответствующих документов. Инспектирование и автоматический анализ – это статические методы верификации и аттестации, поскольку им не требуется исполняемая система. Тестирование ПО есть анализ выходных данных и рабочих характеристик программного продукта для проверки правильности работы системы. Тестирование – динамический метод верификации и аттестации, так как применяется к исполняемой системе.

На рис. 1.1 показано место инспектирования и тестирования в процессе разработки ПО. Стрелки указывают на те этапы процесса разработки, на которых можно применять данные методы.

Рис. 1.1. Статическая и динамическая верификация и аттестация

Согласно этой схеме, инспектирование можно выполнять на всех этапах разработки системы, а тестирование – в тех случаях, когда создан прототип или исполняемая программа. К методам инспектирования относятся: инспектирование программ, автоматический анализ исходного кода и формальная верификация. Однако статическими методами возможно осуществить проверку только на соответствие программ спецификации, с их помощью невозможно выяснить правильность функционирования системы. Кроме того, статическими методами нельзя проверить такие нефункциональные характеристики, как производительность и надежность. Следовательно, для анализа нефункциональных характеристик следует проводить тестирование системы. В настоящее время, несмотря на широкое применение инспектирования ПО, преобладающим методом верификации и аттестации все еще остается тестирование. Тестирование – это проверка работы программ с данными, подобными реальным, которые будут обрабатываться в процессе эксплуатации системы. Неполадки в работе ПО обнаруживаются при анализе выходных данных, среди которых выделяются и исследуются аномальные.

На разных этапах процесса разработки ПО применяют различные виды тестирования. Тестирование дефектов проводится для выявления несоответствий между программным продуктом и его спецификацией, которые обусловлены ошибками в программном коде. Такие тесты разрабатываются для выявления ошибок в системе, а не для имитации ее работы. Статистическое тестирование оценивает производительность и надежность программ, а также работу программы при использовании различных режимов ее эксплуатации. Тесты разрабатываются с целью имитирования, причем имитируется реальная работа системы с реальными выходными данными. Надежность функционирования системы определяется по количеству сбоев, отмеченных в работе программ. Производительность оценивается по результатам измерений полного времени выполнения операций и времени отклика системы при обработке тестовых данных.

Конечно, между этими двумя методами тестирования нет четких границ. Во время тестирования испытатель может получить интуитивное представление о надежности ПО, а во время статистического тестирования есть возможность выявления программных дефектов.

Главная цель верификации и аттестации - удостовериться в том, что система «соответствует своему назначению». Соответствие программной системы своему назначению отнюдь не предполагает, что в ней совершенно не должно быть ошибок. Скорее, система должна хорошо соответствовать тем целям, для которых она планировалась. Уровень необходимой достоверности соответствия зависит от назначения системы, ожиданий пользователей и условий на рынке программных продуктов.

Назначение ПО. Уровень достоверности соответствия зависит от важности (критичности) разрабатываемого программного продукта по каким-либо критериям. Например, ПО для медицинской установки «Аппарат сердце-легкие» является суперкритичным, так как от качества работы системы зависит человеческая жизнь. Можно привести пример систем малой критичности. Это, в частности, опытные образцы программных систем, разрабатываемые для демонстрации некоторых новых идей.

При проведении верификации и аттестации в системе, как правило, обнаруживаются ошибки, которые должны исправляться. После исправления ошибок необходимо снова проверить программу. Для этого можно еще раз выполнить инспектирование программы или повторить тестирование. Разработчик должен знать, что простых методов исправления ошибок в программах не существует. Повторное тестирование необходимо проводить для того, чтобы убедиться, что сделанные в программе изменения не внесли в систему новых ошибок, поскольку на практике высокий процент «исправления ошибок» либо не завершается полностью, либо вносит новые ошибки в программу. При разработке крупных систем каждое повторное тестирование всей системы обходится очень дорого; при этом для экономии средств определяют связи и зависимости между частями системы и проводят тестирование именно этих отдельных частей.

2. Верификация и аттестация ПО

2.1. Планирование верификации и аттестации

Верификация и аттестация – дорогостоящие процессы. Для сложных систем, например, характерно такое соотношение: половина всего бюджета, выделенного на реализацию системы, тратится на верификацию и аттестацию. Поэтому очевидна необходимость тщательного планирования верификации и аттестации.

Планирование верификации и аттестации должно начинаться как можно раньше. На рисунке 2.1 показана модель разработки ПО, учитывающая процесс планирования испытаний.

Рис. 2.1. Планирование испытаний в процессе разработки и тестирования,

Requirements specification – спецификация требований

System specification – системная спецификация

System design – проектирование системы

Detailed Design – детальное проектирование

Acceptance test plan – планирование приемочных испытаний

System integration test plan – планирование тестирования системной сборки

Sub-system integration test plan – планирование тестирования сборки подсистемы

Module and unit code and tess – кодирование и тестирование модулей и компонентов

Sub-system integration test – тестирование сборки подсистем

System integration test – тестирование системной сборки

Acceptance test – приемочные испытания

Service – программный продукт.

Из рисунка видно, что процесс верификации и аттестации разделяется на несколько этапов, причем на каждом этапе проводится определенный тест.

В процессе планирования верификации и аттестации необходимо определить соотношение между статическими и динамическими методами проверки системы, определить стандарты и процедуры инспектирования, составить план тестирования программ. От типа разрабатываемой системы зависит то, чему следует уделить больше внимания – инспектированию или тестированию. Чем более критична система, тем больше внимания следует уделять статическим методам верификации.

План испытаний ПО обязательно должен включать в себя: описание основных этапов процесса тестирования, возможность отслеживания требований (тестирование следует спланировать так, чтобы протестировать все требования в отдельности), тестируемые элементы (следует определить все «выходные» продукты процесса разработки ПО, которые необходимо тестировать), график тестирования (составляется временной график тестирования и распределение ресурсов проводится согласно этому графику, причем график тестирования привязан к более общему графику разработки проекта), процедуры записи тестов (для проверки правильности выполнения тестов), аппаратные и программные требования, ограничения (попытаться предвидеть все неблагоприятные факторы, влияющие на процессы тестирования, например, нехватку средств, персонала…).

Подобно другим планам, план испытаний не является неизменным документом. Его следует регулярно пересматривать, так как тестирование зависит от процесса реализации системы. Например, если реализация какой-либо части систем не завершена, то невозможно провести тестирование сборки системы. Пересмотр плана позволяет использовать сотрудников (не занятых в данный момент) на других работах.

2.2. Инспектирование программных систем

Системное тестирование программ требует разработки огромного количества тестов, их выполнения и проверки. Это значит, что данный процесс достаточно трудоемкий и дорогостоящий. Каждый тест способен обнаружить в программе одну, реже несколько ошибок. Причина такого положения заключается в том, что сбои в работе, происходящие из-за ошибок в системе, часто приводят к разрушению данных. Поэтому сложно сказать, какое количество ошибок «ответственно» за сбой в системе.

Инспектирование программ не требует от последних быть завершенными, поэтому инспектировать можно даже на начальных стадиях разработки. Во время инспектирования проверяется исходное представление системы. Это может быть модель системы, спецификация или программа, написанная на языке высокого уровня. Обнаружение ошибок достигается путем использования знаний рассматриваемой системы и семантики ее исходного представления. Каждую ошибку можно рассмотреть отдельно, не обращая внимания на то, как она влияет на поведение системы.

Доказано, что инспектирование является эффективным методом обнаружения ошибок, причем оно значительно дешевле экстенсивного тестирования. Инспектированием можно обнаружить более 60% всех ошибок, а при более формальном подходе (используя математические методы) – более 90%. Процесс инспектирования также может оценить другие качественные характеристики систем: соответствие стандартам, переносимость и удобства сопровождения.

В системных компонентах выявление ошибок путем инспектирования более эффективно, чем путем тестирования. Во-первых, за один сеанс инспектирования можно обнаружить очень многие дефекты программного кода; при применении тестирования за один сеанс обнаруживается обычно лишь одна ошибка, поскольку ошибки могут привести к полному останову (отказу) системы, а эффекты ошибок могут накладываться друг на друга. Во-вторых, инспектирование использует знание о предметной области и языке программирования. Специалист, проводящий инспектирование, должен знать типы ошибок, что дает возможность сосредоточиться на конкретных видах дефектов.

Понятно, что инспектирование не может заменить тестирование. Инспектирование лучше применять на начальных стадиях для выявления наибольшего количества ошибок. Инспектированием проверяют соответствие ПО его спецификации, но таким способом, например, невозможно оценить динамическое поведение системы. Более того, нерационально инспектировать законченные системы, собранные из нескольких подсистем. На этом уровне возможно только тестирование.

Ошибочно полагать, что тестирование и инспектирование являются конкурирующими методами верификации и аттестации. У каждого из них есть свои преимущества и недостатки. Следовательно, в процессе верификации и аттестации инспектирование и тестирование следует использовать совместно.

Иногда при инспектировании в организации возникают трудности. Эксперты, имеющие большой опыт в тестировании программ, неохотно соглашаются с тем, что инспектирование является более эффективным методом устранения дефектов системы, чем тестирование. Менеджеры относятся к этим технологиям с недоверием, потому что внедрение инспектирования требует дополнительных расходов. Конечная экономия средств при применении инспектирования достигается только благодаря опыту проводящих его специалистов.

2.3. Инспектирование программ

Инспектирование программ – это просмотр и проверка программ с целью обнаружения в них ошибок. Идея формализованного процесса проверки программ была сформулирована корпорацией IBM в 1970-х годах. В настоящее время данный метод верификации получил широкое распространение. На его базе разработано множество других методов, но все они основываются на базовой идее метода инспектирования, согласно которому группа специалистов выполняет тщательный построчный просмотр и анализ исходного кода программы. Главное отличие инспектирования от других методов оценивания качества программ состоит в том, что его цель – обнаружение дефектов, а не исследование общих проблем проекта. Дефектами являются либо ошибки в исходном коде, либо несоответствия программы стандартам.

Процесс инспектирования – формализованный. В нем принимает участие небольшая группа людей (обычно не более, чем четыре человека). У каждого в группе есть своя роль. Обязательно должны присутствовать: автор, рецензент, инспектор, координатор. Рецензент «озвучивает» программный код, инспектор проверяет его, координатор отвечает за организацию процесса. По мере накопления опыта инспектирования в организациях могут появляться другие предложения по распределению ролей в группе (например, одно лицо может исполнять несколько ролей, поэтому количество членов в группе инспектирования может варьироваться).

Для начала процесса инспектирования программы необходимы следующие условия: наличие точной спецификации кода (без полной спецификации невозможно обнаружить дефекты в проверяемом программном компоненте); члены инспекционной группы должны хорошо знать стандарты разработки; в распоряжении группы должна быть синтаксически корректная последняя версия программы (нет смысла рассматривать код, который «почти завершен»).

Рис. 2.2. Процесс инспектирования

На рис. 2.2 показан общий процесс инспектирования. Он адаптирован к требованиям организаций, использующих инспектирование программ.

Сам процесс инспектирования должен быть относительно коротким (не более двух часов) и сосредоточенным только на выявлении дефектов, аномалий и несоответствий стандартам. Инспекционная группа не должна предлагать способы исправления дефектов или рекомендовать какие-либо изменения в других программных компонентах.

После инспектирования автор изменяет программу, исправляя обнаруженные ошибки. На этапе доработки координатор принимает решение о том, необходимо ли повторное инспектирование. Если повторное инспектирование не требуется, все обнаруженные дефекты фиксируются документально.

В процессе инспектирования организация накапливает определенный опыт, поэтому результаты инспектирования можно использовать для улучшения всего процесса разработки ПО. В ходе инспектирования выполняется анализ обнаруженных дефектов. Группа инспектирования и авторы инспектируемого кода определяют причины возникновения дефектов. Чтобы подобные дефекты не возникали в будущих системах, необходимо по возможности устранить причины возникновения дефектов, что означает внесение изменений в процесс разработки программных систем.

Обеспечение инспектирования ПО требует квалифицированного управления и правильного отношения к результатам его проведения. Инспектирование – открытый процесс обнаружения ошибок, когда ошибки, допущенные отдельным программистом, становятся известны всей группе программистов. Менеджеры должны четко разграничивать инспектирование программного кода и оценку кадров. При оценке профессиональных качеств ни в коем случае нельзя учитывать ошибки, обнаруженные в процессе инспектирования. Руководителям инспекционных групп необходимо пройти тщательную подготовку, чтобы грамотно управлять процессом и совершенствовать культуру отношений, которая гарантировала бы поддержку в процессе обнаружения ошибок и отсутствие каких-либо обвинений в связи с этими ошибками.

2.4. Автоматический статический анализ программ

Статические анализаторы программ – это инструментальные программные средства, которые сканируют исходный текст программы и выявляют возможные ошибки и противоречия. Для анализаторов не требуется исполняемая программа. Они выполняют синтаксический разбор текста программы, распознают различные типы операторов. С помощью анализаторов можно проверить, правильно ли составлены операторы, сделать выводы относительно потока управления в программе и во многих случаях вычислить множество значений данных, используемых программой. Анализаторы дополняют средства обнаружения ошибок, предоставляемые компилятором языка.

Цель автоматического статического анализа – привлечь внимание проверяющего к аномалиям в программе, например, к переменным, которые используются без инициализации или инициализированы, но в программе не использовались.

Статический анализ состоит из нескольких этапов.

1. Анализ потока управления. Идентификация и выделение циклов, их точек входа и выхода, выявление неиспользуемого кода.

2. Анализ использования данных. Проверка переменных в программе. На этом этапе также можно выявить условные операторы с избыточными условиями.

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

4. Анализ потоков данных. Определяются зависимости между входными и выходными переменными. Хотя этот анализ не выявляет конкретных ошибок, он дает полный список значений, используемых в программе. Следовательно, легко обнаруживается ошибочный вывод данных.

5. Анализ ветвей программы. На этом этапе семантического анализа определяются все ветви программы и выделяются операторы, исполняемые в каждой ветви. Анализ ветвей программы существенно помогает разобраться в управлении программой и позволяет проанализировать каждую ветвь отдельно.

Следует отметить, что анализ потока данных и анализ ветвей программы генерируют огромное количество информации. Эта информация не выявляет конкретных ошибок, а представляет программу в разных аспектах. Из-за огромного количества генерируемой информации эти этапы иногда исключают из процесса анализа и используют только на ранних стадиях для обнаружения аномалий в разрабатываемой программе. Статические анализаторы особенно полезны в тех случаях, когда используются языки программирования, подобные С. В языке С нет строгого контроля типов, и потому проверка, осуществляемая компилятором языка С, ограничена. В этом случае средствами статического анализа выявляется широкий спектр ошибок, что особенно важно при разработке критических систем.

Анализ с помощью инструментальных средств не может заменить инспектирования, так как существуют такие типы ошибок, которые невозможно выявить с помощью статического анализа. Например, анализаторы способны обнаружить необъявленные переменные, однако они не смогут обнаружить неправильного присвоения. Конечно, для таких языков, как С, статический анализ является эффективным методом обнаружения ошибок. Но в современных языках (типа Java) удалены конструкции, способствующие появлению многих ошибок. Все переменные должны быть объявлены, отсутствуют операторы безусловного перехода, вследствие чего маловероятно случайное создание неиспользуемого кода, и осуществляется автоматическое управление памятью.

2.5 Метод «чистая комната».

При разработке ПО методом «чистая комната» для устранения дефектов используется процесс строгого инспектирования. Цель данного метода – создание ПО без дефектов. Название «чистая комната» взято по аналогии с производством кристаллов полупроводников, где выращивание кристаллов без дефектов происходит в сверхчистой атмосфере (чистых комнатах).

В разработке ПО методом «чистая комната» выделяют пять ключевых моментов:

1. Формальная спецификация . Разрабатывается формальная спецификация. Для записи спецификации используется модель состояний, в которой отображены отклики системы.

2. Пошаговая разработка . Разработка ПО разбивается на несколько этапов, которые проверяются методом «чистая комната» независимо друг от друга.

3. Структурное программирование. Используется ограниченное количество управляющих конструкций. Процесс разработки программы – это процедура поэтапной детализации спецификации.

4. Статическая верификация. Проверка статическим методом строгого инспектирования ПО. Для отдельных элементов тестирование кода не проводится.

5. Статическое тестирование системы. На каждом шаге проводится тестирование статическими методами, позволяющими оценить надежность программной системы.

На первых этапах разработки ПО методом «чистая комната» реализуются наиболее критичные для заказчика системные функции. Менее важные системные функции добавляются на последующих этапах. Таким образом, у заказчика есть возможность испытать систему до полной ее реализации.

Процесс разработки ПО методом «чистая комната» планируется таким образом, чтобы обеспечить строгое инспектирование программ, которое сопровождается строгими математическими доказательствами согласованности и корректности преобразований.

Обычно разработкой больших систем методом «чистая комната» занимаются три группы разработчиков: группа спецификации, группа разработки (разрабатывает и проверяет ПО), группа сертификации (разрабатывает контрольные тесты).

В результате использования метода «чистая комната» программный продукт содержит крайне мало ошибок, а его стоимость меньше, чем у разработанного традиционными методами. В процессе разработки этим методом оказывается рентабельной статическая проверка. Огромное количество дефектов обнаруживается еще до исполнения программы и исправляется в процессе разработки ПО.

3. Тестирование программного обеспечения

3.1. Планирование тестирования

При планировании процесса верификации и аттестации ПО менеджеры проекта должны определить, кто будет отвечать за разные этапы тестирования. Во многих случаях за тестирование своих программ, модулей или объектов несут ответственность программисты. За следующий этап отвечает группа системной интеграции (сборки), которая интегрирует отдельные программные модули в единую систему и тестирует эту систему в целом.

Для критических систем процесс тестирования должен быть более формальным. Такая формализация предполагает, что за все этапы тестирования отвечают независимые испытатели, все тесты разрабатываются отдельно, и во время тестирования ведутся подробные записи. Чтобы протестировать критические системы, независимая группа разрабатывает тесты, исходя из спецификации каждого компонента. При разработке некритических систем подробные спецификации для каждого компонента не создаются. Таким образом, тестирование компонентов, как правило, основывается только на понимании разработчиками того, что должен делать компонент.

Тестирование сборки должно основываться на имеющейся спецификации системы.

В контексте тестирования между объектно-ориентированными системами (ООС) и функционально-ориентированными (ФОС) системами имеется ряд отличий. В ФОС существует четкое различие между основными программными элементами и совокупностью этих элементов. В ООС этого нет. Следовательно, в ООС между тестированием компонентов и тестированием сборки нет четких границ. В таких системах процесс тестирования является продолжением процесса разработки.

3.2. Тестирование дефектов

Целью тестирования дефектов является выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование дефектов противоположно аттестации, в ходе которой проверяется соответствие системы своей спецификации. Во время аттестации система должна корректно работать со всеми заданными тестовыми данными. При тестировании дефектов запускается такой тест, который вызывает некорректную работу программы, и, следовательно, выявляет дефект. Тестирование дефектов демонстрирует наличие , а не отсутствие дефектов в программе.

Полное тестирование, когда проверяются все возможные последовательности выполнения программы, невозможно. Поэтому тестирование должно базироваться на некотором подмножестве всевозможных тестовых сценариев.

Из опыта тестирования больших программных продуктов вытекает, что необычные комбинации функций иногда могут вызывать ошибки, но наиболее часто используемые функции всегда работают правильно.

Методов тестирования дефектов существует несколько.

Тестирование методом черного ящика заключается в том, что вся система представляется как «черный ящик», поведение которого можно определить только посредством изучения входных и соответствующих выходных данных. Другое название этого метода – функциональное тестирование, так как проводится анализ только выполняемых функций.

Структурное тестирование . Метод структурного тестирования предполагает создание тестов на основе структуры системы и ее реализации. Такой подход иногда называют методом «белого ящика», «прозрачного ящика», «стеклянного ящика», чтобы отличать его от тестирования методом черного ящика. Как правило, структурное тестирование применяется к относительно небольшим программным элементам. При таком подходе испытатель анализирует код и для получения тестовых данных использует знания о структуре компонента. Например, из анализа кода можно определить, сколько контрольных тестов нужно выполнить для того, чтобы в процессе тестирования все операторы выполнились по крайней мере один раз.

Тестирование ветвей. Это метод структурного тестирования, при котором проверяются все независимо выполняемые ветви компонента или программы. Если выполняются все независимые ветви, то и все операторы должны выполняться по крайней мере один раз. Более того, все условные операторы тестируются как с истинными, так и с ложными значениями условий. В ООС тестирование ветвей используется для тестирования методов, ассоциированных с объектами. Количество ветвей в программе обычно пропорционально ее размеру. После интеграции программных модулей в систему, методы структурного тестирования оказываются невыполнимыми. Поэтому методы тестирования ветвей, как правило, используются при тестировании отдельных программных элементов и модулей. При тестировании ветвей не проверяются все возможные комбинации ветвей программы. Не считая самых тривиальных программных компонентов без циклов, подобная полная проверка компонента оказывается нереальной, так как в программах с циклами существует бесконечное число всевозможных комбинаций ветвей. В программе могут быть дефекты, которые проявляются только при определенной комбинации ветвей, даже если все операторы протестированы хотя бы один раз.

3.3. Тестирование сборки

После того, как протестированы все отдельные программные компоненты, выполняется сборка системы, в результате чего создается частичная или полная система. Процесс интеграции системы включает сборку и тестирование полученной системы, в ходе которого выявляются проблемы, возникающие при взаимодействии компонентов. Тесты, проверяющие сборку системы, должны создаваться на основе системной спецификации. Тестирование сборки должно начинаться сразу после создания работоспособных версий компонентов системы.

Во время тестирования сборки возникает проблема локализации выявленных ошибок. Между компонентами системы существуют сложные взаимоотношения, и при обнаружении между ними аномальных выходных данных бывает трудно установить источник ошибки. Чтобы облегчить локализацию ошибок, следует использовать пошаговый метод сборки и тестирования системы. Сначала следует создать минимальную конфигурацию системы и протестировать ее. Затем в минимальную конфигурацию нужно добавить новые компоненты и снова протестировать, и так далее до полной сборки системы.

Нисходящее и восходящее тестирование . Методики нисходящего (НТ) и восходящего тестирования (ВТ) отражают разные подходы к системной интеграции. При нисходящей интеграции компоненты высокого уровня интегрируются и тестируются еще до окончания их проектирования и реализации. При восходящей интеграции перед разработкой компонентов более высокого уровня сначала интегрируются и тестируются компоненты нижнего уровня.

НТ является неотъемлемой частью процесса нисходящей разработки систем, при котором сначала разрабатываются компоненты верхнего уровня, а затем компоненты, находящиеся на нижних уровнях иерархии. Программа представляется в виде одного абстрактного компонента с субкомпонентами, являющимися заглушками. Заглушки имеют тот же интерфейс, что и компонент, но с ограниченной функциональностью. После того, как компонент верхнего уровня запрограммирован и протестирован, таким же образом реализуются и тестируются его субкомпоненты. Процесс продолжается до тех пор, пока не будут реализованы компоненты самого нижнего уровня. Затем вся система тестируется целиком.

При ВТ, наоборот, сначала интегрируются и тестируются модули, расположенные на более низких уровнях иерархии. Затем выполняется сборка и тестирование модулей, расположенных выше, и так далее до тех пор, пока не будет протестирован последний модуль. При таком подходе не требуется наличие законченного архитектурного проекта системы, и поэтому он может начинаться на раннем этапе процесса разработки.

Тестирование интерфейсов. Тестирование интерфейсов (ТИ) выполняется в тех случаях, когда модули или подсистемы интегрируются в большие системы. Каждый модуль или подсистема имеет заданный интерфейс, который вызывается другими компонентами системы. Цель ТИ – выявить дефекты, возникающие в системе вследствие ошибок в интерфейсах или вследствие неправильных предположений об интерфейсах.

Данный тип тестирования особенно важен в объектно-ориентированном программировании. Объекты в значительной степени определяются с помощью интерфейсов и могут повторно использоваться в различных комбинациях с разными объектами в разных системах. Во время тестирования отдельных объектов невозможно выявить ошибки интерфейса, так как они являются скорее результатом взаимодействия между объектами, чем изолированного поведения одного объекта.

Между компонентами программы могут быть разные типы интерфейсов и, соответственно, разные типы ошибок интерфейса.

Рис. 3.1. Тестирование интерфейсов

ТИ – сложный процесс, поскольку некоторые ошибки могут проявляться только в необычных условиях. Другая проблема может возникнуть из-за взаимодействий между ошибками в разных программных модулях или объектах. Ошибки в одном объекте можно выявить только тогда, когда поведение другого объекта становится непредсказуемым.

Обычно статические методы тестирования более рентабельны, чем специальное ТИ. В языках со строгим контролем типов ошибки интерфейса помогает обнаруживать компилятор, а в языках со слабым контролем ошибки может выявлять статический анализатор. Кроме того, при инспектировании программ можно сосредоточиться именно на проверке интерфейсов компонентов.

Тестирование с нагрузкой . После полной интеграции системы можно оценить такие интеграционные свойства системы, как производительность и надежность. Чтобы убедиться, что система может работать с заданной нагрузкой, разрабатываются тесты для измерения производительности. Обычно проводят серии тестов с постепенным увеличением нагрузки, пока производительность системы не начнет снижаться.

3.4. Инструментальные средства тестирования

Тестирование – дорогой и трудоемкий этап разработки программных систем. Поэтому создан широкий спектр инструментальных средств для поддержки процесса тестирования, которые значительно сокращают расходы на него. На рис. 3.2 показаны возможные инструментальные средства тестирования и отношения между ними.

Рис. 3.2. Инструментальные средства тестирования

На этом рисунке:

Организатор тестов управляет выполнением тестов, генератор тестовых данных генерирует тестовые данные для тестируемой программы (выбирает тестовые данные из базы данных или использует шаблоны для генерации случайных данных), оракул генерирует ожидаемые результаты тестов, компаратор файлов сравнивает результаты текущего тестирования с результатами предыдущего тестирования и составляет отчет об обнаруженных различиях, генератор отчетов формирует отчеты по тестам, динамический анализатор добавляет в программу код подсчета количества выполнения каждого оператора, имитатор моделирует выполнение программы.

4. Аттестация критических систем

Верификация и аттестация критических систем имеет много общего с подобными процессами, выполняемыми над любой другой программной системой. Однако природа критических систем (КС) такова, что в дополнение к обычному анализу и тестированию системы необходимы еще процессы доказательства ее надежности. Это требуется по двум причинам. Первая причина – цена отказа КС. В КС стоимость отказа значительно выше, чем в каких-либо других. Поэтому экономически выгоднее вложить большее количество средств в верификацию и аттестацию, чем терпеть убытки от сбоев. Вторая причина – аттестация свойств функциональной надежности . Заказчики КС должны быть уверены в том, что система соответствует определенным показателям функциональной надежности. По этим причинам стоимость верификации и аттестации КС значительно выше, чем для других систем.

4.1. Аттестация безотказности

Чтобы быть уверенным, что система соответствует требованиям, необходимо измерить ее показатели безотказности, учитывая работу типичного пользователя. Процесс измерения показателей безотказности состоит из четырех этапов: сначала изучаются аналогичные существующие системы (определяется операционный профиль), затем идет подготовка тестовых данных, дальнейший этап – собственно тестирование, последним шагом выполняется вычисление показателей безотказности. Данный метод иногда называют статическим тестированием, цель которого – оценить безотказность системы. Статическое тестирование противоположно тестированию дефектов, проводимому в целях обнаружения ошибок в системе. Однако этот метод не так прост для применения на практике. Трудности возникают по нескольким причинам:

Неопределенность операционного профиля (профили могут неточно отражать реальное использование системы)

Высокая стоимость генерации тестовых данных (если нет возможности автоматической генерации тестовых данных, то создание большого количества тестовых данных требует больших затрат времени и, соответственно, средств)

Статистическая неопределенность в случае высокой безотказности (для точного измерения показателей безотказности необходимо сгенерировать статистически значимое число отказов).

Операционный профиль (ОП) отражает практику использования системы. Он состоит из спецификации классов входных данных и вероятности их появления. Если система ПО инновационная, предвидеть, как она будет использоваться, сложно. Система используется различными группами пользователей с разными ожиданиями, знаниями и опытом. У новых систем нет предыстории использования, и для работы с ними пользователи часто применяют способы, не предусмотренные разработчиками. Еще одна проблема состоит в том, что ОП может меняться в ходе использования системы. Все эти причины часто не позволяют разработать надежный ОП. В подобных ситуациях сложно оценить степень неопределенности в измерении показателей безотказности систем.

Во время аттестации ПО менеджеры должны уделить основное внимание тестированию системы. Так как тестирование – очень дорогой процесс, важно завершить его как можно раньше, причем так, чтобы впоследствии не пришлось тестировать систему повторно. Тестирование завершается, если достигнут необходимый уровень безотказности. Но иногда выясняется, что требующийся уровень безотказности никогда не будет достигнут. В этом случае менеджер должен принять нелегкое решение о переработке некоторых частей системы или о перезаключении договора с заказчиком.

4.2. Гарантии безопасности

Получение гарантий безопасности системы и аттестация ее безотказности – разные процессы. Безотказность можно определить количественно с помощью различных числовых показателей. Безопасность нельзя достоверно определить количественными способами, следовательно, ее невозможно измерить в ходе тестирования системы.

Поэтому аттестация безопасности определяет уровень надежности системы, который может варьироваться от «очень низкого» до «очень высокого». Здесь требуется профессиональная оценка безопасности. Во многих случаях определение безопасности базируется на опыте организации, разрабатывающей систему. Если в организации уже есть предварительно разработанные надежно функционирующие безопасные системы, то разумно предположить, что в данной организации будут разработаны подобные безопасные системы. С другой стороны, оценка безопасности должна опираться на реальную архитектуру системы, результаты верификации и аттестации, а также на процессы, которые применялись при разработке системы.

4.3. Верификация и аттестация

Верификация и аттестация систем, критических по обеспечению безопасности, имеет много общего с тестированием любых систем с высокими требованиями надежности. Чтобы обнаружить наибольшее количество ошибок, следует применять всестороннее тестирование, а при оценке безопасности использовать статические методы тестирования. Однако вследствие чрезвычайно низкой частоты отказов, присущих многим КС, с помощью статического тестирования не всегда удается количественно оценить безотказность, так как для этого требуется очень большое число тестов. Эти тесты лишь дают основание считать ту или иную КС безопасной.

При создании КС, важен всесторонний анализ разрабатываемой системы. Имеется пять типов анализа системы, обязательных для КС:

1. Анализ правильности функционирования системы

2. Анализ возможности изменения и понятности системной архитектуры

3. Анализ соответствия алгоритма обработки и структуры данных определенному в спецификации поведению системы

4. Анализ согласованности программного кода, алгоритмов и структур данных.

5. Анализ адекватности тестовых сценариев системным требованиям.

Все доказательства безопасности системы строятся на следующем предположении: количество ошибок в системе, которые приводят к аварийным ситуациям, намного меньше общего числа ошибок в системе. Обеспечение безопасности должно сосредоточиться на выявлении потенциально опасных ошибок. Если оказывается, что эти ошибки не проявляются или проявляются, но не приводят к серьезным последствиям, то система считается надежной. Доказательства правильности программ были предложены в качестве методов верификации ПО более 25 лет назад. Однако эти методы в основном используются только в лабораториях. Практические проблемы построения доказательства правильности ПО настолько сложны, что некоторые организации считают использование данных методов в процессе разработки обычных систем неоправданно дорогим. Но, как отмечалось ранее, для ряда КС экономически выгодно использовать доказательства правильности системы, чем ликвидировать последствия отказов.

Несмотря на то, что для большинства систем разрабатывать доказательства правильности нерентабельно, иногда возникает необходимость разработать доказательства безопасности, демонстрирующие соответствие данной программы требованиям по обеспечению безопасности. При доказательстве безопасности необязательно доказывать соответствие программы спецификации. Необходимо только показать, что выполнение программы не приводит к сбоям с опасными последствиями.

Заключение

В этой работе были рассмотрены вопросы верификации и аттестации ПО. Было доказано, что это очень сложные шаги в разработке любого продукта, требующие от инженеров внимания, высочайшей квалификации, терпения, а от организации – больших вложений средств. Однако какими бы дорогостоящими не были эти процессы, экономическая выгода от их использования очевидна, ведь система без сбоев не наносит убытков. Следует помнить, что аварийные ситуации – редкие события (особенно в КС), поэтому практически невозможно смоделировать их во время тестирования системы. Было установлено, что требования безопасности никогда не исключают ненадежного поведения системы. Посредством тестирования и других процессов аттестации невозможно полностью доказать соответствие системы требованиям безопасности.

В настоящее время приобретает большое значение оценка защищенности систем, поскольку все чаще системы объединяются посредством сети Интернет. Требования защищенности в некоторых отношениях подобны требованиям безопасности. В частности, они определяют нештатное поведение системы, а не ее «рабочее» поведение. Однако, как правило, невозможно определить это поведение в виде простых ограничений, контролируемых системой.

Конечным пользователям очень сложно проверить защищенность системы. Поэтому в Европе выработаны системы критериев оценки защищенности, которые контролируются специально обученными экспертами. Поставщики готового ПО могут предоставить на рассмотрение свои конечные продукты для оценки и сертификации по различным критериям защищенности.

Верификация и аттестация должны стать обязательными шагами в разработке ПО, пусть даже самого простого. Каждая компания, производящая ПО, должна создать штат сотрудников, которые будут заниматься только верификацией и аттестацией: это инженеры-тестеры, инженеры-испекторы и др. Организации должны учитывать экономическую обстановку на рынке ПО, желания пользователей (уже было отмечено, что требовательность пользователей к ПО растет).

Если соблюдать все эти требования, то, скорее всего, наступит день, когда нас будут окружать системы, работающие без сбоев.

Литература.

1. Соммервилл И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. – М.: Издат. Дом. «Вильямс», 2002. – 624 с.: ил.

2. А.Г. Гейн, В.Г. Житомирский. Основы информатики и вычислительной техники: проб. Учеб. Для 10-11 кл. сред. шк. – 3-е изд. – М.: Просвещение, 1993. – 254 с.: ил.

3. Ю. Г. Карпов. Теория автоматов. – Спб.: Питер, 2002 – 224 с.: ил.

4. Электронный Архив для инженеров программного обеспечения. http://www.cs.queensu.ca/Software-Engineering/

5. Software Engineering Questions and Answers. http://www.cs.queensu.ca/Software-Engineering/questions.html

6. Ресурсы сервера Института Инженерии Программного Обеспечения Карнеги Меллона (Carnegie Mellon Software Engineering Institute). http://www.sei.cmu.edu/

7. SybaseDevel.Ru – русский портал для разработчиков. http://www.sybasedevel.ru