Негативные тест-кейсы: топ 10

Для чего нужны негативные тест кейсы, ясно видно из их названия. Они исследуют работоспособность приложения при вводе «неправильных» данных. Подобные исследования просто необходимы в ходе тестирования программного продукта. Мы предлагаем вам десятку самых популярных из негативных ситуаций для проверки:

1. Embedded Single Quote, или внутренние одинарные кавычки, зачастую вызывают проблемы во многих SQL базах. Поэтому стоит проверить на этот счет каждое поле ввода.
2. Required Data Entry, или обязательный ввод. Если поле указано как обязательное для заполнения, то необходимо проверять, как себя поведет приложение при отсутствии в нем данных.
3. Field Type Test, или проверка типа данных полей. Спецификация приложения должна четко определять тип данных каждого поля, поэтому также необходимо проверить введение несоответствующего типа данных.
4. Field Size Test, или проверка размера поля. В приложении четко определяется максимально возможное количество символов в каждом поле, не забываем проверять, как ведет себя программа при превышении этого лимита, предупреждает ли пользователя об ошибке и принимает ли такие данные в расчет.
5. Numeric Bounds Test, или проверка числовых граничных значений. Числовые поля, как известно, имеют ограничения допустимых значений чисел. Подобные ограничения либо вытекают из логики работы приложения, либо определяются программистом в спецификации. Поэтому, так же как и в предыдущем случае, проверяем реакцию приложения при вводе значений за рамками допустимого диапазона.
6. Numeric Limits Test, или числовые ограничения. Большинство языков программирования и баз данных числовые значения определяют как переменные определенного типа. И уже, в свою очередь, тип данных может иметь собственные ограничения. Например, как известно, старый добрый integer имеет диапазон от -32768 до 32767. Поэтому даже если спецификация не ограничила значения, их нужно проверять на соответствие ограничениям типа данных.
7. Date Bounds Test, или проверка граничных значения даты. Речь идет о логических ограничениях в полях даты и времени. Например, дата рождения пользователя не может быть еще не наступившим днем календаря или относиться к 17 веку. Проверяем!
8. Date Validity, или валидность даты. Помним, что месяцев ровно 12, что число не может быть 32, а в високосном году есть 29 февраля. Помним, учитываем и снова проверяем!
9. Web Session Testing, или проверка веб-сессии. Здесь мы тестируем использование браузерных сессий, которые отслеживают вошедших в систему пользователей. И не забываем, что многие функции не должны быть доступны не вошедшим в систему посетителям.
10. Performance Changes, или изменения производительности. Необходимо осуществлять проверку производительности приложения после релиза каждой новой версии продукта или при внесении любого рода изменений кода.

Дополнительно: 1