Методы верификации программ. Верификация сертифицируемого программного обеспечения. Автоматический статический анализ программ
Верификация ПО Верификация является одной из форм тестирования. Она была разработана в 80-х гг. Кларком и Эмерсоном в США, а также независимо Квайлом и Сифакисом во Франции. Тестирование ПО – процесс выявления ошибок в ПО. Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно установить корректность функционирования анализируемой программы. Верификация (от лат. verus – истинный, facere - делать) – проверка, проверяемость, способ обоснования (подтверждения) каких-либо теоретических положений путем их сопоставления с опытными данными. Верификация – это подтверждение на основе предоставления объективных свидетельств того, что установленные требования были выполнены (по ГОСТ ИСО).
Формальная верификация Формальная верификацияКак правило, большинством разработчиков программных систем для проверки правильности проекта практикуются методы имитационного моделирования и тестирования. Они довольно эффективны на самых ранних стадиях отладки, когда проектируемая система всё ещё изобилует ошибками, но результативность этих методов быстро снижается, как только система становится чище. Достойной альтернативой имитационному моделированию и тестированию являются методы формальной верификации. При имитационном моделировании и тестировании исследуются только некоторые из возможных сценариев поведения проектируемой системы, поэтому остаётся открытым вопрос о том, не содержится ли фатальная ошибка в незадействованных траекториях. Формальная верификация же обеспечивает исчерпывающий анализ всех возможных вариантов поведения системы.
Методы формальной верификации Автоматическое доказательство теорем – доказательство теорем, реализуемое программно. В основе лежит аппарат математической логики. Также использует идеи теории искусственного интеллекта. Процесс доказательства основывается на логике высказываний и предикатов. Проверка моделей. Метод автоматической верификации параллельных систем с конечным числом состояний. Символьное выполнение (графы). Абстрактная интерпретация.
Этапы формальной верификации на модели Этапы формальной верификации на модели Моделирование. Для проектируемой системы необходимо построить её абстрактную модель (например, конечную систему переходов), приемлемую для инструментальных средств верификации моделей программы. Спецификация. Эта задача состоит в формулировании свойств, которыми должна обладать проектируемая система. Определить, охватывает ли заданная спецификация все свойства, которыми должна обладать система, невозможно. Для аппаратуры и программного обеспечения, как правило, применяют динамические логики, временные логики и их варианты с неподвижными точками. Вычисления алгоритмов. Результатом вычислений алгоритма глобальной проверки на модели является множество состояний модели, в которых спецификация выполняется, а алгоритм локальной проверки на модели строит в качестве контрпримера некоторое вычисление (ошибочную трассу), которое показывает, почему формула не выполняется. Контрпример особенно важен для поиска тонких ошибок в сложных системах переходов.
Метод проверки на модели По сравнению с другими подходами в формальной верификации программ, метод проверки на модели обладает двумя замечательными преимуществами: Он полностью автоматический, и его применение не требует от пользователя никаких особых знаний в таких математических дисциплинах, как логика и теория доказательства теорем. Всякий, кто может провести моделирование проектируемой системы, вполне способен осуществить и проверку этой системы. Если проектируемая система не обладает желаемым свойством, то результатом проверки на модели будет контрпример, который демонстрирует поведение системы, опровергающее это свойство. Эта ошибочная трасса даёт бесценную информацию для понимания причины ошибки, равно как и важный ключ к решению возникшей проблемы. Основной недостаток метода проверки на модели это "комбинаторный взрыв", который возникает, когда в системе переходы в некоторых компонентах выполняются параллельно. В 1987 г. К.МакМиллан показал, что, используя, символьное представление графа переходов, можно верифицировать очень сложные системы. Новое символьное представление было основано на упорядоченных двоичных разрешающих диаграммах (OBDD) Бриана.
Понятие верификации ПО БКУ В РКК «Энергия» нельзя использовать понятие верификация в полном объеме, так как при создании очень сложных систем невозможна реализация полной проверки, так как существуют временные и стоимостные ограничения. Показатель качества отработки и испытаний ПО БКУ КА
Отработка и испытания ПО БКУ. На предприятии РКК «Энергия» для отработки ПО БКУ используются НКО, работающие в реальном масштабе времени. Комплексная отработка и испытания ПО осуществляются группой интеграции и тестирования по специально разработанным программам и методикам испытаний (ПМИ) (тестовым сценариям). НКО-1 НКО-2 (реальная машина БЦВС) Используется для интеграции и последующей отладки ПО БКУ в объеме: выборочные проверки магистральных путей наиболее вероятных нештатных ситуаций; контроль интерфейса,т.е. проверка ПО в рамках: обмен массивами и словами данных; передача командных массивов; передача ТМ-данных; проверка распределения ресурсов (памяти, процессорного времени, каналов I/O). Используется для испытаний, по- другому верификации, ПО БКУ в объеме: отработка ПО БКУ в соответствии с планом полета (ПП) и режимами КА; проверка на соответствие ПО спецификации.
Программа методика испытаний Для проведения проверки ПО разрабатываются программы методики испытаний (ПМИ). ПМИ для каждого сценария должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.
Тестовый сценарий Тестовый сценарий комплексной отладки строится на основе логической схемы процессов отладки. Сценарий должен отражать во времени возникновение событий и взаимосвязей между ними. Выбор дискретных моментов времени, в которые проводится оценка и принимаются управляющие воздействия, осуществляется в зависимости от специфики ПО и хода процесса реализации отладки. Тестовые сценарии пишут на языках, разработанных на предприятии. К таким языкам относятся: Д Диполь (использовался при создании СМ, ТГК и КА спутниковой системы связи «Ямал», также используется в КИС- контрольный испытательный стенд); L Lua (используется сейчас для МИМ1- малый исследовательский модуль); в внутренние тестовые языки.
Матрица прослеживаемости требований (НКО2) В матрице прослеживаемости требований представлен перечень всех требований, идентификатор программной единицы, наименование программной единицы, номер требований вышестоящего ТЗ и идентификатор теста, подтверждающего данные требования.
Протокол испытаний Протокол испытаний – это текстовый файл, содержащий в хронологическом порядке отклики системы на входные воздействия в ходе проведения испытаний. Протокол содержит московское время события, время относительно начала теста, значения устанавливаемых параметров и примечания, содержащие комментарии о событиях.
ТМ-архив Архив телеметрии – это файл, содержащий в закодированном виде набор телеметрических сообщений, полученных от системы в ходе проведения испытаний. Архив содержит бортовое время событий и значения телеметрических параметров. Программа Telemet2 позволяет представить архив телеметрии в виде текстового файла с комментариями и значениями параметров в десятичном и шестнадцатеричном виде.
Критерии приемки ПМИ для каждого теста должна содержать требования, определяющие критерий приемки. Объем и глубина проверок считаются достаточными, при условии выполнения следующих требований полноты тестирования: ПО БКУ должно функционировать во всех возможных полетных конфигурациях; проверены все функциональные альтернативы в соответствии с внешней спецификацией; отработаны основные нештатные ситуации; проверены граничные значения. ПМИ для каждого теста в разделе "Критерий оценки" должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на 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
Информатизация России. Рынок программных средств. Основные задачи стандартизации, сертификации и лицензирования в сфере информатизации. Совокупность инженерных методов и средств создания программного обеспечения. Жизненный цикл программного обеспечения.
Заказчик (заявитель) . Эта роль принадлежит представителю организации, заказавшей разрабатываемую систему. Обычно заявитель ограничен в своем взаимодействии и общается только с менеджерами проекта и специалистом по сертификации или внедрению. Обычно заказчик имеет право изменять требования к продукту (только во взаимодействии с менеджерами), читать проектную и сертификационную документацию, затрагивающую нетехнические особенности разрабатываемой системы.
Менеджер проекта . Эта роль обеспечивает коммуникационный канал между заказчиком и проектной группой. Менеджер продукта управляет ожиданиями заказчика, разрабатывает и поддерживает бизнес- контекст проекта. Его работа не связана напрямую с продажей, он сфокусирован на продукте, его задача - определить и обеспечить требования заказчика . Менеджер проекта имеет право изменять требования к продукту и финальную документацию на продукт.
Менеджер программы . Эта роль управляет коммуникациями и взаимоотношениями в проектной группе, является в некотором роде координатором, разрабатывает функциональные спецификации и управляет ими, ведет график проекта и отчитывается по состоянию проекта, инициирует принятие критичных для хода проекта решений.
Тестирование - процесс выполнения программы с целью обнаружения ошибки.
Тестовые данные - входы, которые используются для проверки системы.
Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований.
Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.
Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.
Ошибка - действие программиста на этапе разработки, приводящее к тому, что в программном обеспечении содержится внутренний дефект, который в процессе работы программы может привести к неправильному результату.
Отказ - непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней.
Таким образом, в процессе тестирования программного обеспечения, как правило, проверяют следующее.
Как известно, универсальные вычислительные машины могут быть запрограммированы для решения самых разнородных задач - в этом заключается одна из основных их особенностей, имеющая огромную практическую ценность. Один и тот же компьютер, в зависимости от того, какая программа находится у него в памяти, способен осуществлять арифметические вычисления, доказывать теоремы и редактировать тексты, управлять ходом эксперимента и создавать проект автомобиля будущего, играть в шахматы и обучать иностранному языку. Однако успешное решение всех этих и многих других задач возможно лишь при том условии, что компьютерные программы не содержат ошибок, которые способны привести к неверным результатам.
Можно сказать, что требование отсутствия ошибок в программном обеспечении совершенно естественно и не нуждается в обосновании. Но как убедиться в том, что ошибки, в самом деле, отсутствуют? Вопрос не так прост, как может показаться на первый взгляд.
К неформальным методам доказательства правильности программ относят отладку и тестирование , которые являются необходимой составляющей на всех этапах процесса программирования, хотя и не решают полностью проблемы правильности. Существенные ошибки легко найти, если использовать соответствующие приемы отладки (контрольные распечатки, трассировки).
Тестирование – процесс выполнения программы с намерением найти ошибку, а не подтвердить правильность программы. Суть его сводится к следующему. Подлежащую проверке программу неоднократно запускают с теми входными данными, относительно которых результат известен заранее. Затем сравнивают полученный машиной результат с ожидаемым. Если во всех случаях тестирования налицо совпадение этих результатов, появляется некоторая уверенность в том, что и последующие вычисления не приведут к ошибочному итогу, т.е. что исходная программа работает правильно.
Мы уже обсуждали понятие правильности программы с точки зрения отсутствия в ней ошибок. С интуитивной точки зрения программа будет правильной, если в результате ее выполнения будет достигнут результат, с целью получения которого и была написана программа. Сам по себе факт безаварийного завершения программы еще ни о чем не говорит: вполне возможно, что программа в действительности делает совсем не то, что было задумано. Ошибки такого рода могут возникать по различным причинам.
В дальнейшем мы будем предполагать, что обсуждаемые программы не содержат синтаксических ошибок, поэтому при обосновании их правильности внимание будет обращаться только на содержательную сторону дела, связанную с вопросом о том, достигается ли при помощи данной программы данная конкретная цель. Целью можно считать поиск решения поставленной задачи, а программу рассматривать как способ ее решения. Программа будет правильной , если она решит сформулированную задачу.
Метод установления правильности программ при помощи строгих средств известен как верификация программ.
В отличие от тестирования программ, где анализируются свойства отдельных процессов выполнения программы, верификация имеет дело со свойствами программ.
В основе метода верификации лежит предположение о том, что существует программная документация, соответствие которой требуется доказать. Документация должна содержать:
спецификацию ввода-вывода (описание данных, не зависящих от процесса обработки);
свойства отношений между элементами векторов состояний в выбранных точках программы;
спецификации и свойства структурных подкомпонентов программы;
спецификацию структур данных, зависящих от процесса обработки.
К такому методу доказательства правильности программ относится метод индуктивных утверждений , независимо сформулированный К. Флойдом и П. Науром.
Суть этого метода состоит в следующем:
1) формулируются входное и выходное утверждения: входное утверждение описывает все необходимые входные условия для программы (или программного фрагмента), выходное утверждение описывает ожидаемый результат;
2) предполагая истинным входное утверждение, строится промежуточное утверждение, которое выводится на основании семантики операторов, расположенных между входом и выходом (входным и выходным утверждениями); такое утверждение называется выведенным утверждением;
3) формулируется теорема (условия верификации):
из выведенного утверждения следует выходное утверждение;
4) доказывается теорема; доказательство свидетельствует о правильности программы (программного фрагмента).
Доказательство проводится при помощи хорошо разработанных математических методов, использующих исчисление предикатов первого порядка.
Условия верификации можно построить и в обратном направлении, т.е., считая истинным выходное утверждение, получить входное утверждение и доказывать теорему:
из входного утверждения следует выведенное утверждение.
Такой метод построения условий верификации моделирует выполнение программы в обратном направлении. Другими словами, условия верификации должны отвечать на такой вопрос: если некоторое утверждение истинно после выполнения оператора программы, то, какое утверждение должно быть истинным перед оператором?
Построение индуктивных утверждений помогает формализовать интуитивные представления о логике программы. Оно и является самым сложным в процессе доказательства правильности программы. Это объясняется, во-первых, тем, что необходимо описать все содержательные условия, и, во-вторых, тем, что необходимо аксиоматическое описание семантики языка программирования.
Важным шагом в процессе доказательства является доказательство завершения выполнения программы, для чего бывает достаточно неформальных рассуждений.
Таким образом, алгоритм доказательства правильности программы методом индуктивных утверждений представляется в следующем виде:
1) Построить структуру программы.
2) Выписать входное и выходное утверждения.
3) Сформулировать для всех циклов индуктивные утверждения.
4) Составить список выделенных путей.
5) Построить условия верификации.
6) Доказать условие верификации.
7) Доказать, что выполнение программы закончится.
Этот метод сравним с обычным процессом чтения текста программы (метод сквозного контроля). Различие заключается в степени формализации.
Преимущество верификации состоит в том, что процесс доказательства настолько формализуем, что он может выполняться на вычислительной машине. В этом направлении в восьмидесятые годы проводились исследования, даже создавались автоматизированные диалоговые системы, но они не нашли практического применения.
Для автоматизированной диалоговой системы программист должен задать индуктивные утверждения на языке исчисления предикатов. Синтаксис и семантика языка программирования должны храниться в системе в виде аксиом на языке исчисления предикатов. Система должна определять пути в программе и строить условия верификации.
Основной компонент доказывающей системы - это построитель условий верификации, содержащий операции манипулирования предикатами, алгоритмы интерпретации операторов программы. Вторым компонентом системы является подсистема доказательства теорем.
Отметим трудности, связанные с методом индуктивных утверждений. Трудно построить «множество основных аксиом, достаточно ограниченное для того, чтобы избежать противоречий, но достаточно богатое для того, чтобы служить отправной точкой для доказательства утверждений о программах» (Э. Дейкстра). Вторая трудность - семантическая, заключающаяся в формировании самих утверждений, подлежащих доказательству. Если задача, для которой пишется программа, не имеет строгого математического описания, то для нее сложнее сформулировать условия верификации.
Перечисленные методы имеют одно общее свойство: они рассматривают программу как уже существующий объект и затем доказывают ее правильность.
Метод, который сформулировали К. Хоар и Э. Дейкстра основан на формальном выводе программ из математической постановки задачи.