Эквивалентное разбиение и анализ граничных значений
Мы уже разобрались с тем, на каких уровнях проверяется программный продукт и как QA-инженер интегрирован в процессы разработки. Однако перед нами встает практический вопрос: как именно выбирать данные для проверки? Если в поле ввода можно вписать любое число от 1 до 1 000 000, мы не можем проверить каждое из них вручную или даже автотестами — это займет вечность и не даст новой информации.
Для решения этой проблемы в тестировании используются техники тест-дизайна. Они позволяют сократить количество проверок до разумного минимума, сохраняя при этом высокую уверенность в качестве продукта. Сегодня мы изучим два фундаментальных метода: эквивалентное разбиение и анализ граничных значений.
Эквивалентное разбиение: группируем похожее
Эквивалентное разбиение — это техника, при которой мы разделяем все возможные входные данные на группы (классы). Мы исходим из предположения, что система обрабатывает любое значение внутри одной группы одинаково.
Если один представитель группы проходит тест успешно, мы считаем, что и все остальные значения в этой группе сработают корректно. И наоборот: если один «делегат» нашел баг, то, скорее всего, этот баг проявится и на других значениях того же класса.
Мы выделяем два типа классов:
- Позитивные классы: валидные данные, которые система должна принимать.
- Негативные классы: невалидные данные, которые система должна отклонять.
Как показано на Схеме 1, использование этой техники превращает бесконечный поток данных в несколько точных проверок.
Практический пример: поле «Возраст»
Представим форму регистрации, где разрешено регистрироваться пользователям от 18 до 65 лет включительно.
- Класс 1 (позитивный): Числа от 18 до 65. Берем
25. - Класс 2 (негативный): Числа меньше 18. Берем
10. - Класс 3 (негативный): Числа больше 65. Берем
80. - Класс 4 (негативный): Нечисловые значения (спецсимволы, буквы). Берем
abc.
Вместо миллионов тестов мы провели всего четыре, покрыв основные сценарии логики.
Анализ граничных значений: ищем ошибки на стыках
Ошибки в коде чаще всего возникают не «в середине» диапазона, а на его краях. Программист может случайно написать в условии > вместо >=, и тогда система сломается именно в пограничной точке.
Анализ граничных значений — это техника проверки поведения системы на границах классов эквивалентности. Если эквивалентное разбиение говорит нам, какую область проверять, то анализ границ указывает на конкретные точки.
Обычно мы проверяем:
- Саму границу.
- Значение чуть меньше границы.
- Значение чуть больше границы.
В современной практике Middle-инженеры часто используют оптимизированный подход «двух точек»: саму границу и значение, выходящее за её пределы. Это экономит время без потери качества.
Пример с границами для поля «Возраст» (18–65)
Для нижней границы (18) мы проверим:
17— система должна выдать ошибку.18— регистрация должна пройти успешно.
Для верхней границы (65) мы проверим:
65— регистрация должна пройти успешно.66— система должна выдать ошибку.
💡 Важное замечание: Границы всегда диктуются требованиями (ТЗ). Если в документации написано «до 65 лет включительно», то 65 — это валидная граница. Если «до 65 лет», то 65 уже может быть невалидным значением. Всегда уточняйте формулировки у аналитиков.
Алгоритм применения техник на проекте
Чтобы спроектировать тесты для веб-элемента, придерживайтесь алгоритма:
- Анализ требований: выделите параметры (цена, количество товара, длина логина).
- Определение типов данных: поймите, что ожидает система (целое число, строка, дата).
- Выделение классов: разбейте данные на позитивные и негативные группы.
- Определение границ: найдите точки перехода между классами.
- Выбор значений: сформируйте список конкретных данных для тест-кейсов.
Сравним подходы на примере поля «Сумма перевода» (от 100 до 5000 рублей).
| Метод | Выбранные значения | Результат |
|---|---|---|
| Случайный выбор | 200, 1500, 4000 | Проверили только позитив. Пропустили ошибки на краях и реакцию на мусорные данные. |
| Профессиональный подход | 99, 100, 2500, 5000, 5001, abc | Проверили обе границы, середину диапазона и обработку некорректного типа данных. |
Почему это критично для Middle QA
Разница между новичком и Middle-инженером — в обоснованности действий. Middle QA не просто «тыкает в кнопки», а может аргументированно объяснить команде, почему он выбрал именно эти 6 тестов вместо 100.
Использование этих техник напрямую влияет на:
- Скорость: мы не тратим время на избыточные проверки. ⚡
- Надежность: мы проверяем самые рискованные места (границы).
- Автоматизацию: эти техники — фундамент для эффективных автотестов.
В веб-приложениях эти методы применимы везде: от полей ввода и API-запросов до фильтров в каталоге и загрузки файлов разного размера.
Мы научились работать с одиночными параметрами. Но что делать, если поведение системы зависит от комбинации условий? Например, скидка зависит и от суммы заказа, и от промокода, и от статуса клиента. В следующей теме мы изучим, как справляться с такими задачами с помощью таблиц решений и попарного тестирования.