Тест-дизайн

Анализ граничных значений тестирует края каждого диапазона входов, потому что дефекты скапливаются на границах (off-by-one, неверный оператор). Для диапазона проверяют минимум, максимум и значения чуть внутри и чуть снаружи каждого края, а не только середину раздела.

Классы эквивалентности делят входные данные на группы, которые система обрабатывает одинаково, после чего тестируется один представитель каждого класса. Предполагается, что любое значение в классе ведёт себя как остальные, поэтому число тест-кейсов сокращается при сохранении покрытия валидных и невалидных групп.

Хороший тест-кейс содержит уникальный ID, понятный заголовок, предусловия, упорядоченные шаги и явный ожидаемый результат; часто также приоритет и тестовые данные. Он должен быть однозначным, воспроизводимым и независимым, чтобы любой мог выполнить его и получить тот же результат, не угадывая замысел.

Тест-сценарий — это высокоуровневое однострочное утверждение о том, что тестировать: сквозной поток или фича. Тест-кейс — это детальная пошаговая реализация сценария: ID, предусловия, упорядоченные шаги, тестовые данные и явный ожидаемый результат. Один сценарий обычно разворачивается в несколько тест-кейсов; сценарий говорит что, а кейс — как именно.

Сначала уточните (платформа, допустимые символы), затем начните с позитива: валидное сложение вроде 4+5=9. Покройте границы (-99, +99 и чуть за -100, +100), классы эквивалентности (валидные целые, невалидные: дроби, буквы, символы) и лимиты полей — ввод вмещает 3 символа (знак + 2 цифры), вывод 4 (знак + 3 цифры). Поле вывода проверяйте отдельно. Если выкатить можно одну — оставьте позитивную: она доказывает, что основная функция работает.

Группируйте проверки по областям: отрисовка вёрстки/контента, затем функциональные сценарии (смена количества пересчитывает итог, удаление обновляет список, валидный/невалидный промокод, оформление активно только при наличии товаров), затем краевые случаи (пустая корзина, нулевое/макс. количество, истёкший промокод), затем нефункциональные (адаптивность, ошибки). Каждый пункт — короткая проверяемая проверка, от позитивного happy-path к негативным и граничным.

Таблица решений сопоставляет комбинации входных условий с ожидаемыми действиями: один столбец на правило. Она хороша, когда результат зависит от нескольких взаимодействующих условий — в отличие от классов эквивалентности, обрабатывающих входы независимо, — обеспечивая тест-кейс на каждую значимую комбинацию бизнес-правил.

Проверки формата и regex необходимы, но никогда не достаточны — RFC для валидных адресов огромен, а синтаксически верный адрес может быть недоставляемым. Единственная окончательная проверка — отправить подтверждающее сообщение и потребовать от пользователя действия (перейти по ссылке или ввести код). Синтаксис доказывает форму, шаг подтверждения доказывает, что ящик существует и принадлежит пользователю.

Сначала оспорьте спецификацию, не тестируйте её. Возраст 18 выпадает в пробел — «до 18» исключает 18 и «от 19» тоже, так что 18 не покрыт. Возраст 35 покрыт дважды, попадая и в правило 19–35, и в «от 35». Спросите: границы включающие или исключающие, есть ли максимальный возраст, считается возраст по дню или точному времени, дата локальная или UTC? Требование, которое нельзя разрешить, нетестируемо.

Позитив: ровно 8 цифр → 200. Границы: 7 и 9 цифр → 503; классы эквивалентности для 503: буквы, символы, пусто, смесь цифр и букв, ведущие нули, ввод с пробелами или отрицательный. Любой код кроме 200/503 (например 500) нарушает спецификацию — залогируйте, заведите дефект, уточните требование и добавьте кейсы под него, а не засчитывайте кейс. 1000 одновременных клиентов — нагрузочный тест, если отражает ожидаемый трафик; стрессом он становится, лишь когда намеренно превышает ёмкость ради поиска точки отказа.

Уровень поля: пропущенные обязательные поля, неверные типы, граничные или слишком большие значения, неверный формат email. Уровень тела: пустое тело, некорректный JSON, неверный Content-Type. Уровень данных: дубликат уже существующего пользователя. Уровень авторизации: отсутствующий или невалидный токен. Уровень безопасности: SQL- или XSS-инъекция. Каждый должен вернуть верный код 4xx, а не 500. Уровень API достаёт случаи, которые UI молча блокирует.

Проверьте каждый край тремя точками: 17 (отклонено), 18 (принято), 19 (принято) на нижней границе; 64 (принято), 65 (принято), 66 (отклонено) на верхней. Добавьте типичное среднее значение, например 40 (принято), и нецелые/пустые входы (отклонено). Каждый кейс явно указывает вход и ожидаемый результат — принято или ошибка.

Сначала позитив: строка отображается и принимает ввод, поиск по точному названию возвращает совпадения, по нескольким словам, по подстроке, на другом языке и срабатывает по Enter и по иконке. Затем негатив: пустая строка, одиночный пробел, спецсимволы, слишком длинная строка. Затем безопасность: SQL-инъекцию и изменение DOM нужно безопасно отклонить. Позитив-до-негатива подтверждает работу ядра, прежде чем проверять, как оно ломается.