Чтобы подобрать граничные значения для тестирования, сначала задайте допустимый диапазон, включение его концов, тип данных и шаг. Для целого количества от 1 до 100 включительно полезны проверки 0, 1, 2, 99, 100 и 101. Но сами числа ещё не образуют тест: для каждого нужен ожидаемый результат из требований.
В упражнении Mentoring.digital составим проверки поля количества. Условия и значения ниже учебные. Их нельзя переносить в любой продукт без уточнения бизнес-правила.
Уточните, что означает диапазон
Примем контракт: количество является целым числом от 1 до 100 включительно. Ноль и отрицательные значения запрещены. Дроби, строки, пустое значение и логические значения не принимаются. Ошибка должна мешать отправке заявки с неверным количеством, а не молча превращать его в другое число.
Фраза «максимум 100» сама по себе не отвечает на вопрос о минимуме, дробях и строке "100". Отдельно уточняйте поведение интерфейса и API. Форма может показывать строку, затем преобразовывать её в число, но правила этого преобразования тоже относятся к требованиям.
Разделите данные на классы и отметьте переходы
Для целых значений у нас три области: меньше 1, от 1 до 100, больше 100. Изменение ожидаемого поведения происходит при переходах 0/1 и 100/101. Типовые ошибки здесь связаны с перепутанными операторами сравнения или неверно указанным пределом.
В терминологии ISTQB CTFL 4.0.1 анализ границ применяется к упорядоченным классам. Двухточечный вариант проверяет граничное значение и ближайшего соседа другого класса, трёхточечный также захватывает соседние значения с обеих сторон. В нашем упражнении добавим 2 и 99, чтобы проверить поведение сразу внутри разрешённой области.
Запишите ожидаемый результат для каждого случая
- 0: отклонить, количество ниже минимума.
- 1: принять нижнюю границу.
- 2: принять значение сразу внутри диапазона.
- 99: принять значение перед верхней границей.
- 100: принять верхнюю границу.
- 101: отклонить, количество выше максимума.
Добавьте обычное внутреннее значение, например 50. Это не новая граница, но полезная контрольная проверка. Пустое поле, дробь и текст проверяются отдельно: они не становятся целочисленными граничными значениями только потому, что система их отклоняет.
В отчёте фиксируйте не только «ошибка появилась», но и конкретное поведение: заявку не создали, значение осталось доступно для исправления, сообщение соответствует нарушенному правилу. Если API должен возвращать определённый код и структуру ошибки, берите их из контракта, а не придумывайте по привычке.
Проверьте правило отдельно от интерфейса
def valid_quantity(value):
return type(value) is int and 1 <= value <= 100
cases = {0: False, 1: True, 2: True, 99: True, 100: True, 101: False}
for value, expected in cases.items():
assert valid_quantity(value) is expected
for value in (True, "1", 1.5, None):
assert valid_quantity(value) is FalseЭтот пример на Python проверяет только заданный предикат. Он не доказывает, что браузерная форма, сервер или база применяют то же правило. Например, интерфейс может блокировать 101, а прямой запрос к API всё равно принимать его. Для продукта потребуются проверки на соответствующих уровнях.
Полезное упражнение: замените <= 100 на < 100 и убедитесь, что случай 100 обнаруживает ошибку. Затем временно разрешите только 1 и 100: проверки внутри диапазона должны обнаружить неверную реализацию. Не ограничивайтесь тем, что тесты проходят на правильной функции.
Учтите шаг и сочетания условий
Для суммы с точностью до копейки ближайший сосед отличается на 0,01, а не на 1. Для времени нужно определить точность и часовой пояс. Для длины текста уточните, что именно считается символом. Без этого один и тот же тест может трактоваться по-разному.
Если допустимый максимум зависит от тарифа или остатка товара, одного диапазона недостаточно. Сначала составьте сочетания условий, затем проверяйте границы для каждого нужного правила. Граничный анализ не покрывает автоматически все комбинации, состояния и ошибки интеграции.
На курсе тестирования с наставником можно превратить требования своего проекта в набор проверок. Наставнику по QA покажите формулировку правила, таблицу ожидаемых результатов и спорные случаи, чтобы разобрать именно тест-дизайн.
