Верификация и валидация — что это такое простыми словами. Валидация что это такое.

Предположим, что велосипедная фабрика получила заказ на партию велосипедов. Производитель сам проводит ТЕСТИРОВАНИЕ велосипедов в соответствии с требованиями заказчика. Однако представители заказчика проводят ПОДТВЕРЖДЕНИЕ (ТЕСТИРОВАНИЕ) соответствия их требованиям.

Эссе о валидации данных

В моем посте «Можете ли вы делить на 0,01?» На сайте для тестировщиков я написал, что тестирование должно проверять согласованность проверенных входных данных с логикой обработки этих данных приложением. Но из комментариев к этому посту я понял, что для понимания того, как следует тестировать валидацию данных, необходимо понимать, как она должна работать, что можно считать правильным, а что нет. Поэтому я написал об этом отдельную статью. В нем рассматриваются следующие три вопроса: 1) зачем нужна проверка данных, 2) где и когда проводится проверка данных, 3) какие существуют виды проверок. И, конечно, он показывает, как все это выглядит на реальных примерах. Возможно, мои аргументы интересны не только для аудиторов, но и для разработчиков.

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

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

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

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

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

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

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

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

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

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

После завершения ввода можно проверить все значение. На вводимое число могут накладываться определенные ограничения, например, оно не должно превышать определенного максимального значения. Если наше числовое поле — это возраст, то он должен быть от 0 до, скажем, 120.

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

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

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