Как будешь тестировать авторизацию на сайте

Стратегия тестирования авторизации на сайте

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

1. Функциональное тестирование (Позитивные и негативные сценарии)

Я проверяю основной поток и множество альтернативных и ошибочных сценарий:

• Валидные данные: Успешный вход с корректным логином/email и паролем. Проверка редиректа на целевую страницу, установки сессионных токенов (например, куки session_id).
• Невалидные данные:

    *   Неверный пароль при правильном логине.
    *   Несуществующий логин/email.
    *   Пустые обязательные поля (логин, пароль).

• Пограничные случая и валидация полей:

    *   Ввод пробелов в начале/конце логина или пароля (должны триммироваться или считаться невалидными).
    *   Длинные строки (например, 255+ символов) - проверка на **SQL-инъекции** и переполнение буфера.
    *   Специальные символы, Unicode в логине.
    *   Чувствительность к регистру для логина и пароля (обычно пароль - чувствителен, логин - нет).

• Восстановление доступа: Тестирование ссылки "Забыли пароль?" - отправка письма, валидность/срок жизни сброс-токена, смена пароля.

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

Это наиболее важный аспект. Я использую ручные техники и инструменты (Burp Suite, OWASP ZAP).

• Уязвимости веб-приложений (OWASP Top 10):

    *   **SQL-инъекция:** Попытка ввода `' OR '1'='1` в поле логина или пароля. Проверяю, экранируются ли специальные символы.

```sql
-- Пример потенциально опасного ввода
username: admin' --
password: anything
```

    *   **Небезопасная десериализация:** Анализ кук и токенов на предмет возможности подмены.
    *   **Уязвимые компоненты:** Анализ используемых библиотек (через SCA-инструменты).

• Защита учетных данных:

    *   **Передача по HTTPS:** Все ли запросы (`POST /login`) идут по защищенному протоколу? Проверка отсутствия смешанного контента (Mixed Content).
    *   **Пароли не в логах:** Убедиться, что пароли не пишутся в логи сервера или браузера в открытом виде.
    *   **Хеширование паролей:** Пароли должны храниться в виде хеша (bcrypt, Argon2) с "солью".

• Управление сессиями:

    *   **Защита от перехвата:** Используются ли **secure** и **HttpOnly** флаги для сессионных кук?
    *   **Таймаут сессии:** Автоматический выход после периода неактивности.
    *   **Выход (Logout):** Уничтожает ли кнопка выхода сессию на сервере и удаляет ли куки на клиенте?
    *   **Параллельные сессии:** Разрешено ли несколько активных сессий под одним пользователем?

• Защита от брутфорса: Наличие ограничения на количество неудачных попыток входа (например, блокировка на 5 минут после 5 попыток). Проверка капчи после нескольких неудач.

3. Тестирование удобства использования (Usability) и доступности (Accessibility)

• Ясность сообщений: Сообщения об ошибках должны быть информативными, но не раскрывать системную информацию (например, "Неверный логин или пароль" вместо "Пользователь не найден").
• Навигация: Работает ли авторизация через клавишу Enter? Корректная табуляция между полями.
• Accessibility (A11y): Наличие корректных aria-label, role для полей ввода и кнопок для скринридеров.

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

Если авторизация происходит через API (например, REST endpoint /api/v1/auth/login), я тестирую его отдельно.

• Проверка HTTP-методов: POST запрос должен работать, GET - возвращать ошибку.
• Анализ запросов/ответов:

POST /api/v1/auth/login HTTP/1.1
Content-Type: application/json

{"username": "testuser", "password": "Secret123!"}

• Ожидаемый ответ при успехе:

{
    "status": "success",
    "token": "eyJhbGciOiJ...",
    "user": {"id": 123, "name": "Test User"}
}

• Ожидаемый ответ при ошибке:

{
    "status": "error",
    "message": "Invalid credentials"
}

5. Нефункциональное тестирование

• Производительность: Время ответа сервера на запрос авторизации под нагрузкой (например, 100 одновременных попыток входа). Использую JMeter или k6.
• Кросс-браузерное/Кросс-платформенное: Проверка корректности работы в разных браузерах (Chrome, Firefox, Safari) и на разных ОС и устройствах (мобильные, планшеты).

6. Автоматизация тестов

Для регрессионного тестирования я автоматизирую ключевые сценарии, используя Page Object Pattern.

import pytest
from pages.login_page import LoginPage

class TestLogin:
    @pytest.fixture
    def login_page(self, browser):
        return LoginPage(browser)

    def test_successful_login(self, login_page):
        """Позитивный сценарий успешного входа."""
        login_page.open()
        login_page.enter_username("valid_user")
        login_page.enter_password("valid_pass")
        login_page.click_login_button()
        assert login_page.is_user_logged_in(), "Пользователь не авторизовался"

    def test_login_with_invalid_password(self, login_page):
        """Негативный сценарий с неверным паролем."""
        login_page.open()
        login_page.enter_username("valid_user")
        login_page.enter_password("wrong_pass")
        login_page.click_login_button()
        assert "Invalid credentials" in login_page.get_error_message()

Итог: Мой подход систематичен. Я начинаю с анализа требований и спецификации, затем проектирую тест-кейсы, покрывающие все аспекты — от базовой функциональности до сложных сценариев безопасности. Приоритет всегда отдается защите пользовательских данных и предотвращению несанкционированного доступа.