Что такое валидация файлов

Обновлено: 05.07.2024

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

Что такое валидность?

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

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

Валидация - что это?

Простыми словами, валидация - это процесс проверки кода и приведения его в соответствие с выбранным доктайпом (DTD).

Как проверяется валидность?

Проверка на наличие синтаксических ошибок:
Пример c habrahabr.ru/post/101985 :
<foo bar="baz"> является корректным синтаксисом, несмотря на то, что <foo> является недопустимым HTML-тэгом
Так что проверка синтаксиса является минимально полезной для написания хорошего HTML-кода.
Проверка вложенности тэгов:
В HTML документе тэги должны быть закрыты в обратном порядке относительно их открытия. Эта проверка выявляет незакрытые или неправильно закрытые теги.
Валидация html согласно DTD:
Проверка того, насколько код соответствует указанному DTD - Document Type Definition (доктайпу). Она включает проверку названий тэгов, атрибутов, и «встраивания» тэгов (тэги одного типа внутри тэгов другого типа).
Проверка на наличие посторонних элементов:
Она обнаружит все, что есть в коде, но отсутствует в доктайпе.
Например, пользовательские тэги и атрибуты.

более удобным и быстрым - пользовательские атрибуты для Javascrip/AJAX или
SЕО оптимизированным - разметка ARIA.

Понятно, что в валидности ради валидности нет никакого смысла.
Как правило, опытные верстальщики придерживаются следующих правил:
- В коде не должно быть грубых ошибок.
- Незначительные можно допустить, но только по обоснованным причинам.
В отношении допустимости ошибок валидации html/CSS:

Ошибки валидации (ОВ) можно разделить на группы:

В сложных темах есть:

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

Невозможность восстановиться после сбоя. Не всегда программа способна «вернуть всё назад». Возможно, в процессе работы программа выполнила какие-то необратимые действия — удалила файл, отправила данные по сети, напечатала что-то на принтер, запустила резец станка и он частично произвёл обработку заготовки детали. Но даже если восстановление в принципе возможно, алгоритм восстановления может тоже содержать ошибки, и это иногда приводит к совсем печальным последствиям.
Дополнительная нагрузка на систему. Восстановление после сбоя — это лишняя работа. Вся работа, которая была выполнена до момента сбоя — тоже лишняя. А это означает дополнительную нагрузку на систему, которой можно избежать, если заранее проверить данные. С другой стороны, валидация — это тоже дополнительная нагрузка, причём восстановление приходится делать лишь изредка, а проверку надо выполнять каждый раз, так что ещё неизвестно, что выгоднее.
Инъекции не вызывают сбоев. Один из основных способов эксплуатации уязвимостей в программах заключается в том, чтобы «обмануть» валидаторы, то есть передать данные, которые валидатор признаёт корректными, но при этом они интерпретируются непредусмотренным образом, так что злоумышленник может получить несанкционированный доступ к данным или некоторым возможностям программы, либо способен разрушить данные или программу. Если валидации нет вообще, задача злоумышленника максимально упрощается.
Сложность идентификации причины проблемы. Если исключение вылетело откуда-то из глубины программы, определить причины его возникновения не так-то просто. И даже если это возможно, может оказаться нелегко объяснить пользователю, что сбой вызван данными, которые он ввёл некоторое время назад в каком-то совершенно другом месте программы. А если проверка выполнена немедленно после ввода данных, никаких сложностей с идентификацией источника проблемы не возникает.

Где и когда выполнять валидацию данных?

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

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

Как выполнять валидацию данных?

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

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

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

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

Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.

Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.

Тестирование валидаторов

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

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

Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:

Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:

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

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

Заключение

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

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

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

Что такое верификация и чем она отличается от валидации?

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

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

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

Слово валидация (от английского validation) ближе всего к понятию аттестация, а по сути означает комплексную проверку изделия требованиям заказчика им же самим. Если собирали велосипед, то он будет валидирован после того, как на нем прокатятся представители заказчика и признают его удовлетворяющим своим «хотелкам».

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

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

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

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

Другими словами. Верификация — это подтверждение того, что задание было выполнено в полном соответствии с требованиями заказчика. А валидация — это проверка того, так ли как надо результирующее изделие (продукт) функционирует на практике. Может возникнуть ситуация, когда ТЗ выполнено, а изделие не работает или работает не так как надо. Поэтому процесс валидации является более всеобъемлющим и показательным, чем верификации (штамп «валидировано» ставится поверх штампа «верифицировано», если так можно выразиться).

Валидация и верификация в онлайн-сервисах интернета?

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

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

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

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

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

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

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

Валидация аккаунта Вконтатке и Одноклассниках — у вас вирус

Во-первых, не вестись на все эти уловки. Кто вас попросил о валидации — администрация социальной сети или злоумышленник, который с помощью вируса подменил страницу социальной сети? Как проверить? Довольно просто.

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

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

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

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

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

Эта статья относится к рубрикам:

Комментарии и отзывы (5)

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

Еще одно прозападное слово, засоряющее Русский язык. Можно использовать аналогичное слово: Подтверждение. Ведь согласитесь, звучит намного лучше, чем какая-то «верификация».

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

В управлении программным обеспечением проекта , тестирования программного обеспечения и программного обеспечения , верификации и валидации ( V & V ) представляет собой процесс проверки того, что система программного обеспечения соответствует техническим требованиям и требованиям , так что она выполняет свою намеченную цель. Это также может называться контролем качества программного обеспечения . Обычно это входит в обязанности тестировщиков программного обеспечения в рамках жизненного цикла разработки программного обеспечения . Проще говоря, проверка программного обеспечения - это: «Предполагая, что мы должны создать X, достигает ли наше программное обеспечение своих целей без каких-либо ошибок или пробелов?» С другой стороны, проверка программного обеспечения - это: «Был ли X тем, что мы должны были создать? Соответствует ли X требованиям высокого уровня?»

СОДЕРЖАНИЕ

Определения

Верификация и валидация - это не одно и то же, хотя их часто путают. Бем лаконично выразил разницу как

Проверка: правильно ли мы создаем продукт?
Валидация: создаем ли мы правильный продукт?

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

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

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

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

Проверка программного обеспечения

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

Проверка артефакта или спецификации

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

Примеры проверки артефактов:

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

Проверка программного обеспечения

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

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

Проверка артефакта или спецификации

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

Примеры проверки артефактов:

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

Проверка и проверка

Проверка программного обеспечения: процесс оценки программного обеспечения во время или в конце процесса разработки, чтобы определить, удовлетворяет ли оно указанным требованиям. [IEEE-STD-610]
Проверка программного обеспечения: процесс оценки программного обеспечения для определения того, удовлетворяют ли продукты данной фазы разработки условиям, установленным в начале этой фазы. [IEEE-STD-610]

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

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

В этой статье используется строгое или узкое определение верификации.

С точки зрения тестирования:

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

Связанные понятия

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

В сообществе моделирования и моделирования (M&S) определения верификации, валидации и аккредитации аналогичны:

M&S Verification - это процесс определения того, что компьютерная модель , имитация или объединение моделей и реализаций имитаций и связанные с ними данные точно представляют концептуальное описание и спецификации разработчика.
Проверка M&S - это процесс определения степени, в которой модель, имитация или объединение моделей и имитаций и связанных с ними данных являются точными представлениями реального мира с точки зрения предполагаемого использования.
Аккредитация - это официальное свидетельство того, что модель или симуляция приемлемы для использования в определенных целях.

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

V&V методы

Формальный

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

Независимый

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

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

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

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

История

ISVV является производным от применения IV&V (независимой проверки и валидации) к программному обеспечению. Раннее приложение ISVV (известное сегодня) восходит к началу 1970-х годов, когда армия США спонсировала первую значительную программу, связанную с IV&V для системы противоракетной обороны Safeguard . Другой пример - программа НАСА IV&V, созданная в 1993 году.

К концу 1970-х годов IV&V быстро стал популярным. Постоянное увеличение сложности, размера и важности программного обеспечения привело к увеличению спроса на IV&V, применяемые к программному обеспечению.

Между тем, IV&V (и ISVV для программных систем) консолидировались и теперь широко используются такими организациями, как Министерство обороны , FAA , NASA и ESA . IV&V упоминается в DO-178B , ISO / IEC 12207 и формализовано в IEEE 1012 .

В ЕКА

Первоначально в 2004–2005 годах европейский консорциум под руководством Европейского космического агентства в составе DNV , Critical Software SA , Terma и CODA SciSys plc создал первую версию руководства, посвященного ISVV, под названием «Руководство ESA по независимой проверке и проверке. "при поддержке других организаций. В этом руководстве описаны методологии, применимые ко всем этапам разработки программного обеспечения в том, что касается ISVV.

В 2008 году Европейское космическое агентство выпустило вторую версию, полученную от многих различных заинтересованных сторон European Space ISVV.

Методология

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

Планирование

Планирование деятельности ISVV
Анализ критичности системы: идентификация критических компонентов с помощью набора действий RAMS ( соотношение цены и качества )
Выбор подходящих методов и инструментов

Проверка требований

Проверка на: полноту, правильность, тестируемость

Проверка дизайна

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

Проверка кода

Проверка на: полноту, правильность, непротиворечивость
Анализ метрик кода
Проверка соответствия стандартам кодирования

Проверка

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

Нормативно-правовая база

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

Читайте также: