Когда безопасность может быть функциональным тестом?

Когда безопасность становится функциональным требованием?

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

Ключевые сценарии, где безопасность — функциональный тест:

1. Аутентификация и авторизация как основная функция

• Когда система управления доступом — ядро продукта (например, банковское приложение, корпоративный портал).
• Пример: тестирование сценария, где пользователь с ролью «гость» не может получить доступ к финансовым отчетам, а «администратор» — может. Это прямая функциональная проверка.

Feature: Управление доступом к отчетам
  Scenario: Пользователь с ролью "менеджер" может просматривать финансовые отчеты
    Given я залогинен как пользователь с ролью "менеджер"
    When я запрашиваю страницу "Финансовые отчеты"
    Then я должен увидеть таблицу с данными
    And кнопка "Экспорт в PDF" должна быть активна

  Scenario: Пользователь с ролью "аналитик" НЕ может редактировать отчеты
    Given я залогинен как пользователь с ролью "аналитик"
    When я пытаюсь отправить POST-запрос на endpoint "/api/reports/update"
    Then я должен получить статус ответа 403 Forbidden

2. Шифрование данных как заявленная возможность

• Если в требованиях указано: «все сообщения шифруются по протоколу TLS 1.2+» или «платежные данные хранятся в зашифрованном виде».
• Функциональный тест: проверка, что при отправке формы данные действительно передаются по HTTPS, а не HTTP.

import pytest
import requests

def test_https_encryption_for_payment_page():
    # Функциональная проверка: шифрование — это фича
    url = "https://example.com/payment"
    response = requests.get(url, verify=True)  # verify проверяет SSL-сертификат
    
    assert response.status_code == 200
    assert response.url.startswith("https://"), "Данные передаются без шифрования!"
    # Дополнительно можно проверить протокол TLS

3. Аудит и логирование как функция соответствия

• В системах, подпадающих под регулирование (GDPR, PCI DSS, HIPAA), ведение логов — это не просто атрибут, а обязательная функция.
• Пример: тест на запись в лог при попытке неудачного входа или изменении критичных настроек.

4. Защита от конкретных угроз как часть логики приложения

• Капча для предотвращения брутфорса, подтверждение операции по SMS, блокировка аккаунта после N неудачных попыток.
• Это — бизнес-логика, которую можно проверить через функциональные сценарии.

// Пример теста для функции "блокировка аккаунта после 3 неудачных попыток ввода пароля"
describe('Account Lockout Functionality', () => {
  it('should lock account after 3 failed login attempts', async () => {
    for (let i = 0; i < 3; i++) {
      await login('user', 'wrong_password');
    }
    const response = await login('user', 'correct_password');
    expect(response.message).toBe('Account locked. Contact support.');
  });
});

Почему важно выделять такие тесты?

• Требования и приемка: если безопасность зафиксирована в пользовательских историях или спецификациях, её нужно тестировать как функциональность. Например: «Как пользователь, я хочу, чтобы мой пароль хранился в хешированном виде, чтобы избежать утечки».
• Влияние на UX: сбои в безопасности могут ломать основной функционал. Если из-за ошибки CORS пользователь не может отправить форму — это дефект функциональности.
• Регуляторные требования: для медицинских или финансовых продуктов многие проверки безопасности — это обязательные функциональные тесты для сертификации.

Разграничение с нефункциональным тестированием безопасности

Вывод

Безопасность становится функциональным тестом, когда она:

• Прямо указана в требованиях к продукту.
• Реализует бизнес-правила (например, многофакторная аутентификация для премиум-клиентов).
• Влияет на выполнение основных пользовательских сценариев.
• Требуется для соответствия стандартам, где проверяется как функция.

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