Как будешь тестировать поле логина техникой эквивалентного разбиения

Тестирование поля логина с помощью метода эквивалентного разбиения

Тестирование поля ввода логина с использованием техники эквивалентного разбиения (Equivalence Partitioning) — это метод, который позволяет систематизировать тестовые данные, сократить количество тестовых случаев и повысить эффективность проверки. Основная идея заключается в том, что входные данные можно разделить на группы (классы эквивалентности), где все значения внутри одной группы приводят к одинаковому поведению системы. Для каждого класса эквивалентности выбирается одно тестовое значение, которое считается представительным для всей группы.

Определение классов эквивалентности для поля логина

Для поля логина (username) можно выделить следующие классы эквивалентности, исходя из требований и предполагаемых правил валидации:

1. Допустимые корректные значения (Valid inputs):

    *   Логины, удовлетворяющие всем правилам валидации (например, длина от 3 до 20 символов, разрешенные символы: буквы, цифры, точки, подчеркивания).

1. Недопустимые значения (Invalid inputs) — здесь важно разбить на подклассы по типу нарушения:

    *   **Пустое поле** (Empty input): Пользователь не ввел ничего.
    *   **Слишком короткий логин** (Too short): Логин меньше минимально допустимой длины (например, менее 3 символов).
    *   **Слишком длинный логин** (Too long): Логин превышает максимально допустимую длину (например, более 20 символов).
    *   **Неверный формат/запрещенные символы** (Invalid format): Логин содержит символы, не разрешенные правилами (например, пробелы, спецсимволы `@`, `#`, `$`).
    *   **Логин, который уже занят** (Already taken): Попытка использования логина, существующего в системе (для процесса регистрации).

1. Крайние/граничные значения (Boundary values): Этот класс часто рассматривается совместно с эквивалентным разбиением. Для логина это значения на границах допустимого диапазона длины.

    *   **Минимальная допустимая длина** (Min length): Логин длиной точно 3 символа.
    *   **Максимальная допустимая длина** (Max length): Логин длиной точно 20 символов.

Пример тестовых случаев на основе классов эквивалентности

На основе выделенных классов можно создать следующий набор тестовых случаев. Предположим, требования к логину: длина от 3 до 20 символов ASCII (буквы a-z, A-Z, цифры 0-9, точки ., подчеркивания _).

Тесты для допустимых корректных значений:

• TC_VALID_1: Логин "john_doe" (8 символов, разрешенные символы).
• TC_VALID_2: Логин "alice" (5 символов, минимально допустимый, но не граничный).
• TC_VALID_3: Логин "user.name_2023" (15 символов, содержит разные разрешенные типы).

Тесты для недопустимых значений:

• TC_INVALID_EMPTY: Пустая строка "". Ожидается сообщение об ошибке "Поле логина не может быть пустым".
• TC_INVALID_TOO_SHORT: Логин "ab" (2 символа). Ожидается ошибка "Логин должен содержать от 3 до 20 символов".
• TC_INVALID_TOO_LONG: Логин "very_long_username_exceeding_limit" (25 символов). Ожидается аналогичная ошибка о длине.
• TC_INVALID_FORMAT: Логин "john@doe" (содержит запрещенный символ @). Ожидается ошибка "Логин может содержать только буквы, цифры, точки и подчеркивания".
• TC_INVALID_TAKEN: Логин "admin", если он уже существует в базе. Ожидается ошибка "Этот логин уже занят" (для регистрации).

Тесты для граничных значений (Boundary Value Analysis, дополняющая техника):

• TC_BOUNDARY_MIN: Логин "abc" (точно 3 символа). Допустимое значение.
• TC_BOUNDARY_MAX: Логин "abcdefghijklmnopqrst" (точно 20 символов). Допустимое значение.
• TC_BOUNDARY_MIN-1: Логин "ab" (2 символа). Недопустимое (слишком короткий).
• TC_BOUNDARY_MAX+1: Логин "abcdefghijklmnopqrstu" (21 символов). Недопустимое (слишком длинный).

Практическая реализация и проверка поведения системы

Для каждого тестового случая мы проверяем не только само поле, но и интеграцию с другими компонентами:

• Валидация на стороне клиента (frontend): Проверка, что сообщения об ошибках появляются динамически, без отправки формы.
• Валидация на стороне сервера (backend): Проверка ответа API при отправке формы с недопустимыми данными. Сервер должен возвращать соответствующий HTTP статус (например, 400 Bad Request) и детали ошибки в теле ответа.
• Состояние системы после ввода: Для допустимых значений поле должно принимать ввод без ошибок, форма должна быть готовой к отправке. Для недопустимых — система должна блокировать дальнейшие действия (например, кнопка "Войти" или "Зарегистрироваться" неактивна).

Пример проверки ответа API для недопустимого логина:

// Ожидаемый ответ API (например, в формате JSON) при отправке слишком короткого логина:
{
  "status": "error",
  "code": 400,
  "message": "Validation failed",
  "details": {
    "username": "Логин должен содержать от 3 до 20 символов"
  }
}

Ключевые преимущества применения метода

• Сокращение количества тестов: Вместо проверки всех возможных недопустимых логинов (например, "a", "ab", "a b", "@"), мы проверяем один представитель каждого класса.
• Систематический подход: Метод обеспечивает полное покрытие всех типов входных данных, снижая риск пропустить целый класс ошибок.
• Фокусировка на требования: Процесс начинается с анализа требований к полю, что делает тестирование более целевым и соответственным спецификации.

В итоге, использование техники эквивалентного разбиения для тестирования поля логина позволяет создать эффективный, структурированный набор тестов, который проверяет все ключевые сценарии обработки входных данных, минимизируя усилия тестирования и максимизируя покрытие возможных проблем.