Как будешь тестировать плавающий баг

Как я подхожу к тестированию «плавающего» бага

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

1. Детальная документация и сбор контекста

Первое и главное — немедленно начать фиксировать все наблюдаемые обстоятельства при каждом проявлении бага. Я создаю максимально подробный шаблон для описания в баг-трекинге (например, в Jira) и заполняю его:

• Точные шаги воспроизведения (даже если они не гарантируют результат).
• Дата, время и временная зона.
• Состояние системы: версия приложения, ОС, браузера, спецификации железа (CPU, RAM, диск).
• Контекст выполнения: тестовое окружение (DEV, STAGE, PROD), нагрузка на систему в момент возникновения, состояние сети (ping, потеря пакетов).
• Логи: немедленно собираю логи приложения (application logs), системные логи (syslog, dmesg), логи веб-сервера (Nginx/Apache) и БД. Ключевой момент — корреляция по timestamp.
• Скриншоты/видеозапись экрана, особенно если баг UI-ориентированный.

2. Анализ паттернов и гипотез

Собрав несколько инцидентов, я ищу закономерности:

# Пример анализа данных в Python (pandas) для поиска корреляций
import pandas as pd

# Собранные данные о проявлениях бага
bug_occurrences = pd.DataFrame({
    'time': ['10:30', '14:15', '09:00', '16:45'],
    'day_of_week': ['Mon', 'Wed', 'Mon', 'Fri'],
    'system_load': [85, 12, 78, 90],  # % загрузки CPU
    'network_latency_ms': [120, 15, 95, 200],
    'test_environment': ['STAGE', 'DEV', 'STAGE', 'STAGE']
})

# Поиск корреляции: баг чаще возникает при высокой нагрузке и латентности сети
high_load_cases = bug_occurrences[bug_occurrences['system_load'] > 75]
print(f"Баг проявлялся при высокой нагрузке в {len(high_load_cases)} из {len(bug_occurrences)} случаев")

На этом этапе формируются первые гипотезы:

• Конкурентный доступ/состояние гонки (race condition): баг возникает при параллельном выполнении операций.
• Проблемы с памятью: утечки, нехватка heap/stack, кэширование.
• Внешние зависимости: неустойчивость API третьих сторон, таймауты БД, проблемы с сетью или файловой системой.
• Временные условия: зависимость от времени, даты, таймеров, планировщиков ОС.
• Неочищенные состояния: остаточные данные от предыдущих тестовых прогонов.

3. Активное воспроизведение и усиление условий

Чтобы подтвердить гипотезу, я создаю сценарии, которые намеренно ухудшают условия, чтобы увеличить вероятность проявления бага:

• Нагрузочное тестирование: использую JMeter или k6 для создания конкурентной нагрузки на подозреваемый функционал.
• Эмуляция плохой сети: через Charles Proxy или Chrome DevTools добавляю задержки (latency), дросселирование (throttling) и потерю пакетов.
• Манипуляция временем: для проверки гипотез, связанных с датами/временем (например, переход на летнее время, конец месяца).
• Тестирование в изоляции и под отладчиком: запуск теста в отладчике (pdb для Python, gdb для C++, debugger в IDE) с брейкпоинтами для анализа состояния потоков и переменных в «момент сбоя».

4. Инструментарий и углублённая диагностика

Для low-level анализа я применяю:

• Мониторинг в реальном времени: top, htop, vmstat, iostat в Linux для отслеживания нагрузки на CPU, память, I/O в момент падения.
• Профайлеры: для выявления узких мест в коде и проблем с памятью (например, Async Profiler для JVM, py-spy для Python).
• Логирование с повышенной детализацией: временно добавляю или включаю TRACE/DEBUG логи в коде, особенно вокруг подозреваемых участков (обработка транзакций, работа с кэшем, сетевые вызовы).
• Контроль состояния БД: анализ долгих запросов, блокировок (locks), deadlock-ов с помощью инструментов мониторинга СУБД.

5. Разработка детерминированного теста и коммуникация

Как только гипотеза подтверждается, я:

1. Создаю максимально детерминированный тест, который, по возможности, стабильно воспроизводит проблему (например, тест на состояние гонки, который запускает два потока с строго определённой синхронизацией).
2. Документирую Root Cause Analysis (RCA) в баг-репорте: что, как и почему происходит. Это критически важно для разработчика.
3. Предлагаю сценарии фикса: не только «где чинить», но и как избежать подобного в будущем (внедрение idempotency keys, улучшение таймаутов и retry-логики, добавление health checks, стабилизация тестов через изоляцию и правильные assertions).

6. Постмортем и профилактика

После фикса бага я выступаю за проведение короткого постмортема, чтобы ответить на вопросы:

• Что позволило этому багу попасть в продукт?
• Можно ли улучшить мониторинг (например, добавить алерт на рост числа исключений определенного типа)?
• Нужно ли доработать тестовую стратегию (добавить chaos-инжиниринг, stress-тесты, тесты на конкурентность)?
• Стоит ли внедрить детекторы флейки в CI/CD пайплайн для автоматического кворума перезапусков падающих тестов?

Ключевая мысль: Тестирование плавающего бага — это не «попробовать ещё раз», а научный метод, сочетающий в себе наблюдательность, анализ данных, формирование гипотез и их методичную проверку с помощью продвинутого инструментария. Цель — превратить недетерминированную проблему в понятный и фиксируемый инцидент.