Методы верификации информации реферат
Обновлено: 16.05.2024
Жизненный цикл программного обеспечения как интервал времени, начиная от идеи его создания с необходимым функционалом для решения задач до полного прекращения использования последней версии этой программы. Методы верификации: экспертиза и инспекция.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 17.12.2015 |
| Размер файла | 18,8 K |
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Методы верификации и тестирования программного обеспечения
Человеку свойственно ошибаться. Ошибки всегда были и всегда будут. В айтишной среде ходит шутка, что если программа с первого раза запустилась и сразу заработала, то нужно искать ошибку.
Вместе с развитием вычислительной техники, с её проникновением во все сферы жизни, растёт и количество ошибок в программах. Причём, рост ошибок непропорционален росту количества программ. Каждый год ряды программистов пополняются быдлокодерами (и имя им - легион), которые развивают сферу ошибок в геометрической прогрессии.
Но есть сферы, в которых ошибки программирования могут привести к самым печальным последствиям. Один из первых случаев, который мне удалось найти, - это космический аппарат Mariner 1, который был уничтожен 22 июля 1962 года на 293 секунде после старта из-за ошибки в программе бортового компьютера. Это хорошо, что тогда погибших не было.
А что будет, если бортовой компютер Boeing-747, с четырьмя сотнями пассажиров на борту, выбросит exception?.
В некоторой зарубежной литературе процессы верификации и тестирования отождествляются, а кое-где тестирование рассматривается, как один из методов верификации. Данную работу я буду выполнять в меру своего понимания, отдельно рассматривать процессы верификации и тестирования. Также, справедливости ради, затрону тему валидации ПО.
1. Определения
Жизненный цикл (ЖЦ) программного обеспечения. Под этим термином понимается интервал времени, начиная от идеи создания программного обеспечения с необходимым функционалом для решения определённых задач до полного прекращения использования последней версии этой программы.
Артефакты жизненного цикла программного обеспечения (ПО). Сюда входят самые разные информационные материалы, связанные с созданием ПО. Это техническое задание, описание архитектуры, исходный код, пользовательская документация и другие документы. Материалы, которые использовались при разработке, но не были зафиксированы в доступной форме (например, комментарии в коде и ругань разработчиков в чате) артефактами не являются.
2. Верификация
Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам. В частности, верификация проверяет соответствие между нормами стандартов, описанием требований (техническим заданием) к ПО, проектными решениями, исходным кодом, пользовательской документацией и функционированием самого ПО. Кроме того, проверяется, что требования, проектные решения, документация и код оформлены в соответствии с нормами и стандартами, принятыми в данной стране, отрасли и организации при разработке ПО, а также - что при их создании выполнялись все указанные в стандартах операции, в нужной последовательности. Обнаруживаемые при верификации ошибки и дефекты являются расхождениями или противоречиями между несколькими из перечисленных документов, между документами и реальной работой программы, между нормами стандартов и реальным процессами разработки и сопровождения ПО. При этом принятие решения о том, какой именно документ подлежит исправлению (может быть, и оба) является отдельной задачей.
Выше приведено официальное определение верификации. На самом деле, всё намного проще: верификация определяет, правильно ли мы делаем программу.
Таким образом, основными методами верификации являются экспертиза и инспекция.
программа экспертиза верификация
3. Валидация
В процессе валидации проверяется соответствие любых создаваемых или используемыв ходе разработки и сопровождения ПО артефактов нуждам и потребностям пользователей и заказчиков этого ПО, с учётом законов предметной области и ограничений контекста использования ПО.
И снова за множеством слов скрывается очень простая задача: в процессе валидации проверяется, нужен ли определённый функционал программы данным пользователям / заказчикам. Отвечает ли программный продукт пожеланиям заказчиков и конечных пользователей.
4. Тестирование
Тестирование - это процесс обнаружения ошибок в ПО путём исполнения кода программной системы на тестовых данных, сбора рабочих характеристик в динамике выполнения в конкретной операционной среде, выявления различных ошибок, дефектов, отказов и изъянов, вызванных нерегулярными и аномальными ситуациями или аварийным прекращением работы ПО.
Исторически первым видом тестирования была отладка.
Отладка - это проверка описания программного объекта на языке программирования с целью обнаружения в нём ошибок и последующее их устранение. Ошибки обнаруживаются компилятором при их синтаксическом контроле. После отладки проводится верификация по проверке правильности кода и валидация по проверке соответствия продукта заданным требованиям.
1. Статические методы тестирования
Статические методы используются при проведении инспекций и рассмотрении спецификаций компонентов без их выполнения. Техника статического анализа заключается в методическом просмотре и анализе структуры программ, а также в доказательстве их правильности. Статический анализ направлен на анализ документов, разработанных на всех этапах ЖЦ и заключается в инспекции исходного кода и сквозного контроля программы.
Инспекция ПО - это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программ) на процессах ЖЦ. Просмотры и инспекции результатов проектирования и соответствия их требованиям заказчика обеспечивают более высокое качество создаваемых программных систем.
2. Динамические методы тестирования
Методы тестирования по этому принципу используются для тестирования функций, реализованных в программе, путём проверки несоответствия между реальным поведением функций и ожидаемым поведением с учётом спецификаций требований. Во время подготовки к этому тестированию строятся таблицы условий, причинно-следственные графы 1 и области разбивки. Кроме того, подготавливаются тестовые наборы, учитывающие параметры и условия среды, которые влияют на поведение функций.
Данный метод позволяет исследовать внутреннюю структуру программы, причём обнаружение всех ошибок в программе является критерием исчерпывающего тестирования маршрутов потоков передач управления, среди которых рассматриваются:
- критерий покрытия операторов - набор тестов в совокупности должен обеспечить прохождение каждого оператора не менее одного раза;
- критерий тестирования ветвей (aka покрытие решений или покрытие переходов) - набор тестов в совокупности должен обеспечить прохождение каждой ветви или выхода хотя бы один раз.
3. Функциональное тестирование
Цель функционального тестирования - обнаружение несоответствий между реальным поведением реализованных функций и ожидаемым поведением в соответствии со спецификацией и исходными требованиями. Функциональноые тесты должны охватывать все реализованные функции с учётом наиболее вероятных типов ошибок. Тестовые сценарии, объединяющие отдельные тесты, ориентированы на проверку качества решения функциональных задач.
Функциональные тесты создаются по спецификациям функций, проектной информации и по тексту на языке программирования и применяются для определения полноты реализации функциональных задач и их соответствия исходным требованиям.
В задачи функционального тестирования входят:
- идентификация множества функциональных требований;
- идентификация внешних функций и построение последовательностей функций в соответствии с их использованием в программной системе;
- идентификация множества входных данных каждой функции и определение областей их изменения;
- построение тестовых наборов и сценариев тестирования функций;
- выявление и представление всех функциональных требований с помощью тестовых наборов и проведение тестирования ошибок в программе и при взаимодействии со средой.
Тесты, создаваемые по проектной информации, связаны со структурами данных, алгоритмами, интерфейсами между отдельными компонентами и применяются для тестирования компонентов и их интерфейсов. Основная цель - обеспечение полноты и согласованности реализованных функций и интерфейсов между ними.
5. Типы ошибок по стандарту ANSI/IEEE-729-83
Ошибка (error) - состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе её разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению.
Дефект (fault) в программе - следствие ошибок разработчика на любом из этапов разработки, которые могут содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может, быть обнаружен дефект или сбой.
Отказ (failure) - это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования. Отказ может быть результатом следующих причин:
- ошибочная спецификация или пропущенное требование, означающее, что спецификация точно не отражает того, что предполагал пользователь;
- спецификация может содержать требование, которое невозможно выполнить на данной аппаратуре и программном обеспечении;
- проект программы может содержать ошибки (например, база данных спроектирована без средств защиты от несанкционированного доступа пользователя, а требуется защита);
- программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или он реализован неполностью.
Все эти стандарты формулировались в 80-х годах прошлого столетия для космической промышленности США. В последующие годы они исправлялись и переиздавались, но разногласия и противоречия в документах оставались.
Вывод: структуру методов верификации, валидации и тестирования следует воспринимать, как условную.
Список используемой литературы
2. Кулямин В.В. Методы верификации программного обеспечения М.: Институт системного программирования, 2008
Подобные документы
Жизненный цикл программного обеспечения - непрерывный процесс, который начинается с принятия решения о необходимости создания ПО и заканчивается при полном изъятия его из эксплуатации. Подход к определению жизненного цикла ПО Райли, по Леману и по Боэму.
реферат [39,1 K], добавлен 11.01.2009
Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.
презентация [1,0 M], добавлен 11.05.2015
История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
курсовая работа [309,5 K], добавлен 16.12.2015
Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.
курсовая работа [112,2 K], добавлен 22.03.2015
Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
ГОСТ
Верификация информации – это проверка достоверности полученных данных.
Верификация информации
В каждом исследовании очень важным является этап обработки и анализ собранных сведений об изучаемом объекте или явлении. Среди процедур, которые обязательно необходимо выполнить на начальной стадии обработки информации, особое место занимает верификация. Верификация информации является необходимым условием успешного проведения исследования.
Существует несколько критериев надежности информации. Одним из них является адекватность информации изучаемым процессам. То есть собранная информация должна соответствовать реальному состоянию изучаемых явлений, объективным параметрам.
Еще один критерий достоверности информации – надежность. Надежность информации – это ее способность устойчиво воспроизводить именно те характеристики объекта исследования, которые имеют важное значение для исследователя.
Информация должна быть валидной, то есть измерять свойства или качества изучаемых процессов и явленийю
Основы достоверной информации формируются в процессе составления программы исследования.
Верификация информация может проводиться непосредственно в процессе сбора данных, либо опосредованно, когда контролируется уже полученная информация.
Существует несколько способов непосредственной верификации информации:
Существенным фактором, обеспечивающим достоверность информации, является контроль над ходом сбора информации.
Готовые работы на аналогичную тему
Фактчекинг в журналистике
Важным пунктом при написании журналистского (и любого другого) текста является фактчекинг.
Фактчекинг – это проверка фактов, являющаяся необходимым условием работы журналиста.
Обусловлено это во многом этическими принципами, такими, как объективность, независимость, беспристрастность, точность. Именно соблюдение этих принципов позволяет завоевать доверие аудитории и формирует репутацию медиа.
Фактчекинг является одним из направлений контролирующей журналистики. Он направлен на выявление несоответствия между полученной информацией и окружающей реальностью.
Фактчекинг можно разделить на пред-проверку и пост-проверку. Из текста перед публикацией убирают неточности, опечатки, фактоиды, что помогает избежать многих серьезных проблем. Результат пост-проверки это, как правило, еще одна внешняя публикация, в которой подробно описываются допущенные неточности. Это может быть опровержение в том же средстве массовой информации или аналитическая заметка в другом СМИ.
Одним из базовых правил фактчекинга является поиск первоисточника либо подтверждение информации из нескольких источников. Найти первоисточник – профессиональное требование для ответственного, серьезного журналиста. Источником может быть человек, от которого исходит первоначальное действие или высказывание, очевидец, либо человек, близко знакомый с первоисточником. Полезно проверить информацию из разных источников, спросить мнение экспертов и людей, разбирающихся в теме. Однако важно отделять источник от комментария.
Журналист должен узнать мнение противоположной стороны. Это правило является логическим продолжением первого правила. Материала теряет объективность, если все опрошенные источники придерживаются одного мнения, одной позиции. Поэтому нужно попытаться опросить все стороны.
Умение распознавать фейки является необходимым навыком журналиста и фактчекера.
Фейки – это не только осознанные симуляции и подделки. К ним можно отнести и технические ошибки, опечатки, которые, оказавшись в массовом сознании, становятся ложной реальностью.
Поэтому журналисту крайне важно проверять написание имен, званий и профессий людей, сверять адреса, названия, даты и т.д.
Социальные сети облегчают работу журналистов. Однако с ними следует быть особенно осторожными, и по каждому фату, полученному в них, следует найти еще два-три подтверждения.
Кроме того, в ходе фактчекинга следует разделять информацию и источник, то есть проверять и то, и другое. В социальных сетях не составляет никакого труда создать фиктивные аккаунты. Именно с них и идут потоки дезинформации. Поэтому невозможность доскональной проверки полученного из соцсетей контента ставит под угрозу доверие читателя.
Таким образом, журналист непременно должен придерживаться следующих принципов:
- Всегда делать собственную проверку информации. Не стоит опираться на информацию, полученную из других источников, так как уровень предвзятости других СМИ может быть разным;
- Не опираться на один источник информации. Источников информации должно быть несколько. При этом очень важна также и проверка фотографий.
- Работать с первоисточником;
- Вычисление фейков.
Международной фактчекинговой сетью был разработан ряд принципов для верификации информации в медиа:
При этом в стандартах IFCN данные как источник не рассматриваются, и фактчекинг представления и анализа данных не упоминается.
Фактчекинг – это не свод правил. В первую очередь, фактчекинг – это ответственность, неравнодушие, заинтересованность журналиста, его понимание медиаландшафта и знание сервисов и технологий.
Читайте также: