валидация информации что это такое
Валидация данных
Привет, Хабр! В преддверии старта курса «Архитектор сетей» предлагаем прочитать перевод полезной статьи.
Оптимизация модели данных и удаление повторений — это, конечно, здорово, но каким образом мы можем убедиться, что работаем с валидной моделью данных?
На этот вопрос легко ответить в рамках традиционной реализации IPAM/CMDB с использованием внутренней базы данных и пользовательской логики обработки данных, предлагающей REST API, графический интерфейс или и то, и другое. Пользовательская логика обработки данных проверяет данные перед их вводом в базу данных, и, таким образом мы получаем гарантию того, что база данных содержит синтаксически и семантически допустимые данные.
В более простом решении, использующем текстовые файлы для хранения сетевой модели данных (также известной как источник истины или source-of-truth), сложно выполнить тщательную проверку каждой транзакции, тем более, если для изменения этих файлов вы используете текстовый редактор. В этих случаях вам нужно писать собственный конвейер валидации, используя инструменты, которые проверяют:
синтаксис текстового файла;
соответствие схеме модели данных;
Используя нашу последнюю модель данных с per-link префиксами, которые хранятся как куча Ansible host_vars файлов и network.yml файл, конвейер валидации должен проверить что:
Все файлы соответствуют синтаксису YAML (чтобы сделать это, вы можете использовать такие инструменты как yamllint );
Факты о хостах содержат значения hostname и bgp_as для каждого хоста;
Core ссылки содержат prefix и как минимум два других значения;
Edge ссылки содержат одно значение, которое является словарем (или объектом, если вы предпочитаете терминологию JSON) с одним значением.
Зачастую проверить ссылочную целостность с помощью языка моделирования данных бывает сложно. Для этого вам, возможно, придется написать свое собственное программное решение, но, по крайней мере, вы можете спихнуть скучную рутину проверки структур и форматов данных на стороннее решение.
Валидация данных хоста
Из полученной JSON структуры данных нам нужно извлечь только переменные хоста, и jq идеально подходит для этой работы:
Валидация сетевой модели данных
Для проверки network.yml файла мы будем использовать аналогичный подход:
Convert YAML file into JSON format with yq
Преобразуем YAML файл в формат JSON с помощью yq
Run jsonschema on the resulting JSON file
Запустим jsonschema на полученном JSON файле
Как упоминалось выше, JSON Schema позволяет нам проверять грамматику модели данных, а ссылочную целостность — нет. Например:
Мы не можем проверить, валидны ли имена хостов, указанные для core или edge ссылок.
Хотя мы можем проверить формат имени интерфейса, у нас нет средств, позволяющих проверить, обладают ли устройства интерфейсами, которые мы хотим использовать, без подключения к сетевым устройствам или извлечения данных из системы управления сетью.
Пару слов о JSON Schema
Языки моделирования данных не для слабонервных, и JSON Schema не исключение. Замысловатая подача спецификации тоже не особо облегчает жизнь (мне было интереснее читать стандарты ISO или IEEE). К счастью, онлайн-книга Разбираемся с JSON Schema довольно хорошо объясняет все тонкости.
Просто чтобы вы прочувствовали, что такое JSON Schema: вот документ JSON, описывающий ожидаемую структуру данных переменных хоста, полученный из инвентаря Ansible:
Вот что можно сказать об этой схеме:
Она описывает инвентарные данные Ansible (Ansible inventory data);
Она содержит определения дополнительных схем (см. ниже).
Элемент верхнего уровня — это объект (словарь) с некоторыми свойствами (мы знаем, что это инвентарные имена хостов), и каждое свойство должно соответствовать схеме router
Минимальное количество свойств — одно (хотя бы один хост в файле инвентаризации).
Определение схемы router находится в свойстве definitions :
Согласно этой схеме роутер (если быть точнее, факты хоста Ansible, описывающие роутер) — это объект со следующими свойствами:
Числовым свойством bgpas , которое должно быть от 1 до 65535;
Строковым свойством hostname
Оба свойства являются обязательными, и в объекте не должно быть других свойств.
Закатываем рукава
JSON схемы хоста и сети, а также исходный код скрипта проверки доступны на GitHub. Не стесняйтесь клонировать репозиторий, менять host_vars файлы или сетевую модель данных и запускать скрипт проверки в своих целях.
Вам также может захотеться исследовать JSON Schema побольше, в частности:
выяснить, что делает JSON схема network ;
добавить необязательное свойство description в модель данных роутера;
Вам понадобятся следующие инструменты:
Больше о валидации данных
Мы рассматриваем валидацию данных и конвейеры CI/CD более подробно в части Validation, Error Handling and Unit Tests нашего онлайн-курса Building Network Automation Solutions.
Дополнительная информация
Чтобы узнать больше об использовании моделей данных в решениях для автоматизации сети, ознакомьтесь с модулем 3 нашего онлайн-курса Building Network Automation Solutions.
Далее в программе
Data Model Hierarchy
Иерархия моделей данных
Подробнее о курсе «Архитектор сетей». Посмотреть запись открытого урока на тему «Overlay. Что это такое и зачем необходимо» можно здесь.
Такие слова, как «верификация» и «валидация», довольно часто можно услышать в различных телепередачах, но мало кто из людей знает, что они означают. Их звучание довольно сходное, и те, кто произносят эти слова, часто сами путаются в них. Из контекста слушатель догадывается, что дело и там, и там связано с проверкой чего-то. Что же в действительности означают эти слова, что у них общего и чем отличается валидация от верификации?
Происхождение термина
Философский и научный термин «верификация» пришел в наш язык из латыни (от лат. verus — «истинный», и facere — «делать»). Он означает проверку какого-либо предположения на соответствие заранее сформулированным требованиям, стандартам или спецификациям. Содержание термина существенно меняется в зависимости от контекста.
Верификация в науке
Для этого проводятся серии натурных или мысленных экспериментов, и если их результаты подтверждают гипотезу, она считается верифицированной и становится научной концепцией или даже теорией.
Верификация на производстве товаров и в предоставлении услуг
Наиболее широко процесс начал использоваться при производстве программного обеспечения и разработке сложных технических систем. Из этих отраслей метод распространился и в другие отрасли.
Подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены. (ИСО 9000:2000)
Производственная верификация заключается в сборе документальных доказательств того, что проектируемый и производимый продукт (или услуга) соответствует всем требованиям технического задания, производственных спецификаций и стандартов отрасли на каждом этапе производственного цикла. В случае сложных и продолжительных производственных процессов важно не откладывать сбор таких свидетельств на ночь перед отгрузкой продукции.
В производстве сложных систем и программных продуктов применяют следующие методы верификации:
Тестирование и анализ документов представляют собой наиболее широко и часто используемые подходы. Сопоставление научно-технической и проектной документации также весьма популярно, однако для многих передовых разработок трудно подобрать аналогичный проект.
Проведение альтернативных расчетов по независимому алгоритму позволяет получить базу для оценки точности расчетов, выполненных по проверяемому алгоритму. Один из наиболее часто используемых способов альтернативных расчетов – это калькулятор.
Верификация субъекта услуги
В этом случае происходит идентификация личности пользователя, какого-либо сетевого сервиса, например Twitter. В данном случае это означает проверку подлинности пользователя и подтверждения его личности. Аналогичные идентификации проводят и другие социальные медиа, сетевые торговые площадки и платежные системы.
Верификация заемщика в банке заключается не только в установлении его личности, но и в проверке его соответствия требованиям банка к пользователю данного продукта, таких как:
В русскоязычных медиа термин иногда используется в значении «проверка публикуемых фактов». Это чисто русский новояз, весь мир пользуется простым термином “fact cheking”, или «проверка фактов».
Валидация
Валидация на транспорте
Валидатором (от англ. valid – «действительный, правомерный») называют также специальное приспособление, с помощью которого проводят проверку электронных проездных документов. Таким образом определяют правомочность посадки пассажира в салон общественного транспорта. Часто валидатор совмещают с турникетом. Это позволяет экономить значительные средства на организации и проведении контроля оплаты проезда пассажирами. Применяют такие устройства также и для контроля прохода сотрудников на территорию предприятия.
Валидация в системе управления качеством
Формулировка в стандарте ИСО несколько невнятная и слишком похожа на определение «верификации».
«Валидация — подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены».
Основное отличие
В чем основное отличие верификации и валидации?
Верификация – обязательный внутренний процесс проверки изделия или услуги на соответствие стандартам и спецификациям.
«-К пуговицам претензии есть?
-К лацканам претензии есть?
К рукавам претензии есть?
«-Костюм можно носить?
Основная задача верификации и валидации
Основная задача верификации состоит в том, что она подтверждает тот факт, что удалось произвести правильный продукт, абстрактно соответствующий всем утвержденным стандартам и спецификациям. Основная задача валидации заключается в том, чтобы подтвердить, что продукт может успешно использоваться конкретным потребителем в вот таких-то конкретных условиях.
Верификация проводится всегда, а вот валидация может и не проводиться.
Примеры верификации и валидации
Завод по производству лекарственных препаратов всегда будет проверять, соответствуют ли они техническим условиям и стандартам (верификация), а вот проверку, подойдут ли эти препараты определенному пациенту с таким-то набором симптомов, не будет (валидация).
Компания выпускает ботинки, предназначенные для загородных прогулок. Эти ботинки полностью соответствуют техническим условиям, и это проверяется для каждой пары (верификация). А вот подойдет ли эта обувь для высокогорных восхождений, предстоит определять отдельно (валидация).
Еще один пример, относящийся практически к любому предприятию. Отдел технического контроля осуществляет верификацию, а аудиторы проводят валидацию.
Эссе о валидации данных
Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Как выполнять валидацию данных?
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
Валидация — что это простыми словами? Чем отличается валидация от верификации? + ПРАКТИЧЕСКИЙ СОВЕТ
Здравствуйте, дорогие читатели! Добро пожаловать на блог!
Валидация — что это простыми словами? Чем отличается валидация от верификации? Ответы на эти вопросы — в статье.
Многие слова «валидация» и «верификация» считают синонимами. Но это не так. Разница есть, но она очень тонкая. Давайте разбираться.
Валидация и верификация — что это простыми словами?
Справедливости ради надо сказать, что в разных областях деятельности (в банках, в платежных системах, в интернете), в разных отраслях производства эти термины используются по-разному. Я решила привести здесь определение валидации и верификации из стандарта ISO 9000.
Мы видим, что определения совпадают в значительной части, но не полностью. Однако, несмотря на такое большое совпадение валидация и верификация — это разные действия.
Чтобы проще было понять, что такое валидация, давайте сначала разберемся, чем валидация отличается от верификации.
Чем отличается валидация от верификации?
Итак, что такое верификация? Более детально можете узнать из этой статьи, но здесь скажем коротко, что слово «верификация» происходит от английского слова «verification» — проверка. А слово «валидация» происходит от английского «validation» — придание законной силы.
Примеры валидации и верификации в разных сферах.
Без примеров трудно понять отличия валидации и верификации. Приведем несколько примеров из разных областей.
Пример из области медицины
Скажем, разработали новое лекарство. Провели многочисленные тесты для ПРОВЕРКИ, что лекарство лечит такую-то болезнь. Здесь речь идет о ВЕРИФИКАЦИИ (о проверке соответствия лекарства его предназначению). Но Вы знаете, что на самом деле лекарство подходит не всем. Чтобы начать лечение Вам нужна ВАЛИДАЦИЯ врача. Только врач может ПОДТВЕРДИТЬ, что это лекарство подойдет КОНКРЕТНО Вам.
ВЕРИФИКАЦИЯ — это тестирование лекарства с целью ПРОВЕРКИ на соответствие его предназначению. А ВАЛИДАЦИЯ — это ПОДТВЕРЖДЕНИЕ врача, что лекарство подойдет КОНКРЕТНОМУ больному.
Пример из области производства
Предположим завод по производству велосипедов принял заказ на партию велосипедов. Так вот, ВЕРИФИКАЦИЮ (ПРОВЕРКУ) на соответствие требованиям заказчика выполняет сам завод-производитель. А вот ВАЛИДАЦИЮ (ТЕСТИРОВАНИЕ, ПРОВЕРКУ) на соответствие своим требованиям будут выполнять представители самого заказчика.
Пример из области IT
Аналогичный пример можно привести из области IT. Компания — разработчик программного обеспечения получила заказ на разработку какого-то софта. Программа, которая была создана, прошла тестирование. Результатом тестирования является ВЕРИФИКАЦИЯ на стороне компании, выполняющей заказ, что программа полностью соответствует тех заданию заказчика. А вот ВАЛИДАЦИЮ будет выполнять сам заказчик, когда установит программное обеспечение и протестирует его.
Пример из сферы интернета
Социальная сеть Твиттер проводит ВЕРИФИКАЦИЮ аккаунтов знаменитостей, чтобы участники сети точно знали, что посты публикуются действительно этой знаменитостью. В результате верификации в аккаунте знаменитости появляется синий значок с галочкой.
Еще пример. Для того, чтобы стать продавцом на Амазоне, Вам необходимо пройти ВЕРИФИКАЦИЮ личности. Также необходимо пройти верификацию при регистрации аккаунтов во всех платежных системах (Вебмани, Яндекс.Деньги, Киви и т.д.)
Пример из законодательной области
Инициативный депутат решил улучшить жизнь и придумал прогрессивный Закон. Законотворческие органы выполнят ПРОВЕРКУ нового Закона на соответствие другим Законам и международному праву и ВЕРИФИЦИРУЮТ его. Но Закон вступит в силу не сразу, а только через месяц — после его ВАЛИДАЦИИ (придания законной силы) высшим органом законодательной власти. За этот месяц можно отозвать Закон, выявив вред для каких-то КОНКРЕТНЫХ слоев населения.
Например, соц сеть Твиттер верифицирует аккаунты знаменитостей для того, чтобы пользователи были уверены, что сообщения действительно публикует эта знаменитость или её официальный представитель. В аккаунте пользователя Твиттере, который прошел такую верификацию, ставится синий значок с галочкой.
Теперь можно сделать общий вывод, что верификация (проверка) встречается чаще, чем валидация. Валидация (подтверждение для конкретного случая) нужна не всегда.
Практический совет
Вы спросите, для чего нужно разбираться в этих терминах? Скажу, что есть и практическая польза. Главная цель верификации и валидации — безопасность, чтобы Ваши банковские карты и аккаунты были защищены. Однако, пользуясь тем, что многие не разбираются в этих терминах, злоумышленники для похищения личных данных часто применяют такой способ, как сообщение с просьбой верифицировать или валидировать вашу банковскую карту, аккаунт и т.д..
Практический совет: При появлении окна с просьбой верификации или валидации Ваших данных проверьте в адресной строке данные сайта, нет ли пропущенных или лишних символов. Либо попробуйте зайти в эту программу с другого устройства и если такого сообщения не появляется, значит Ваш компьютер надо лечить от опасных вирусов.
Резюме
Надеюсь, статья, оказалась полезной для Вас и Вы теперь знаете ответы на вопросы: Валидация — что это простыми словами? Чем отличается валидация от верификации?
Вот по традиции порция полезного видео. В котором Жак Фреско учит мыслить нестандартно, не так, как все. ЭТИ НЕСКОЛЬКО МИНУТ БУДУТ ТОЧНО ПОТРАЧЕНЫ НЕ ЗРЯ!
Желаю всем новых идей и много сил для их реализации!
Валидация и верификация требований к системе
Очень часто путают два понятия валидация и верификация. Кроме того, часто путают валидацию требований к системе с валидацией самой системы. Я предлагаю разобраться в этом вопросе.
В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.
Пусть у нас есть проектируемый функциональный объект. Пусть этот объект рассматривается нами как часть конструкции другого функционального Объекта. Пусть есть описание конструкции Объекта, такое, что в нем присутствует описание объекта. В таком описании объект имеет описание как целого, то есть, описаны его интерфейсы взаимодействия с другими объектами в рамках конструкции Объекта. Пусть дано описание объекта как конструкции. Пусть есть информационный объект, содержащий требования к оформлению описания объекта как конструкции. Пусть есть свод знаний, который содержит правила вывода, на основании которых из описания объекта как целого получается описание объекта как конструкции. Свод знаний – это то, чему учат конструкторов в институтах – много, очень много знаний. Они позволяют на основе знанию об объекте спроектировать его конструкцию.
Итак, можно начинать. Мы можем утверждать, что если правильно описан объект как целое, если свод знаний верен, и если правила вывода были соблюдены, то полученное описание конструкции объекта, будет верным. То есть, на основе этого описания будет построен функциональный объект, соответствующий реальным условиям эксплуатации. Какие могут возникнуть риски:
1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.
2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.
3. Неверный свод знаний. Нас учили приоритету массы над остальными параметрами, а оказалось, что надо было наращивать скорость.
4. Неправильное применение правил вывода к описанию объекта. Логические ошибки, что-то пропущено в требованиях к конструкции объекта, нарушена трассировка требований.
5. Неполная запись полученных выводов о конструкции системы. Все учли, все рассчитали, но забыли написать.
6. Созданная система не соответствует описанию.
Понятно, что все артефакты проекта появляются, как правило, в завершенном своем виде только к концу проекта и то не всегда. Но, если предположить, что разработка водопадная, то риски такие, как я описал. Проверка каждого риска – это определенная операция, которой можно дать название. Если кому интересно, можно попытаться придумать и озвучить эти термины.
Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.
Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация — это в том числе проверка описания на непротиворечивость, полноту и понятность.
Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.