Какие знаешь уровни ошибок в логах?

Уровни логирования в разработке ПО

В современных системах логирования, особенно при использовании популярных фреймворков вроде Log4j, Logback, SLF4J или стандартного Python logging, существует общепринятая иерархия уровней серьезности (severity) сообщений. Эти уровни позволяют фильтровать, классифицировать и оперативно реагировать на события в системе. Как QA Engineer, я использую эти уровни не только для анализа инцидентов, но и для проектирования тестового покрытия и мониторинга качества на разных стадиях.

Стандартные уровни ошибок (от наиболее к наименее критичным)

1. FATAL / CRITICAL

    *   **Назначение:** Критические ошибки, которые приводят к неработоспособности всего приложения или одной из его ключевых подсистем. Требуют немедленного вмешательства. Пример: невозможность подключиться к базе данных на старте, потеря дискового пространства в критическом разделе.
    *   **Использование в QA:** Появление таких логов в production-среде — прямой индикатор провала тестирования отказоустойчивости и мониторинга.

1. ERROR

    *   **Назначение:** Ошибки, которые нарушают выполнение конкретной операции или бизнес-процесса, но не останавливают работу всего приложения. Это целевой уровень для логирования необработанных исключений. Пример: сбой при обработке платежа, ошибка валидации внешнего API, неудачная попытка сохранить данные.
    *   **Использование в QA:** Основной фокус при анализе после прогона автоматизированных или нагрузочных тестов. Статистика по ERROR-логам — ключевая метрика стабильности сборки.

1. WARN (Предупреждение)

    *   **Назначение:** Потенциально проблемные ситуации, которые не являются ошибками на текущий момент, но могут привести к ним в будущем. Приложение продолжает работать в штатном режиме. Пример: приближение к лимиту использования памяти, использование устаревшего (deprecated) метода API, повторные попытки подключения.
    *   **Использование в QA:** Важен для нефункционального тестирования (нагрузка, стабильность). Накопление WARN-логов во время длительного теста может указывать на утечку ресурсов.

1. INFO

    *   **Назначение:** Информационные сообщения, которые описывают нормальный ход работы приложения. Используются для аудита и общего понимания потока выполнения. Пример: "Пользователь успешно аутентифицирован", "Запущен процесс обработки заказа №X", "Приложение стартовало на порту 8080".
    *   **Использование в QA:** Полезны для проверки корректности сценариев (e2e-тесты). Убеждаемся, что система прошла через ключевые шаги.

1. DEBUG

    *   **Назначение:** Детальная отладочная информация для разработчиков. Обычно включается только в тестовых и разработческих средах. Содержит значения переменных, состояния объектов, вызовы внутренних методов.
    *   **Использование в QA:** Незаменимый инструмент при исследовательском тестировании или анализе сложного дефекта в тестовой среде. Позволяет восстановить полный контекст события.

1. TRACE

    *   **Назначение:** Наиболее детальный уровень, логирующий буквально каждое мелкое действие внутри компонента (вход/выход из метода, параметры вызовов). Сильно влияет на производительность и объем логов.
    *   **Использование в QA:** Может использоваться для отладки проблем в высоконагруженных или распределенных системах, когда даже DEBUG-уровня недостаточно.

Практическое применение в работе QA

В своей работе я активно оперирую этими уровнями:

• Настройка мониторинга: В тестовых средах для автоматических регресс-тестов я настраиваю алерты на появление ERROR и FATAL логов. Это позволяет быстро выявить регрессию.
• Анализ причин сбоя: При воспроизведении бага цепочка логов от INFO (что пытался сделать пользователь) через WARN (возможные аномалии) к ERROR (конкретное исключение) дает полную картину.
• Написание тестов: Иногда автотесты могут проверять не только UI/API-ответ, но и наличие или отсутствие определенных записей в логах. Например, успешная операция не должна порождать WARN или ERROR.

# Пример проверки логов в автотесте (Python, pytest)
import logging

def test_payment_processing(log_capture):
    # log_capture — фикстура, перехватывающая логи
    process_payment(user_id=123, amount=100)

    # Убеждаемся, что не было ошибок
    assert log_capture.get_level_count(logging.ERROR) == 0

    # Можно проверить наличие конкретного информационного сообщения
    assert any("Payment for user 123 completed" in record.getMessage()
               for record in log_capture.records
               if record.levelno == logging.INFO)

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