Как работал с логами на девайсах

Работа с логами на девайсах в рамках QA-процесса

Работа с логами на физических устройствах (девайсах) — это фундаментальная часть моей повседневной деятельности как QA Engineer, особенно в проектах связанных с мобильными приложениями (Android/iOS), IoT устройствами, или embedded системами. Это не просто просмотр текста, а целый комплекс процессов для выявления, анализа и доказательства дефектов.

Основные источники и методы получения логов

Логи на девайсах можно получать из нескольких ключевых источников, каждый со своим методом доступа:

• Системные логи (Logcat для Android, syslog для iOS/Linux устройств):

    Это основной источник информации об работе ОС и приложения. Для Android я использую **adb (Android Debug Bridge)** через командную строку или интегрированные инструменты в IDE (Android Studio). Типичные команды:

```bash
# Фильтрация логов по тегу конкретного приложения
adb logcat -s "MyAppTag"

# Запись логов в файл для дальнейшего анализа
adb logcat > device_logs.txt

# Очистка буфера логов перед началом теста для чистоты данных
adb logcat -c
```

    Для iOS устройств, подключенных через USB, часто используется **Console.app** на macOS или инструменты через Xcode.

• Логи приложения (файлы на устройстве):

    Многие приложения записывают свои собственные логи в файлы в специальных директориях (`/data/data/<package>/` на Android, в песочнице на iOS). Чтобы их получить, требуется:

```bash
# Pull файла лога с устройства на компьютер
adb pull /sdcard/myapp_logs/debug.log

# Поиск и просмотр файлов на устройстве
adb shell ls -la /sdcard/myapp_logs/
```

    Часто приходится координировать с разработчиками, чтобы знать точное расположение и формат этих файлов.

• Логи через интерфейс разработчика (Developer Options):

    На Android устройствах можно включить дополнительные опции, такие как **"Взятие отчета о ошибках" (Bug Report)** или **"Запись трафика WiFi"**. Сформированный `bugreport.zip` — это мощный артефакт, содержащий моментальный снимок ВСЕХ системных логов, состояний процессов, трассировки и т.д.

Практический процесс анализа логов в тестировании

Моя работа с логами структурирована и состоит из нескольких этапов:

1. Подготовка и сбор: Перед началом тестового сценария я очищаю буфер логов и, если необходимо, начинаю запись в файл. Это обеспечивает "чистую" последовательность событий, соответствующую только моим действиям.

2. Фильтрация и поиск: Во время или после выполнения теста (особенно если обнаружен дефект) я фильтрую логи. Я использую:

    *   Фильтры по тегам (`TAG:MyApp`).
    *   Фильтры по уровню серьезности (`ERROR`, `WARN`).
    *   Поиск по ключевым словам (стектрейс исключения, имя метода, ID операции).

```bash
# Пример поиска всех ошибок (ERROR level) в логах
adb logcat | grep -i "error"
```

3. Анализ и интерпретация: Это самая сложная часть. Я ищу:

    *   **Исключения и стектрейсы:** `NullPointerException`, `IOException`, `ANR` (Application Not Responding) для Android.
    *   **Неожиданные сообщения:** Предупреждения (`WARN`) о deprecated методах, ошибки сети (`SocketTimeout`).
    *   **Паттерны:** Повторяющиеся сообщения перед сбоем, рост памяти, сообщения о убитых процессах (`AM killed`).

1. Создание артефакта для баг Réport: Логи — это неопровержимое доказательство. В баг-репорт я не просто вставляю тысячу строк. Я:

    *   Обязательно указываю **маркеры времени** (timestamp) начала и конца тестового сценария.
    *   Выделяю **ключевые строки**, непосредственно связанные с ошибкой, и объясняю их контекст.
    *   Прикрепляю полный файл лога (или bug report) как вложение, чтобы разработчик мог провести глубокий анализ.

Инструменты и лучшие практики

Для эффективной работы я использую не только командную строку, но и специализированные инструменты:

• ADB в сочетании с PowerShell/Bash скриптами для автоматизации сбора логов для серии тестов.
• GUI инструменты (Like Logcat в Android Studio) для удобного живого мониторинга и цветового выделения.
• Платформы для удаленного тестирования (BrowserStack, Sauce Labs) предоставляют свои интерфейсы для доступа к логам удаленных устройств.

Ключевые лучшие практики, которые я выработал:

• Знать код: Базовое понимание архитектуры приложения и ключевых тегов логгирования, используемых разработчиками, значительно упрощает фильтрацию.
• Логировать сценарий: Включать запись логов не только для негативных тестов, но и для успешных сценариев. Это помогает в анализе производительности и сравнения.
• Синхронизация действий и логов: Четко отмечать в логах момент начала конкретного тестового шага (можно даже добавлять свои маркеры через приложение, если есть доступ).
• Конфиденциальность данных: Логи часто содержают PII (Personal Identifiable Information), токены. При передаче вне команды необходимо их "обезличивать" (scrubbing).

В итоге, работа с логами на девайсах — это навык, сочетающий техническую компетенцию (знание ОС, инструментов) и аналитическое мышление для поиска "истории" ошибки в сырых текстовых данных. Это один из самых мощных инструментов QA для диагностики сложных дефектов, которые не проявляются явно в UI.