Цитаты из книг автора «Марина Охапкина»

станет пустым. Поэтому проверьте, что валидация на обязательность ввода игнорирует пробелы и знаки табуляции. Большое количество обязательных полей может вызвать раздражение у пользователей, так как требует от него больших усилий. Поэтому, делая поле обязательным, задайте себе два вопроса: 1) Можно ли отложить ввод данных в это поле. Например, пользователь регистрируется в интернет-магазине. Конечно, магазину обязательно нужно знать адрес пользователя, но на этапе регистрации лучше его не спрашивать. Возможно, пользователь не захочет ничего покупать и адрес не потребуется. Но куда более неприятно будет узнать, что пользователь, увидев дюжину обязательных полей, передумал регистрироваться и иметь дело с этим магазином. 2) Можно ли заполнить обязательное поле каким-нибудь значением по умолчанию. Например, ваш интернет-магазин делает доставку только по Москве и Московской области. Поэтому поле “город” лучше всего не оставлять пустым, а по умолчанию вписать в него самый большой город на обслуживаемой территории – Москва. Всегда проверяйте, что валидация отсекает все ненужные символы. Даже если список разрешенных символов не оговорен, то лучше все равно добавить валидацию на специальные символы. Сложно предугадать поведение

– обязательность заполнения поля; – запрещенные символы; – формат введенных данных; – уникальность данных; – истинность данных (Captcha). Валидация на обязательность заполнения поля – наиболее частый кейс. Ее работу легко проверить. Оставьте обязательное поле пустым и нажмите кнопку [Submit]. Мы должны увидеть сообщение об ошибке, например: Также можно сделать пару кейсов, введя в поле только пробелы. Так как пробелы обрезаются, а кроме них ничего не введено, то поле

конечно. Оно должно сохраниться в базу как NULL (специальное значение, которое используется для заполнения пустых ячеек). – Проверьте, что пробелы, введенные в начале и в конце строки, обрезаются (truncate) при сохранении. Пробел может быть введен пользователем случайно и не замечен, так как он не виден. Пробелы могут вызвать проблемы, так как они могут повлиять на сортировку по этому полю, могут повлиять на результаты поиска и т.д. Валидация Говоря об элементах ввода, нельзя не упомянуть про такое понятие, как валидация. В нашем контексте валидация – это проверка данных перед сохранением. Мы проверяем, что данные соответствуют нашим ожиданиям. Например, мы проверяем, что в числовое поле пользователь не ввел буквы. Валидация позволяет нам избежать заведомо некорректных данных и повышает стабильность работы программы. Если пользователь пытается ввести некорректные данные, то при срабатывании валидации пользователю будет выведено сообщение о том, что он сделал не так и как это исправить. Чаще всего валидация срабатывает при нажатии на кнопку [Submit], но бывают и другие способы вызвать валидацию. Об этом чуть позже. Работа валидации также должна быть описана в требованиях. Частично она вытекает из требований к типу и формату данных, принимаемых полем.

преобразуются символы в XML: " – " ' – ' < – < > – > & – & Примеры зарезервированных символов в различных языках: XML: ‘ “ < > & HTML: ‘ “ < > & JSON: ‘ “ \ SQL: ‘ – Поле разрешает ввести количество символов, указанное в требованиях, но также не разрешает превысить это количество. Плохо, если поле разрешает ввести большее количество символов, чем нужно. При попытке сохранить строку с длиной, превышающей максимальную для этого поля, случится ошибка или часть строки обрежется. Если количество символов не оговорено, то проверьте, что оно достаточно, руководствуясь здравым смыслом. – Проверьте, как сохраняется пустое значение (в поле ничего не введено), если оно разрешено,

Текстовое поле (Input text field) – это основной элемент, предназначенный для ввода текстовых данных. Что нужно проверить: – Пользователь может осуществить ввод текста в поле. Это особенно актуально, если Ваше приложение может быть запущено с мобильного устройства без физической клавиатуры. Виртуальная клавиатура может не появиться при установке фокуса в поле. – Пользователь может ввести с клавиатуры все разрешенные символы. Бывает так, что поле имеет защиту от ввода некоторых специальных символов. Поэтому нужно проверить, что разрешённые символы не под запретом. Проверьте, что не возникает ошибок при сохранении данных, имеющих все разрешенные символы. Особенно важно это проверить, если поле должно принимать все символы, которые можно ввести с клавиатуры. Чаще всего возникают ошибки при вводе символов, которые являются зарезервированными в таких языках как XML, JSON, HTML, SQL, так как эти языки используются для передачи и хранения данных. Использование зарезервированных символов может нарушить работу приложения, если они не были преобразованы в специальную последовательность разрешенных символов (escape or encode). При извлечении данных из базы происходит обратное преобразование (decode). Весть процесс не заметен для пользователей.

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

Например, может быть не уточнено, какое количество символов может принимать поле “Имя”. Поэтому мы будем руководствоваться здравым смыслом в определении максимальной длины ввода, и не будем раздражать заказчика большим количеством вопросов. На данном этапе мы будем считать, что все ключевые требования собраны и понятны, а остальные аспекты интуитивно понятны.

Для этого выполним самый позитивный кейс (case). Кейс – это тестовый случай. Если весь процесс тестирования разделять на кусочки, то кейс – это минимально возможный кусочек, как квант для энергии или фотон для света. Под самым позитивным кейсом понимают действия, которые пользователи будут выполнять чаще всего. Например, в поле “Имя” пользователи чаще всего будут вводить значения типа “Иван”, “Петр” и т.д., а затем будут нажимать кнопку [Submit]. Это и будет самый позитивный кейс. Начинать тестирование всегда нужно с самых позитивных кейсов. Это непреложная истина тестирования. Начинать тестирование поля “Имя” с ввода строки типа “?><@!#” – дурной тон

Для этого выполним самый позитивный кейс (case). Кейс – это тестовый случай. Если весь процесс тестирования разделять на кусочки, то кейс – это минимально возможный кусочек, как квант для энергии или фотон для света. Под самым позитивным кейсом понимают действия, которые пользователи будут выполнять чаще всего. Например, в поле “Имя” пользователи чаще всего будут вводить значения типа “Иван”, “Петр” и т.д., а затем будут нажимать кнопку [Submit]. Это и будет самый позитивный кейс. Начинать тестирование всегда нужно с самых позитивных кейсов. Это непреложная истина тестирования. Начинать тестирование поля “Имя” с ввода строки типа “?><@!#” – дурной тон.

Кейс – это тестовый случай. Если весь процесс тестирования разделять на кусочки, то кейс – это минимально возможный кусочек, как квант для энергии или фотон для света. Под самым позитивным кейсом понимают действия, которые пользователи будут выполнять чаще всего. Например, в поле “Имя” пользователи чаще всего будут вводить значения типа “Иван”, “Петр” и т.д., а затем будут нажимать кнопку [Submit]. Это и будет самый позитивный кейс. Начинать тестирование всегда нужно с самых позитивных кейсов. Это непреложная истина тестирования. Начинать тестирование поля “Имя” с ввода строки типа “?><@!#” – дурной тон.