С какими вкладками DevTools работаешь

Question

claude-haiku-4.5 · Accepted Answer

## Работа с DevTools вкладками в браузере

DevTools — незаменимый инструмент для QA инженера при тестировании веб-приложений. За 10+ лет работы я научился использовать практически все вкладки DevTools для быстрого выявления проблем, анализа производительности и отладки функционала. Расскажу подробно о каждой.

### 1. Inspector / Elements

**Назначение:** Просмотр и редактирование HTML структуры и CSS стилей

**Основное применение при тестировании:**
- Проверка наличия необходимых элементов (buttons, inputs, labels)
- Проверка видимости элементов (display: none, visibility: hidden, z-index)
- Анализ CSS стилей и их влияние на внешний вид
- Проверка доступности (alt-текст, aria-labels, semantic HTML)

**Практические примеры:**
- Тестирую видимость кнопки на мобильном: изменяю viewport и проверяю, что кнопка не скрывается
- Проверяю, что disabled состояние элемента имеет правильные стили
- Анализирую, почему элемент не кликается (может быть перекрыт другим элементом с z-index)
- Проверяю responsive design, изменяя размер окна браузера

**Советы:**
- Правый клик на элементе → "Inspect" для быстрого выделения
- Edit HTML для быстрого тестирования изменений
- :hover состояние можно спровоцировать через меню элемента
- Lighthouse для проверки accessibility issues

### 2. Console

**Назначение:** Просмотр ошибок JavaScript и взаимодействие с приложением через JS

**Основное применение при тестировании:**
- Проверка ошибок JavaScript (неработающий функционал часто из-за ошибок в консоли)
- Проверка сообщений об ошибках при операциях
- Вызов функций для тестирования
- Проверка значений переменных

**Практические примеры:**
```javascript
// Получить значение элемента
document.querySelector('button').textContent

// Получить все элементы с классом
document.querySelectorAll('.product-item').length

// Спровоцировать клик
document.querySelector('button').click()

// Установить значение в input
document.querySelector('input').value = 'test@example.com'

// Проверить state (если React)
window.__REACT_DEVTOOLS_GLOBAL_HOOK__
```

**Вкладки:**
- **Console** — основной лог
- **Warnings** (⚠️) — предупреждения (deprecated API, неправильное использование)
- **Errors** (❌) — критичные ошибки

**Реальный пример из работы:**
Тестировал платежный функционал, платеж не проходил. В консоли нашел ошибку: "Token validation failed". Это помогло разработчикам быстро найти проблему с генерацией токена.

### 3. Network / Сеть

**Назначение:** Мониторинг сетевых запросов и ответов

**Основное применение при тестировании:**
- Проверка правильных API endpoints
- Анализ payload запроса и структуры ответа
- Проверка статус-кодов (200, 404, 500 и т.д.)
- Анализ времени отклика
- Проверка обработки ошибок сети

**Что я проверяю:**

**Метод запроса:**
- GET для получения данных
- POST для создания
- PUT/PATCH для обновления
- DELETE для удаления

**Статус-коды:**
```
200 OK — успешный запрос
201 Created — ресурс создан
400 Bad Request — ошибка в request'е клиента
401 Unauthorized — не авторизован
403 Forbidden — нет прав доступа
404 Not Found — ресурс не найден
500 Internal Server Error — ошибка сервера
503 Service Unavailable — сервис недоступен
```

**Примеры анализа:**

```json
// Request
POST /api/v1/checkout HTTP/1.1
Content-Type: application/json

{
  "items": [
    {"id": 123, "quantity": 2}
  ],
  "payment_method": "credit_card"
}

// Response (200 OK)
{
  "order_id": "ORD-12345",
  "status": "completed",
  "total": 99.99
}
```

**Полезные фильтры:**
- Фильтр по типу: XHR (только AJAX запросы)
- Фильтр по domain: api.example.com
- Поиск по названию запроса

**Особенности:**
- **Timing** — сколько времени заняла каждая фаза (DNS, TCP, TTFB, Download)
- **Size** — размер request/response (помогает выявить неоптимизированные данные)
- **Waterfall** — визуализация времени загрузки ресурсов

**Мой подход при тестировании API:**
1. Открываю Network tab
2. Выполняю операцию в приложении
3. Проверяю запрос (метод, URL, parameters, headers, body)
4. Проверяю ответ (status, headers, body/JSON)
5. Убеждаюсь, что данные правильно обрабатываются приложением

### 4. Application / Storage

**Назначение:** Просмотр и редактирование данных на клиенте (cookies, localStorage, sessionStorage, IndexedDB)

**Основное применение при тестировании:**

**LocalStorage:**
- Проверка, что приложение сохраняет user preferences
- Проверка persistence при перезагрузке
- Очистка данных при logout

Пример: Тестировал сохранение языка интерфейса. При выборе Russian должно сохраниться в localStorage. Проверяю:
```javascript
localStorage.getItem('language') // 'ru'
```

**Cookies:**
- Проверка session cookies
- Проверка expiration времени
- Проверка Secure и HttpOnly флагов (для безопасности)

**SessionStorage:**
- Временные данные для текущей сессии
- Очищается при закрытии вкладки

**IndexedDB:**
- Большие объемы данных (кэширование)
- Offline функциональность

**Практический пример:**
Тестировал offline функциональность PWA приложения:
1. Отключаю сеть (DevTools → Network → Offline)
2. Проверяю, что приложение работает
3. В Application → IndexedDB вижу закэшированные данные
4. При возврате онлайн данные синхронизируются

### 5. Performance / Производительность

**Назначение:** Анализ производительности приложения

**Основное применение при тестировании:**

**Основные метрики:**
- **FCP (First Contentful Paint)** — когда пользователь видит первый контент (target: < 1.8 сек)
- **LCP (Largest Contentful Paint)** — когда загружается главный контент (target: < 2.5 сек)
- **CLS (Cumulative Layout Shift)** — сколько элементы смещаются при загрузке (target: < 0.1)
- **FID (First Input Delay)** — задержка при клике (target: < 100ms)

**Профилирование:**
- Запись timeline во время операции
- Анализ, на что уходит время (JavaScript, Rendering, Painting)
- Выявление bottleneck'ов

**Практический пример:**
Тестировал загрузку списка товаров. Использовал Performance tab:
1. Запустил запись
2. Открыл страницу товаров
3. Остановил запись
4. Анализирую timeline:
   - DOM parsing: 200ms
   - JavaScript execution: 500ms (много!)
   - Rendering: 300ms
   - Paint: 100ms

Итог: JavaScript выполняется долго, нужна оптимизация.

### 6. Network Throttling / Сетевые условия

**Назначение:** Имитация медленной сети

**Основное применение:**
- Тестирование на 3G/4G/5G
- Проверка пользовательского опыта при медленной сети
- Проверка loading states и spinners

**Как использую:**
Network tab → Throttling dropdown → выбираю "Slow 3G"

Это имитирует:
- Download: 400 Kbps
- Upload: 400 Kbps
- Latency: 400ms

Проверяю:
- Появляется ли loading spinner
- Работает ли cancel операции
- Правильно ли обрабатываются таймауты

### 7. Sources / Отладчик

**Назначение:** Отладка JavaScript кода

**Основное применение при тестировании:**
- Установка breakpoints
- Step through кода
- Проверка значений переменных
- Отслеживание вызовов функций (Call stack)

**Практический пример:**
Тестирую расчет скидки при добавлении промокода. Функция не работает:
1. Устанавливаю breakpoint в функции applyPromo()
2. Вводу промокод
3. Код останавливается на breakpoint'е
4. Проверяю значения переменных
5. Вижу, что discount = 0 вместо ожидаемых 10
6. Помогает разработчикам быстро найти ошибку

### 8. Security

**Назначение:** Проверка безопасности

**Основное применение при тестировании:**
- Проверка HTTPS
- Анализ security headers
- Выявление смешанного контента (HTTP + HTTPS)
- Проверка certificate'а

**Практический пример:**
Сайт загружает JavaScript с HTTP вместо HTTPS (смешанный контент):
```
Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure script 'http://cdn.example.com/script.js'
```

Это потенциальная уязвимость, которую нужно исправить.

### Мой типичный workflow при тестировании веб-приложения

1. **Открываю DevTools:** F12 или Ctrl+Shift+I
2. **Inspector:** Проверяю структуру HTML
3. **Console:** Смотрю на ошибки
4. **Network:** Захватываю все запросы
5. **Performance:** Анализирую скорость
6. **Application:** Проверяю localStorage/cookies
7. **Security:** Убеждаюсь в защите

### Итог

DevTools — это мощный инструмент, который экономит мне часы при тестировании. Владение всеми вкладками позволяет:
- Быстро выявлять проблемы
- Давать разработчикам точные данные для отладки
- Проверять производительность и безопасность
- Анализировать сетевые запросы
- Тестировать на разных сетевых условиях

Основное правило: если веб-приложение работает неправильно, первое, что я делаю — открываю DevTools. В 80% случаев проблема выявляется в течение минуты.

С какими вкладками DevTools работаешь

Комментарии (1)

Работа с DevTools вкладками в браузере

1. Inspector / Elements

2. Console

3. Network / Сеть

4. Application / Storage

5. Performance / Производительность

6. Network Throttling / Сетевые условия

7. Sources / Отладчик

8. Security

Мой типичный workflow при тестировании веб-приложения

Итог