Как тестировать поле ввода информации
Всем доброго времени суток. Помогите неопытному тестировщику составить собственный список на что надо проверять поле ввода информации. Уверен, что у всех опытных тестировщиков, есть такой список. Поделитесь если не жалко.
Сам я ничего кроме самых простых типо (ввести одни пробелы, не вводить текст, ввесть HTML, SQL, JS, сложную комбинацию символов, ну и ещё нескольких не замослыватых пунктов не нашёл).
Всем доброго времени суток. Помогите неопытному тестировщику составить собственный список на что надо проверять поле ввода информации. Уверен, что у всех опытных тестировщиков, есть такой список. Поделитесь если не жалко.
Сам я ничего кроме самых простых типо (ввести одни пробелы, не вводить текст, ввесть HTML, SQL, JS, сложную комбинацию символов, ну и ещё нескольких не замослыватых пунктов не нашёл).
вобщем многое зависит от того что за поле вообще.
+ проверка на ограничение поля
+ проверка работы кнопок Del, BackSpace, Tab, вперед,назад,Enter, Ctrl+V (вставка текста больших размеров..) в данном поле + проверка в разных браузерах (IE,FF,Chrome,Opera..)
+ проверка снятия ограничений наложенных на поле (размер, ограничение на какието символы), ввод невалидных данных, сохранение изменений.
Всем доброго времени суток. Помогите неопытному тестировщику составить собственный список на что надо проверять поле ввода информации. Уверен, что у всех опытных тестировщиков, есть такой список. Поделитесь если не жалко.
Сам я ничего кроме самых простых типо (ввести одни пробелы, не вводить текст, ввесть HTML, SQL, JS, сложную комбинацию символов, ну и ещё нескольких не замослыватых пунктов не нашёл).
Самые простые и эффективные способы тестирования поля ввода текста
Любое текстовое поле в создаваемом программном обеспечении кажется таким простым и понятным функционалом, что процесс тестирования сводится к банальной проверке правильности его заполнения. Но, это только на первый взгляд.
Проверять правильность работы текстового поля нужно с особой тщательностью, ведь с его помощью можно очень быстро получить несанкционированный доступ к базе данных!
Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить манипуляции с пользовательскими файлами и данными. Также это своего рода защита перед появлением в БД вредной информации.
Подобные вирусные файлы могут вызвать проблемы с функционированием веб-продукта как на стороне клиента, так и на стороне сервера. Ну и наконец, корректная валидация позволяет сразу же предотвратить атаки межсайтового скриптинга и вредоносных SQL-инъекций хакеров.
Основные типы проверки текстового поля
Проверять работоспособность текстового поля можно очень многими способами. Мы выделим наиболее важные проверки, которые QA-специалист должен выполнять в обязательном порядке при тестировании текстовых полей.
Тестирование форм без спецификации
Итак, представим, что необходимо проверить текстовое поле, о котором нет особой информации в спецификации на проекте.
В подобной ситуации можно выполнить следующие проверки:
Проверка полей на основе технической документации
Представим, что мы кое-что знаем о формах, знаем какие примерные значения можно вводить в форму, а также каковы ограничения в них установлены.
Тестирование поля с известными данными
Итак, что мы можем конкретного проверить:
Для всего вышеизложенного перечня проверок стоит выяснить, какие именно сообщения об ошибке отображаются и убедится в том, что все сообщения при валидной отправке тоже корректны.
Тестирование текстовых полей + автоматизация
Без автоматизации тестирования в данном случае тоже никак не обойтись.
Если тестировщик выполнил полный перечень ручных проверок, скорее всего нет надобности в автоматизации тестов. Более того, множество форм состоит из нескольких полей, а значит масса тестов для каждого по отдельности – это огромное количество потраченного времени на их выполнение.
Тем не менее, целесообразной будет автоматизация следующих пунктов:
Конечно же, это неполный перечень того, что можно тестировать при проверке форм. Но данный список можно использовать как базовый набор проверок, которые стоит в обязательном порядке выполнять при работе с текстовыми формами.
Тестировщик никогда не должен верить разработчику на слово, что все и так работает, и незачем лишний раз себя утруждать монотонными проверками. Ведь при нахождении клиентом технической уязвимости, спросят в первую очередь именно с проверяющего!
Как тестировать текстовое поле
Что пишут в блогах
В этом видео Крутов рассказал про инструменты Moon и Moon Cloud. Обсудили новые фичи: поддержка Selenium 4, Playwright, Cypress.
29-30 октября в Москве пройдет международная конференция по тестированию SQA Days!
Продолжу хвастаться статусом книги.
В этом выпуске говорили о новостях мира тестирования за август 2021: книги, полезные материалы и новые релизы инструментов. Новые эпизоды «Вечера грязи».
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Все примеры тестов строятся на числах:
Тестировщики кивают головами и говорят — «Все понятно!». А потом им предлагают строковое поле и все, ступор о_О
Что вводить в строку? Символы русские, английские, спецсимволы, циферки, перемешал — готово! Но так и робот может проверить, тестировщик то зачем?)) И как вы отловите баги, когда имя “Иван” считается некорректным, потому что распространенное? (А такое бывает — пруфлинк, поиск по «Иванов Иван Иванович»)
Тренер Ольга Назина подготовила пример тестирования поля «Имя» для своих студентов — смотрите и вдохновляйтесь! 🙂 Столько уникальных для поля тестов, а ведь казалось бы, простая строка.
Это выдержка из лекции про классы эквивалентности курса «Техники и инструменты поиска и оформления дефектов». Без знания о классах эквивалентности и граничных значениях никуда, особенно при поиске багов. Поэтому мы сделали отдельную тему для отработки навыка. Приходите, будет интересно 🙂
Как тестировать текстовое поле
Моды для сервера
Огромный выбор различных модификаций для Вашего сервера. Пролистайте эти темы! Возможно именно там Вы найдете то, что искали уже давно.
Модификации SA
Хотите разнообразить свою игру в San Andreas? Смелее в наш раздел. Отличный сборник готовых решений. Играйте с удовольствием
ShTorm
Эксперт
При разработке диалоговых окон с полем для ввода, различных команд для ввода в чат, многие разработчики допускают как незначительные, так и значимые ошибки, которые могут серьезно повлиять на работу игрового сервера. Во избежание множества дефектов, связанных с недостаточными знаниями разработчика при разработке функционала полей, имеет место пользоваться глобальным чек-листом тестирования текстового поля.
Примерный алгоритм использования техники анализа граничных значений:
1. Во-первых, нужно выделить классы эквивалентности. Опять же, это очень важный шаг, и от правильности разбиения на классы эквивалентности зависит эффективность тестов граничных значений.
2. Далее нужно определить граничные значения этих классов.
3. Нам нужно понять, к какому классу будет относиться каждая граница.
4. Для каждой границы нам нужно провести тесты по проверке значения до границы, на границе, и сразу после границы.
Количество тестов для проверки граничных значений будет равно количеству границ, умноженному на 3. Рекомендуется проверять значения вплотную к границе. Например, если мы имеем диапазон целых значений, и граница у нас находится в
числе 10, то мы будем проводить тесты
❖ с числом 9 (вплотную до границы),
❖ 10 (саму границу)
❖ 11 (сразу после границы)
Используя данный чек-лист при работе с полями, Вы можете сократить количество выходящих дефектов.
Для полей функционала логин/пароль существует чек-лист тестирования полей логин-пароль .
Разрабатывайте, тестируйте и выпускайте свои системы с наименьшим количеством дефектов!
Чек-лист для тестирования числового поля
При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.
Сегодня мы разберем чек-лист для числового поля. Сначала я напишу общий чек-лист, потом пройдемся по каждому пункту и разберемся, зачем он нужен, а в конце напишем чек-лист по этому шаблону.
Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:
При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.
Какие проверки тут можно провести:
Корректные значения
Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:
Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:
Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.
Также важно понимать, что у нас может быть не одно корректное значение. Это когда у нас есть несколько диапазонов, и разные условия на каждом.
Например, тот же возраст:
Или если у нас идет расчет страховки в зависимости от стажа вождения:
Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.
Некорректные значения
Тут есть разные варианты. Что значит некорректное значение?
— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.
Потом внимательно смотрим на выбранный интервал:
— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:
— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.
Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!
А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.
Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!
Граничные значения
Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.
В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида:
