Что тестировщику надо знать про панель разработчика

Панель разработчика — мощный инструмент... разработчика  Но и тестировщику бывает полезна — для локализации дефекта, описания ошибки, проведения тестов... Хочу зафиксировать краткую напоминалку, как ее можно применять. Глубоко копать мы не будем, только простые для понимания вещи.

Подопытный кролик — статья http://kiss-my-abs.livejournal.com/218056.html

1. Инспектор

F12 → Инспектор

Про интерфейс инспектора читать тут. Тестировщики обычно используют кнопку выбора элемента.

Инспектор → Самая левая кнопка → Наводим на элемент на странице → Попадаем на код элемента!

Примеры использования:

— Надо дать ссылку на окно регистрации, где воспроизводится баг.
— Надо дать ссылку на середину страницы. Мотать туда-сюда для воспроизведения отстой.
— Картинка не отображается, надо посмотреть, куда она ведет, может, там опечатка просто?
— Нужен идентификатор элемента для автотеста. Но если вы пишите код, вы и так все знаете 

См также:
Как получить прямую ссылку на всплывающее окно — ну или на блок текста в середине страницы, если у него есть якорь в коде.


Также тут можно на лету подхачить maxlength и снять проверку на клиенте. Например, когда мы создаем нового пользователя в Users, поле с именем кошечки ограничено 16-ю символами, но что будет, если изменить это ограничение или снять его?

Панель разработчика в хроме

Система Users создана специально для моих курсов. Это ее открытая версия, так что можете смело тренироваться. Скажу больше, там специально закопаны баги   Которые мы будем искать на курсе в расширенной версии, поэтому в комментариях к посту свои решения не предлагать)

См также:
Изучаем HTML, XHTML и CSS — крутая книжка про HTML
Конспекты лекций по HTML & CSS — мои заметки по книге

2. Консоль

Консоль → JS.

Ошибки сервера ищем в логах на сервере. А вот если упал JS — это надо ловить в консоли. Тут все просто, открываем консоль, вкладку JS — и проводим обычное тестирование, следя за тем, что в консоли нет ошибок.

Консоль и логи JS

См также:
Исследовательское тестирование — можно использовать туры, если не знаете, с чего начать тестирование

3. Запросы

Сеть → все (или отдельно только HTML, CSS итд).

Обновляем страницу, видим все входящие запросы. Выделяем любой и можем изучить входные параметры и полученный ответ. Например, кнопка на клиенте не сработала, почему? Это сервер не послал запрос или клиент не смог осилить ответ?

На вкладке "Сеть" смотрим входящие запросы и их статус

4. Ограничение трафика

Chrome F12 → Network → No trotting

В хроме есть крутая фишка, можно потестить «как будто бы у меня фиговый интернет». На скорость не пожалуйся, но и ошибок не должно появляться, если список долго грузится, например.

Как ограничить трафик в Google Chrome

Всем спасибо, все свободны!

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

• Школа для начинающих тестировщиков
• Логи как инструмент тестировщика

Безусловно, панель разработчика дает больше возможностей. И если это специфика вашей работы, вы знаете намного больше меня. Но мои курсы — не про тестирование веб-приложений.

Просто новичкам надо знать, как обойти ограничение maxlength, а в курсе про логи мы затрагиваем тему логов на клиенте и изучаем логи JS. Но, если хотите знать больше именно про веб:

— как перехватить запросы;

— как найти уязвимость;

— как померить производительность;

— ...

Вот это все — не ко мне, а к Алексею Баранцеву на тренинге про веб-приложения. 

PPS — Статья добавлена на Testbase в навык тестирования Web-а. Теперь не потеряется!