Класс эквивалентности объединяет значения, которые система по выбранному правилу должна обрабатывать одинаково. Вместо перебора всех значений тестировщик выбирает представителей классов. Основанием служат требования и модель обработки, а не внешнее сходство данных.
В учебном примере Mentoring.digital API принимает JSON с полем quantity. Зафиксируем контракт: поле обязательно, его значение должно быть числом с целым значением от 1 до 99. Строки и null не преобразуются автоматически. Это условия примера, а не свойства конкретного магазина.
Сначала разделяем данные по правилам
Один огромный класс «неправильно» скрывает разные способы отказа. Здесь полезно выделить следующие непересекающиеся варианты входа:
- Поле отсутствует: ожидается ошибка обязательного поля.
- Поле содержит null: ожидается ошибка типа.
- Поле содержит строку, например "12": ожидается ошибка типа.
- Поле содержит объект, массив или логическое значение: по контракту они тоже недопустимы; при разных ветках обработки их стоит разделить на самостоятельные классы.
- Число не целое, например 2.5: ожидается отказ по правилу целочисленности.
- Целое число меньше 1, например -3: ожидается ошибка диапазона.
- Целое число от 1 до 99, например 12: ожидается принятие значения.
- Целое число больше 99, например 120: ожидается ошибка диапазона.
Важно сначала разделить типы, затем числовые подмножества. Иначе «меньше 1» и «нецелое» будут пересекаться на значении 0.5. Если система нормализует строки до проверки, модель будет другой и классы нужно пересмотреть.
Записываем проверку целиком
Недостаточно перечислить 12, -3 и 120. Для каждого представителя сохраните условие, вход, ожидаемый ответ и проверяемое последствие. Например, для quantity=120 ответ должен сообщить о диапазоне, а недопустимое значение не должно сохраниться в заказе.
Сначала держите остальные поля корректными. Если одновременно испортить quantity и адрес доставки, первая ошибка может скрыть вторую. После независимых проверок переходите к сочетаниям полей по отдельной стратегии.
Что означает покрытие классов
Покрытие показывает долю выделенных классов, для которых выполнен хотя бы один тест. Оно зависит от качества модели. Прохождение всех запланированных проверок не доказывает отсутствие других классов, ошибок реализации и проблем при сочетании параметров.
Если выяснилось, что одинаковые на первый взгляд значения проходят разные обработчики, разделите класс и добавьте представителей. Список классов является рабочей моделью, которую уточняют вместе с требованиями.
Чем это отличается от граничных значений
Значение 12 представляет допустимый числовой класс, но не проверяет поведение на границах 1 и 99. Граничный анализ дополняет разбиение проверками самих границ и соседних значений. Это отдельный приём, а не причина включать сотни случайных чисел в один сценарий.
Для самостоятельной работы добавьте правило «для оптового заказа минимум 10 единиц». Определите, какие классы меняются и где появляется зависимость между типом заказа и количеством. Не называйте ожидаемые результаты фактическими, пока тесты не выполнены.
Техники тест-дизайна изучают на курсах QA. Проверить полноту модели для вашей формы или API поможет наставник по тестированию.
