Как оформить Heisenbug при тестировании

Оформление Heisenbug в процессе тестирования

Оформление Heisenbug (от имени физика Гейзенберга и его принципа неопределенности) — это особая задача в работе тестировщика, поскольку этот тип дефекта проявляется непредсказуемо и часто «исчезает» при попытке его воспроизвести. Принципиальное отличие от обычного бага — его неуловимость и зависимость от внешних или скрытых факторов. Вот как следует подходить к его документированию и передаче разработчикам.

Ключевые шаги при оформлении Heisenbug

1. Сбор максимального контекста: В момент проявления дефекта необходимо зафиксировать всё, что может иметь отношение к проблеме. Это критически важно, так как воспроизвести его «по желанию» может не получиться.

2. Структура отчета об ошибке (Bug Report): Отчет должен быть особенно детализированным. Помимо стандартных полей (заголовок, окружение, шаги), необходимо добавить специальные разделы.

Пример структуры отчета для Heisenbug

**Заголовок:** [Heisenbug] Нестабильное падение сервиса "А" при высокой нагрузке, связанное с таймингами.

**Окружение (Environment):**
*   OS: Ubuntu 22.04 LTS
*   App Version: 2.5.1-release
*   Java: OpenJDK 17.0.4
*   Конфигурация сервера: 4 CPU, 16GB RAM, параметры JVM: -Xmx8g

**Шаги для воспроизведения (Steps to Reproduce):**
1.  Запустить нагрузочный тест сценария "Б" (JMeter script "scenario_b.jmx") с 50 виртуальными пользователями.
2.  Параллельно вручную выполнять 3-4 запроса к API эндпоинту `/api/v1/data/export`.
3.  Через 5-15 минут наблюдается падение сервиса с ошибкой `OutOfMemoryError: Java heap space`.
4.  **ВАЖНО:** Воспроизводится примерно в 30% попыток. При повторе тех же шагов, но с другим порядком операций, может не проявиться.

**Фактический результат (Actual Result):**
Сервис "А" завершает работу с критической ошибкой в логе (см. приложение). После перезапуска работает стабильно.

**Ожидаемый результат (Expected Result):**
Сервис должен сохранять работоспособность при комбинированной нагрузке.

**Степень серьезности/приоритет (Severity/Priority):**
Severity: Critical / Priority: Medium (из-за нестабильности воспроизведения)

**Собранные данные и контекст (Heisenbug Context):**
*   **Логи приложения (полные, за 10 минут до падения):** приложены файлом `service_a_heisen_crash.log`.
*   **Логи системы (syslog, dmesg):** приложены.
*   **Метрики (Metrics):** Скриншоты Grafana dashboard за период падения (показывают резкий рост потребления памяти и скачок активности GC).
*   **Версии зависимостей (Dependencies):** Вывод команды `mvn dependency:tree` приложен.
*   **Состояние системы:** На момент падения свободной оперативной памяти было ~2GB, нагрузка на CPU ~70%.
*   **Гипотеза (Hypothesis):** Предполагаю, что проблема связана с race condition в кешировании больших объектов при параллельных запросах на экспорт и нагрузке от JMeter. Дефект проявляется только при определенном "состоянии" кучи (heap).
*   **Попытки воспроизведения (Attempts to Reproduce):**
    *   Попытка 1 (с теми же параметрами JMeter) — успешно, сервис упал.
    *   Попытка 2 (увеличен `-Xmx` до 12G) — дефект не проявился.
    *   Попытка 3 (один поток в JMeter) — дефект не проявился.

Рекомендации для оформления

• Яркий маркер в заголовке: Используйте префикс [Heisenbug] или [Intermittent], чтобы сразу привлечь внимание.
• Детализация контекста: Чем больше данных (логи, метрики, дампы памяти, трафик сети), тем выше шансы у разработчика на анализ. Всегда прикрепляйте файлы.
• Формулировка гипотезы: Даже если она неточна, ваше предположение о возможной причине (race condition, состояние гонки, утечка памяти при специфическом сценарии, проблема с блокировками deadlock) задает направление для расследования.
• Описание невоспроизводимости: Четко укажите процент успешных попыток воспроизведения, какие факторы, по вашим наблюдениям, влияют на проявление (нагрузка, тайминг, порядок действий, состояние кеша).
• Связь с тестовой документацией: Укажите, из какого тест-кейса или исследовательского тестирования (exploratory testing) была обнаружена проблема.
• Коммуникация: После создания отчета обязательно устно обсудите проблему с разработчиком или на daily-standup. Heisenbug требуют командной работы и мозгового штурма.

Итог: Основная цель при оформлении Heisenbug — не предоставить четкий алгоритм воспроизведения (это часто невозможно), а дать разработчику максимально полный снимок (snapshot) состояния системы в момент сбоя и ваши обоснованные предположения. Такой подход превращает отчет из простого описания ошибки в ценную основу для глубокого расследования.