Ответ
Техника эквивалентного разбиения (Equivalence Partitioning) позволяет сократить количество тестов, группируя входные данные в классы, где поведение системы ожидается одинаковым.
Шаги для поля логина:
- Определить классы эквивалентности (КЭ):
- Валидный КЭ: Корректный логин, соответствующий всем требованиям (например,
user@example.comилиvalid_username). - Невалидные КЭ:
- Пустая строка.
- Строка короче минимально допустимой длины.
- Строка длиннее максимально допустимой длины.
- Содержит запрещённые символы (пробелы, недопустимые спецсимволы).
- Не соответствует формату (например, не email, если требуется).
- Валидный КЭ: Корректный логин, соответствующий всем требованиям (например,
- Выбрать по одному представителю из каждого класса для тестирования.
- Дополнить проверкой граничных значений (Boundary Value Analysis) на стыках классов (например, минимальная и максимальная длина).
Пример тест-кейсов на Python:
def validate_login(login: str) -> bool:
# Примерная логика валидации
if not login:
return False
if len(login) < 3 or len(login) > 100:
return False
if " " in login:
return False
# ... другие проверки
return True
# Тесты для представителей классов эквивалентности
def test_equivalence_partitioning():
# Валидный класс
assert validate_login("correct.user") == True
# Невалидные классы
assert validate_login("") == False # Пустое поле
assert validate_login("ab") == False # Слишком коротко (граница)
assert validate_login("a" * 101) == False # Слишком длинно (граница)
assert validate_login("user name") == False # Запрещённый символ (пробел)Почему это работает: Система должна одинаково обрабатывать все значения внутри одного класса. Если тест с одним представителем проходит, с высокой вероятностью пройдут и другие значения из этого класса, что экономит ресурсы.
Ответ 18+ 🔞
А, ну это же классика, блядь! Техника эквивалентного разбиения, ёпта! Суть в чём, а? Чтобы не тестировать каждый пиздёныш по отдельности, а сгруппировать их в стада, где поведение системы, по идее, должно быть одинаковым. Экономия времени и нервов, в рот меня чих-пых!
Вот смотри, представь себе поле для логина. И вот ты, такой, стоишь и думаешь: «И чё мне, блядь, вбивать сюда? Все комбинации от a до zzzzzzzzzz? Да я с ума сойду!»
А вот и нет! Берёшь и делишь весь этот зоопарк возможных вводов на понятные классы, где система должна вести себя предсказуемо.
Как это делается, на примере этого ёбаного поля логина:
-
Находишь классы эквивалентности (КЭ). Это как сортировать мусор, только для тестов.
- Класс годных ребят (валидный КЭ): Всё, что проходит по всем правилам. Ну, типа
norm_user_228илиpochta@domen.ru. Один такой тест — и вроде как за всех. - Классы отбросов (невалидные КЭ): Тут уже веселее, блядь. Система должна на всех них одинаково орать «НЕ-А!».
- Пустышка. Просто ничего. Enter нажал и всё.
- Коротышка. Меньше, чем разрешено. Если минимум 3 символа, то
ab— уже пиздец. - Долговязый. Больше максимума.
aaaaaaaaa...на 101 символ — тоже мимо. - С запрещёнкой. Засунул пробел, звёздочку или ещё какую хуйню, которую нельзя.
- Кривой формат. Требуется email, а ты
vasya_pupkinвбил. Иди нахуй, Вася.
- Класс годных ребят (валидный КЭ): Всё, что проходит по всем правилам. Ну, типа
-
Выбираешь по одному солдату из каждого взвода. Не надо гонять всю роту. Достаточно одного ублюдка из каждой категории, чтобы понять, как система реагирует на весь класс.
-
Добавляешь граничные значения, ёпта! Это самое сладкое. Не просто «меньше трёх», а ровно два символа (
ab). Не просто «больше ста», а ровно сто один (a*101). Именно на этих стыках система чаще всего и показывает, что она — пизда с ушами, и падает самым неожиданным образом.
Вот, смотри, как это в коде выглядит, если представить, что наша функция валидации — это такой строгий, блядь, вахтёр:
def validate_login(login: str) -> bool:
# Примерная логика валидации, которую мы тестируем
if not login:
return False
if len(login) < 3 or len(login) > 100:
return False
if " " in login:
return False
# ... другие проверки
return True
# А вот наши тесты, где мы проверяем каждого представителя банды
def test_equivalence_partitioning():
# Валидный класс — свой парень
assert validate_login("correct.user") == True
# Невалидные классы — вся шушера
assert validate_login("") == False # Пустое поле (просто вынос мозга)
assert validate_login("ab") == False # Слишком коротко (пограничный случай, два символа)
assert validate_login("a" * 101) == False # Слишком длинно (пограничный случай, 101 символ)
assert validate_login("user name") == False # Запрещённый символ (пробел, сука!)А почему это, блядь, работает? Да потому что если система правильно обработала одного уродца из класса (например, строку с одним пробелом), то, скорее всего, она так же правильно отправит нахуй и все остальные строки с пробелами. Не нужно проверять "user name", "user name", " user" и т.д. по отдельности. Один тест — и доверия ебать на весь класс! Экономия времени — овердохуища!