Тестирование с Devtools для тех, кто никогда не. Ч.3 – остальные вкладки

Когда только осваиваешь азы тестирования, бывает непонятно – зачем не-программисту в принципе нужна Devtools. Окей, там лежит код, убегают вдаль запросы, складируются кэш и куки…. Но к чему это всё ручному тестировщику? Расскажем в этой статье :)

В первой и второй частях мы рассказывали о двух вкладках панели разработчика – Elements и Network.

Сегодня речь пойдет сразу о нескольких вкладках: Console, Sources, Application.

Рассмотрим конкретные случаи, в которых эти вкладки пригодятся тестировщику — все кейсы взяты из нашей практики на проекте «Джуны».

Console показывает работу JavaScript на странице.

JavaScript, сокращенно JS, – это скрипты, которые приводят в движение анимацию на сайте, обеспечивают красивые переходы по кнопкам, отвечают за плавный автоскролл по странице или выполняют любой другой каприз. А главное — именно в скриптах прописываются методы, которые отправляют запросы на сервер и позволяют сайтам с клиент-серверной архитектурой функционировать. Наглядно это можно отследить в столбике Initiator вкладки Network – там указано, какой код вызвал тот или иной запрос. Для запросов на сервер это JavaScript.

Но вернемся к Console. Получается, что консоль – это журнал (по-айтишному – логи) выполняемых на странице скриптов. Сюда попадают информационные сообщения, предупреждения и сообщения об ошибках JS.

А еще в консоли можно увидеть ошибки, связанные с загрузкой изображений, стилей и других ресурсов страницы.

Скриншоты из консоли с логами JavaScript можно и нужно прикладывать к баг-репортам – разработчику будет легче пофиксить локализованный баг с точными данными об ошибке.

Задача 1. Определенный функционал не работает, но пользователю об этом не сообщается.

Такое случается довольно часто, разработчики в спешке могут просто забыть добавить уведомление для пользователя на фронтенде. А вот в консоли ошибка отобразится.

Задача 2. Необходимо составить рекомендации по оптимизации.

«Побочный эффект» от наблюдений за консолью – начинаешь замечать, какие скрипты регулярно выдают ошибку. Можно поговорить об этом с разработчиком – возможно, скрипты устарели или не используются. Страница будет грузиться и работать быстрее, если избавлять ее от такого мусора.

Важно: в консоль могут попадать ошибки, не связанные с сайтом как таковым. Например, уведомление The message port closed before a response was received означает, что нарушена работа расширения в браузере.

Тестируемый сайт и наши родные разработчики тут не при чем. Поэтому проводить проверки предпочтительно в режиме инкогнито.

Вкладка Sources выводит список файлов, из которых построена страница. И – о ужас! – эти файлы даже можно редактировать.

Sources нужнее программисту, чем тестировщику – она по сути представляет собой встроенную среду разработки (IDE). Но её можно использовать и при тестировании, давайте посмотрим как.

Задача 1. Нужно выявить неиспользуемый код.

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

Нажмите на кнопку Coverage в нижней части панели. Затем – на круглую стрелку. Через несколько секунд появится подробный отчет.

В колонке Unused Bytes подсчитаны байты кода, которые не используются на странице. Справа – они же, но уже в виде графика. Красные полосы – визуализация неиспользуемого объема кода.

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

Задача 2. Вам нужно поменять элементы сайта так, чтобы изменения сохранялись после перезагрузки.

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

Ответ прост — подменить содержимое можно локально через вкладку Sources.

Откройте вкладку Sources, затем – Overrides. Нажав на плюсик, вы сможете выбрать папку, куда будут сохраняться вносимые вами изменения. Важно после добавления папки дать панели разработчика доступ к этой папке.

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

Найдя элемент, вы можете внести в него желаемые изменения – будь то стиль или текст. После этого нажмите ctrl/cmd + S для сохранения – обратите внимание, во вкладке Overrides появился новый файл со светящейся точкой. Теперь он будет подменять собой изначальный ресурс для сайта.

Созерцаем результат, который не покинет нас даже после перезагрузки страницы <3

Во вкладке Application хранятся те самые кэш и куки, по поводу которых нас вечно тормошат уведомления на сайтах. Протестировать можно и их.

Задача 1. Необходимо проверить, что без авторизационных куки происходит выход из профиля.

Тут все просто: нужно авторизоваться на сайте, открыть вкладку Application и найти куки, связанные с авторизацией.

Удаляем их либо индивидуально (через правую кнопку мыши), либо чистим все данные на вкладке Storage.

Как только куки исчезнут – должен автоматически произойти выход из профиля.

Задача 2. Нужно протестировать бэкенд (внезапно).

Если на сайте предусмотрены разные роли, то для тестирования API могут пригодиться токены пользователей с разным уровнем доступа.

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

Заодно можно проверить, насколько токен отвечает требованиям безопасности: есть ли у него срок давности? Можно ли воспользоваться ручкой без токена вовсе?

Задача 3. Надо удостовериться, что новым пользователям приходят положенные уведомления, а старых пользователей не донимают одними и теми же вопросами.

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

Для этого также откроем Application и найдем куки, отвечающие за всплывающую рекламу или другую информацию. Если их удалить, соответствующие сообщения должны появиться снова.

И наоборот – даже если мы не взаимодействуем с всплывающими окнами, но устанавливаем значение true у куки просмотра этих окон, информация перестает появляться.

Например, новым пользователям показывается предупреждение об использовании куки. Пока пользователь не нажмет на крестик и не покажет, что он видел это предупреждение – всплывающее окно так и будет его преследовать :)

Попробуем, не нажимая на крестик, вручную вписать куки, которые должны сообщить системе: «Пользователь все прочитал».

Уведомление исчезнет, как только система получит соответствующие куки.

Это встроенный инструмент для оценки качества веб-страницы, очень схожий с PageSpeed (который, как и Chrome, разработан Google).

Главная цель Lighthouse – помочь с оптимизацией сайта. Он собирает весь неиспользуемый код, сообщает о перекрытии элементов, устаревших форматах файлов и других уязвимостях.

Грубо говоря, для ручного тестирования здесь мало простора. Но через отчет Lighthouse можно выявить основные проблемы с сайтом и получить конкретные рекомендации для улучшения. А кто как не тестировщик может донести эти ценные мысли до руководства и dev-отдела :)

Конечно, функционал панели разработчика далеко не исчерпывается этими кейсами. Мы просто надеемся, что с нашими примерами и лайфхаками Devtools стал чуть более понятным и ручным зверем для начинающих тестировщиков.

Если хочется практики, то можно воспользоваться бесплатным тренажером или поучаствовать в тестировании реального проекта в Джунах.

Остаемся на связи <3