Каков комплексный подход к тестированию функциональности авторизации?

«Каков комплексный подход к тестированию функциональности авторизации?» — вопрос из категории Веб-тестирование, который задают на 10% собеседований QA Тестировщик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

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

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

1. Позитивные сценарии (Happy Path):

  • Успешный вход по логину/паролю.
  • Вход через социальные сети (OAuth 2.0, OpenID Connect) — проверка редиректа и получения токена.
  • Функция "Запомнить меня" — сохранение сессии после закрытия браузера.
  • Выход из системы (Logout) — инвалидация сессии/токена.

2. Негативные сценарии и валидация:

  • Неверный пароль для существующего пользователя.
  • Несуществующий логин.
  • Пустые или состоящие из пробелов поля.
  • Пользователь заблокирован/деактивирован.
  • Просроченный токен/сессия.

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

  • Устойчивость к брутфорсу: Система должна блокировать учетную запись или вводить CAPTCHA после N неудачных попыток.
  • Защита от инъекций: Попытки SQL-инъекции, NoSQL-инъекции или XSS в полях ввода должны блокироваться или экранироваться.
  • Безопасность передачи данных: Логин/пароль должны передаваться по HTTPS (проверка заголовков HSTS).
  • Хранение паролей: Пароли должны храниться в хэшированном виде (например, bcrypt, Argon2).
  • Уязвимости сессии: Проверка на фиксацию сессии (Session Fixation), корректное использование HttpOnly и Secure флагов для кук.

4. Функциональность восстановления доступа:

  • Работа ссылки "Забыли пароль?".
  • Валидность токена сброса пароля (срок жизни, одноразовость).
  • Требования к сложности нового пароля.

Пример теста для API авторизации (Python, requests):

import requests

def test_auth_negative_scenarios():
    base_url = "https://api.example.com"

    # 1. Неверные учетные данные
    resp = requests.post(f"{base_url}/auth/login", 
                         json={"username": "user", "password": "wrong"})
    assert resp.status_code == 401  # Unauthorized

    # 2. SQL-инъекция (ожидаем 400 или 401, НЕ 500 Internal Server Error)
    resp = requests.post(f"{base_url}/auth/login", 
                         json={"username": "' OR '1'='1", "password": "any"})
    assert resp.status_code in [400, 401]

    # 3. Успешный вход и проверка токена
    resp = requests.post(f"{base_url}/auth/login", 
                         json={"username": "valid_user", "password": "ValidPass123"})
    assert resp.status_code == 200
    token = resp.json().get("access_token")
    assert token is not None

    # 4. Использование токена для доступа к защищенному эндпоинту
    headers = {"Authorization": f"Bearer {token}"}
    resp = requests.get(f"{base_url}/api/profile", headers=headers)
    assert resp.status_code == 200

5. Дополнительные проверки:

  • Логирование: Все попытки входа (успешные и неуспешные) должны логироваться с IP-адресом и timestamp.
  • Мультифакторная аутентификация (MFA): Если реализована, проверка всех этапов.
  • Конкурентный доступ: Параллельные попытки входа с одними учетными данными с разных устройств.
  • UI/UX: Сообщения об ошибках должны быть информативными, но не раскрывать детали (например, "Неверный логин или пароль" вместо "Пользователь не найден").