Логи и переменные окружения

Updated Jul 2026

Чтение логов

Логи -- ваш основной инструмент отладки, когда тесты падают в CI или на удалённых серверах. Вы не можете поставить точку останова на CI-раннере. Вы не можете открыть DevTools браузера на headless-раннере в 2 часа ночи. Но вы всегда можете прочитать логи.

Команды анализа логов

Базовое чтение логов

# Мониторинг логов в реальном времени
tail -f /var/log/app/application.log

# Последние 100 строк
tail -100 /var/log/app/application.log

# Первые 50 строк (проверка формата лога, заголовков)
head -50 /var/log/app/application.log

# Постраничный просмотр большого лог-файла
less /var/log/app/application.log
# Используйте: / для поиска, n для следующего совпадения, q для выхода

Фильтрация логов по времени

# Ошибки в определённом временном окне
awk '/2024-01-15 14:3[0-9]/' app.log | grep ERROR

# Логи за последний час (если формат лога включает ISO-временные метки)
awk -v start="$(date -d '1 hour ago' '+%Y-%m-%d %H:%M')" '$0 >= start' app.log

# Между двумя временными метками
awk '/2024-01-15 14:30/,/2024-01-15 14:45/' app.log

Структурированные (JSON) логи

Многие современные приложения ведут логи в формате JSON. Используйте jq для их парсинга:

# Форматированный вывод JSON-записей лога
cat app.json | jq .

# Фильтрация только ошибок
cat app.json | jq 'select(.level == "error")'

# Извлечение конкретных полей
cat app.json | jq 'select(.level == "error") | {timestamp, message, stack}'

# Подсчёт ошибок по сообщению
cat app.json | jq -r 'select(.level == "error") | .message' | sort | uniq -c | sort -rn

# Фильтрация по имени сервиса
cat app.json | jq 'select(.service == "payment-api" and .level == "error")'

Логи контейнеров

# Логи Docker-контейнера
docker logs test-app --tail 100 --follow

# Логи Docker Compose (все сервисы)
docker compose logs -f

# Логи Docker Compose (конкретный сервис)
docker compose logs -f app

# Логи пода Kubernetes
kubectl logs pod/test-app -f

# Логи Kubernetes с фильтрацией по времени
kubectl logs pod/test-app --since=1h

Типичные паттерны для поиска в логах

Переменные окружения

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

Установка переменных окружения

# Установить для текущей сессии
export BASE_URL=https://staging.example.com
export API_KEY=test-key-12345
export DB_HOST=localhost
export DB_PORT=5432

# Использовать в командах
curl -H "Authorization: Bearer $API_KEY" "$BASE_URL/api/users"

# Установить только для одной команды
BASE_URL=https://prod.example.com npx playwright test --project=smoke

Загрузка из .env-файлов

# Формат .env-файла
BASE_URL=https://staging.example.com
API_KEY=test-key-12345
DB_HOST=localhost
DB_PORT=5432
LOG_LEVEL=debug

# Загрузить все переменные из .env
export $(grep -v '^#' .env | xargs)

# Или загрузить из конкретного файла
export $(grep -v '^#' .env.staging | xargs)

Значения по умолчанию

# Использовать умолчание, если переменная не установлена
TIMEOUT=${TEST_TIMEOUT:-30000}
BROWSER=${TEST_BROWSER:-chromium}
WORKERS=${TEST_WORKERS:-4}
BASE_URL=${BASE_URL:-http://localhost:3000}

# Проверить, что обязательные переменные установлены
: "${API_KEY:?ERROR: API_KEY must be set}"
# Если API_KEY пустая или не установлена, скрипт завершается с сообщением об ошибке

Конфигурация для конкретного окружения

# Паттерн: разные .env-файлы для каждого окружения
# .env.dev
BASE_URL=http://localhost:3000
DB_HOST=localhost

# .env.staging
BASE_URL=https://staging.example.com
DB_HOST=staging-db.example.com

# .env.production
BASE_URL=https://www.example.com
DB_HOST=prod-db.example.com

# Загрузить нужный файл
ENV=${ENVIRONMENT:-dev}
export $(grep -v '^#' ".env.${ENV}" | xargs)
echo "Running tests against $BASE_URL"

Просмотр переменных окружения

# Показать все переменные окружения
env

# Показать все, отсортированные и отфильтрованные
env | sort | grep -i test

# Показать конкретную переменную
echo $BASE_URL

# Проверить, установлена ли переменная
if [ -z "$API_KEY" ]; then
  echo "WARNING: API_KEY is not set"
fi

Краткий справочник: основные команды

Собираем всё вместе: рабочий процесс отладки

Когда тест падает в CI, вот систематический подход с использованием инструментов командной строки:

# Шаг 1: Проверить, что изменилось (что могло вызвать сбой?)
git log --oneline -5 --stat

# Шаг 2: Проверить результаты тестов
cat test-results/junit.xml | grep 'failure message'

# Шаг 3: Проверить логи приложения на ошибки около времени выполнения теста
grep -A 5 "ERROR" /var/log/app/application.log | tail -30

# Шаг 4: Проверить системные ресурсы (был ли раннер перегружен?)
free -h
df -h
uptime

# Шаг 5: Проверить здоровье сервиса
curl -s -o /dev/null -w "%{http_code}" https://staging.example.com/health

# Шаг 6: Проверить статус контейнеров (если используется Docker)
docker ps -a
docker logs test-app --tail 50

# Шаг 7: Проверить переменные окружения (загружена ли правильная конфигурация?)
env | grep -i "base_url\|api_key\|db_"

# Шаг 8: Воспроизвести локально
export $(grep -v '^#' .env.staging | xargs)
npx playwright test tests/failing-test.spec.ts --headed

Практическое упражнение

1. Найдите и прочитайте последние 50 строк лог-файла приложения на вашей системе
2. Используйте jq для парсинга JSON лог-файла и извлечения только записей уровня error
3. Создайте .env-файл с тестовой конфигурацией и загрузите его в вашу оболочку
4. Напишите скрипт, который проверяет, установлены ли все обязательные переменные окружения, перед запуском тестов
5. Используйте watch для мониторинга здоровья эндпоинта каждые 5 секунд
6. Отработайте полный рабочий процесс отладки, описанный выше, на реальном или имитированном сбое теста

Тезис для собеседования: «Я ежедневно использую командную строку для QA-работы -- curl для быстрой валидации API, jq для парсинга JSON-ответов, grep для поиска корневых причин в логах приложений и Bash-скрипты для автоматизации повторяющихся задач вроде дымового тестирования нескольких окружений. Я уверенно работаю с Docker для развёртывания изолированных тестовых окружений с Compose-файлами, читаю логи контейнеров для отладки проблем инфраструктуры и управляю переменными окружения для конфигурации тестов в dev, staging и production. Когда тест падает в CI, мой первый шаг -- обычно проверка логов контейнеров и логов приложения, а не ожидание, пока кто-то другой расследует проблему. Я также пишу скрипты для очистки тестовых данных, проверки готовности сервисов и мониторинга здоровья окружений для поддержания надёжности нашей тестовой инфраструктуры.»