Практическая ситуация: поле принимает целое число от 1 до 100 включительно. Какие значения выбрать в первую очередь для ручной проверки и какой риск покрывает такой набор?
В первую очередь проверяют значения 0, 1, 2, 99, 100 и 101. Это значения непосредственно за пределами диапазона, на его границах и сразу внутри него; такой набор прежде всего выявляет ошибки проверки условий: пропуск допустимой границы, ошибочное включение недопустимого значения и смещение порога на единицу.
Анализ граничных значений появился как практический способ уменьшить число тестов без потери наиболее ценных проверок. Наблюдение, лежащее в основе подхода: дефекты часто возникают не в типичных значениях, а в местах перехода между допустимым и недопустимым состоянием.
Подход дополняет разбиение на классы эквивалентности. Вместо проверки большого количества чисел тестировщик выделяет области с одинаковым ожидаемым поведением и уделяет особое внимание их границам.
Диапазон от 1 до 100 включает обе границы. Ошибка в условии проверки может сделать значение 1 или 100 недопустимым либо, наоборот, пропустить 0 или 101.
Если проверить только 1, 50 и 100, можно не обнаружить дефект, при котором система принимает 0. Если проверить только типичное значение 50, тест почти не защищает от ошибок в логике границ, преобразовании данных или различиях между валидацией интерфейса и серверной частью.
Минимальный приоритетный набор строится вокруг обеих границ:
Ожидаемый результат для 1, 2, 99 и 100 — успешное принятие, а для 0 и 101 — отказ с корректной обработкой ошибки. Такой набор проверяет не только сами границы, но и переход через них.
На практике нужно отдельно проверить, где именно применяется ограничение: при вводе, потере фокуса, отправке формы, на сервере или при сохранении в базе данных. Если разные слои используют разные правила, интерфейс может принять значение, которое затем отклонит сервер, либо скрыть ошибку от пользователя.
Граничный анализ не заменяет другие проверки. Он не выявляет, например, ошибки в формате, переполнении, локали, пустом значении, пробелах или бизнес-правилах, не сводящихся к числовому диапазону. Для широких или непрерывных диапазонов также важно проверить представление числа, округление и тип данных.
Добавление типичного значения, например 50, полезно для проверки обычного сценария, но оно не заменяет шесть приоритетных граничных значений. Если стоимость тестов высока, сначала сохраняют проверки переходов через границы, а менее критичные комбинации выполняют позже.
В форме настройки скидки указано: допустимы целые проценты от 1 до 100. Тестировщик проверил 10, 50 и 90, после чего тест прошёл. В эксплуатации обнаружилось, что скидка 100% отклоняется сервером, хотя интерфейс считает её допустимой.
Рассматривались три варианта. Проверять несколько обычных значений было быстро, но такой вариант не покрывал пороги. Проверять все значения от 0 до 101 давало высокую полноту для этого поля, но избыточно при каждом ручном прогоне. Использовать набор 0, 1, 2, 99, 100 и 101 было дешевле и целенаправленно покрывало основной риск.
Выбрали третий вариант, дополнив его проверкой на интерфейсе и сервере. В результате обнаружили рассогласование: клиент разрешал 100, а сервер применял условие, допускающее значения только до 99. После унификации правила значение 100 стало корректно приниматься, а 0 и 101 — отклоняться с понятным сообщением.
Нет. Проверка только допустимых границ подтверждает их доступность, но не показывает, отклоняются ли ближайшие недопустимые значения. Она также не проверяет корректность перехода внутрь диапазона: ошибка в сравнении или преобразовании может проявиться именно на 0, 2, 99 или 101.
Да, если ограничение реализовано в обоих слоях или сервер является самостоятельной точкой приёма данных. Клиентская проверка улучшает обратную связь, но не должна быть единственной защитой: запрос может прийти из другого интерфейса, после изменения данных или при обходе пользовательской формы. Ожидаемые правила должны быть согласованы, иначе возникают противоречивые результаты и трудно диагностируемые дефекты.
Одних внешних границ будет недостаточно. Появятся дополнительные классы и границы вокруг правила кратности: например, нужно проверить значения 9, 10 и 11, а также 19, 20 и 21, если кратность относится ко всему диапазону. Диапазон и шаг — разные ограничения, поэтому для каждого значимого перехода применяют соответствующие граничные проверки; иначе система может правильно обработать 1 и 100, но принять 11 или отклонить 10.