Чек-лист для тестирования числового поля
При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.
Сегодня мы разберем чек-лист для числового поля. Сначала я напишу общий чек-лист, потом пройдемся по каждому пункту и разберемся, зачем он нужен, а в конце напишем чек-лист по этому шаблону.
Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:
При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.
Какие проверки тут можно провести:
Корректные значения
Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:
Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:
Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.
Также важно понимать, что у нас может быть не одно корректное значение. Это когда у нас есть несколько диапазонов, и разные условия на каждом.
Например, тот же возраст:
Или если у нас идет расчет страховки в зависимости от стажа вождения:
Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.
Некорректные значения
Тут есть разные варианты. Что значит некорректное значение?
— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.
Потом внимательно смотрим на выбранный интервал:
— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:
— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.
Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!
А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.
Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!
Граничные значения
Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.
В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида:
четверг, 5 апреля 2018 г.
Классы эквивалентности для строки, которая обозначает дату
Большинство примеров про классы эквивалентности приводятся для чисел. Самый заезжанный пример — тестирование калькулятор. Он используется в книгах и статьях, потому что простой и понятный.
Но потом доходит до дела и сразу ступор: а как применять классы эквивалентности где-то еще? Ладно, используем правило «ищи число»: если речь идет о поле с символами, берем длину поля (число) и тестируем на границы. Вроде все хорошо, логично и понятно.
Однако на своих студентах я заметила, что это правило стало серебряной пулей. Если это нечисловое поле — по границам тестируем ТОЛЬКО на длину. Точка. Просишь протестировать дату, получаешь примерно такой ответ:
Четкий формат дд.мм.гггг
Допустим, я могу ввести в профиле свою дату рождения и система сама посчитает, сколько мне лет. Формат даты известен заранее, на поле стоит маска, дату в другом формате я ввести не смогу.
Если никаких ограничений нет, все равно включаем логику — дата рождения не может быть отрицательной. Так что уже как минимум есть граница в TODAY (сегодняшнее число). Надо проверить, можно ли ввести меньше и больше.
По идее, календарик должен блокировать выбор дальше текущего числа. Логично, конечно, усложнить и не давать вводить возраст до 4 лет, но это дополнительные ограничения из серии «а зачем?». А вот «не вводить дальше, чем сегодня» — стандартная практика, вполне можно использовать.
Если ввели с клавиатуры, можно подсвечивать поле красным и выдавать ошибку «Дата рождения должна быть меньше текущей даты». Но даже если никаких ограничений нет, мы просто проверяем, как поведет себя система при вводе этой логической границы и попытке выйти за ее пределы.
Но как быть с другими границами? Которых нет в ТЗ.
Нижняя граница
Конечно, это негативная проверка из серии «упадет / не упадет». Зачем нам четыре теста вместо одного? Потому что разработчик мог поставить защиту от дурака от даты «00.00.0000», а вот если нули только в одном компоненте — ой, все пропало.
Если говорить о нижней границе, то помимо нуля я рекомендую проверить:
А еще некоторые системы сбрасывают в «01.01.1900» всякий треш, пришедший на входе. Ведь с точки зрения системы это вполне корректная дата, так что это бывает значением «по-умолчанию». По крайней мере, я видела такое поведение в системах, с которыми мы интегрировались на работе.
Верхняя граница
Просто строка с датой
 |
| Просто поле для ввода |
Даже если у нас нет ограничения на формат, мы сначала смотрим на строку как на дату. Это очень важно — видеть в поле тот смысл, который заложил туда разработчик, а не просто абстрактную строку. Вы ведь не знаете заранее, как она обрабатывается. Может быть, никак, это правда строка. А может, над ней висят какие-то правила, ограничения, преобразования.
Поэтому наш план действий:
Как тестировать дату конкретного формата, мы рассмотрели выше. Надеюсь, не надо пояснять, что маска на поле может быть любой, хоть дд.мм.гггг, хоть гггг/мм/дд, хоть какая-то другая. Это не мешает нам подставить туда все нули, все девятки или ввести магическое 01.01.1900.
Рассмотрим оставшиеся пункты.
Разные форматы даты
Система умеет работать только с российским форматом? Или с другими тоже? Проверяем основные:
Поле ввода с датой DatePicker
Поле помогает вводить дату с клавиатуры или выбирать ее с помощью мыши.
Когда использовать
Используйте поле с датой, когда нужно ввести дату в формате ДД.ММ.ГГГГ.
Описание работы
Поле с датой отличается от обычного поля ввода наличием иконки, маски и блока календаря.
Календарь и маска появляются всегда, когда поле получает фокус. Для этого можно кликнуть по самому полю или иконке, также можно перейти в поле табом.
Быстрый ввод
Если можно предположить, какое значение введет пользователь, предложите быстрый ввод соответствующих дат:
Блок календаря
Блок календаря состоит из заголовка и скроллируемой области с календарной сеткой. Когда курсор находится над календарной сеткой, основной скролл страницы блокируется.
В заголовке показывается название текущего месяца и года.
Календарный блок «следует» за значением в поле: поменяли месяц с клавиатуры — календарь прокрутился до соответствующей даты.
Выбор месяца и года
При клике на год или месяц раскрываются соответствующие списки. Список открывается «вокруг» выбранного пункта, но если верхняя граница списка оказывается за пределами экрана, список смещается вниз, так чтобы верхняя граница вошла.
В списке годов одновременно показывается 11 пунктов, чтобы сверху и снизу было по 5 строк. Список также можно прокручивать колесом мышки, или кнопками вверху и внизу списка: однократное нажатие прокручивает список сразу на 3 строки, если зажать кнопку, список начнет прокручиваться непрерывно. Нажатие клавиши Esc закрывает список, другого управления с клавиатуры у списка нет.
После выбора месяца или года из раскрывающегося списка, значение подставляется в поле ввода, календарь прокручивается к соответствующей дате.
Сегодня
В нижней части календаря есть кнопка «Сегодня», нажатие на которую прокручивает календарь до текущего месяца, выбирается текущий день. Календарь при этом не закрывается — это полезно для сценариев, когда пользователю нужно выбрать дату близкую сегодняшней.
Если выбор текущей даты не нужен по сценарию, кнопку можно не показывать.
Выходные и праздничные дни
В контрол можно передать данные производственного календаря. Компонент подсветит красным праздничные дни, так же как выходные.
Данные производственного календаря можно взять через API портала открытых данных РФ на data.gov.ru.
Неактивные дни
Если пользователь должен выбрать дату только внутри заданного периода — ограничьте выбор, передав в параметры максимальную и минимальную дату. Недоступные для выбора дни будут отображаються серым и высветленным красным.
Размер и расположение
Поле ввода с датой, как и обычное поле ввода, может быть трех размеров. Подробнее смотри в гайде поля ввода.
Не корректно реализовано в библиотеке React UI — #2025
Работа с клавиатурой
Редактирование значения в поле отличается от обычного поля с маской. При получении фокуса в поле не появляется текстовый курсор, вместо этого выделяется одна из трех частей даты.
Если фокус получает пустое поле, всегда выделяется первый блок:
После ввода двух цифр выделение переходит на месяц:
После ввода одной цифры можно нажать пробел, точку или запятую — фокус будет переведен на следующую часть даты.
После ввода четырех цифр года выделение остается на месте, если пользователь продолжает набирать — ввод игнорируется как в поле с маской: поле вспыхивает синим, значение не меняется.
Не корректно реализовано в библиотеке React UI — #1970
В заполненном поле клик мышкой выделяет ту часть даты, над которой был курсор:
Нажатие клавиш ← → перемещает область выделения:
Клавиши ↑ ↓ увеличивают или уменьшают выделенное значение на 1. Увеличение/уменьшение затрагивает только выделенное значение, например, за 31 января, следует 1 января и наоборот:
Если период выбора даты ограничен, увеличение/уменьшение просто останавливается у границы. Например, нельзя выбирать дату позднее 31 декабря 2020 года — при нажатии клавиши ↑ поле вспыхивает синим, но значение не меняется:
Backspace работает как в обычном поле с маской: последовательно удаляет цифры с конца выделенной части даты, перепрыгивая разделители-точки:
Если пользователь ввел число из одной или двух цифр — контрол считает это указанием дня текущего месяца.
Поле корректно обрабатывает вставку даты из буфера обмена, приводя значение к правильному формату:
Валидация
Некорректные даты должны быть заблокированы в блоке с календарной сеткой. Если пользователь указал некорректную дату с помощью клавиатуры, при потере фокуса поле валидируется и подсвечивается красным:
Если поле обязательно для заполнения:
О поведении полей ввода с ошибками читайте в гайде по валидации.
Дизайн
Правила выделения дат и наведения, как в раскрывающемся списке: наведение — белый текст на синем фоне, выбранная дата — серый фон.
Выбранный день выделяется серым кружком #E9E9E9.
Заблокированные дни отображаются с прозрачностью 50 %.
Анимация
При прокрутке название следующего месяца выталкивает текущий месяц из заголовка.
То, что поможет начинающему тестировщику
I. Дата и время:
Американский/Канадский формат даты/времени представлен в виде mm/dd/yyyy (hh:mm:ss).
Европейский формат даты/времени представлен в виде dd-mm-yyyy (hh:mm:ss).
Тестирование осуществляется по следующим этапам:
1. Вводятся типичные правильные значения, и проверяется связанная с полем функциональность (“05/05/2005” или “05-05-2005”).
2. Вводятся типичные неправильные значения, и проверяется присутствие валидации (“dfg”).
3. Вводятся граничные правильные значения. Каждый элемент (день, месяц, год, час, минута, секунда) тестируются отдельно. Можно совмещать в один тестовый пример тестирование нескольких элементов одновременно, но при нахождении ошибки нужно провести тестирование каждого элемента по отдельности. Это значит, что только один элемент принимает граничное правильное значение, а остальные – типичные правильные.
Границы правильных значений:
3.1. Месяц: 01..12.
3.2. День: 01..max_in_month, где max_in_month – максимальное количество дней в выбранном месяце. Варианты: 02/29/2000, 03/31/2000.
3.3. Год: 1753..9999.
3.4. Час: 00..23.
3.5. Минута: 00..59.
3.6. Секунда: 00..59.
3.7. Если дата не может быть будущей, то вводим сегодня/сейчас.
3.8. Если 2 даты означают диапазон, то вводим одинаковые даты.
4. Дата/время остаются правильными если:
4.1. Месяц/день/час/минута/секунда представлены одной цифрой.
4.2. Секунды отсутствуют.
6. Производятся атаки на поле:
6.1. DoS атака. Строка содержит очень много символов (0,1-1Мб).
6.2. Строка содержит спецсимволы («♦♣☺♂»).
6.3. XSS атака. Строка содержит html или php теги. Примеры:
6.4. SQL инъекция. Строка содержит SQL команды в правильном формате для исполнения: ’01/01/2000″; DROP TABLE users; SELECT * FROM data WHERE name LIKE «%’.
Далее у меня описаны правила тестирования числовых полей, полей для мыла, текстовых полей, text area и т.д.
P.S. Дал бы больше по этому топику, но сам только начал работать над этим. Правда еще есть чуть-чуть:
II. Числовой поле:
Числовые поля делятся на 2 вида: целые и дробные. Поля для дробных чисел обычно имеют форматер, устанавливающий определенное количество знаков за точкой (лишние знаки обрезаются, а недостающие заменяются нулями).
Тестирование осуществляется по следующим этапам:
2. Вводятся типичные правильные значения, и проверяется связанная с полем функциональность.
3. Вводятся типичные неправильные значения, и проверяется присутствие валидации и форматера.
4. Если форматер есть, и он не описан в спецификации, то обычно его не тестируют. Его работа проверяется при тестировании валидации.
Форматер может быть следующих типов:
а) не позволяет вводить нечисловую информацию;
б) после потери фокуса обнуляет значение, введенное неверно;
в) после потери фокуса убирает все нечисловые символы;
г) после потери фокуса сохраняет только числовую часть, которая стоит перед первым нечисловым символом.
Тестирование поля даты рождения
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова
Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую мы можем протестировать. Почему? Потому что текстовые поля дают доступ к приложению и его базе данных. Валидация текстового поля – это то, что предотвращает появление в базе плохих данных. Эти данные могут вызвать разнообразные проблемы для пользователей и разработчиков. Валидация также предотвращает атаки межсайтового скриптинга и SQL-инъекции.
Тестировать текстовое поле можно миллионами способов, и я коснусь этих способов в статье. Для начала давайте представим, что мы тестируем текстовое поле, не имея никакой информации о том, что оно делает:
Затем давайте предположим, что мы что-то знаем о том, что должно вводиться в это поле, и каковы ограничения для данных:
Для всех вышеописанных тестов выясните, какое сообщение об ошибке вы должны получать, и убедитесь, что получаете правильное сообщение.
И, наконец, нужно подумать об автоматизации. Если вы тщательно протестировали ваше поле вручную, то, возможно, нет необходимости автоматизировать все ваши тесты. Более того, большинство форм имеют более одного поля ввода, и куча тестов для каждого отдельного поля – это куча потраченного времени на прогон. Вот несколько советов, что можно автоматизировать:
Это не исчерпывающий список, а просто способ подтолкнуть вас к размышлениям о большом количестве тестов, которые можно прогнать, тестируя единственное поле. Не верьте на слово, что разработчик, создававший поле, добавил нужную валидацию, проверьте ее сами! Как-то раз я тестировала поле ввода даты, у которого было ограничение на год – он не мог быть меньше 1900 или больше, чем текущий год. Я получала нужное сообщение об ошибке, вводя 1880, но даты 1300 года легко принимались!
