С помощью негативных тест-кейсов выполняются проверки на уровень функциональности программного обеспечения при условии использования негативных данных. Подобные тест-кейсы необходимо выполнять при проверке любого ПО.
Далее будут приведены 10 самых используемых негативных тестовых сценариев, которые должны применяться на постоянной основе.
1. Внутренние одинарные кавычки (Embedded Single Quote)
В большей части базы данных SQL могут возникать некоторые проблемы с наличием одинарных кавычек в теле запроса (к примеру, Ritchie’s car).
Всегда применяйте одинарные кавычки при валидации каждого поля ввода, функционирующего с БД.
2. Обязательный ввод данных (Required Data Entry)
В любой спецификации на продукт всегда необходимо указывать все поля, где требуется в обязательном порядке вводить данные. Помните о том, что все формы, которые содержат цифирные или текстовые поля, определенные как «обязательные», не сохраняются при полном отсутствии информации в них.
3. Виды данных полей (Fields Type test)
Спецификации для ПО должны содержать типы данных, определенные для каждого конкретного поля (поле даты, времени, числовые поля, поля для контактных телефонов, поле для email и прочее). Всегда нужно проверять любое текстовое поле на его возможность свободно вводить / выводить (и сохранять) из спецификации исключительно определенный вид информации (к примеру, программа должна отображать запрет на введение пользователем букв или специальных символов, если данное поле числовое).
4. Размеры полей (Fields Size Test)
Информационные критерии соответствия ПО заявленным требованиям должны валидировать только четко установленному максимальному набору знаков в каждом поле. К примеру, сумма знаков в поле с именем пользователя должна быть не более 50 знаков. Нужно тестировать, что программа запрещает пользователю вводить или сохранять в системе большее количество знаков, нежели указанно в содержании спецификаций.
Всегда помните о том, что информация любого поля должна не просто корректно валидироваться, но и иметь возможность сообщать пользователю об установленных ограничениях. Например, оповещения на основе использования пояснительных текстовых блоков или всплывающих окон с ошибками.
5. Проверка числовых ограничений (Numeric Bounds Test)
Некоторые числовые поля ПО могут содержать определенные ограничения на ввод допустимых числовых комбинаций. Подобные ограничения могут находиться в спецификации продукта или происходить из логики его работы.
К примеру, перед вами поставлена задача по проверке функциональности, которая касается начисления процентов на счет. В таком случае, тест-кейс должен быть нацелен на проверку возможности начисленных процентов нести в себе отрицательные индексы (то есть, такое возможно или нет).
Всегда стоит тестировать ПО на выдачу ошибки в ситуации, когда значения находятся за границами валидного диапазона данных. Как пример, информация об ошибке должна отображаться при вводе данных 19 и 26 при возможном значении от 20 до 25.
6. Числовые ограничения (Numeric Limits Test)
Существует большое количество БД и языков программирования, которые определяют числовые значения в форме переменных с некоторым видом.
Крайне важно тестировать граничные данные применяемых в БД переменных для числовых полей, граничные показатели которых не четко выделены и расписаны в содержании спецификации.
7. Гранично-допустимые значения даты (Date Bounds Test)
Есть программы, которые содержат логические ограничения для полей, демонстрирующих время и дату. К примеру, если проверяющий тестирует поле даты рождения пользователя, правильным будет выполнить проверку на возможность ввода будущей даты (то есть такой, которая физически еще не наступила). Также стоит проверить ограничение на ввод даты, разнящейся от необходимой более чем на 150 лет.
8. Валидная дата (Date Validity)
Поле даты обязательно должно содержать запрограммированную проверку ввода валидных значений. И всегда стоит помнить о надобности тестирования даты в високосный год.
9. Веб-сессии (Web Session Testing)
Множество веб-программ основаны на работе браузерных сессий и направлены на отслеживание пользователей, вошедших в систему. При этом они дополнительно применяют массу специфических конфигураций для определенного виртуального пользователя.
Кроме того, некоторые функциональные возможности ПО не могут и не должны работать без шага предварительного логирования в системе. Нужно тестировать ПО на то, что страницы или логика работы ПО после логирования абсолютно недоступны пользователям, которые не прошли процесс верификации в системе.
10. Настройки производительности (Performance Changes)
Все новые версии программного обеспечения должны внедряться в использование только после стадии тестирования их производительности (скорость добавления данных, процесс удаления информации и прочее).
Сравнивайте итоги с тестами производительности ранних модификаций продукта. Такая стратегия тестирования позволяет изначально находить возможные проблемы производительности, которые могут возникнуть вследствие редактирования программного кода в новых версиях ПО.
Оставить комментарий