Негативные тест кейсы базируются на работе с неверными данными, то есть необходимы для проверки работоспособности продукта при их поступлении. Если проще, то целью негативных тест кейсов является проверка реакции приложения на ввод некорректных параметров.
Сделаем полезное дело - приведем 10 наиболее популярных негативных тест сценариев:
EmbeddedSingleQuote или Внутренние одинарные кавычки – у многих баз данных SQL при наличии в запросе одинарных кавычек, появляются проблемы, чтобы таковых не возникало, стоит использовать одинарные кавычки проверяя каждое поле ввода, которое работает с базой данных.
RequiredDataEntry или Обязательный ввод – спецификация приложения должна четко определять поля, которые требуют обязательного ввода данных. Потому каждую форму с полями обязательного ввода данных, необходимо проверить на невозможность сохранения без их присутствия.
FieldTypeTest или Типы данных полей – так же спецификация должна определять типы данных для каждого из существующих полей (числовые поля, поля даты/времени, поля для ввода номера телефона или почтового кода и т.д.). Исходя из этого, необходимо проверить каждое поле на сохранение данных исключительно определённых спецификацией.
FieldSizeTest или Размер поля – максимально допустимое количество символов в каждом поле тоже должно быть четко определено спецификацией. Данные поля при вводе больше граничного количества символов должны оповещать пользователя об ошибке.
NumericBoundsTest или Числовые граничные значения – ограничения допустимых числовых значений (в числовых полях) должны быть логично предугадываемыми (очевидными) либо так же прописаны в спецификации. Проверяйте приложение значениями, лежащими за пределами допустимого диапазона и граничными значениями. Детальнее метод Boundary - мы рассматриваем и изучаем на нашем Курсе для старта карьеры тестировщиком ПО :)
NumericLimitsTest или Числовые ограничения - не только логика и спецификация определяют ограничения допустимых числовых значений, но и большенство баз данных и языков программирования, определяющих числовые значения как переменные с некоторым типом (integer – в диапазоне от -32768 до 32767 или longinteger - от -2147483648 до 2147483647). В этом случае необходимо проверить граничные значения таковых переменных для существующих числовых полей, которые в свою очередь не имеют граничных значений определеных спецификацией.
DateBoundsTest или Граничные значения – это логические ограничения для полей даты и времени. Проверяйте невозможность «путешествий в будущее» или же границы допустимого прошлого (логично, что человек указывающий дату рождения не может появиться на свет в следующем году).
DateValidity или Валидность даты - ещё одно ограничение полей даты, задавая параметры, не забывайте сверяться с календарём, дабы понимать, что в апреле, июне, сентябре и ноябре не существует 31-го числа, не говоря уже о феврале, который ещё и високосным годом обделён.
WebSessionTesting или Веб сессии – исходя из того, что не редко веб приложения используют браузерные сессии для отслеживания вошедших пользователей, применяя специфические настройки приложений для конкретных из них, необходимо отслеживать функциональность находящуюся за паролем. Она должна быть недоступна без предшествующей авторизации.
PerformanceChanges или Изменения производительности – каждая новая версия продукта требует повторения тестов производительности, которое в сравнении с предыдущими результатами, позволит выявиться потенциальны проблемы, вызванные изменениями кода.
5 июня / 2014
Comentários