Как тестировать поле ввода числа: проверки, ограничения и валидация

Что проверяют

Умеете ли вы применять техники тест-дизайна, а не перечислять «ввести буквы». Интервьюер ждёт классы эквивалентности и граничные значения, а следом почти всегда спрашивает, какие у поля требования. Сильный ответ с этого вопроса и начинается.

Как отвечать

Сначала уточните: целое или дробное, диапазон, обязательность, разделитель, сколько знаков после запятой, что происходит при ошибке (блокировка ввода, подсветка, сообщение). Без этого тесты превращаются в угадывание.

Дальше техники:

• классы эквивалентности: для диапазона от 1 до 100 это «меньше 1», «внутри», «больше 100» и нечисловой ввод. Из каждого класса хватает одного представителя;
• граничные значения: 0, 1, 2 и 99, 100, 101. Для дробного поля граница зависит от точности: 100.00 и 100.01;
• формат: запятая против точки (в русской локали пользователь напишет 12,5), пробелы по краям, ведущие нули 007, знак +5, экспонента 1e3, которую браузерный <input type="number"> пропускает;
• переполнение: очень длинное число, выход за int32 (2 147 483 647), потеря точности у дробных на бэкенде;
• способ ввода: вставка из буфера, автозаполнение, стрелки и колесо мыши у числового поля, цифровая клавиатура на телефоне.

Отдельно проверьте, что валидация есть и на сервере. Отправьте запрос в обход интерфейса через DevTools, Postman или curl: если бэкенд принял -5 или строку, это баг, даже когда форма такое не пропускает.

Автотесты строятся параметризованно по таблице значений: @pytest.mark.parametrize или @ParameterizedTest в JUnit 5, UI-часть через Playwright или Selenium.

Где спотыкаются

Проверяют саму границу без соседних значений. Ошибка < вместо <= ловится только парой «ровно на границе и рядом».

Забывают про локаль. Поле идеально работает с точкой и ломается у пользователя, который ставит запятую.

Ограничиваются интерфейсом. Клиентская валидация защищает от опечаток, но не от прямого запроса к API.