зачем тестировщику консоль в браузере
Зачем тестировщику консоль в браузере
Для чего тестировщику нужна панель разработчика браузера
Тренер курса «Погружение в тестирование. Jedi Point» Александр Астапченко расскажет как точно локализовать ошибки при тестировании веб-сайтов и сэкономить при этом время.
Панель (консоль) разработчика браузера нужна не только им самим, как многие думают – она может пригодиться и в тестировании веб-сайтов.
Данная статья предназначена для тех, кто хочет разобраться в эффективных методах тестирования, поэтому будем рассматривать вкладки, которые однозначно пригодятся тестировщикам.
Итак, начнем. Чтобы зайти в панель разработчика, необходимо открыть тестируемый веб-сайт и нажать на кнопку F12, после чего перед нами открывается следующая картина:
Начнем мы со вкладки “Elements”.
В моей практике был следующий случай: мне необходимо было протестировать страницу веб-сайта. В техническом задании был указан цвет кнопки (в кодировке). Именно для таких проверок вкладка “Elements” просто необходима как воздух.
Как же нам убедиться, что цвет кнопки именно такой, который указан в ТЗ :
Следующая вкладка которая нам может пригодиться, называется “Network”.
В моей практике был случай: я проходил негативный сценарий оформления заказа. При нажатии на кнопку “оформить заказ” ничего не происходило. Никаких ошибок на фронте (то есть видимой для пользователя части сайта) не отображалось. И вот тут-то помогла данная вкладка. Повторно проходя данный кейс с открытой консолью, был обнаружен запрос с ошибкой 401. Система отработала верно, но ошибка должна была отображаться и конечным пользователям.
Не стоит забывать и про адаптив, так как сейчас активно серфят интернет и через мобильные девайсы. Крайне важно убедиться, что не будет проблем с версткой при просмотре сайта через мобильное устройство/планшет. В таких ситуациях нам поможет “Toggle device bar”.
Итак, открываем консоль и кликаем на кнопку “Toggle device bar”.
Мы можем указывать вручную нужное разрешение или воспользоваться списком девайсов, которые уже есть в Google Chrome.
Также мы можем сами добавлять новые устройства в список, для этого необходимо нажать на кнопку “Edit”:
Для добавления необходимо установить чекбокс на нужное устройство, кроме того можно и создать устройство:
Созданный девайс отображается в выпадающем списке.
Ну что ж, я думаю у вас не осталось сомнений, что использование консоли намного эффективнее в решении этих задач. Это заметно экономит нам время и дает возможность точно локализовать ошибки.
Если вы хотите больше узнать о тестировании, приобрести знания и навыки, необходимые для работы джуниор-тестировщиком, записывайтесь на курс “«Погружение в тестирование. Jedi Point», а по промокоду jedi вам будет предоставлена скидка 10%.
И обязательно скачайте чек-лист “Что должен знать и уметь джуниор-тестировщик”, заполнив небольшую анкету.
Полезные функции DevTools для тестировщиков
P.S.: Очередность пунктов в списке не говорит об их важности.
Как мне кажется, на данный момент большинство компаний, которые делают продукты для мобильных устройств, имеют парк, из необходимых для полного тестирования их продукта, девайсов. Однако далеко не все считают необходимым тратить деньги на подобное. И, необходимость протестировать свой продукт на том или ином устройстве, не всегда зависит от того делают ли данный продукт для мобилок или нет. В связи с этим есть необходимость проверять свои сайты на мобильных устройствах без их физического присутствия. Минус данного подхода заключается в том, что большинство этих эмуляторов являются коммерческими.
Второй подпункт позволяет без всяких эмуляторов отследить все запросы и поведение Вашего продукта на устройствах android, просто подключив его к компьютеру и произведя небольшое количество манипуляций. Также плюс этого способа заключается в том, что можно настроить доступ к локальным серверам через такой тип подключения.
Продолжим рассматривать возможности DevTools для мобильных устройств. В вышеуказанных двух пунктах говорится о возможности изменять (подменять) геолокацию нахождения устройства и параметры юзер агента. Думаю, что многим тестировщикам частенько приходится воспроизводить какие-либо баги, которые были выловлены клиентами продукта не имея на то соответствующих технических возможностей. Подмена User-Agent поможет воспроизвести тот или иной баг, который был воспроизведен из какой-либо версии браузера или ОС. Закончив тестирование, никогда не забывайте возвращать данные User-Agent в исходное положение.
Подмена User-Agent
Определение JS пути к строке.
Этот пункт будет больше интересен тем, кто занимается автоматизацией тестирования. Скопировав полный путь к определенной строке в формате JS, можно ссылаться на него в автоматизированном тесте. Безусловно, данный способ не самый популярный для автоматизаторов, потому что этот путь может часто меняться, но на первых порах, когда еще не будет выработан скилл, помогающий с закрытыми глазами строить нужные селекторы для тестов, то эта возможность в DevTools может Вам помочь.
Считаю очень полезным умением для тестировщика представлять, как может выглядеть та или иная кнопка на сайте или какое-либо поле. В данном пункте рассматривается добавление фонового окраса для поля. Помимо этого, для элементов можно изменять и другие параметры (шрифт, размер, цвет и т.д.), для того чтобы можно было сразу указать разработчику или дизайнеру, как Вы видите этот элемент в контексте страницы либо, по просьбе заказчика изменить кнопку в “live” режиме.
Пример изменения размера поля элемента
Не будем забывать про тестирование производительности, данный пункт будет интересен именно с точки зрения ускорения загрузки Вашего web-сайта. Если количество неиспользуемого кода, который каждый раз “пробегает” при загрузке той или иной страницы, очень велико, то при помощи действий, описанных в статье, будет возможность найти весь неиспользуемый код и указать его, как артефакт в баг репорте.
Отчет о покрытии кода
Немного интересного про debug JavaScript.
Такую возможность добавили в DevTools относительно недавно (с 65 версией). Она позволяет сохранять все изменения, которые были внесены в те же CSS стили, о которых я говорил выше. И при перезагрузке страницы они сохранятся, чтобы, например, была возможность посмотреть, как ведет себя измененная кнопка при загрузке страницы.
Выбор скорости соединения
Тоже очень полезная вещь, которую я не смог найти ни в одной статье про DevTools для тестировщиков. Здесь можно настроить именно те столбцы, которые необходимы для анализа запросов на сайте в Вашем конкретном случае.
Список возможных столбцов в Network
Думаю, этот пункт было бы логично связать с восьмым в этом списке. Тоже очень полезная вещь, как мне кажется, которая может помочь уловить плавающий баг, либо отследить ненормальное или нелогичное поведение во время загрузки страницы.
С развитием рекламы в сети появились и различные приложения, которые эту рекламу блокируют, для удобства пользования браузерами. Для того, чтобы проверить как себя поведет страница, если будет заблокирован тот или иной запрос, можно воспользоваться блокировкой интересующего запроса, хороший пример описан в источнике.
Бонусы:
Здесь я бы хотел оставить те ссылки (с небольшими пометками), которыми я лично еще не пользовался, но которые, по моему мнению, были бы полезны для изучения и последующего применении тестировщиком на практике:
Безусловно DevTools не ограничивается тем функционалом, который я описал выше. Есть очень интересные вкладки, которые называется performance и audit, но я не стал нагружать еще этой информацией, так как считаю это темой для отдельной статьи, если в целом это интересно будет прочитать и познакомиться с этими вкладками в DevTools.
Chrome Developer Tools для тестировщика
Google Chrome — один из самых популярных браузеров. Он доминирует на рынке, и в ближайшие пару лет это вряд ли изменится.
Положение лидера делает тестирование в Chrome обязательным пунктом в чеклисте кроссбраузерного тестирования.
Инструменты разработчика (Dev Tools) — одна из функций браузера Chrome. Эти инструменты стали важной частью ежедневной работы как разработчиков, так и тестировщиков. Поэтому тестировщики должны знать, как пользоваться этими инструментами на полную и обеспечивать с их помощью лучшее качество тестирования.
Вообще инструменты разработчика доступны во всех основных браузерах. Но Chrome Dev Tools выделяются на их фоне, поскольку команда Google Chrome постоянно улучшает и расширяет их функционал.
В этой статье мы дадим 16 советов по использованию инструментов разработчика Chrome для кроссбраузерного тестирования. В следующем разделе мы расскажем, как зайти в Dev Tools. Если вы знаете, как это сделать, можно пролистать дальше и перейти сразу к советам.
Если вы хотите добавить дополнительные инструменты для упрощения тестирования — вот наша статья с подборкой пяти расширений Google Chrome, упрощающих жизнь тестировщику.
Как открыть инструменты разработчика?
Прежде чем знакомиться с различными приемами работы с Dev Tools, тестировщику следует научиться хотя бы открывать их. Это можно сделать двумя способами.
1. Откройте Google Chrome. Кликните правой кнопкой мыши по экрану. В открывшемся меню выберите Inspect.
2. Второй способ открыть инструменты разработчика — использовать сочетание клавиш. Можно нажать или Ctrl + Shift + C (Cmd + Option + C), или Ctrl + Shift + J (Cmd + Option + J).
В этой статье мы будем работать с инструментами разработчика в Google Chrome. Но аналогичный функционал есть и в других браузерах, например, в Mozilla Firefox и Safari. Открывается он примерно так же, как в Chrome: правый клик мышью и выбор Inspect Element в появившемся меню.
Итак, пора перейти к собственно советам по использованию инструментов разработчика для улучшения кроссбраузерного тестирования.
1. Поиск элемента
Эта функция помогает тестировщику (или разработчику) искать в DOM-дереве нужные элементы страницы.
Откройте Chrome Dev Tools и зайдите на вкладку Elements. Собственно, ее не нужно искать: по умолчанию она открывается первой. Находясь в этом разделе, нажмите Ctrl + F (Cmd + F).
Откроется поле для ввода, где вы сможете вставить искомое слово. После ввода инструмент подсветит этот элемент в коде.
2. Добавление и редактирование элементов
Инструменты разработчика позволяют добавлять теги в код или изменить их.
Таким образом можно быстро вносить изменения в стили сайта. Эти изменения будут применены только в вашем браузере и только в текущей сессии. Как только вы перезагрузите страницу, все восстановится в изначальном виде.
3. Изменение расположения DOM-элементов в дереве
Вы можете изменить позиции элементов во вкладке Elements, просто перетаскивая их.
Таким образом можно изменить структуру страницы и прикинуть, где ваш контент будет лучше смотреться.
4. Поиск CSS-свойства в Sources
Тестировщику часто приходится искать в Sources свойство, определенное в Elements, для внесения каких-то изменений. Это можно быстро сделать при помощи Ctrl + Click (Cmd + Click). Затем перейдите во вкладку Sources, где нужное свойство будет подсвечено.
5. Скриншот элемента
Тестировщики могут делать скриншоты элементов. Для этого выберите элемент и нажмите Ctrl + Shift + P (Cmd + Shift + P).
Откроется палитра команд. Выберите в ней Capture Node Screenshot, чтобы сделать скриншот элемента.
6. Использование результатов предыдущей операции в консоли
Работая в консоли, вы можете заметить, что каждая новая строка выдает определенный output, зависящий от выражения, определенного в предыдущей. Инструменты разработчика позволяют использовать этот output в следующих выражениях, обращаясь к нему при помощи «$_».
7. Многострочные скрипты
Обычно в любой программе или операционной системе консоль на каждой новой строке выдает результат предыдущего выражения.
Консоль разработчика работает аналогично.
Но в Console в Chrome Dev Tools тестировщик может применять многострочные скрипты. Для этого в конце каждой строки нажимайте не Enter, а Shift + Enter.
Вкладка Console быстро заполняется различными логами. Чтобы очистить консоль, нажмите Ctrl + L (Cmd + K) или напишите команду clear();
8. Локаторы для автоматизированного тестирования при помощи Selenium
Для автоматизированного тестирования с использованием Selenium очень часто используются локаторы. Они нужны для поиска конкретных элементов на странице.
В Selenium есть следующие локаторы:
При помощи инструментов разработчика можно быстро находить локаторы для любых элементов страницы.
Например, если вам нужен Xpath элемента, вы можете скопировать его при помощи инструментов разработчика, и «скормить» своим скриптам в Selenium.
9. Очистка cookies
Тестирование любого стороннего приложения создает множество cookies при отладке. Поскольку отладка требует выполнения скриптов множество раз, cookies могут влиять на результаты. Поэтому их необходимо чистить.
В Google Chrome для этого есть специальная опция в настройках. Но тестировщик может сэкономить время и быстро очистить все cookies на конкретном сайте или странице.
Для этого нужно перейти во вкладку Applications и выбрать Cookies в меню. Это даст вам возможность удалить cookies выборочно или все сразу.
10. Переход к определенной строке
В инструментах разработчика можно перейти к указанной строке, введя ее номер в строке поиска. Для открытия поиска нажмите Ctrl + O (Cmd + O).
11. Переключение между файлами в рамках проекта
Веб-проекты, как правило, содержат много файлов. Тестировщику может понадобиться неоднократно переключаться между ними в ходе интеграционного тестирования или на стадии юнит-тестов.
Инструменты разработчика позволяют быстро переключаться на нужный файл (в рамках проекта), просто введя его название в строке поиска.
Поиск по файлам открывается клавишами Ctrl + P (Cmd + P).
12. Watch Expression
В инструментах разработчика Chrome есть функция под названием Watch Expression. Найти ее можно во вкладке Sources, в колонке справа.
Тестировщику во время дебага нужно постоянно следить за переменными и выражениями. Искать их снова и снова очень затратно по времени. Watch Expression может делать это за вас.
Тестировщик просто вводит выражение или переменную в этот раздел, и они будут обновляться при каждом изменении.
13. JavaScript Breakpoints
Современные сайты содержат много JavaScript-кода. При одном-единственном запросе может меняться множество значений, а тестировщику нужно определять, где они находятся, и наблюдать за ними.
Например, API-запрос, использующий AJAX, может запускаться 4 раза и возвращать разные коды статуса. Для эффективного тестирования его нужно проверять на каждом этапе. Для этого в инструментах разработчика есть специальная фича — JavaScript Breakpoints.
Используя JavaScript Breakpoints, вы можете определять строку, на которой хотите приостановить выполнение кода.
Чтобы воспользоваться этой функцией, просто кликните на номер строки, на которой выполнение JavaScript-кода должно прерваться.
14. XHR/Fetch Breakpoints
Во вкладке Sources под Watch Expression есть раздел XHR/Fetch Breakpoint. С его помощью вы можете устанавливать брейкпоинт в скрипте при каждой отправке запроса.
Тестировщик также может использовать эту функцию только для определенных запросов, с конкретными URL.
15. Включение нескольких курсоров
Разве не круто было бы иметь возможность писать на разных строках одновременно? Инструменты разработчика позволяют это делать. Для этого нужно инициализировать множественные курсоры, зажав Ctrl (Cmd) и кликая в нужных местах.
16. Мониторинг производительности
Dev Tools позволяют тестировщику следить за производительностью сайта прямо в панели инструментов. Для этого нужно зайти во вкладку Performance, нажать Ctrl + E (Cmd + E), а затем — Ctrl + R (Cmd + R) для перезагрузки страницы. Чтобы прекратить замеры производительности, нажмите кнопку «Stop».
Инструменты разработчика сильно упрощают и ускоряют работу. Обязательно используйте их во время тестирования!
Инструменты тестировщика. Панель разработчика Chrome
Google Chrome включает в себя огромный набор функционала для тестирования сайтов веб-разработчиком. Панель разработчика открывается нажав F12:
Elements
Перед нами наше HTML-древо сайта разложенное по полочкам. Расположение внутреннего контента может отличаться, в данном случае я разбил на 2 колонки, где слева HTML-древо, а справа CSS свойства выбранного элемента (тега или тега, оба варианта применяются). Изменяется HTML-древо достаточно просто, выбираете нужный Вам тэг и нажимаете F2, далее изменяете HTML-код блока, где вы можете не только его содержание изменить, но и добавить другие атрибуты этому тэгу, а так же добавить другой тег перед или после данного тэга. При наведении мышкой на данный тэг на экране будет подсвечена область данного тэга, где оранжевым и зеленым цветом отмечены padding и margin.
Найти нужный тег в древе не сложно, есть 2 способа. Способ первый — перед Elements в меню находятся 2 иконки, вторая из которых перевод сайта в мобильную версию (не надо даже телефон покупать, всё итак видно верстальщику), а первая — выбрать элемент на странице. Достаточно нажать на первую кнопку, выбрать нужный блок и кликнуть по нему левой кнопкой мыши, таким образом у нас откроется именно данный тэг для корректировки. Метод второй, более быстрый — сразу правой кнопкой мыши нажать на нужный участок сайта и выбрать «Просмотреть код».
Выбрав нужный тег мы без труда можем его подправить в нужный нам вид. Хочу заметить, что именно так я корректирую верстку всегда, попросту беру нужные теги и меняю им свойства в браузере, и когда я останавливаюсь на последнем понравившемся варианте, то копирую результат уже в мои html и css. Теперь поговорим о правой колонке — styles и computed. computed — финальная версия всех стилей применённых к тегу. Помните я говорил о том, что браузер по умолчанию имеет перечень свойств у тега, а мы их лишь меняет на нужные нам, так вот тут и есть этот самый перечень финальной версии, то есть вместе с изменёнными нами свойствами. Если посмотреть внимательно, то можно заменить интересную особенность, что почти все теги имеют одни и те же свойства с разными значениями, а это говорит о том, что практически весь сайт можно сверстать используя всего 1 или 2 тега, что кажется и абсурдным, но возможным 🙂 В первой же колонке Styles указаны именно изменёнными нами стили (нашими таблицами стилей). В данной вкладке мы можем поменять влияние стилей как на данный тег работая в блоке element.style, так и изменять по id и class для всех элементов на сайте.
Итак, практическая задача, создайте 3 колонки через float:left с содержанием картинки + текста с одним классом. Далее через панель разработчика добавьте рамки, подкорректируйте расстояние между блоками и текстом используя внутренние и внешние отступы (меняя свойства класса), измените цвет текста в каждом блоке на свой цвет (тут уже element.style). Этого будет вполне достаточно, хотя для себя можете поэкспериментировать меняя таким образом код и других сайтов. Но помните самое важное, Вы не изменяете настоящие html и css файлы, а только временные конкретно данной страницы и как только вы обновите страницу, то и слетят все Ваши настройки!
Console
Без неё и жизнь не мила у любого программиста 🙂 Абсолютно все WARNING и ERROR записываются в данный блок. Убедитесь, что у вас выводятся все ошибки проверив следующим образом: нажмите на иконку filter в данном разделе и выберите вкладку «all», то есть выводить все ошибки.
Логи сохраняются в рамках данной страницы с момента открытия консоли, а не загрузки страницы. Поэтому если загрузить страницу, а после открыть консоль, то ошибок вы не увидите, хотя ошибки на странице присутствуют! Поэтому сначала мы открываем консоль, а потом перезагружаем данную страницу! Теперь справа от ошибки будет указываться файл на котором произошла ошибка и даже сама строчка. Хочу заметить, что в консоль так же попадают ошибки различных установленных плагинов и расширений для Google Chrome включая вирусы (они тоже прописываются как плагин или расширение).
Работая с JavaScript можем столкнуться с тем, что по клику происходит переадресация на другую страницу в формате: click — ошибка — переадресация, а ошибка произошла перед строчкой, которая должна была заблокировать переадресацию и поэтому в консоли пусто. Решается всё предельно просто, установите галочку Preserve Log, и тогда логи не будут очищаться после перезагрузки или переадресации страницы.
Sources и Network
Network более сложный функционал, тут перечень всех запросов и их ответов с сервером. Обратите внимание на то, что тут так же есть Filter — All, а так же Preserve log, это очень важно!
Ваш внешний вид данного раздела может немного отличаться, там может быть включен overview (соответствующая иконка с графиками), что я обычно выключаю. В левой колонке у нас запросы, в правой идут ответы. При этом ответы так же разделены на подразделы. Первый запрос всегда идёт к исполняющему файлу (указан url), если закрыть правую колонку, то можно увидеть подробности запроса, а именно: метод запроса, как долго он выполнялся (что будет свидетельствовать на сколько сеть и сайт работают хорошо, объем файла. Закрыв правую колонку можно вновь открыть повторно кликнув на интересующий нас файл для анализа.
Preview и Response
После запроса сервер возвращает нам что-либо, в Preview попадёт удобный для человека вид, а в Response — неотформатированный исходник. На примере запроса изображения во вкладку Preview попадёт сама картинка, а исходный код картинки по соображениям морали будет скрыт, но вот если Вы запросили HTML, JS, PHP файлы, то как раз заглянуть во вкладку Response стоит обязательно для того, чтобы убедиться, что там вернулся именно тот контент, который мы запросили и ожидаем увидеть!