Эссе о валидации данных
В заметке «Можно ли делить на 0,01 ?» на сайте тестировщиков я написал, что при тестировании нужно проверять согласованность валидаторов входных данных с логикой обработки этих данных приложением. Но из комментариев к этой заметке я понял, что для понимания того, как надо тестировать валидацию данных, надо понимать, как она должна работать, что можно считать правильным, а что нет. Поэтому я написал об этом отдельную статью. В ней рассматривается три вопроса: 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок. Ну и конечно продемонстрировано, как всё это выглядит на живых примерах. А может быть мои рассуждения окажутся интересны не только тестировщикам, но и разработчикам.
Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
- Невозможность восстановиться после сбоя. Не всегда программа способна «вернуть всё назад». Возможно, в процессе работы программа выполнила какие-то необратимые действия — удалила файл, отправила данные по сети, напечатала что-то на принтер, запустила резец станка и он частично произвёл обработку заготовки детали. Но даже если восстановление в принципе возможно, алгоритм восстановления может тоже содержать ошибки, и это иногда приводит к совсем печальным последствиям.
- Дополнительная нагрузка на систему. Восстановление после сбоя — это лишняя работа. Вся работа, которая была выполнена до момента сбоя — тоже лишняя. А это означает дополнительную нагрузку на систему, которой можно избежать, если заранее проверить данные. С другой стороны, валидация — это тоже дополнительная нагрузка, причём восстановление приходится делать лишь изредка, а проверку надо выполнять каждый раз, так что ещё неизвестно, что выгоднее.
- Инъекции не вызывают сбоев. Один из основных способов эксплуатации уязвимостей в программах заключается в том, чтобы «обмануть» валидаторы, то есть передать данные, которые валидатор признаёт корректными, но при этом они интерпретируются непредусмотренным образом, так что злоумышленник может получить несанкционированный доступ к данным или некоторым возможностям программы, либо способен разрушить данные или программу. Если валидации нет вообще, задача злоумышленника максимально упрощается.
- Сложность идентификации причины проблемы. Если исключение вылетело откуда-то из глубины программы, определить причины его возникновения не так-то просто. И даже если это возможно, может оказаться нелегко объяснить пользователю, что сбой вызван данными, которые он ввёл некоторое время назад в каком-то совершенно другом месте программы. А если проверка выполнена немедленно после ввода данных, никаких сложностей с идентификацией источника проблемы не возникает.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
-
Для валидации требуется доступ к недоступной части состояния системы. Это особенно характерно для проверки данных, вводимых человеком через графический интерфейс пользователя. Современные приложения часто построены с использованием многоуровневой архитектуры, которая предполагает, что реализация пользовательского интерфейса выделена в презентационный слой, а для проверки требуется доступ к другим слоям, вплоть до слоя базы данных.
Как выполнять валидацию данных?
- Посимвольная проверка. Как правило такие проверки выполняются в пользовательском интерфейсе, по мере ввода данных. Но не только. Например, лексический анализатор компилятора тоже выявляет недопустимые символы непосредственно в процессе чтения компилируемого файла. Поэтому такие проверки можно условно назвать «лексическими».
- Проверка отдельных значений. Для пользовательского интерфейса это проверка значения в отдельном поле, причём выполняться она может как по мере ввода (проверяется то неполное значение, которое введено к настоящему моменту), так и после завершения ввода, когда поле теряет фокус. Для программного интерфейса (API) это проверка одного из параметров, переданных в вызываемую процедуру. Для данных, получаемых из файла, это проверка какого-то прочитанного фрагмента файла. Такие проверки, опять-таки по аналогии с компиляторной терминологией, можно назвать «синтаксическими».
- Совокупность входных значений. Можно предположить, что в программу сначала передаются какие-то данные, после чего подаётся некоторый сигнал, который инициирует их обработку. Например, пользователь ввёл данные в форму или в несколько форм (в так называемом «визарде») и наконец нажал кнопку «OK». В этот момент можно выполнить так называемые «семантические» проверки, нацеленные на валидацию не только отдельных значений, но и взаимосвязей между ними, взаимных ограничений.
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
- тестирование
- валидация данных
Валидация
Валидация 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.
Валидация
Валидация — это проверка значений, указанных пользователем, и отображение найденных ошибок.
Описанное здесь поведение валидаций и отображение ошибок реализовано в библиотеке «React UI Validations», по возможности используйте эту библиотеку в продукте.
Принципы
- Ограничьте выбор заведомо неверных значений в списке: блокируйте эти значения или не показывайте в списке.
- Ограничьте ввод неподходящих символов. Если в поле нужно вводить только цифры, и это очевидно пользователю, игнорируйте ввод букв вместо того, чтобы показать ошибку. Используйте маски в полях, где у значений известен формат.
- Пишите подсказки для заполнения формы. Например, плейсхолдер в полях ввода.
Валидация на только что открытой пустой форме запрещена. Исключение — черновики, когда пользователь уже заполнял эту форму, через какое-то время вернулся к ней, а она заполнена с ошибками.
Виды валидации
Существует три вида валидаций: мгновенная, по потере фокуса и по отправке формы.
Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.
Самый быстрый способ сообщить об ошибке — мгновенная валидация. Но она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Обычно такие ошибки связаны с неправильной раскладкой клавиатуры (кириллица вместо латиницы) или вводом букв в цифровое поле (ИНН, КПП и др.) Для этих случаев мы используем поля с масками: ввод неподходящих символов в них заблокирован. Поэтому в наших интерфейсах есть только два вида валидации:
- по потере фокуса — основной вид валидации
- по отправке формы — для тех случаев, когда валидация по потере фокуса невозможна.
Валидация по потере фокуса
Когда использовать
Этот вид валидации подходит для большинства случаев.
Как работает
Не валидируйте поля на пустоту по потере фокуса — не показывайте ошибку если поле не заполнено, возможно пользователь вернется и заполнит поле чуть позже. Показывать ошибку в таких случаях можно только после отправки формы.
Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено. Если найдена ошибка, поле подсвечивается красным. Фокус в это поле автоматически не возвращается:
Текст ошибки появляется в тултипе, когда поле получает наведение или фокус:
Поле с ошибкой должно остаться подсвеченным, если оно получило фокус, его значение не исправляли, а затем оно потеряло фокус.
Красная подсветка снимается с поля, как только пользователь начал исправлять ошибочное значение.
Валидация при отправке формы
Когда использовать
Используйте этот вид валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей.
Как работает
Проверка происходит после того, как пользователь нажал кнопку отправки данных: все поля с ошибками на форме подсвечиваются, страница прокручивается к первому полю с ошибкой, фокус перемещается в это поле, курсор встает в конец строки, рядом с полем появляется тултип с подсказкой.
При прокрутке к первому полю от верхней границы окна до ошибочного поля остается отступ 48px — шесть модулей.
Блокирование кнопки отправки
В небольших формах вместо проверки заполнения обязательных полей можно блокировать кнопку отправки формы. Используйте это поведение, когда очевидно, почему кнопка отправки формы неактивна. Например, на форме входа:
Как только заполнены все обязательные поля — кнопка становится активной. Если после этого пользователь стер значение в одном из полей — кнопка снова должна стать не активной.
Сообщения об ошибках
Об ошибках можно сообщать двумя способами:
- Красным текстом около поля, обычно под полем или справа от него:
- Текстом в тултипе:
Из этих двух способов мы рекомендуем использовать тултипы. Они идут отдельным слоем, поэтому не раздвигают форму и легко размещаются, даже если поля на форме расположены плотно.
Тултипы
Как работают
Тултип с подсказкой появляется в двух случаях:
- При наведении на поле с ошибкой.
- Когда поле с ошибкой получает фокус.
Если значение в поле с ошибкой было изменено, потеряло фокус, а потом заново оказалось в фокусе — тултип с текстом старой ошибки уже не возникает. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Тултип исчезает, когда:
- Курсор вышел из области поля с ошибкой.
- Поле с ошибкой потеряло фокус.
Тултип по наведению перекрывает тултип по фокусу.
Тултип может появляться сверху или справа от контрола с ошибкой, так чтобы он не перекрывал полезную информацию:
Единообразие поведения и внешнего вида
Показывайте тултипы справа от полей. Eсли в этом случае они перекрывают важное содержимое на странице, выводите тултипы сверху. Придерживайтесь единообразия, но помните, что контент важнее него.
Красные тексты на странице
Как работают
Красный текст ошибки появляется сразу, как только произошла валидация и ошибочное поле подсветилось.
Как только пользователь начал исправлять значение, красная подсветка поля исчезает.
Текст ошибки пропадает по потере фокуса и больше не появляется, если поле заново получает фокус. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Выводите текст ошибки справа, если на форме есть место, а само сообщение короткое. Так форму не придется раздвигать, чтобы показать ошибку.
Если справа от поля нет места для текста, раздвигайте форму и выводите сообщение под полем.
На более сложных формах выводите сообщение об ошибке в тултипе.
Валидация зависимых полей
Зависимые поля — это поля, значение которых зависит друг от друга.
Ошибки, которые связаны с нарушением зависимости полей, мы показываем после отправки формы. Например, ИНН и КПП. Если пользователь указал ИНН из 10 цифр, а поле с КПП оставил пустым, после отправки формы пустое поле с КПП будет подсвечено.
ИНН может быть двух видов:
- 10-значный у юридических лиц
- 12-значный у ИП.
Если пользователь указал ИНН из 12 цифр, значит организация — индивидуальный предприниматель, и у нее нет КПП, значит поле КПП заполнять не нужно. И наоборот, если заполнено КПП, а ИНН указан 12-значный, возможно неверно указан ИНН.
Подсветка зависимых полей пропадает, как только пользователь начал исправлять значение в одном из этих полей.
Если при заполнении зависимого поля нарушен формат значения, сообщайте о такой ошибке при потере фокуса. Например, пользователь ввел 3 цифры в поле ИНН и убрал фокус. Такое поле должно подсветиться сразу же.
Пример
Есть форма из 5 полей:
- Название организации — простое текстовое, обязательное
- ИНН — 10 или 12 цифр, проверка контрольной суммы по потере фокуса, обязательное
- КПП — 9 цифр с проверкой контрольной суммы по потере фокуса, обязательное, если ИНН состоит из 10 цифр
- Электронная почта — адрес почты, проверка по потере фокуса по маске a@a.aa, необязательное
- Телефон — международный формат, проверка по потере фокуса по маске +00000000000, обязательное
Пользователь пропустил поле с названием организации, заполнил ИНН значением из 10 цифр, перешел в поле почты, указал некорректный адрес, перешел в поле с телефоном и указал некорректный номер, но из поля пока не ушел:
Пользователь навел курсор на поле с почтой, появился тултип. Но исправлять значение пользователь не стал:
Пользователь нажал кнопку «Отправить» — фокус перешел в поле «Название организации», так как оно обязательное и незаполненное:
Поле с телефоном также подсветилось красным, так как заполнено некорректно. ИНН и КПП подсветились, так как ИНН состоит из 10 цифр, значит должен быть заполнен и КПП — валидация зависимых полей произошла только после отправки формы.
Пользователь начинает вводить название организации, подсветка поля гаснет, а текст подсказки остается:
Заполнил название организации, перешел в поле ИНН:
Понял, что ИНН правильный, и нужно заполнить КПП:
Начал заполнять поле КПП. Красная рамка у ИНН и КПП исчезла — пользователь изменил значение в одном из зависимых полей:
Заполнил КПП, перешел в следующее поле:
Исправил почту, перешел в следующее поле:
Исправил телефон, кликнул за пределами поля:
Теперь по нажатию кнопки «Отправить» все будет хорошо.
Реализованный пример этой формы можно посмотреть в библиотеке валидаций.
Валидация данных
Валидация — это проверка данных временных рядов на соответствие заданным условиям и ограничениям.
Валидация данных выполняется с помощью правил валидации. Для последовательного выполнения нескольких правил валидации они могут быть объединены в группу.
Примечание . Валидация доступна для экспресс-отчетов, таблиц в аналитических панелях, областей данных в регламентных отчётах, если источником данных является база данных временных рядов, стандартный или автоматический куб с календарным измерением. При работе с глобальным кэшем валидация данных недоступна.
Все правила и группы валидации отображаются на вкладке боковой панели « Правила валидации ».
- Убедитесь, что боковая панель отображается.
- Установите переключатель на боковой панели:
- Источник . Переключатель в экспресс-отчёте;
- Данные . Переключатель в аналитической панели;
- Документ . Переключатель в регламентном отчёте.
- Перейдите на вкладку « Правила валидации ».
- вкладки « Правила валидации » на боковой панели для создания и редактирования правил валидации.
- выберите вкладку в группе вкладок « Источник »/« Данные » боковой панели;
- нажмите на кнопку « Валидация > Настроить правила валидации » на вкладке « Расширенная аналитика » ленты инструментов.
- группы « Валидация данных » на вкладке « Расширенная аналитика » ленты инструментов для выполнения и просмотра итогов применения правил валидации.
- нажмите кнопку « Создать > Правило валидации » на вкладке « Правила валидации » на боковой панели;
- выполните команду « Создать > Правило валидации » в контекстном меню объекта репозитория на вкладке боковой панели « Правила валидации ».
- нажмите кнопку « Редактировать »;
- выполните команду « Редактировать » в контекстном меню правила;
- дважды щелкните по правилу валидации;
- нажмите клавишу F4. Возможность доступна только в настольном приложении.
- нажмите кнопку « Создать > Группа правил валидации »;
- выполните команду « Создать > Группа правил валидации » в контекстном меню объекта репозитория на вкладке боковой панели.
- нажмите кнопку « Редактировать »;
- выполните команду « Редактировать » в контекстном меню группы;
- дважды щелкните по группе правил валидации;
- нажмите клавишу F4. Возможность доступна только в настольном приложении.
- в аналитической панели в текущем блоке;
- в экспресс-отчета на текущем листе;
- в регламентном отчете в текущей области данных.
- вкладку боковой панели « Правила валидации »:
- Выберите правило/группу правил.
- Нажмите кнопку « Выполнить » или выполните одноименную команду в контекстном меню.
- вкладку « Расширенная аналитика » на ленте инструментов:
- Нажмите кнопку « Валидация ».
- В отобразившемся меню выберите требуемое правило/группу.
- нажмите кнопку « Удалить »;
- выполните команду « Удалить » в контекстном меню;
- нажмите сочетание клавиш CTRL+DELETE. Возможность доступна только в настольном приложении.
- Выделите правило/группу правил на вкладке боковой панели « Правила валидации ».
- Используйте команды в контекстном меню: « Копировать », « Вырезать », « Вставить ».
- Перейдите на вкладку « Правила валидации » на боковой панели.
- Выделите элемент, внутри которого должна быть создана папка.
- Нажмите кнопку « Создать > Папку » или выполните одноименную команду в контекстном меню.
- выполните команду « Переименовать » в контекстном меню;
- щелкните по выделенному правилу/группе правил;
- нажмите клавишу F2. Возможность доступна только в настольном приложении и в экспресс-отчете в веб-приложении.
- . Выделяет предыдущее исключение;
- . Выделяет следующее исключение;
- . Выделяет первое исключение;
- . Выделяет последнее исключение.
Пример результата валидации данных:
Работа с правилами валидации
Работа с правилами валидации осуществляется с помощью:
Для отображения вкладки « Правила валидации » убедитесь, что боковая панель отображена и выполните одно из действий:
Работа с вкладкой подобна работе с вкладкой « Правила валидации » анализа временных рядов;
Примечание . При открытии отчета в « Р ежиме просмотра » работа с правилами валидации возможна только через ленту инструментов.
Основные операции с правилами/группами правил валидации
Для создания правила валидации:
Будет открыт диалог « Правило валидации ». Созданное правило будет сохранено в БД временных рядов, но не будет выполнено.
Используйте вкладку боковой панели « Правила валидации ». Для настройки параметров выбранного правила валидации:
Для создания группы правил валидации:
Используйте вкладку боковой панели « Правила валидации ». Для настройки параметров выбранной группы правил валидации:
Будет открыт диалог для редактирования выбранной группы.
Правило/группа правил валидации может быть выполнена:
Для выполнения правила/группы правил валидации используйте:
Валидация данных будет выполнена в указанной области.
Совет . Для выполнения правила/группы правил на текущем листе экспресс-отчета в веб-приложении перетащите правило/группу правил на лист.
Для работы с результатами валидации используйте вкладку « Расширенная аналитика » на ленте инструментов.
Для удаления правила/группы правил, выделенной на вкладке боковой панели « Правила валидации »:
Будет запрошено подтверждение выполняемого действия.
Для перемещения правил/группы правил валидации:
Для создания папки, в которой могут храниться правила/группы правил валидации:
Папка будет создана внутри выделенного элемента.
Для поиска правила/группы правил валидации используйте строку поиска, расположенную в верхней части вкладки « Правила валидации » на боковой панели. Введите наименование искомого правила/группы правил в строку поиска. На вкладке останутся лишь правила/группы правил, соответствующие условиям поиска.
Для сброса результатов поиска очистите строку поиска.
Для переименования правила/группы правил, выделенной на вкладке боковой панели « Правила валидации »:
Название правила/группы правил будет переведено в режим редактирования. Для завершения редактирования нажмите клавишу ENTER.
Работа с результатами валидации
В процессе выполнения правила валидации выявляются исключения. Исключения — это наблюдения или временные ряды, не соответствующие условиям правила валидации.
Если правило валидации выполнялось, то исключения будут отображены в области выполнения валидации. Стиль оформления исключений зависит от настроек правила валидации.
После выполнения валидации для работы с исключениями предназначена вкладка « Расширенная аналитика » на ленте инструментов.
Для быстрого перемещения между исключениями в таблице данных используйте кнопки на вкладке ленты « Расширенная аналитика »:
Перемещение выполняется относительно текущей выделенной ячейки.
Легенда предназначена для демонстрации стиля оформления исключений в правилах валидации.
Для отображения легенды нажмите кнопку « Легенда » на вкладке ленты « Расширенная аналитика ». Легенда содержит стили оформления исключений и названия только тех правил, которые выявили исключения.
Для скрытия легенды переведите кнопку « Легенда » в ненажатое состояние.
Примечание . В инструменте « Отчёты » настройка доступна только в настольном приложении.
Нажмите кнопку « Очистить » группы кнопок « Валидация данных » на вкладке ленты инструментов « Расширенная аналитика ».
Список запущенных валидаций и их результаты будут очищены.