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

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

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

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

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

Тестирование - процесс выполнения программы с целью обнаружения ошибки.

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

Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований.

Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.

Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.

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

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

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

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

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

Размещено на 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


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

Целью данного курса является изложение комплексного взгляда на процесс верификации программного обеспечения. Предметом обсуждения являются различные подходы и методы, применяемые в области верификации и, в частности, тестирования программного обеспечения. Предполагается, что разрабатываемое программное обеспечение является частью более общей системы. Подобная система включает аппаратные, информационные и организационные (человек-пользователь, человек-оператор и т.п.) компоненты, разрабатываемые, возможно, разными коллективами. Поэтому необходимы документы разработки, определяющие требования к различным компонентам системы и правила их взаимодействия. Кроме того, предполагается, что отказы системы могут приводить к последствиям той или иной тяжести, поэтому при разработке программного обеспечения необходимы и оправданы усилия, потраченные на выявление скрытых дефектов. В первую очередь, это касается средств и процедур верификации программного обеспечения. В состав курса входит ряд практических занятий, иллюстрирующих на примере простой системы приемы и методы верификации программного обеспечения в среде Microsoft Visual Studio 2005 Team Edition for Software Testers. Данная публикация входит в состав "Библиотеки учебных курсов", формирование которой ведется в рамках программы академического сотрудничества MSDN Academic Alliance (MSDN AA).

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

Рис. 7 Тестирование, верификация и валидация Верификация программного обеспечения – более общее понятие, чем тестирование. Целью верификации является достижение гарантии того, что верифицируемый объект (требования или программный код) соответствует требованиям, реализован без непредусмотренных функций и удовлетворяет проектным спецификациям и стандартам. Процесс верификации включает в себя инспекции, тестирование кода, анализ результатов тестирования, формирование и анализ отчетов о проблемах. Таким образом, принято считать, что процесс тестирования является составной частью процесса верификации, такое же допущение сделано и в данном учебном курсе. Валидация программной системы – процесс, целью которого является доказательство того, что в результате разработки системы мы достигли тех целей, которые планировали достичь благодаря ее использованию. Иными словами, валидация – это проверка соответствия системы ожиданиям заказчика. Вопросы, связанные с валидацией выходят за рамки данного учебного курса и представляют собой отдельную интересную тему для изучения. Если посмотреть на эти три процесса с точки зрения вопроса, на который они дают ответ, то тестирование отвечает на вопрос «Как это сделано?» или «Соответсвует ли поведение разработанной программы требованиям?», верификация – «Что сделано?» или «Соответствует ли разработанная система требованиям?», а валидация – «Сделано ли то, что нужно?» или «Соответствует ли разработанная система ожиданиям заказчика?». 1.7. Документация, создаваемая на различных этапах жизненного цикла Синхронизация всех этапов разработки происходит при помощи документов, которые создаются на каждом из этапов. Документация при этом создается и на прямой отрезке жизненного цикла – при разработке программной системы, и на обратном – при ее верификации. Попробуем на примере V-образного жизненного цикла проследить за тем, какие типы документов создаются на каждом из отрезков, и какие взаимосвязи между ними существуют (Рис. 8). Результатом этапа разработки требований к системе являются сформулированные требования к системе – документ, описывающие общие принципы работы системы, ее взаимодействие с «окружающей средой» - пользователями системы, а также, программными и аппаратными средствами, обеспечивающими ее работу. Обычно параллельно с требованиями к системе создается план верификации и определяется стратегия верификации. Эти документы определяют общий подход к тому, как будет выполняться тестирование, какие методики будут применяться, какие аспекты будущей системы должны быть подвергнуты тщательной проверке. Еще одна задача, решаемая при помощи определения стратегии верификации – определение места различных верификационных процессов и их связей с процессами разработки. 20 Верификационный процесс, работающий с системными требованиями – это процесс валидации требований, сопоставления их реальным ожиданиям заказчика. Забегая вперед, скажем, что процесс валидации отличается от приемо-сдаточных испытаний, выполняемых при передаче готовой системы заказчику, хотя может считаться частью таких испытаний. Валидация является средством доказать не только корректность реализации системы с точки зрения заказчика, но и корректность принципов, положенных в основу ее разработки. Рис. 8 Процессы и документы при разработке программных систем Требования к системе являются основой для процесса разработки функциональных требований и архитектуры проекта. В ходе этого процесса разрабатываются общие требования к программному обеспечению системы, к функциям которые она должна выполнять. Функциональные требования часто включают в себя определение моделей поведения системы в штатных и нештатных ситуациях, правила обработки данных и определения интерфейса с пользователем. Текст требования, как правило, включает в себя слова «должна, должен» и имеет структуру вида «В случае, если значение температуры на датчике ABC достигает 30 и выше градусов Цельсия, система должна прекращать выдачу звукового сигнала». Функциональные требования являются основой для разработки архитектуры системы – описания ее структуры в терминах подсистем и структурных единиц языка, на котором производится реализация – областей, классов, модулей, функций и т.п. На базе функциональных требований пишутся тест-требования – документы, содержащие определение ключевых точек, которые должны быть проверены для того, чтобы убедиться в корректности реализации функциональных требований. Часто тест- требования начинаются словами «Проверить, что» и содержат ссылки на соответствующие им функциональные требования. Примером тест-требований для приведенного выше функционального требования могут служить «Проверить, что в случае падения температуры на датчике ABC ниже 30 градусов Цельсия система выдает предупреждающий звуковой сигнал» и «Проверить, что в случае, когда значение температуры на датчике ABC выше 30 градусов Цельсия, система не выдает звуковой сигнал». 21 Одна из проблем, возникающих при написании тест-требований – принципиальная нетестируемость некоторых требований, например требование «Интерфейс пользователя должен быть интуитивно понятным» невозможно проверить без четкого определения того, что является интуитивно понятным интерфейсом. Такие неконкретные функциональные требования обычно впоследствии видоизменяют. Архитектурные особенности системы также могут служить источником для создания тест-требований, учитывающих особенности программной реализации системы. Примером такого требования является, например, «Проверить, что значение температуры на датчике ABC не выходит за 255». На основе функциональных требований и архитектуры пишется программный код системы, для его проверки на основе тест-требований готовится тест-план – описание последовательности тестовых примеров, выполняющих проверку соответствия реализации системы требованиям. Каждый тестовый пример содержит конкретное описание значений, подаваемых на вход системы, значений, которые ожидаются на выходе и описание сценария выполнения теста. В зависимости от объекта тестирования тест-план может готовиться либо в виде программы на каком-либо языке программирования, либо в виде входного файла данных для инструментария, выполняющего тестируемую систему и передающего ей значения, указанные в тест-плане, либо в виде инструкций для пользователя системы, описывающей необходимые действия, которые нужно выполнить для проверки различных функций системы. В результате выполнения всех тестовых примеров собирается статистика об успешности прохождения тестирования – процент тестовых примеров, для которых реальные выходные значения совпали с ожидаемыми, так называемых пройденных тестов. Не пройденные тесты являются исходными данными для анализа причин ошибок и последующего их исправления. На этапе интеграции осуществляется сборка отдельных модулей системы в единое целое и выполнение тестовых примеров, проверяющих всю функциональность системы. На последнем этапе осуществляется поставка готовой системы заказчику. Перед внедрением специалисты заказчика совместно с разработчиками проводят приемо- сдаточные испытания – выполняют проверку критичных для пользователя функций согласно заранее утвержденной программе испытаний. При успешном прохождении испытаний система передается заказчику, в противном случае отправляется на доработку. 1.8. Типы процессов тестирования и верификации и их место в различных моделях жизненного цикла 1.8.1. Модульное тестирование Модульному тестированию подвергаются небольшие модули (процедуры, классы и т.п.). При тестировании относительного небольшого модуля размером 100-1000 строк есть возможность проверить, если не все, то, по крайней мере, многие логические ветви в реализации, разные пути в графе зависимости данных, граничные значения параметров. В соответствии с этим строятся критерии тестового покрытия (покрыты все операторы, все логические ветви, все граничные точки и т.п.). . Модульное тестирование обычно выполняется для каждого независимого программного модуля и является, пожалуй, наиболее распространенным видом тестирования, особенно для систем малых и средних размеров. 1.8.2. Интеграционное тестирование Проверка корректности всех модулей, к сожалению, не гарантирует корректности функционирования системы модулей. В литературе иногда рассматривается 22 «классическая» модель неправильной организации тестирования системы модулей, часто называемая методом «большого скачка». Суть метода состоит в том, чтобы сначала оттестировать каждый модуль в отдельности, потом объединить их в систему и протестировать систему целиком. Для крупных систем это нереально. При таком подходе будет потрачено очень много времени на локализацию ошибок, а качество тестирования останется невысоким. Альтернатива «большому скачку» - интеграционное тестирование, когда система строится поэтапно, группы модулей добавляются постепенно. 1.8.3. Системное тестирование Полностью реализованный программный продукт подвергается системному тестированию. На данном этапе тестировщика интересует не корректность реализации отдельных процедур и методов, а вся программа в целом, как ее видит конечный пользователь. Основой для тестов служат общие требования к программе, включая не только корректность реализации функций, но и производительность, время отклика, устойчивость к сбоям, атакам, ошибкам пользователя и т.д. Для системного и компонентного тестирования используются специфические виды критериев тестового покрытия (например, покрыты ли все типовые сценарии работы, все сценарии с нештатными ситуациями, попарные композиции сценариев и проч.). 1.8.4. Нагрузочное тестирование Нагрузочное тестирование позволяет не только получать прогнозируемые данные о производительности системы под нагрузкой, которая ориентирована на принятие архитектурных решений, но и предоставляет рабочую информацию службам технической поддержки, а также менеджерам проектов и конфигурационным менеджерам, которые отвечают за создания наиболее продуктивных конфигураций оборудования и ПО. Нагрузочное тестирование позволяет команде разработки, принимать более обоснованные решения, направленные на выработку оптимальных архитектурных композиций. Заказчик со своей стороны, получает возможность проводить приёмо-сдаточные испытания в условиях приближенных к реальным. 1.8.5. Формальные инспекции Формальная инспекция является одним из способов верификации документов и программного кода, создаваемых в процессе разработки программного обеспечения. В ходе формальной инспекции группой специалистов осуществляется независимая проверка соответствия инспектируемых документов исходным документам. Независимость проверки обеспечивается тем, что она осуществляется инспекторами, не участвовавшими в разработке инспектируемого документа. 1.9. Верификация сертифицируемого программного обеспечения Дадим несколько определений, определяющих общую структуру процесса сертификации программного обеспечения: Сертификация ПО – процесс установления и официального признания того, что разработка ПО проводилась в соответствии с определенными требованиями. В процессе сертификации происходит взаимодействие Заявителя, Сертифицирующего органа и Наблюдательного органа Заявитель - организация, подающая заявку в соответствующий Сертифицирующий орган на получения сертификата (соответствия, качества, годности и т.п.) изделия. Сертифицирующий орган – организация, рассматривающая заявку Заявителя о проведении Сертификации ПО и либо самостоятельно, либо путем формирования специальной комиссии производящая набор процедур направленных на проведение процесса Сертификации ПО Заявителя. 23 Наблюдательный орган – комиссия специалистов, наблюдающих за процессами разработки Заявителем сертифицируемой информационной системы и дающих заключение, о соответствии данного процесса определенным требованиям, которое передается на рассмотрение в Сертифицирующий орган. Сертификация может быть направлена на получение сертификата соответствия, либо сертификата качества. В первом случае результатом сертификации является признание соответствия процессов разработки определенным критериям, а функциональности системы определенным требованиям. Примером таких требований могут служить руководящие документы Федеральной службы по техническому и экспортному контролю в области безопасности программных систем . Во втором случае результатом является признание соответствия процессов разработки определенным критериям, гарантирующим соответствующий уровень качества выпускаемой продукции и его пригодности для эксплуатации в определенных условиях. Примером таких стандартов может служить серия международных стандартов качества ISO 9000:2000 (ГОСТ Р ИСО 9000-2001) или авиационные стандарты DO- 178B , AS9100 , AS9006 . Тестирование сертифицируемого программного обеспечения имеет две взаимодополняющие цели: Первая цель - продемонстрировать, что программное обеспечение удовлетворяет требованиям на него. Вторая цель - продемонстрировать с высоким уровнем доверительности, что ошибки, которые могут привести к неприемлемым отказным ситуациям, как они определены процессом, оценки отказобезопасности системы, выявлены в процессе тестирования. Например, согласно требованиям стандарта DO-178B, для того, чтобы удовлетворить целям тестирования программного обеспечения, необходимо следующее: Тесты, в первую очередь, должны основываться на требованиях к программному обеспечению; Тесты должны разрабатываться для проверки правильности функционирования и создания условий для выявления потенциальных ошибок. Анализ полноты тестов, основанных на требованиях на программное обеспечение, должен определить, какие требования не протестированы. Анализ полноты тестов, основанных на структуре программного кода, должен определить, какие структуры не исполнялись при тестировании. Также в этом стандарте говорится о тестировании, основанном на требованиях. Установлено, что эта стратегия наиболее эффективна при выявлении ошибок. Руководящие указания для выбора тестовых примеров, основанных на требованиях, включают следующее: Для достижения целей тестирования программного обеспечения должны быть проведены две категории тестов: тесты для нормальных ситуаций и тесты для ненормальных (не отраженных в требованиях, робастных) ситуаций. Должны быть разработаны специальные тестовые примеры для требований на программное обеспечение и источников ошибок, присущих процессу разработки программного обеспечения. Целью тестов для нормальных ситуаций является демонстрация способности программного обеспечения давать отклик на нормальные входы и условия в соответствии с требованиями. 24 Целью тестов для ненормальных ситуаций является демонстрация способности программного обеспечения адекватно реагировать на ненормальные входы и условия, иными словами, это не должно вызывать отказ системы. Категории отказных ситуаций для системы устанавливаются путем определения опасности отказной ситуации для самолета и тех, кто в нем находится. Любая ошибка в программном обеспечении может вызвать отказ, который внесет свой вклад в отказную ситуацию. Таким образом, уровень целостности программного обеспечения, необходимый для безопасной эксплуатации, связан с отказными ситуациями для системы. Существует 5 уровней отказных ситуаций от несущественной до критически опасной. Согласно этим уровням вводится понятие уровня критичности программного обеспечения. От уровня критичности зависит состав документации, предоставляемой в сертифицирующий орган, а значит и глубина процессов разработки и верификации системы. Например, количество типов документов и объем работ по разработке системы, необходимых для сертификации по самому низкому уровню критичности DO-178B могут отличаться на один-два порядка от количества и объемов, необходимых для сертификации по самому высокому уровню. Конкретные требования определяет стандарт, по которому планируется вести сертификацию. 25 ТЕМА 2. Тестирование программного кода (лекции 2-5) 2.1. Задачи и цели тестирования программного кода Тестирование программного кода – процесс выполнения программного кода, направленный на выявление существующих в нем дефектов. Под дефектом здесь понимается участок программного кода, выполнение которого при определенных условиях приводит к неожиданному поведению системы (т.е. поведению, не соответствующему требованиям). Неожиданное поведение системы может приводить к сбоям в ее работе и отказам, в этом случае говорят о существенных дефектах программного кода. Некоторые дефекты вызывают незначительные проблемы, не нарушающие процесс функционирования системы, но несколько затрудняющие работу с ней. В этом случае говорят о средних или малозначительных дефектах. Задача тестирования при таком подходе – определение условий, при которых проявляются дефекты системы и протоколирование этих условий. В задачи тестирования обычно не входит выявление конкретных дефектных участков программного кода и никогда не входит исправление дефектов – это задача отладки, которая выполняется по результатам тестирования системы. Цель применения процедуры тестирования программного кода – минимизация количества дефектов, в особенности существенных, в конечном продукте. Тестирование само по себе не может гарантировать полного отсутствия дефектов в программном коде системы. Однако, в сочетании с процессами верификации и валидации, направленными на устранение противоречивости и неполноты проектной документации (в частности – требований на систему), грамотно организованное тестирование дает гарантию того, что система удовлетворяет требованиям и ведет себя в соответствии с ними во всех предусмотренных ситуациях. При разработке систем повышенной надежности, например, авиационных, гарантии надежности достигаются при помощи четкой организации процесса тестирования, определения его связи с остальными процессами жизненного цикла, введения количественных характеристик, позволяющих оценивать успешность тестирования. При этом, чем выше требования к надежности системы (ее уровень критичности), тем более жесткие требования предъявляются. Таким образом, в первую очередь мы рассматриваем не конкретные результаты тестирования конкретной системы, а общую организацию процесса тестирования, используя подход «хорошо организованный процесс дает качественный результат». Такой подход является общим для многих международных и отраслевых стандартах качества, о которых более подробно будет рассказано в конце данного курса. Качество разрабатываемой системы при таком подходе является следствием организованного процесса разработки и тестирования, а не самостоятельным неуправляемым результатом. Поскольку современные программные системы имеют весьма значительные размеры, при тестировании их программного кода используется метод функциональной декомпозиции. Система разбивается на отдельные модули (классы, пространства имен и т.п.), имеющие определенную требованиями функциональность и интерфейсы. После этого по отдельности тестируется каждый модуль – выполняется модульное тестирование. Затем выполняется сборка отдельных модулей в более крупные конфигурации – выполняется интеграционное тестирование, и наконец, тестируется система в целом – выполняется системное тестирование. С точки зрения программного кода, модульное, интеграционное и системное тестирование имеют много общего, поэтому в данной теме основное внимание будет уделено модульному тестированию, особенности интеграционного и системного тестирования будут рассмотрены позднее. 26 В ходе модульного тестирования каждый модуль тестируется как на соответствие требованиям, так и на отсутствие проблемных участков программного кода, могущих вызвать отказы и сбои в работе системы. Как правило, модули не работают вне системы – они принимают данные от других модулей, перерабатывают их и передают дальше. Для того, чтобы с одной стороны, изолировать модуль от системы и исключить влияние потенциальных ошибок системы, а с другой стороны – обеспечить модуль всеми необходимыми данными, используется тестовое окружение. Задача тестового окружения – создать среду выполнения для модуля, эмулировать все внешние интерфейсы, к которым обращается модуль. Об особенностях организации тестового окружения пойдет речь в данной теме. Типичная процедура тестирования состоит в подготовке и выполнении тестовых примеров (также называемых просто тестами). Каждый тестовый пример проверяет одну «ситуацию» в поведении модуля и состоит из списка значений, передаваемых на вход модуля, описания запуска и выполнения переработки данных – тестового сценария, и списка значений, которые ожидаются на выходе модуля в случае его корректного поведения. Тестовые сценарии составляются таким образом, чтобы исключить обращения к внутренним данным модуля, все взаимодействие должно происходить только через его внешние интерфейсы. Выполнение тестового примера поддерживается тестовым окружением, которое включает в себя программную реализацию тестового сценария. Выполнение начинается с передачи модулю входных данных и запуска сценария. Реальные выходные данные, полученные от модуля в результате выполнения сценария сохраняются и сравниваются с ожидаемыми. В случае их совпадения тест считается пройденным, в противном случае – не пройденным. Каждый не пройденный тест указывает либо на дефект в тестируемом модуле, либо в тестовом окружении, либо в описании теста. Совокупность описаний тестовых примеров составляет тест-план – основной документ, определяющий процедуру тестирования программного модуля. Тест-план задает не только сами тестовые примеры, но и порядок их следования, который также может быть важен. Структура и особенности тест-планов будут рассмотрены в данной теме, проблемы, связанные с порядком следования тестовых примеров – в теме «Повторяемость тестирования». При тестировании часто бывает необходимо учитывать не только требования к системе, но и структуру программного кода тестируемого модуля. В этом случае тесты составляются таким образом, чтобы детектировать типичные ошибки программистов, вызванные неверной интерпретацией требований. Применяются проверки граничных условий, проверки классов эквивалентности. Отсутствие в системе возможностей, не заданных требованиями, гарантируют различные оценки покрытия программного кода тестами, т.е. оценки того, какой процент тех или иных языковых конструкций выполнен в результате выполнения всех тестовых примеров. Обо всем этом пойдет речь в завершение данной темы. 2.2. Методы тестирования 2.2.1. Черный ящик Основная идея в тестировании системы, как черного ящика состоит в том, что все материалы, которые доступны тестировщику – требования на систему, описывающие ее поведение и сама система, работать с которой он может только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, таким образом, система и представляет собой «черный ящик», правильность поведения которого по отношению к требованиям и предстоит проверить. 27 С точки зрения программного кода черный ящик может представлять с собой набор классов (или модулей) с известными внешними интерфейсами, но недоступными исходными текстами. Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке соответствия поведения системы требованиям. Кроме того, тестировщик должен проверить работу системы в критических ситуациях – что происходит в случае подачи неверных входных значений. В идеальной ситуации все варианты критических ситуаций должны быть описаны в требованиях на систему и тестировщику остается только придумывать конкретные проверки этих требований. Однако в реальности в результате тестирования обычно выявляется два типа проблем системы: 1. Несоответствие поведения системы требованиям 2. Неадекватное поведение системы в ситуациях, не предусмотренных требованиями. Отчеты об обоих типах проблем документируются и передаются разработчикам. При этом проблемы первого типа обычно вызывают изменение программного кода, гораздо реже – изменение требований. Изменение требований в данном случае может потребоваться ввиду их противоречивости (несколько разных требований описывают разные модели поведения системы в одной и той же самой ситуации) или некорректности (требования не соответствуют действительности). Проблемы второго типа однозначно требуют изменения требований ввиду их неполноты – в требованиях явно пропущена ситуация, приводящая к неадекватному поведению системы. При этом под неадекватным поведением может пониматься как полный крах системы, так и вообще любое поведение, не описанное в требованиях. Тестирование черного ящика называют также тестированием по требованиям, т.к. это единственный источник информации для построения тест-плана. 2.2.2. Стеклянный (белый) ящик При тестировании системы, как стеклянного ящика, тестировщик имеет доступ не только к требованиям на систему, ее входам и выходам, но и к ее внутренней структуре – видит ее программный код. Доступность программного кода расширяет возможности тестировщика тем, что он может видеть соответствие требований участкам программного кода и видеть тем самым – на весь ли программный код существуют требования. Программный код, для которого отсутствуют требования называют кодом, непокрытым требованиями. Такой код является потенциальным источником неадекватного поведения системы. Кроме того, прозрачность системы позволяет углубить анализ ее участков, вызывающих проблемы – часто одна проблема нейтрализует другую и они никогда не возникают одновременно. 2.2.3. Тестирование моделей Тестирование моделей находится несколько в стороне от классических методов верификации программного обеспечения. Прежде всего это связано с тем, что объект тестирования – не сама система, а ее модель, спроектированная формальными средствами. Если оставить в стороне вопросы проверки корректности и применимости самой модели (считается, что ее корректность и соответствие исходной системе может быть доказана формальными средствами), то тестировщик получает в свое распоряжение достаточно мощный инструмент анализа общей целостности системы. Работая с моделью можно создать такие ситуации, которые невозможно создать в тестовой лаборатории для реальной системы. Работая с моделью программного кода системы можно анализировать его свойства и такие параметры системы, как оптимальность алгоритмов или ее устойчивость. 28 Однако тестирование моделей не получило широкого распространения именно ввиду трудностей, возникающих при разработке формального описания поведения системы. Одно из немногих исключений – системы связи, алгоритмический и математический аппарат которых достаточно хорошо проработан. 2.2.4. Анализ программного кода (инспекции) Во многих ситуациях тестирование поведения системы в целом невозможно – отдельные участки программного кода могут никогда не выполняться, при этом они будут покрыты требованиями. Примером таких участков кода могут служить обработчики исключительных ситуаций. Если, например, два модуля передают друг другу числовые значения, и функции проверки корректности значений работают в обоих модулях, то функция проверки модуля-приемника никогда не будет активизирована, т.к. все ошибочные значения будут отсечены еще в передатчике. В этом случае выполняется ручной анализ программного кода на корректность, называемый также просмотрами или инспекциями кода. Если в результате инспекции выявляются проблемные участки, то информация об этом передается разработчикам для исправления наравне с результатами обычных тестов. 2.3. Тестовое окружение Основной объем тестирования практически любой сложной системы обычно выполняется в автоматическом режиме. Кроме того, тестируемая система обычно разбивается на отдельные модули, каждый из которых тестируется вначале отдельно от других, затем в комплексе. Это означает, что для выполнения тестирования необходимо создать некоторую среду, которая обеспечит запуск и выполнение тестируемого модуля, передаст ему входные данные, соберет реальные выходные данные, полученные в результате работы системы на заданных входных данных. После этого среда должна сравнить реальные выходные данные с ожидаемыми и на основании данного сравнения сделать вывод о соответствии поведения модуля заданному (Рис. 9). Тестовый драйвер Ожидаемые выходные данные Тестируемый Обработка Входные данные модуль результатов Реальные выходные данные Заглушки Рис. 9 Обобщенная схема среды тестирования Тестовое окружение также может использоваться для отчуждения отдельных модулей системы от всей системы. Разделение модулей системы на ранних этапах тестирования позволяет более точно локализовать проблемы, возникающие в их программном коде. Для поддержки работы модуля в отрыве от системы тестовое окружение должно моделировать поведение всех модулей, к функциям или данным которых обращается тестируемый модуль. 29

Верификация ПО Верификация является одной из форм тестирования. Она была разработана в 80-х гг. Кларком и Эмерсоном в США, а также независимо Квайлом и Сифакисом во Франции. Тестирование ПО – процесс выявления ошибок в ПО. Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно установить корректность функционирования анализируемой программы. Верификация (от лат. verus – истинный, facere - делать) – проверка, проверяемость, способ обоснования (подтверждения) каких-либо теоретических положений путем их сопоставления с опытными данными. Верификация – это подтверждение на основе предоставления объективных свидетельств того, что установленные требования были выполнены (по ГОСТ ИСО).

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

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

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

Метод проверки на модели По сравнению с другими подходами в формальной верификации программ, метод проверки на модели обладает двумя замечательными преимуществами: Он полностью автоматический, и его применение не требует от пользователя никаких особых знаний в таких математических дисциплинах, как логика и теория доказательства теорем. Всякий, кто может провести моделирование проектируемой системы, вполне способен осуществить и проверку этой системы. Если проектируемая система не обладает желаемым свойством, то результатом проверки на модели будет контрпример, который демонстрирует поведение системы, опровергающее это свойство. Эта ошибочная трасса даёт бесценную информацию для понимания причины ошибки, равно как и важный ключ к решению возникшей проблемы. Основной недостаток метода проверки на модели это "комбинаторный взрыв", который возникает, когда в системе переходы в некоторых компонентах выполняются параллельно. В 1987 г. К.МакМиллан показал, что, используя, символьное представление графа переходов, можно верифицировать очень сложные системы. Новое символьное представление было основано на упорядоченных двоичных разрешающих диаграммах (OBDD) Бриана.

Понятие верификации ПО БКУ В РКК «Энергия» нельзя использовать понятие верификация в полном объеме, так как при создании очень сложных систем невозможна реализация полной проверки, так как существуют временные и стоимостные ограничения. Показатель качества отработки и испытаний ПО БКУ КА

Отработка и испытания ПО БКУ. На предприятии РКК «Энергия» для отработки ПО БКУ используются НКО, работающие в реальном масштабе времени. Комплексная отработка и испытания ПО осуществляются группой интеграции и тестирования по специально разработанным программам и методикам испытаний (ПМИ) (тестовым сценариям). НКО-1 НКО-2 (реальная машина БЦВС) Используется для интеграции и последующей отладки ПО БКУ в объеме: выборочные проверки магистральных путей наиболее вероятных нештатных ситуаций; контроль интерфейса,т.е. проверка ПО в рамках: обмен массивами и словами данных; передача командных массивов; передача ТМ-данных; проверка распределения ресурсов (памяти, процессорного времени, каналов I/O). Используется для испытаний, по- другому верификации, ПО БКУ в объеме: отработка ПО БКУ в соответствии с планом полета (ПП) и режимами КА; проверка на соответствие ПО спецификации.

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

Тестовый сценарий Тестовый сценарий комплексной отладки строится на основе логической схемы процессов отладки. Сценарий должен отражать во времени возникновение событий и взаимосвязей между ними. Выбор дискретных моментов времени, в которые проводится оценка и принимаются управляющие воздействия, осуществляется в зависимости от специфики ПО и хода процесса реализации отладки. Тестовые сценарии пишут на языках, разработанных на предприятии. К таким языкам относятся: Д Диполь (использовался при создании СМ, ТГК и КА спутниковой системы связи «Ямал», также используется в КИС- контрольный испытательный стенд); L Lua (используется сейчас для МИМ1- малый исследовательский модуль); в внутренние тестовые языки.

Матрица прослеживаемости требований (НКО2) В матрице прослеживаемости требований представлен перечень всех требований, идентификатор программной единицы, наименование программной единицы, номер требований вышестоящего ТЗ и идентификатор теста, подтверждающего данные требования.

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

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

Критерии приемки ПМИ для каждого теста должна содержать требования, определяющие критерий приемки. Объем и глубина проверок считаются достаточными, при условии выполнения следующих требований полноты тестирования: ПО БКУ должно функционировать во всех возможных полетных конфигурациях; проверены все функциональные альтернативы в соответствии с внешней спецификацией; отработаны основные нештатные ситуации; проверены граничные значения. ПМИ для каждого теста в разделе "Критерий оценки" должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.

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

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

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

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

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

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

Метод установления правильности программ при помощи строгих средств известен как верификация программ.

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

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

спецификацию ввода-вывода (описание данных, не зависящих от процесса обработки);

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

спецификации и свойства структурных подкомпонентов программы;

спецификацию структур данных, зависящих от процесса обработки.

К такому методу доказательства правильности программ относится метод индуктивных утверждений , независимо сформулированный К. Флойдом и П. Науром.

Суть этого метода состоит в следующем:

1) формулируются входное и выходное утверждения: входное утверждение описывает все необходимые входные условия для программы (или программного фрагмента), выходное утверждение описывает ожидаемый результат;

2) предполагая истинным входное утверждение, строится промежуточное утверждение, которое выводится на основании семантики операторов, расположенных между входом и выходом (входным и выходным утверждениями); такое утверждение называется выведенным утверждением;

3) формулируется теорема (условия верификации):

из выведенного утверждения следует выходное утверждение;

4) доказывается теорема; доказательство свидетельствует о правильности программы (программного фрагмента).

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

Условия верификации можно построить и в обратном направлении, т.е., считая истинным выходное утверждение, получить входное утверждение и доказывать теорему:

из входного утверждения следует выведенное утверждение.

Такой метод построения условий верификации моделирует выполнение программы в обратном направлении. Другими словами, условия верификации должны отвечать на такой вопрос: если некоторое утверждение истинно после выполнения оператора программы, то, какое утверждение должно быть истинным перед оператором?

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

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

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

1) Построить структуру программы.

2) Выписать входное и выходное утверждения.

3) Сформулировать для всех циклов индуктивные утверждения.

4) Составить список выделенных путей.

5) Построить условия верификации.

6) Доказать условие верификации.

7) Доказать, что выполнение программы закончится.

Этот метод сравним с обычным процессом чтения текста программы (метод сквозного контроля). Различие заключается в степени формализации.

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

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

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

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

Перечисленные методы имеют одно общее свойство: они рассматривают программу как уже существующий объект и затем доказывают ее правильность.

Метод, который сформулировали К. Хоар и Э. Дейкстра основан на формальном выводе программ из математической постановки задачи.