Как найти запрос, который вызывает ошибку на браузере?

Как найти запрос, вызывающий ошибку в браузере

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

Основные инструменты и методы

1. Панель разработчика браузера (DevTools)

Первая линия обороны. Открывается через F12 или Ctrl+Shift+I.

• Вкладка Network (Сеть): Здесь отображаются ВСЕ HTTP/HTTPS-запросы.

    * **Фильтрация**: Используйте фильтры по типу (XHR, JS, CSS), статусу (4xx, 5xx) или домену.
    * **Поиск ошибок**: Красный статус код (например, `404`, `500`, `403`) или статус `(failed)` сразу указывают на проблему.
    * **Preserve log**: Включите эту опцию, чтобы логи не очищались при перезагрузке страницы.
    * **Throttling**: Имитируйте медленную сеть, чтобы выявить таймауты.

• Вкладка Console (Консоль): JavaScript-ошибки и CORS-ошибки часто связаны с неудачными запросами. Ищите сообщения типа Failed to load resource или CORS policy.

Пример быстрого анализа в DevTools:

1. Откройте DevTools (F12) → вкладка Network.
2. Воспроизведите сценарий ошибки.
3. Отсортируйте таблицу по столбцу Status.
4. Кликните на запрос с ошибкой → исследуйте вкладки Headers, Response, Timing.

2. Прокси-серверы для автоматизации (Charles Proxy, Fiddler, mitmproxy)

Незаменимы для автоматизированного тестирования, так как позволяют перехватывать и модифицировать трафик из любых источников (браузер, мобильное приложение, автотесты).

• Charles Proxy:

    * Установите SSL-сертификаты для расшифровки HTTPS.
    * Используйте **Breakpoints** (точки останова), чтобы приостановить запрос и изучить его.
    * **Map Local/Remote** для подмены ответов сервера и симуляции ошибок.
    * Сохраняйте сессии (`.chls` файлы) для анализа или прикрепления к баг-репорту.

• Fiddler:

    * Мощные возможности фильтрации и скриптования на **C#**.
    * **Autoresponder** для подмены ответов.

Пример настройки перехвата в автотесте (Python + Selenium):

from selenium import webdriver
from selenium.webdriver.common.proxy import Proxy, ProxyType

# Настройка прокси для перенаправления трафика через Charles (localhost:8888)
proxy = Proxy()
proxy.proxy_type = ProxyType.MANUAL
proxy.http_proxy = "localhost:8888"
proxy.ssl_proxy = "localhost:8888"

capabilities = webdriver.DesiredCapabilities.CHROME
proxy.add_to_capabilities(capabilities)

driver = webdriver.Chrome(desired_capabilities=capabilities)
# Далее весь трафик из теста будет виден в Charles

3. Логирование на стороне браузера (Performance API, пользовательские обработчики)

Для сложных случаев можно встраивать код в тесты для мониторинга.

• Performance Observer API: Можно отслеживать ресурсы с ошибками.
• Перехват fetch/XHR: Подписка на события ошибок глобально.

Пример кода для отслеживания неудачных запросов в браузере:

// Код для выполнения в браузере через execute_script в Selenium
window.failedRequests = [];

const originalFetch = window.fetch;
window.fetch = function(...args) {
    return originalFetch.apply(this, args).then(response => {
        if (!response.ok) {
            window.failedRequests.push({
                url: args[0],
                status: response.status,
                statusText: response.statusText
            });
        }
        return response;
    }).catch(error => {
        window.failedRequests.push({ url: args[0], error: error.message });
        throw error;
    });
};

// Аналогично для XMLHttpRequest
const originalSend = XMLHttpRequest.prototype.send;
XMLHttpRequest.prototype.send = function(body) {
    this.addEventListener('error', function() {
        window.failedRequests.push({
            url: this.responseURL,
            status: this.status,
            statusText: this.statusText
        });
    });
    originalSend.call(this, body);
};

Стратегия поиска в процессе тестирования

1. Воспроизведение: Четко зафиксируйте шаги, приводящие к ошибке.
2. Включение записи: Запустите запись в DevTools или прокси ДО воспроизведения.
3. Анализ по фильтрам:

    * `status>=400`
    * `method:POST` (часто проблемные)
    * Поиск по части URL или ключевому слову из ошибки.

1. Изучение деталей проблемного запроса:

    * **Request Headers** (корректны ли `Authorization`, `Content-Type`?).
    * **Request Payload/Query String** (правильные ли данные отправлены?).
    * **Response Body/Headers** (что именно вернул сервер?).
    * **Timing/Waterfall** (на каком этапе запрос упал: DNS, SSL, Waiting?).

1. Сравнение с успешным запросом (если есть).
2. Фиксация доказательств: Делайте скриншоты всей вкладки Network, сохраняйте HAR-файл (Export HAR), логи из прокси.

Интеграция с автотестами

Для QA Automation критично уметь находить ошибки автоматически:

• Использование Selenium Logs (Performance Log): Chrome DevTools Protocol позволяет получать Network-логи.

  from selenium import webdriver
  
  caps = webdriver.DesiredCapabilities.CHROME
  caps['goog:loggingPrefs'] = {'performance': 'ALL'}  # Включаем логи производительности
  
  driver = webdriver.Chrome(desired_capabilities=caps)
  
  # После выполнения действий
  logs = driver.get_log('performance')
  for entry in logs:
      # Парсим JSON, ищем события Network.responseReceived с ошибкой
      print(entry['message'])
  

• Сторонние библиотеки: BrowserMob Proxy (в связке с Selenium) для генерации HAR программно.
• Мониторинг в Page Object: Можно добавить проверку на отсутствие критических ошибок в сети после ключевых действий.

Заключение: Умение быстро находить проблемный запрос — это комбинация знания инструментов и методичного подхода. Всегда начинайте с DevTools для ручного исследования, а для автоматизации внедряйте прокси-серверы и логирование через CDP. Ключ к успеху — фиксация контекста: HAR-файлы, логи и четкие шаги воспроизведения бесценны как для разработчика, так и для создания автоматических проверок на подобные ошибки в будущем.