Что такое валидация в программировании

Валидация и верификация требований к системе

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

В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

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

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

1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.

2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.

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

4. Неправильное применение правил вывода к описанию объекта. Логические ошибки, что-то пропущено в требованиях к конструкции объекта, нарушена трассировка требований.

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

6. Созданная система не соответствует описанию.

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

Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.

Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация — это в том числе проверка описания на непротиворечивость, полноту и понятность.

Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.

• анализ требований
• валидация
• верификация

Валидация

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

Описанное здесь поведение валидаций и отображение ошибок реализовано в библиотеке «React UI Validations», по возможности используйте эту библиотеку в продукте.

Принципы

1. Ограничьте выбор заведомо неверных значений в списке: блокируйте эти значения или не показывайте в списке.
2. Ограничьте ввод неподходящих символов. Если в поле нужно вводить только цифры, и это очевидно пользователю, игнорируйте ввод букв вместо того, чтобы показать ошибку. Используйте маски в полях, где у значений известен формат.
3. Пишите подсказки для заполнения формы. Например, плейсхолдер в полях ввода.

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

Виды валидации

Существует три вида валидаций: мгновенная, по потере фокуса и по отправке формы.

Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.

Самый быстрый способ сообщить об ошибке — мгновенная валидация. Но она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Обычно такие ошибки связаны с неправильной раскладкой клавиатуры (кириллица вместо латиницы) или вводом букв в цифровое поле (ИНН, КПП и др.) Для этих случаев мы используем поля с масками: ввод неподходящих символов в них заблокирован. Поэтому в наших интерфейсах есть только два вида валидации:

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

Валидация по потере фокуса

Когда использовать

Этот вид валидации подходит для большинства случаев.

Как работает

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

Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено. Если найдена ошибка, поле подсвечивается красным. Фокус в это поле автоматически не возвращается:

Текст ошибки появляется в тултипе, когда поле получает наведение или фокус:

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

Красная подсветка снимается с поля, как только пользователь начал исправлять ошибочное значение.

Валидация при отправке формы

Когда использовать

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

Как работает

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

При прокрутке к первому полю от верхней границы окна до ошибочного поля остается отступ 48px — шесть модулей.

Блокирование кнопки отправки

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

Как только заполнены все обязательные поля — кнопка становится активной. Если после этого пользователь стер значение в одном из полей — кнопка снова должна стать не активной.

Сообщения об ошибках

Об ошибках можно сообщать двумя способами:

1. Красным текстом около поля, обычно под полем или справа от него:
2. Текстом в тултипе:

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

Тултипы

Как работают

Тултип с подсказкой появляется в двух случаях:

1. При наведении на поле с ошибкой.
2. Когда поле с ошибкой получает фокус.

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

Тултип исчезает, когда:

1. Курсор вышел из области поля с ошибкой.
2. Поле с ошибкой потеряло фокус.

Тултип по наведению перекрывает тултип по фокусу.

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

Единообразие поведения и внешнего вида

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

Красные тексты на странице

Как работают

Красный текст ошибки появляется сразу, как только произошла валидация и ошибочное поле подсветилось.

Как только пользователь начал исправлять значение, красная подсветка поля исчезает.

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

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

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

На более сложных формах выводите сообщение об ошибке в тултипе.

Валидация зависимых полей

Зависимые поля — это поля, значение которых зависит друг от друга.

Ошибки, которые связаны с нарушением зависимости полей, мы показываем после отправки формы. Например, ИНН и КПП. Если пользователь указал ИНН из 10 цифр, а поле с КПП оставил пустым, после отправки формы пустое поле с КПП будет подсвечено.

ИНН может быть двух видов:

• 10-значный у юридических лиц
• 12-значный у ИП.

Если пользователь указал ИНН из 12 цифр, значит организация — индивидуальный предприниматель, и у нее нет КПП, значит поле КПП заполнять не нужно. И наоборот, если заполнено КПП, а ИНН указан 12-значный, возможно неверно указан ИНН.

Подсветка зависимых полей пропадает, как только пользователь начал исправлять значение в одном из этих полей.

Если при заполнении зависимого поля нарушен формат значения, сообщайте о такой ошибке при потере фокуса. Например, пользователь ввел 3 цифры в поле ИНН и убрал фокус. Такое поле должно подсветиться сразу же.

Пример

Есть форма из 5 полей:

• Название организации — простое текстовое, обязательное
• ИНН — 10 или 12 цифр, проверка контрольной суммы по потере фокуса, обязательное
• КПП — 9 цифр с проверкой контрольной суммы по потере фокуса, обязательное, если ИНН состоит из 10 цифр
• Электронная почта — адрес почты, проверка по потере фокуса по маске a@a.aa, необязательное
• Телефон — международный формат, проверка по потере фокуса по маске +00000000000, обязательное

Пользователь пропустил поле с названием организации, заполнил ИНН значением из 10 цифр, перешел в поле почты, указал некорректный адрес, перешел в поле с телефоном и указал некорректный номер, но из поля пока не ушел:

Пользователь навел курсор на поле с почтой, появился тултип. Но исправлять значение пользователь не стал:

Пользователь нажал кнопку «Отправить» — фокус перешел в поле «Название организации», так как оно обязательное и незаполненное:

Поле с телефоном также подсветилось красным, так как заполнено некорректно. ИНН и КПП подсветились, так как ИНН состоит из 10 цифр, значит должен быть заполнен и КПП — валидация зависимых полей произошла только после отправки формы.

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

Заполнил название организации, перешел в поле ИНН:

Понял, что ИНН правильный, и нужно заполнить КПП:

Начал заполнять поле КПП. Красная рамка у ИНН и КПП исчезла — пользователь изменил значение в одном из зависимых полей:

Заполнил КПП, перешел в следующее поле:

Исправил почту, перешел в следующее поле:

Исправил телефон, кликнул за пределами поля:

Теперь по нажатию кнопки «Отправить» все будет хорошо.

Реализованный пример этой формы можно посмотреть в библиотеке валидаций.

Валидация

Валидация HTML-разметки — это проверка кода веб-страницы на соответствие стандартам Консорциума Всемирной паутины (World Wide Web Consortium, W3C). Эта организация разрабатывает требования, повышающие удобство и универсальность Сети. Проверка на валидность осуществляется с помощью онлайн-валидатора разметки, созданного также W3C, или сервисов от сторонних разработчиков.

Освойте профессию «Frontend-разработчик»

Зачем нужна проверка валидности кода?

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

Аналогичная ситуация и с искусственными языками, к которым относится HTML, CSS, XML и т.д. Они используются веб-разработчиками как средство «общения» с машиной (точнее, веб-браузером) и взаимодействия друг с другом при разработке. Поэтому, чтобы все задействованные стороны пришли к общему пониманию, необходимо установить одни и те же правила. То есть можно выделить следующие причины, почему важна проверка сайта на валидность:

• Корректное отображение веб-страницы. То, как будет выглядеть и работать сайт, во многом зависит от особенностей используемого устройства (ПК, смартфона, планшета), операционной системы и веб-браузера. Например, сайт, адаптированный под Google Chrome или Firefox, не всегда корректно отображается в Safari и Internet Explorer. Соблюдение общепринятых стандартов W3C позволяет компенсировать эти различия, благодаря чему веб-ресурс будет выглядеть и работать одинаково в любом браузере и устройстве.
• Легкость разработки и поддержки. Как правило, над сайтом трудится несколько человек: программист, верстальщик, тестировщик и т.д. Валидный код облегчает их взаимопонимание, упрощает поиск ошибок, техническое сопровождение. Особенно это актуально, когда сайт существует долгое время и людей, которые трудились над ним вначале, сменила другая команда разработчиков. Разумеется, эти специалисты должны сами знать стандарты W3C.
• Быстрая загрузка. Чтобы страница отобразилась в браузере, браузер должен прочесть ее код от начала и до конца. Если в нем будет много мусорных тегов, посторонних символов (они часто возникают при копировании с обычных текстовых редакторов), то загрузка будет происходить дольше. А это нервирует пользователей, ухудшает имидж и посещаемость ресурса.
• Эффективное продвижение. Валидный код, лишенный мусора и ошибок, очень нравится поисковым роботам. Страницы с высокой скоростью загрузки ранжируются в поисковой выдаче выше — соответственно, и посещаются они пользователями чаще.

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

Обязательна ли валидность кода?

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

Например, если в коде не проставить метатег с указанием кодировки или атрибут lang (language — язык), то текст на странице может частично или полностью замениться на буквы другого алфавита или вообще отобразиться в виде набора несвязанных символов.

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

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

Например, в верхней части кода типичной HTML-страницы есть тег DOCTYPE, который описывает схему документа для его верной интерпретации браузером. В зависимости от его содержания используются определенные атрибуты, порядок вложенности тегов и другие правила. Но часто разработчик использует свои пользовательские теги, которые «не вписываются» в текущую схему. Из-за их наличия валидатор распознает код как инвалидный, однако сам браузер отобразит его корректно. Более того, такой код будет работать даже лучше.

Станьте Frontend-разработчиком
и создавайте интерфейсы сервисов, которыми пользуются все

Как проверить код на ошибки?

Для проверки кода сайта на соответствие стандартам Консорциума разработаны различные инструменты (валидаторы):

• онлайн-сервисы, которые работают непосредственно в браузере, их не нужно скачивать и устанавливать на ПК;
• расширения для браузеров, установить которые можно через интернет-магазин Chrome, Safari, Firefox и т.д.;
• офлайн-приложения, которые нужно скачивать и устанавливать непосредственно на компьютер.

Один из самых популярных сервисов для онлайн-проверки кода — Markup Validation Service, валидатор от самого W3C. Принцип действия у него простой: достаточно ввести адрес страницы, файл или фрагмент кода, затем нажать кнопку «Проверить».

Результаты проверки в этом сервисе отображаются в виде списка ошибок и предупреждений, а также их расположения в коде.

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

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

Какие ошибки ищет валидатор кода?

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

• неправильные знаки препинания (служебные символы);

• отсутствующие члены предложения (атрибуты);
• неправильно используемые вспомогательные слова (теги и метатеги) и т.д.

При этом сервис отражает значимость этих ошибок — например, Markup Validation Service делит их на следующие категории:

• Ошибки. Это серьезные нарушения, которые могут привести к нестабильной работе или полной неработоспособности веб-страницы. К ним относятся отсутствующие, неправильно вложенные друг в друга или незаполненные теги и атрибуты.
• Предупреждения. Незначительные проблемы, которые не «положат» сайт, но не соответствуют стандартам W3C и могут вызвать мелкие неприятности вроде долгой загрузки. Типичные ошибки этого рода — лишние символы, мусорные теги и т.д.

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

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

Frontend-разработчик

Научитесь создавать удобные и эффектные сайты, сервисы и приложения, которые нужны всем. Сегодня профессия на пике актуальности: в России 9000+ вакансий, где требуется знание JavaScript.

Что такое верификация и валидация в тестировании ПО

Узнайте о верификации и валидации в тестировании ПО, их отличиях и примерах для обеспечения качества продукта!

Алексей Кодов
Автор статьи
23 июня 2023 в 17:34

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

Верификация

Верификация – это процесс проверки, что продукт соответствует определенным требованиям и спецификациям на каждом этапе разработки. Верификация фокусируется на «Делаем ли мы продукт правильно?«. Она включает в себя следующие действия:

• Анализ требований
• Использование статических методов анализа кода
• Контроль проекта и процессов разработки
• Проведение код-ревью

Пример верификации:
Проверка того, что требования к программному обеспечению ясны, полны и не противоречивы.

Валидация

Валидация – это процесс проверки, что продукт соответствует ожиданиям и потребностям пользователей. Валидация фокусируется на «Делаем ли мы правильный продукт?«. Она включает в себя следующие действия:

• Тестирование функциональности
• Тестирование производительности
• Тестирование безопасности
• Тестирование совместимости
• Проведение пользовательского приема

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

Инженер-тестировщик: новая работа через 9 месяцев
Получится, даже если у вас нет опыта в IT

Основные отличия между верификацией и валидацией

1. Цель: Верификация проверяет, что продукт соответствует требованиям и спецификациям, в то время как валидация проверяет, что продукт соответствует ожиданиям и потребностям пользователей.
2. Этапы разработки: Верификация проводится на каждом этапе разработки, в то время как валидация проводится после завершения разработки.
3. Методы: Верификация включает статические методы анализа (без исполнения кода), в то время как валидация включает динамические методы тестирования (с исполнением кода).

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