ПРОВЕРКА ВВОДИМЫХ ДАННЫХ ОСНОВНЫЕ ПРОБЛЕМЫ И СПОСОБЫ ИХ РЕШЕНИЯ

Постановка задачи

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

Ну, по поводу register_globals Я ничего объяснять не собираюсь, так как читающий эту статью точно уже знает о этой проблеме. Повторять общеизвестные факты Я не буду.
Отключенные magic_quotes_gpc объясняются тем, что Я ориентируюсь на использование технологии ajax для своих проектов и «магические кавычки» — это «большая палка в колёса». По мне лучше экранировать необходимые данные вручную, чем потом искать среди ответов сервера на ajax-запрос ошибочное двойное экранирование.

Функция логирования

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

Функция проверки поступивших данных

Все поступившие данные необходимо в начале привести к подобающему виду, затем проверить на «плохие» слова и произвести экранирование кавычек. Давайте, всё разберем на конкретном примере:

Ну, а теперь всё по порядку:

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

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

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

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

Проверка
на уровне поля

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

Применение
свойств элемента управления TextBox

Чаще всего для приема данных от
пользователя применяется элемент
управления TextBox. Некоторые из его свойств
позволяют ограничивать диапазон
значений, вводимых в текстовое поле,
например:

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

Свойство PasswordChar позволяет скрывать от
посторонних глаз значение, вводимое во
время выполнения. Например, если сделать
значением свойства PasswordChar звездочку
(*), текстовое поле будет отображать все
вводимые пользователем символы как
звездочки. Этот прием обычно используют
для защиты паролей в окнах входа.

Для замены пароля вы можете назначить
любой допустимый символ, например точку
с запятой или знак «&». Независимо от
назначенного символа, свойство Text всегда
содержит то значение, которое реально
ввел пользователь.

Свойство ReadOnly определяет, разрешено ли
пользователю редактировать значение
текстового поля. Если это свойство
установлено в true, пользователю не удастся
изменить отображаемый в поле текст, в
противном случае значение текстового
поля можно редактировать, как обычно.

Свойство Multiline определяет, одна или
много строк в поле. Если оно установлено
в true, пользователь может вводить
многострочный текст, завершая строки
символом возврата каретки. Введенные
строки сохраняются в виде строкового
массива в наборе Text Box. Lines. Чтобы получить
нужную строку, следует указать ее индекс
в массиве.

Применение
событий для проверки на уровне поля

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

События
KeyDown и KeyUp

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

Чаще всего события KeyDown и KeyUp используют,
чтобы определить, нажаты ли клавиши
Alt, Ctrl или Shift. Результат передается
обработчику соответствующего события
через ссылку на экземпляр класса
KeyEventArgs. Его свойства Ait, Ctrl и Shift возвращают
значения типа Boolean, указывающие, были
ли нажаты соответствующие клавиши.
Значение True свидетельствует о том, что
клавиша была нажата, а false — о том, что
нет. Ниже показан пример обработчика
события KeyUp, проверяющего нажатие клавиши
Alt:

private
void textBox1_KeyUp(object sender,

if
(e. Alt == true)

MessageBox. Show(“The
ALT key is still down”);

Свойство KeyEventArgs. KeyCode позволяет определить,
какая именно клавиша спровоцировала
событие. Это свойство возвращает код
нажатой или отпущенной клавиши
(соответственно при событиях KeyDown или
KeyUp). Ниже показан пример простого
обработчика события, отображающего
сообщение с кодом нажатой клавиши:

private
void textBox1_KeyDown(object sender,
System. Windows. Forms. KeyEventArgs e)

Когда пользователь нажимает клавишу,
которой соответствует значение ASCII,
генерируется событие KeyPress. К этим
клавишам относятся все алфавитно-цифровые
клавиши (a— z, A— Z, 0—9), а также ряд
специальных клавиш, таких, как Enter и
Backspace. Если при нажатии клавиши или их
комбинации не генерируется ASCII-символ,
событие KeyPress также не генерируется. К
таким клавишам относятся клавиши
-модификаторы Ctrl и Alt, а также все
функциональные клавиши.

Это событие очень удобно для перехвата
нажатия клавиш и проверки соответствующих
символов. При генерации события KeyPress
обработчик получает экземпляр класса
KeyEventArgs, свойство Key EventArgs. Key Code которого
содержит ASCII-символ клавиши, нажатие
которой спровоцировало это событие.
Чтобы проверить, например, была ли нажата
цифра, достаточно проверить свойство
KeyChar в обработчике события KeyPress.

Все они проверяют символы и возвращают
булевы значения. Что проверяет каждый
метод — легко догадаться по его имени.
Функция Char. IsDigit возвращает true, если
переданный ей символ является цифрой,
и false в любом другом случае; Char. IsLower
возвращает true, если ее аргументом
является буква в нижнем регистре, и
false в противном случае; сходным образом
работают остальные методы. Вот пример
применения метода Char. IsDigit для проверки
нажатия цифр на клавиатуре:

private
void textBox1_KeyPress (object sender,

System.
Windows. Forms. KeyPressEventArgs e)

if
(Char. IsDigit(e. KeyChar) == true)

MessageBox. Show(“You
pressed a number key”);

Работа
с фокусом ввода

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

Элемент управления, обладающий фокусом,
всегда находится на активной форме
приложения.

У каждого элемента управления есть
метод Focus, который передает фокус ввода
вызвавшему его элементу управления.
Метод Focus возвращает булево значение,
свидетельствующее об успешной или
неудачной передаче фокуса. Деактивированные
или невидимые элементы управления не
получают фокус ввода. Определить,
способен ли данный элемент управления
получить фокус ввода, позволяет его
свойство CanFocus: если оно возвращает true,
элемент управления может получить
фокус, а если false — нет.

//
Проверить, может ли TextBox1 получить фокус,

//
и, если да, передать ему фокус.

if
(textBox1. CanFocus == true)

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

События Enter, Leave генерируются, когда
фокус переходит к элементу управления
(но еще не получен им) и покидает его.
События GotFocus и LostFocus генерируются при
получении и потере фокуса элементом
управления. В принципе, эти события
можно применять для проверки вводимых
значений на уровне поля, однако события
Validating и Validated лучше подходят для этой
цели.

Проще всего проверить вводимые данные
при помощи события Validating, генерируемого
перед потерей фокуса элементом управления.
Это событие генерируется, только если
у элемента управления, который получит
фокус следующим, свойство Causes Validation
установлено в true. Поэтому, если значение
элемента управления предполагается
проверять при помощи события Validating, для
элемента управления, который получит
фокус следующим, свойство CausesValidation
следует установить в true. Кроме того,
использование события Validating требует,
чтобы свойство CausesValidation у проверяемого
элемента управления было установлено
в true. У всех элементов управления,
созданных во время разработки, свойство
CausesValidation установлено в true по умолчанию,
обычно исключение составляет лишь
кнопка Help.

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

Событие Validating включает экземпляр
CancelEventArgs — класса с единственным
свойством Cancel. Если введенное значение
не отвечает заданным параметрам, проверив
свойство Cancel в обработчике события
Validating, можно отменить дальнейшую
обработку этого события и вернуть фокус
исходному элементу управления.

Событие Validated генерируется после успешной
проверки значения элемента управления
и позволяет выполнить некоторые действия
в зависимости от результатов проверки.

Ниже показан пример обработчика события
Validating, который не разрешает передать
фокус следующему элементу управления,
пока пользователь не введет значение
в поле TextBoxl.

private
void textBox1_Validating(object sender,

System.
ComponentModel. CancelEventArgs e)

if
(textBoxt. Text == “”)

e.
Cancel = true;

Применение
события Validating для проверки текстового
поля

1.
Поместите на форму текстовое поле.

2.
Создайте для него обработчик события
Validating,
устанавливающий
свойство
e.
Cancel в
true,
чтобы
прервать проверку и вернуть фокус
текстовому полю.

3.
Для всех элементов управления, которые
не должны генерировать событие
Validating,
установите
свойство Causes
Validation
в
false.

Проверка на уровне формы позволяет
одновременно проверить все поля формы.

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

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

private
void btnValidate_Click(object sender, System. EventArgs
e)

//
Проверить все элементы управления формы
в цикле.

foreach
(System. Windows. Forms. Control aControl in this. Controls)

if
(aControl is System. Windows. Forms.
TextBox && aControl. Text ==””

//
передать ему фокус и выйти из метода.

Обработка
событий клавиатуры на уровне формы

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

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

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

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

Оповещение
пользователя об ошибках ввода

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

Примечание В Visual C# нет встроенных
методов, отвечающих за подачу звуковых
сигналов.

Привлечь внимание пользователя к ошибке
можно и по-другому, изменив цвет фона
или текста элемента управления (при
помощи его свойств BackColor и ForeColor
соответственно). Например, выделить
текстовое поле с недопустимым значением,
задав для него красный фон через свойство
BackColor.

Чтобы вывести более информативное
описание ошибки, воспользуйтесь методом
MessageBox. Show, отображающим небольшое
модальное окно с сообщением.

Поскольку это окно — модальное,
пользователю не удастся просто
игнорировать его и продолжить работу
с программой. Вот пример вызова метода
Message Box. Show;

MessageBox. Show(“That
value is not valid for this control”);

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

Отображение
сообщений об ошибках

Метод SetError компонента ErrorProvider позволяет
вывести сообщение об ошибке рядом с
элементом управления. Этот метод
принимает имя элемента управления и
текст сообщения об ошибке в качестве
параметров; вызывают его так:

//
Предполагается существование элемента
управления nameTextBox

myErrorProvider. SetError(nameTextBox,
“Name cannot be left blank!”);

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

Сообщение об ошибке разрешается задавать
и во время проектирования Если изучить
окно Properties после добавления на форму
компонента ErrorProvider, нетрудно заметить,
что у каждого элемента управления
появилось новое свойство Error on х, где х
— имя экземпляра ErrorProvider. Во время
проектирования значение этого свойства
задают через окно Properties, во время
выполнения заданное таким образом
значение отображается как сообщение
об ошибке для данного элемента, Ряд
свойств компонента ErrorProvider определяет
способ отображения сообщения об ошибке.
Свойство Icon задает значок, отображаемый
после элемента управления. Одна форма
может содержать несколько экземпляров
ErrorProvider, например один, отображающий
сообщения об ошибках, а другой —
предупреждения, при этом каждому
экземпляру ErrorProvider разрешается назначить
собственный значок. Другое свойство
этого компонента — BlinkStyle — заставляет
значок мигать, частоту мигания определяет
свойство BlinkRate.

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

1.
Создайте форму и добавьте к ней компонент
ErrorProvider — он появится в области
компонентов.

2.
Установите в true
свойство
CausesValidation
элемента
управления, который должен выводить
сообщения об ошибках, если это еще не
сделано.

3.
Добавьте к обработчику события Validating
этого
элемента управления код, проверяющий
введенное в него значение. При помощи
метода SetError
установите
текст
сообщения, которое отображается, если
при проверке введенного обнаружится
ошибка. Вот пример обработчика,
использующего экземпляр компонента
ErrorProvider
с именем my Error Provider;
этот обработчик проверяет текстовое
поле
pswordTextBox:

private
void pswordTextBox_Validating(object sender,

if
(pswordTextBox. Text == “”)

myErrorProvider.
Set Error (pswordTextBox, “Password cannot be blank!”);

//
Если введено допустимое значение,
очистить текст сообщения:

//
поскольку ошибки нет, сообщение не
выводится.

Для преобразования типов используются
следующие методы:

//
преобразование текста в целое число

int
balance
= Convert. ToInt32(textBox1. Text);

// преобразование целого числа в
текст

textBox1. Text
= Convert. ToString(balance);

Процесс создания приложения заключается
в выполнении следующих шагов:

1. Создать интерфейс приложения (перетащить
все необходимые компоненты, настроить
их свойства).

2. Настроить обработку событий необходимых
компонент.

Проверка допустимости вводимых данных

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

Для
проверки доменного имени добавляем
такое выражение:

Объединяя
эти шаги, получаем следующее регулярное
выражение для проверки адресов электронной
почты:

Точно
таким же образом вы можете проверить и
остальные заполняемые пользователем
поля.

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

Время на прочтение

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

Зачем нужна валидация данных?

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

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

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

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

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

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

Увы, здравый смысл иногда вынужден отступить перед натиском действительности. « Фейс-контроль» данных на входе иногда не просто нецелесообразен, но вообще невозможен. Ниже приведены некоторые причины этого.

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

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

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

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

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

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

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

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

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

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

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

Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:

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

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

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

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

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

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

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

Заключение

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

Пишем гостевую книгу на php

Сейчас
мы разработаем приложение “Гостевая
книга на PHP”.

Сообщения
будут храниться в файлах, которые
расположены в директории RECORDS (позже
мы разработаем вариант гостевой книги,
основанный на хранении сообщений в базе
данных). Код размещен в двух
файлах: index.php (отображение
сообщений) и addrec.php (добавление
сообщений, их проверка и запись в файл).

Итак,
создайте файл addrec.php и в той же директории,
в которой расположен этот файл создайте
директорию RECORDS.

Сначала
проверяем, ввел ли пользователь данные
и правильно ли он их ввел:

if
(empty($msg))
// если не введено сообщение

if
(empty($name))
// если не введено имя

/*
если введен e-mail, то проверяем с помощью
регулярного выражения

Теперь
обрабатываем введенный пользователем
текст функциями удаления HTML-тегов и
обратных слешей:

$name
= htmlspecialchars(stripslashes($name));
// обрабатываем
имя

$city
= htmlspecialchars(stripslashes($city));
// обрабатываем
город

$email
= htmlspecialchars(stripslashes($email));
// обрабатываем
e-mail

$url
= htmlspecialchars(stripslashes($url));
// обрабатываем
url-адрес

$msg
= htmlspecialchars(stripslashes($msg));
// обрабатываем
сообщение

if
(empty($error))
// если ошибок нет, обрабатываем сообщение

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

/*
создаем файл с именем вида “rec.+время
добавления сообщения” */

//
записываем информацию в файл, по одной
строчке на каждое поле

Вызываем
скрипт index.php,
ответственный за отображение сообщений:

Добавляем
код вывода сообщений об ошибках и
HTML-код формы добавления сообщения:

/*
если есть ошибки, выводим сообщение об
ошибках */

После
окончания работы с кодом, размещенным
в файле addrec.php, форма для добавления
сообщений должна иметь следующий вид:

Проверка вводимых данных

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

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

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

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

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

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

Дополнительные средства контроля

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

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

Соседние файлы в папке Лекции по Excel

Удаление html – тегов и обратных слешей

Как
уже говорилось, вводимый пользователем
текст необходимо обработать функциями
удаления HTML-тегов (для исключения
возможности написания скриптов на
JavaScript и Visual Basic) и обратных слешей (для
исключения возможности написания
скриптов на Perl). К примеру, если
переменная $name содержит
текст с именем пользователя, то обработка
этого текста выглядит так:

О том, как можно проверять значения, введёные пользователем

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

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

Для проверки значение помещаем в класс обёртку:

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

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

А теперь о том, как это использовать. Допустим нам нужно проверить текстовое поле (tb1) и убедиться, что в него введено целое число в диапазоне от 0 до 10. Это можно сделать так:

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

Ну вот, собственно, и всё: о)