Как тестировал авторизацию

Question

deepseek-v3.2 · Accepted Answer

## Подход к тестированию авторизации

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

### Основные направления тестирования

1.  **Функциональное тестирование (Positive и Negative тесты)**
2.  **Тестирование безопасности**
3.  **Юзабилити- и UI-тестирование**
4.  **Интеграционное и API-тестирование**
5.  **Нагрузочное и тестирование восстановления**

### Детальная методология

#### 1. Функциональное тестирование
Здесь проверяется, что авторизация работает согласно требованиям при корректных и некорректных данных.

*   **Позитивные сценарии (Positive Testing):**
    *   Успешный вход с правильным логином и паролем.
    *   Проверка перенаправления на целевую страницу после входа.
    *   Сохранение сессии (при наличии функции "Запомнить меня").
    *   Вход через альтернативные методы (если есть): OAuth (Google, GitHub), LDAP, биометрия.

*   **Негативные сценарии (Negative Testing):**
    *   Ввод неверного пароля при правильном логине.
    *   Ввод несуществующего логина.
    *   Пустые поля логина и/или пароля.
    *   Ввод данных с учетом регистра (Case Sensitivity).
    *   Попытки входа заблокированного/удаленного пользователя.
    *   Проверка лимитов попыток входа (блокировка после N неудачных попыток).

**Пример тест-кейса в формате, близком к коду:**
```gherkin
Scenario: Неуспешная авторизация с неверным паролем
    Given Пользователь находится на странице авторизации
    When Пользователь вводит валидный "логин"
    And Пользователь вводит невалидный "пароль"
    And Пользователь нажимает кнопку "Войти"
    Then Отображается сообщение об ошибке "Неверный логин или пароль"
    And Пользователь остается на странице авторизации
    And Парольное поле очищается (или маскируется)
```

#### 2. Тестирование безопасности
Это самый важный блок. Я использую комбинацию ручных проверок и инструментов.

*   **Уязвимости инъекций:** Проверяю поля ввода на SQL-инъекции и XSS.
    ```bash
    # Пример простой проверки SQL-инъекции в поле логина
    Ввод в поле логина: ' OR '1'='1
    Ожидаемый результат: Ошибка авторизации, НЕ внутренняя ошибка СУБД.
    ```
*   **Перехват и защита трафика:** Убеждаюсь, что все запросы (особенно передача пароля) используют **HTTPS**. Анализирую сетевые запросы в DevTools (Chrome/Firefox) на предмет передачи пароля в открытом виде.
*   **Безопасность хранения данных:** Проверяю, что пароли не хранятся в открытом виде в **Local Storage**, **Session Storage** или куках. Токены доступа (JWT) должны храниться безопасно.
*   **Защита от брутфорса:** Тестирую механизм блокировки после нескольких неудачных попыток (например, 5). Проверяю, что блокировка работает по IP или учетной записи и сбрасывается через заданное время или после восстановления пароля.
*   **CSRF-токены:** Убеждаюсь, что форма авторизации защищена уникальным токеном, предотвращающим межсайтовую подделку запроса.

#### 3. Интеграционное и API-тестирование
Часто авторизация реализована как отдельный сервис. Я тестирую эндпоинты API.

*   **Тестирование REST API эндпоинта `/auth/login`:** Проверяю коды ответов (200 OK, 401 Unauthorized, 429 Too Many Requests), тело ответа (наличие токена), заголовки.
    ```python
    # Пример теста на Python с использованием requests (для концепции)
    import requests

def test_auth_with_valid_credentials():
        url = "https://api.example.com/auth/login"
        payload = {"username": "valid_user", "password": "valid_pass"}
        response = requests.post(url, json=payload)
        assert response.status_code == 200
        assert "access_token" in response.json()
        assert response.json()["token_type"] == "Bearer"

def test_auth_with_invalid_credentials():
        url = "https://api.example.com/auth/login"
        payload = {"username": "invalid", "password": "invalid"}
        response = requests.post(url, json=payload)
        assert response.status_code == 401
    ```
*   **Валидация JWT токена (если используется):** Проверяю срок жизни токена (`exp`), издателя (`iss`), аудиторию (`aud`).

#### 4. Дополнительные аспекты
*   **Восстановление пароля:** Тесно связанный с авторизацией процесс. Проверяю весь цикл: запрос восстановления, получение ссылки/кода, установка нового пароля, вход с новым паролем.
*   **Многофакторная аутентификация (2FA/MFA):** Тестирую сценарии с включенным и отключенным 2FA, проверку одноразовых кодов, использование резервных кодов.
*   **Международность:** Ввод логина/пароля с символами разных языков (кириллица, иероглифы, эмодзи).
*   **Доступность (Accessibility):** Корректная работа с screen readers, навигация с клавиатуры (Tab, Enter).

### Инструменты и артефакты
*   **Для ручного тестирования:** Браузерные DevTools, **Postman** или **Insomnia** для API, **OWASP ZAP** или **Burp Suite Community** для базовых проверок безопасности.
*   **Для автоматизации:** **Selenium WebDriver** или **Playwright** для UI-сценариев, **Pytest + Requests** для API-тестов, интеграция в CI/CD (Jenkins, GitLab CI).
*   **Артефакты:** Чек-листы, подробные тест-кейсы в **TestRail** или **Allure**, баг-репорты в **Jira** с четкими шагами воспроизведения, логами и скриншотами.

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

Как тестировал авторизацию

Комментарии (2)

Подход к тестированию авторизации

Основные направления тестирования

Детальная методология

1. Функциональное тестирование

2. Тестирование безопасности

3. Интеграционное и API-тестирование

4. Дополнительные аспекты

Инструменты и артефакты