Классы эквивалентности и граничные значения — две техники тест-дизайна, которые вместе позволяют проверить поле или функцию с ограниченным числом тест-кейсов вместо перебора всех возможных входных значений. Классы эквивалентности группируют входные данные так, чтобы одна проверка представляла целую группу схожих значений, а анализ граничных значений добавляет прицельные проверки именно там, где по статистике чаще всего прячутся баги — на границах между классами.
Что такое классы эквивалентности?
Класс эквивалентности — это группа входных значений, которые система должна обрабатывать одинаково: если баг проявится на одном значении из класса, разумно ожидать, что он проявится и на любом другом значении из того же класса, и наоборот — если одно значение прошло проверку успешно, остальные значения этого же класса с высокой вероятностью тоже пройдут. Смысл техники — не проверять каждое возможное значение поля, а выбрать по одному представителю от каждого класса, сократив количество тест-кейсов в разы без потери значимого покрытия.
Как разбить поле на классы эквивалентности на практике?
Возьмём поле «Возраст» с бизнес-правилом «принимаются целые числа от 18 до 65 включительно». Первый шаг — выделить один валидный класс (числа внутри диапазона, например 30) и минимум два невалидных: числа меньше минимума (например, 10) и числа больше максимума (например, 90). Если правило сложнее — например, поле дополнительно не принимает нецелые числа и буквы, — для каждого такого дополнительного ограничения заводится собственный невалидный класс: отдельно нецелое число (30.5), отдельно буквы («тридцать»), отдельно пустое значение. Итоговый список классов должен покрывать все содержательно разные причины, по которым значение может быть принято или отклонено, а не просто произвольный набор чисел.
Что такое анализ граничных значений и зачем он нужен?
Анализ граничных значений (Boundary Value Analysis) исходит из эмпирического наблюдения: дефекты в коде статистически чаще концентрируются на границах диапазонов, а не в их середине — типичная причина в реальном коде это неправильно выбранный оператор сравнения (< вместо <=, > вместо >=), из-за которого граничное значение обрабатывается не так, как остальные значения того же класса. Тестирование только середины класса эквивалентности (например, только числа 30 для диапазона 18–65) такую ошибку не поймает, потому что середина диапазона обычно ведёт себя правильно даже при сломанном условии сравнения — проблема проявляется именно на самой границе.
Как выбрать конкретные значения для проверки границ?
Для диапазона «от 18 до 65 включительно» проверяются шесть значений: 17 и 66 (по одному шагу за каждой границей — должны отклоняться), 18 и 65 (сами границы — должны приниматься, если правило «включительно»), 19 и 64 (по одному шагу внутрь диапазона от каждой границы — должны приниматься). Такой набор из трёх значений на каждую границу (за границей, на границе, сразу внутри) — это минимальный набор, который отличает правильное условие сравнения от сломанного: если код по ошибке использует age > 18 вместо age >= 18, именно проверка значения 18 (граница) поймает эту ошибку, а проверки 17 и 19 её не заметят.
Чем классы эквивалентности отличаются от анализа граничных значений?
Классы эквивалентности и анализ граничных значений решают разные задачи и ловят разные ошибки — они не конкурируют, а дополняют друг друга:
— Что проверяет: классы эквивалентности — что представитель каждой группы значений обрабатывается корректно (один тест на группу). Граничные значения — поведение системы на переходе между классами и внутри одного класса рядом с границей.
— Сколько значений на класс: классы эквивалентности — обычно одно значение из середины класса. Граничные значения — три значения вокруг каждой границы (за ней, на ней, сразу после).
— Какие ошибки ловит: классы эквивалентности — грубые ошибки обработки целой категории входных данных (например, поле вообще не принимает буквы, когда должно их отклонять). Граничные значения — точечные ошибки в условиях сравнения (< вместо <=).
Классы эквивалентности задают, какие диапазоны и категории вообще существуют, а граничные значения уточняют проверку внутри и вокруг этих диапазонов.
— Что проверяет: классы эквивалентности — что представитель каждой группы значений обрабатывается корректно (один тест на группу). Граничные значения — поведение системы на переходе между классами и внутри одного класса рядом с границей.
— Сколько значений на класс: классы эквивалентности — обычно одно значение из середины класса. Граничные значения — три значения вокруг каждой границы (за ней, на ней, сразу после).
— Какие ошибки ловит: классы эквивалентности — грубые ошибки обработки целой категории входных данных (например, поле вообще не принимает буквы, когда должно их отклонять). Граничные значения — точечные ошибки в условиях сравнения (< вместо <=).
Классы эквивалентности задают, какие диапазоны и категории вообще существуют, а граничные значения уточняют проверку внутри и вокруг этих диапазонов.
Как обе техники работают вместе на одном примере?
Для поля «Возраст 18–65» классы эквивалентности дают три группы для проверки: одно валидное значение из середины диапазона (40), одно невалидное значение меньше минимума (10) и одно невалидное значение больше максимума (90) — это покрывает, что система вообще правильно отличает «в целом валидный» ввод от «в целом невалидного». Граничные значения добавляют шесть точечных проверок вокруг самих границ (17, 18, 19, 64, 65, 66), которые проверяют, что переход между классами происходит именно там, где заявлено в требованиях, а не на одно значение раньше или позже:
— 10 — невалидный, меньше минимума. Ожидаемый результат: отклоняется.
— 17 — невалидный, за границей минимума. Ожидаемый результат: отклоняется.
— 18 — граница минимума. Ожидаемый результат: принимается.
— 19 — валидный, сразу после минимума. Ожидаемый результат: принимается.
— 40 — валидный, середина диапазона. Ожидаемый результат: принимается.
— 64 — валидный, сразу перед максимумом. Ожидаемый результат: принимается.
— 65 — граница максимума. Ожидаемый результат: принимается.
— 66 — невалидный, за границей максимума. Ожидаемый результат: отклоняется.
— 90 — невалидный, больше максимума. Ожидаемый результат: отклоняется.
Вместе получается компактный набор из девяти значений, который покрывает и общую логику работы поля, и самые вероятные места для ошибок в условиях сравнения — вместо перебора всех 48 чисел диапазона (18–65) или тем более всех целых чисел вообще.
— 10 — невалидный, меньше минимума. Ожидаемый результат: отклоняется.
— 17 — невалидный, за границей минимума. Ожидаемый результат: отклоняется.
— 18 — граница минимума. Ожидаемый результат: принимается.
— 19 — валидный, сразу после минимума. Ожидаемый результат: принимается.
— 40 — валидный, середина диапазона. Ожидаемый результат: принимается.
— 64 — валидный, сразу перед максимумом. Ожидаемый результат: принимается.
— 65 — граница максимума. Ожидаемый результат: принимается.
— 66 — невалидный, за границей максимума. Ожидаемый результат: отклоняется.
— 90 — невалидный, больше максимума. Ожидаемый результат: отклоняется.
Вместе получается компактный набор из девяти значений, который покрывает и общую логику работы поля, и самые вероятные места для ошибок в условиях сравнения — вместо перебора всех 48 чисел диапазона (18–65) или тем более всех целых чисел вообще.
Какие вопросы про классы эквивалентности и граничные значения чаще всего возникают?
Работают ли эти техники только с числовыми диапазонами? Нет, обе техники применимы к любым входным данным, где можно выделить группы «одинаково обрабатываемых» значений — например, к длине строки (граница «максимум 255 символов» проверяется строками в 254, 255 и 256 символов), к количеству элементов в списке (пустой список, список из одного элемента, список у верхнего лимита), или даже к датам (последний день месяца, первый день следующего месяца).
Сколько тест-кейсов достаточно для одного невалидного класса? Обычно один представитель на класс — если система отклоняет значение 10 для диапазона 18–65, разумно ожидать, что она так же отклонит и 5, и -100, потому что это одна и та же категория «меньше минимума». Исключение — если внутри «невалидного» диапазона есть свои содержательные подслучаи (например, отдельно отрицательные числа и отдельно ноль, если они обрабатываются по-разному), тогда каждый такой подслучай — отдельный класс со своим представителем.
Что делать, если в требованиях не указано явно, включает ли диапазон границу («от 18 до 65» — это 18 и 65 или строго между)? Это сигнал уточнить требования у аналитика или продакт-менеджера, а не тестировать наугад — «от» и «до» на естественном языке неоднозначны именно в вопросе включения границ, и разные разработчики могут закодировать это по-разному без документации. Пока формулировка не уточнена, стоит явно зафиксировать в тест-кейсе предположение (например, «включительно») и пометить его как допущение, требующее подтверждения.
Можно ли применять эти техники к необязательным полям (пустое значение допустимо)? Да, пустое значение (или его отсутствие) в таком случае — ещё один самостоятельный класс эквивалентности, который тоже нужно проверить отдельно, а не игнорировать как «недостаточно интересный» — на практике обработка пустых/отсутствующих значений — один из самых частых источников багов именно потому, что про этот класс легко забыть при проектировании тест-кейсов.
Эти техники применимы только к ручному тестированию или их используют и в автотестах? Обе техники в равной мере применимы к автоматизированному тестированию — параметризованные тесты (например, pytest.mark.parametrize в Python или таблицы данных в Playwright) — это ровно тот механизм, который позволяет прогнать один и тот же тестовый сценарий с разным набором граничных и классовых значений без дублирования кода теста.
Сколько тест-кейсов нужно, если на форме одновременно проверяется несколько полей? Если просто перемножить количество классов и границ по каждому полю, число сочетаний растёт экспоненциально — уже 4 поля с 3-4 значениями каждое дают сотни комбинаций, которые нереально прогнать вручную. На практике это ограничивают: часть сочетаний проверяют не все вместе, а по одному изменённому полю за раз (остальные — валидные значения), а для отдельной проверки совместного влияния нескольких полей применяют технику попарного тестирования (pairwise testing) — она подбирает существенно меньший набор комбинаций, в котором каждая пара значений разных полей встречается хотя бы раз. Классы эквивалентности и граничные значения на этом этапе никуда не деваются — они как раз и определяют, какие значения каждого поля вообще стоит включать в комбинации.
Правда ли, что анализ граничных значений иногда называют просто «граничным анализом»? Да, это одно и то же — «граничный анализ», «анализ граничных значений» и Boundary Value Analysis (BVA) в русскоязычных материалах и на собеседованиях используются как синонимы одной и той же техники.
Сколько тест-кейсов достаточно для одного невалидного класса? Обычно один представитель на класс — если система отклоняет значение 10 для диапазона 18–65, разумно ожидать, что она так же отклонит и 5, и -100, потому что это одна и та же категория «меньше минимума». Исключение — если внутри «невалидного» диапазона есть свои содержательные подслучаи (например, отдельно отрицательные числа и отдельно ноль, если они обрабатываются по-разному), тогда каждый такой подслучай — отдельный класс со своим представителем.
Что делать, если в требованиях не указано явно, включает ли диапазон границу («от 18 до 65» — это 18 и 65 или строго между)? Это сигнал уточнить требования у аналитика или продакт-менеджера, а не тестировать наугад — «от» и «до» на естественном языке неоднозначны именно в вопросе включения границ, и разные разработчики могут закодировать это по-разному без документации. Пока формулировка не уточнена, стоит явно зафиксировать в тест-кейсе предположение (например, «включительно») и пометить его как допущение, требующее подтверждения.
Можно ли применять эти техники к необязательным полям (пустое значение допустимо)? Да, пустое значение (или его отсутствие) в таком случае — ещё один самостоятельный класс эквивалентности, который тоже нужно проверить отдельно, а не игнорировать как «недостаточно интересный» — на практике обработка пустых/отсутствующих значений — один из самых частых источников багов именно потому, что про этот класс легко забыть при проектировании тест-кейсов.
Эти техники применимы только к ручному тестированию или их используют и в автотестах? Обе техники в равной мере применимы к автоматизированному тестированию — параметризованные тесты (например, pytest.mark.parametrize в Python или таблицы данных в Playwright) — это ровно тот механизм, который позволяет прогнать один и тот же тестовый сценарий с разным набором граничных и классовых значений без дублирования кода теста.
Сколько тест-кейсов нужно, если на форме одновременно проверяется несколько полей? Если просто перемножить количество классов и границ по каждому полю, число сочетаний растёт экспоненциально — уже 4 поля с 3-4 значениями каждое дают сотни комбинаций, которые нереально прогнать вручную. На практике это ограничивают: часть сочетаний проверяют не все вместе, а по одному изменённому полю за раз (остальные — валидные значения), а для отдельной проверки совместного влияния нескольких полей применяют технику попарного тестирования (pairwise testing) — она подбирает существенно меньший набор комбинаций, в котором каждая пара значений разных полей встречается хотя бы раз. Классы эквивалентности и граничные значения на этом этапе никуда не деваются — они как раз и определяют, какие значения каждого поля вообще стоит включать в комбинации.
Правда ли, что анализ граничных значений иногда называют просто «граничным анализом»? Да, это одно и то же — «граничный анализ», «анализ граничных значений» и Boundary Value Analysis (BVA) в русскоязычных материалах и на собеседованиях используются как синонимы одной и той же техники.
Где отработать тест-дизайн на практике?
Понять технику на бумаге и уверенно применять её к реальному полю с кучей скрытых условий — разные уровни навыка, и разница видна именно на практике с обратной связью от того, кто уже прошёл этот путь. В Quality Academy на курсе «Инженер по ручному тестированию» тест-дизайн разбирается на реальных примерах в процессе обучения, а тиры трижды в неделю (в том числе практический тир по пятницам) дают возможность потренироваться объяснять свой подход вслух — ровно так, как это спрашивают на собеседованиях.
-------
Полезные ссылки школы
Сайт Quality Academy:
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena