Как тестировать бэкэнд с помощью devtools

Полезные функции DevTools для тестировщиков

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA — кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование — я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков).

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией :), решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования — скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.

P.S.: Очередность пунктов в списке не говорит об их важности.

1. Эмуляцияandroid и ios, подключениеandroidпри отладке. Как мне кажется, на данный момент большинство компаний, которые делают продукты для мобильных устройств, имеют парк, из необходимых для полного тестирования их продукта, девайсов. Однако далеко не все считают необходимым тратить деньги на подобное. И, необходимость протестировать свой продукт на том или ином устройстве, не всегда зависит от того делают ли данный продукт для мобилок или нет. В связи с этим есть необходимость проверять свои сайты на мобильных устройствах без их физического присутствия. Минус данного подхода заключается в том, что большинство этих эмуляторов являются коммерческими. Второй подпункт позволяет без всяких эмуляторов отследить все запросы и поведение Вашего продукта на устройствах android, просто подключив его к компьютеру и произведя небольшое количество манипуляций. Также плюс этого способа заключается в том, что можно настроить доступ к локальным серверам через такой тип подключения.
2. Переопределениегеолокациии подменаUser-Agent. Продолжим рассматривать возможности DevTools для мобильных устройств. В вышеуказанных двух пунктах говорится о возможности изменять (подменять) геолокацию нахождения устройства и параметры юзер агента. Думаю, что многим тестировщикам частенько приходится воспроизводить какие-либо баги, которые были выловлены клиентами продукта не имея на то соответствующих технических возможностей. Подмена User-Agent поможет воспроизвести тот или иной баг, который был воспроизведен из какой-либо версии браузера или ОС. Закончив тестирование, никогда не забывайте возвращать данные User-Agent в исходное положение.
3. ОпределениеJS путик строке. Этот пункт будет больше интересен тем, кто занимается автоматизацией тестирования. Скопировав полный путь к определенной строке в формате JS, можно ссылаться на него в автоматизированном тесте. Безусловно, данный способ не самый популярный для автоматизаторов, потому что этот путь может часто меняться, но на первых порах, когда еще не будет выработан скилл, помогающий с закрытыми глазами строить нужные селекторы для тестов, то эта возможность в DevTools может Вам помочь.
4. Изменение стилей CSSу элементов. Считаю очень полезным умением для тестировщика представлять, как может выглядеть та или иная кнопка на сайте или какое-либо поле. В данном пункте рассматривается добавление фонового окраса для поля. Помимо этого, для элементов можно изменять и другие параметры (шрифт, размер, цвет и т.д.), для того чтобы можно было сразу указать разработчику или дизайнеру, как Вы видите этот элемент в контексте страницы либо, по просьбе заказчика изменить кнопку в “live” режиме.
5. Неиспользуемые CSS и Javascriptв вёрстке. Не будем забывать про тестирование производительности, данный пункт будет интересен именно с точки зрения ускорения загрузки Вашего web-сайта. Если количество неиспользуемого кода, который каждый раз “пробегает” при загрузке той или иной страницы, очень велико, то при помощи действий, описанных в статье, будет возможность найти весь неиспользуемый код и указать его, как артефакт в баг репорте.
6. Немного интересного проdebug JavaScript. Многим этот пункт покажется лишним, ведь дебажить код — это вещь, которой в основном занимаются разработчики для отладки кода. Но со своей стороны хочу сказать, что это умение для тестировщика, лишним точно не будет. Безусловно для отладки кода необходимо уметь его читать. Думаю, многие видели большое количество мемов про JavaScript, которые красноречиво говорят о том, что язык далеко не самый легкий, особенно для простого обывателя. С другой стороны, некоторые данные иногда формируются на фронте, проходя несколько функций и понять почему в переменной сформировалось определенное значение, бывает очень важно. Даже в мои 3 года опыта работы в тестировании я уже сталкивался с дебагом кода именно в Chrome. Безусловно, без помощи разработчика я бы вряд ли смог это сделать, но в этой ситуации я понял, что этот момент очень важен.
7. Сохранение изменений в Chromeпри перезагрузке страницы. Такую возможность добавили в DevTools относительно недавно (с 65 версией). Она позволяет сохранять все изменения, которые были внесены в те же CSS стили, о которых я говорил выше. И при перезагрузке страницы они сохранятся, чтобы, например, была возможность посмотреть, как ведет себя измененная кнопка при загрузке страницы.
8. Имитация медленного сетевого соединения. Эффект DevTools, который демонстрирует, как ведет себя страница при её загрузке на мобильных устройствах. Разработка, в 90% случаев, ведется при хороших условиях, связанных со скоростью интернета и его стабильностью, также как и тестирование, в связи с чем выловить баг, который воспроизводится у пользователя, становится возможным только полностью воспроизведя все окружение, в котором этот баг проявился. С появлением нового высокоскоростного интернета для мобильный устройств, возможно эта проблема будет не совсем актуальной, но пока этого не происходит. По крайней мере не во всех странах .
9. Настройка столбцовна вкладке Network. Тоже очень полезная вещь, которую я не смог найти ни в одной статье про DevTools для тестировщиков. Здесь можно настроить именно те столбцы, которые необходимы для анализа запросов на сайте в Вашем конкретном случае.
10. Снимки экранапри загрузке страницы. Думаю, этот пункт было бы логично связать с восьмым в этом списке. Тоже очень полезная вещь, как мне кажется, которая может помочь уловить плавающий баг, либо отследить ненормальное или нелогичное поведение во время загрузки страницы.
11. Блокирование запросов. С развитием рекламы в сети появились и различные приложения, которые эту рекламу блокируют, для удобства пользования браузерами. Для того, чтобы проверить как себя поведет страница, если будет заблокирован тот или иной запрос, можно воспользоваться блокировкой интересующего запроса, хороший пример описан в источнике.
12. Все о cookiesво вкладке applications. Cookies — очень важная вещь для анализа пользовательских сессий, соответственно, так как мы (тестировщики) воспроизводим пользовательские сценарии, нам необходимо знать, как можно улучшить тест-кейсы, используя работу с куками. В статье описаны все сценарии (поиск, удаление, изменение данных).

Бонусы:

Здесь я бы хотел оставить те ссылки (с небольшими пометками), которыми я лично еще не пользовался, но которые, по моему мнению, были бы полезны для изучения и последующего применении тестировщиком на практике:

• описание всех shortcuts, которые существуют в chrome DevTools;
• все об анализе безопасности;
• имитация нового посетителя;
• повтор xhr запроса;
• проверка анимации;
• основные команды для запуска JavaScript в консоли;
• основные проблемы, которые можно увидеть во вкладке network.

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

Всем спасибо за внимание!

• тестирование
• devtools
• manual testing
• qa testing
• chrome devtools
• google chrome

Как начать тестировать backend и не сойти с ума

Дисклеймер: B первую очередь материал будет интересен тем, кто уже значительное время занимается тестированием пользовательского интерфейса и не знает, как подойти к тестированию backend части приложения. Я не претендую на истину: всё, что сказано ниже, является моим субъективным мнением и пережитым опытом.

Введение

Рынок IT специалистов начал стремительно развиваться в последние пару лет. Требования ко всем специальностям, которые задействованы в разработке программного обеспечения, растут со скоростью развития применяемых технологий. Требования выросли и к специалистам по тестированию. Например, если ещё в 2019 году для того, чтобы устроится тестировщиком в международную IT компанию достаточно было иметь год опыта тестирования чего-нибудь, прочитать «Тестирование dot com» Савина, уметь писать тест-кейсы, знать такие слова как «GIT», «SQL» и «Redmine», то в 2021 году ситуация стала радикально меняться. Осознание того факта, что пятилетний опыт ручного тестирования frontend части различных приложений недостаточен для конкурирования на рынке, привёл меня к выгоранию и побудил к решительным действиям. Я осознал, чтобы не остаться на обочине всей IT индустрии необходимо соответствовать современным критериям хорошего специалиста по тестированию. А именно, попытаться понять, как тестировать серверную часть приложений.

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

Отличие backend тестирования от frontend тестирования

Для начала расскажу, что такое backend тестирование (далее в тексте буду использовать сокращение БТ) и чем оно отличается от frontend тестирования (ФТ).

БТ — это процесс проверки функциональности и производительности серверной части программного обеспечения. Он может включать в себя тестирование базы данных, проверку работоспособности API и других сервисов, таких как кэширование или очереди сообщений.

ФТ — это процесс проверки пользовательского интерфейса и функциональности web и desktop приложений. Он включает в себя проверку правильности отображения веб-страниц, а также взаимодействия элементов пользовательского интерфейса, таких как кнопки, поля ввода, выпадающие списки, меню и т.д. Для ФТ используются инструменты, которые позволяют обнаружить ошибки в пользовательских интерфейсах, проверять поведение пользовательских элементов и форм, а также различные сценарии взаимодействия пользователя.

Для БТ используются инструменты, позволяющие создавать тесты для API, которые предназначены для обработки запросов и в некоторых случаях их автоматизации. Позже приведу примеры таких инструментов. В общем, важнейшим отличием между этими двумя видами тестирования является то, что ФТ осуществляется на уровне пользовательского интерфейса, а БТ на уровне сервера. Важно понимать, что если мы тестируем backend, то это не значит, что мы не используем его фронтовую часть для проверок.

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

Однако при переходе на backend есть ряд ключевых вещей, которые следует учитывать:

Понимание технологий. На мой взгляд БТ требует углубленного технического понимания проекта, поэтому важно знать основы разработки клиент-серверных приложений, понимать основы программирования, так как умение читать и понимать код является существенным преимуществом. Пригодятся навыки работы в IDE (рус. интегрированная среда разработки) и СУБД (системы управления базами данных), так как затрагивает, в том числе и проверку на корректность и целостность данных, а также проверку производительности базы данных при большой нагрузке.

Какие инструменты могут понадобиться в работе с новым проектом:

• Graylog – Платформа с открытым исходным кодом для чтения логов

• Lens – Полноценная IDE для Kuberneties, в БТ чаще всего используется для чтения логов микросервисов. Про Kuberneties, кластеризацию, контейнеризацию и в целом про Linux также есть смысл отдельно почитать, информации достаточно, и лишним точно не будет.

• Notepad++ — Текстовый редактор с широкими возможностями, удобно читать логи, запросы и ответы. Есть плагины для xml и json, а также для декодирования Base64.

• JMS Active MQ – Брокер сообщений ориентированный на передачу сообщений на языке программирования Java.

• Offset explorer и Kafka UI – Графические интерфейсы для Apache Kafka распределенного хранилища событий и платформы потоковой обработки.

• Redis – Резидентная СУБД. На разных проектах может использоваться по-разному, например как база данных или для реализации кэшей и брокеров сообщений.

• PostgreSQL, MySQL – Системы управления базами данных, в разных компаниях могут использоваться разные, главное знать SQL.

• DBeaver, SQL Developer, PgAdmin, Squirrel SQL – Клиенты для администрирования баз данных, бывают всякие, без SQL никуда.

• Elasticsearch – По сути документо-ориентированная база данных, используется в продуктах, для которых требуется реализация какого-нибудь поиска.

• Charles Proxy, Fiddler, Wireshark – Снифферы трафика, позволяют просматривать HTTP запросы и подменять ответы. В основном используются для ФТ, но уметь пользоваться крайне полезно.

• GIT (GIT LAB, GIT bash, GIT Extensions, Tortoise GIT) – Всё, что связано с распределенными системами управления версиями и их вспомогательными инструментами, тоже важно знать. Это упростит вхождение в сложные проекты.

• Отдельно выделю, надеюсь, всем известные инструменты разработчика: DevTools и чат-боты kuberneties в телеграм. Если ничего об этом не слышали, то срочно читайте.

Тестирование способов взаимодействия одной компьютерной программы с другими или тестирование API (Application Programming Interface), является существенной частью БТ. Тестировщик должен знать, какими инструментами тестирования API они могут пользоваться, какие сценарии нужно проверять и какие типы ошибок можно ожидать при работе с ним.

API играет ключевую роль в процессе обеспечения функциональности приложения и включает проверку правильности запросов и ответов, а также проверку соответствия контрактам сервисов. В тестировании backend используются различные протоколы, такие как HTTP, HTTPS, SOAP и другие. Понимание этих протоколов и стандартов поможет лучше понимать, как устроен backend, и какие тесты нужно создавать.

• Postman – Наверное, самый популярный инструмент c широким функционалом для тестирования REST API. Позволяет не только собирать коллекции запросов, но и автоматизировать тест-кейсы, а также перехватывать http трафик благодаря расширению на Google Chrome — Postman interceptor.

• SoapUi – Одно из старейших приложения для тестирования веб-сервисов c SOAP (Протокол обмена структурированными сообщениям в распределённой вычислительной среде), также начинен серьезным функционалом по тестированию REST API и нагрузочному тестированию.

• Swagger — это набор инструментов для разработчиков API и бывшая спецификация, на которой основана спецификация OpenAPI. Если Swagger присутствует на проекте, то это сильно упрощает работу по тестированию.

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

• jMeter – Инструмент для проведения нагрузочного тестирования от Apache.

• Yandex Tank – Чуть менее популярный инструмент от Яндекса.

• Иногда компании разрабатывают свои внутренние приложения для нагрузочного тестирования, но принцип работы будет схож с другими.

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

Концептуальные подходы к пониманию проблем:

• Ищите информацию. Учитесь работать с базами знаний вашей команды, это может быть Confluence или Wiki, что-то полезное можно найти в Jira, если конечно этими инструментами пользуются на проекте, но наверняка что-то похожее будет.
• Пользуйтесь поиском в корпоративных мессенджерах, часто бывает, что кто-то уже задавал похожий вопрос в рабочих чатах — опробуйте поискать по ключевым словам. Также не забывайте про поисковики, какую-то общую информацию можно найти и там.

• Записывайте всё. На каком проекте бы вы не работали, невозможно запомнить все нюансы, например, как запустить сборку, какой конфигурационный файл где лежит и за что он отвечает, как ставить доработки на тестовые стенды, и многое другое. Пишите инструкции, записывайте видео, в общем, ведите свою базу знаний, это сильно облегчает работу.

• Задавайте вопросы. Тут пригодятся все ваши soft skills. Если поиск в интернете и по своим записям ни к чему не привели, то самое время обратиться к всевышним. Обратитесь к старшим коллегам-тестировщикам: наверняка они уже с этим когда-то разбирались и обязательно вам помогут (помните, что когда-то они были на вашем месте). Не забывайте задавать вопросы напрямую разработчикам фичи, которую вы будете проверять. Это закрывает большую часть проблем. Если ничего из вышеперечисленного не помогает, то пишите вашему прямому руководителю, чем быстрее, тем лучше для всех.

Как повысить свои когнитивные способности:

• Выспаться. Постоянный недосып напрямую влияет на работу мозга, старайтесь спать не меньше 8 часов.

• Исключить стресс. Решение сложной задачи само по себе стрессовая ситуация, но можно просто относиться к этому проще, в конце концов это всего лишь работа.

• Следить за питанием. Здоровый рацион сам по себе крайне важен в жизни, но в нашем случае будет достаточно не переедать во время работы и употреблять достаточное количество жидкости.

• Отдыхать. Без эффективного отдыха решение задач дается еще тяжелее, старайтесь не перерабатывать и уделять время любимым делам.

• Обеспечить организм физическими нагрузками. В идеале конечно спорт, но это подходит далеко не всем, например, для себя я выбрал длительные пешие прогулки, ремонт кабинета и дачные хлопоты.

Бонусом небольшой список терминов, с которыми вы, может, ещё не знакомы, но которые наверняка встретятся на бэкэнд проекте. Поясню кратко как я их понимаю, а если есть необходимость узнать больше о них просто погуглите.

• Stack trace (рус. «стектрейс», трассировка стека) – Понятие объемное и не простое, но тестировщику достаточно знать что это кусок логов который нужно прислать разработчику если возникло исключение.

• Exception (рус. «экзепшн», исключение, исключительный случай) – Возникает, когда произошло что-то что не было учтено программой, какое-то не спрогнозированное поведение.

• HAR (рус. «хар лог», «хар файл») – Архив или лог сетевых запросов браузера. Иногда тоже может потребоваться такой лог, в котором собраны все отправленные запросы.

• Breakpoint (рус. «брейкопинт», точка остановки) – Преднамеренное прерывание хода выполнения программы. Понятие может потребоваться в процессе работы со снифферами трафика или с интегрированной средой разработки.

• Mocks (рус. «моки», «заглушки») – Сюда входят любые инструменты которые заменяют реальный объект в условиях теста. Обычно применяются во всех видах тестирования, но конкретно при работе с бэкэндом без них никуда.

• Core (рус. «кор», ядро) – Достаточно широкое понятие и может употребляться в разном контексте, например, для определения какой частью приложения занимается группа разработки и тестирования, если самой основной, то говорят «кор команда». Также если речь идет непосредственно о коде: «зашито в коре».

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

• Legacy (рус. «легаси код», наследие) – Буквально термин означает старый код, который был написан очень давно по старой монолитной архитектуре. Его достаточно сложно читать и поддерживать.

• Microservices (рус. микросервисы, микросервисная архитектура) – В отличие от монолита направленная на взаимодействие небольших, слабо связанных и легко изменяемых модулей – микросервисов.
• Enterprise (рус. «энтерпрайз») – Термин не относится напрямую к понятию бэкэнд команд, но обычно сложные бэкэнд проекты являются значимой частью энтерпрайз разработки, проще говоря этим словом подразумевается промышленная разработка крупных систем под требования конкретного заказчика, ну и вся инфраструктура организации.

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

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

• Блог компании Usetech
• Программирование
• SQL
• Git
• Тестирование веб-сервисов

7 полезных функций DevTools для тестировщиков

Инструменты разработчика отображаются в браузере Chrome в виде панели, на которой доступны сведения об открытой вкладке. Чтобы воспользоваться DevTools, откройте меню, нажав на три точки в правом верхнем углу, выберите More Tools (Дополнительные инструменты), а затем Developer Tools (Инструменты разработчика). Также можно использовать горячие клавиши Ctrl+Shift+I или нажать F12. По желанию панель DevTools можно переместить или открыть в отдельном окне.

О том, как открыть DevTools в других браузерах и почему инструменты разработчика делают работу эффективнее, мы рассказали в этой статье.

Просмотр информации об элементах

На вкладке Elements (Элементы) можно просмотреть информацию об элементах веб-страницы, дереве DOM и стилях CSS. На основе этой информации можно определить лучшие локаторы для веб-элементов, что особенно актуально при тестировании средств веб-автоматизации.

В инструментах разработчика можно получить XPath или CSS-селектор элемента. Для этого откройте вкладку Elements, щелкните правой кнопкой мыши на нужном элементе и выберите Copy (Копировать), а затем Copy XPath или Copy Selector.

Для поиска элементов в DOM нажмите Ctrl+F . Искать можно не только по простому тексту, но и с помощью фильтров, которые позволяют обнаружить сложные CSS-селекторы или XPath. С их помощью можно убедиться, что локатор обнаруживает нужные элементы и увидеть количество совпадений.

Указанный CSS-селектор соответствует 9 элементам в DOM

Мониторинг HTTP-запросов

Вкладка Network (Сеть) содержит информацию о HTTP-запросах. Здесь отображаются заголовки, тело запроса, код статуса, тело и время ответа. На этой вкладке тестировщик может увидеть текущий статус сетевых запросов.

URL и тело запроса можно скопировать, чтобы в дальнейшем использовать для тестирования API, например, с применением Postman. Также тут можно обнаружить лишние запросы, отправляемые во время загрузки. Если страница загружается долго, можно определить, с какими запросами это связано.

Для работы со вкладкой Network нажмите на кнопку Record (Запись). Затем отправьте запросы в приложении, и они отобразятся на этой вкладке.

HTTP-запросы, которые зафиксированы на вкладке Network при загрузке блога TestProject

Нажмите на HTTP-запрос, чтобы просмотреть:

• URL запроса
• Заголовки запросов и ответов
• Метод запроса и код статуса
• Тело запроса и ответа.

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

Каскадная диаграмма на вкладке Network позволяет увидеть этапы запросов. Например, сколько времени занял каждый запрос, когда он был отправлен и выполнен. С помощью этого инструмента тестировщик может узнать, какие запросы выполняются параллельно и обнаружить проблемы с производительностью.

Моделирование характеристик сети

На вкладке Performance (Производительность) отображается длительность каждого события. Начните запись, выполните нужные действия и остановите ее.

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

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

Моделирование характеристик сети

Эмуляция устройств

Хотя девтулс Chrome не заменят тестирование на реальных устройствах или продвинутых эмуляторах, в них доступны средства эмуляции. С их помощью можно посмотреть, как приложение выглядит на различных экранах.

Для этого перейдите в меню настроек или нажмите F1 в режиме Инструментов разработчика и выберите Devices (Устройства).

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

Чтобы активировать эмуляцию устройства, нажмите на иконку с изображением телефона и планшета.

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

Работа с файлами cookie

Файлы cookie содержат информацию, которая хранится на устройстве, и передают данные серверу, позволяя отображать персонализированный контент. Благодаря таким файлам страницы загружаются быстрее и сохраняют важную информацию, например, содержимое корзины в интернет-магазине.

Веб-приложения нужно тестировать с разными настройками файлов cookie. Основные сведения о файле cookie — Name (Название), Value (Значение) и Expiration date (Срок действия) — название, значение и срок действия — можно получить на вкладке Applications (Приложения) инструментов разработчика Chrome.

Раскройте список Cookies в левом меню. Выберите сайт для просмотра сохраненных файлов cookie и подробной информации о них. Здесь можно удалить файлы cookie, изменить их значения и отследить влияние таких изменений на работу приложения.

Файлы cookie для страницы веб-приложения

Создание скриншотов

С помощью инструментов разработчика можно делать скриншоты сайта или веб-приложения. Нажмите Ctrl+Shift+P , введите «screenshot» и выберите один из четырех вариантов.

• Capture area screenshot (сделать скриншот области) создает скриншот определенной области экрана, как инструмент «Ножницы» в Windows.
• Capture full size screenshot (сделать полноразмерный скриншот) создает копию изображения всей страницы, включая области, которые не отображаются на экране.
• Capture node screenshot (сделать скриншот узла) делает скриншот элемента, выделенного на вкладке Elements.
• Capture screenshot (сделать скриншот) делает скриншот отображаемой части страницы.

При выборе любого варианта будет сохранен скриншот в формате .png.

Тестирование локализации

Если приложение локализовано, и нужно проверить его работу с различными настройками страны и языка, в инструментах разработчика можно изменить региональные настройки браузера. Откройте меню с тремя точками рядом с кнопкой настроек, нажмите More Tools, а затем Sensors (Датчики).

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

Эта статья — адаптированный перевод материала тестировщицы Андреа Драничану, опубликованного в блоге TestProject.

Изучите ручное тестирование на Хекслете На Хекслете есть профессия «Инженер по тестированию». Освойте ее и познакомьтесь с этапами разработки и жизненным циклом ПО, техниками тест-дизайна, системами управления тестированием и системами баг-трекинга.

Полезные функции DevTools для тестировщиков

В статье оцениваем браузерные инструменты, которые ускорят и упростят процесс тестирования.

Привет! Меня зовут Ульяна, я тестирую новые фичи и продукты Selectel. Обычно тестирую фронтенд сайта компании или панели управления, но сегодня выступлю немного в другой роли тестировщика.

Я завсегдатай Heisenbug — одной из самых крупных конференций для тестировщиков. На последнем митапе мне запомнился доклад про различные фичи и возможности браузерных инструментов разработчика. Некоторые были для меня в новинку, и я решила протестировать самые интересные и полезные, на мой взгляд. Оценила их на практике и составила обзор по каждому. Если вы в поисках новых инструментов для работы, этот текст для вас.

Нефункциональное тестирование

В некоторых случаях, кроме функционального тестирования, мы обращаемся к формату UX-тестирования новых фич. В первый раз, конечно, это делает UX-проектировщик, который создавал макет работы функциональности в интерфейсе, но мы скорее перепроверяем. Что-то могло пойти не так в ходе задачи — чтобы не упустить нюансы, мы иногда проверяем мелкие детали, сравнивая их с изначальным макетом.

Если перед вами стоит похожая задача, вам в этом помогут несколько решений в DevTools. Они ускорят процесс сверки-тестирования, а также упростят его.

Проверка шрифтов

Браузер: Firefox
Сложность: 7/10
Оценка: 5/10

Через DevTools вы можете вывести список шрифтов, используемых на проверяемой странице. Фича позволяет увидеть названия всех шрифтов на странице и их внешний вид. Будет полезно в случаях, когда кажется, что шрифт одного из элементов на странице отличается, или когда на странице используется большое количество различных шрифтов и элементов.

Как использовать?

1. Перейти на вкладку Инспектор.
2. Нажать на одну из кнопок — Включить 3-панельный инспектор или Показать все вкладки, выбрать Шрифты.

Алгоритм выбора отражен на гифке ниже:

Ограничения и минусы

• Фича есть только в браузере Firefox. Поэтому, если у вас есть необходимость упростить и ускорить проверку, придется его установить (если ранее вы его не использовали) и открыть проверяемую страницу в нем. В том же Chrome можно проверить шрифт только у каждого из элементов в отдельности, что будет значительно дольше. Особенно если элементов на странице очень много.
• Решение не для всех и каждого. Будет полезно тем, у кого есть частая потребность в подобных проверках. Например, вы создаете проект с нуля, и изменения во внешнем виде сайта или личного кабинета проходят довольно интенсивно.
• Найти функционал в DevTools не так просто. Инструмент менее используемый и специфичный, так что разработчики запрятали шрифты подальше. Но, надеюсь, гифка вам помогла!

Личный опыт

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

Режим редактирования всего документа

Браузер: любой
Сложность: 1/10
Оценка: 8/10

Эта фича будет полезна, если при проверке UX-макета необходимо понять, что произойдет, если у одного или нескольких элементов изменится длина названия или объем содержимого. Всего одна команда в консоли (вместо редактирования запросов или поиска нужного свойства в коде) позволяет:

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

Как использовать?

1. Открыть консоль.
2. Ввести команду document.designMode=’on’ .
3. Чтобы выйти из режима редактирования, используйте команду document.designMode=’off’ .

Ограничения и минусы

• Непросто редактировать ссылки или кликабельные элементы. Приходится ловить правильный курсор, что, к сожалению, не всегда получается. Это затрудняет, а в некоторых местах делает невозможным применение инструмента.
• Фича не дает гарантий. Нет твердой уверенности в том, что, если в этот элемент придет введенное вами содержимое, при перезагрузке оно отобразится точно так же, как в режиме редактирования. Если есть необходимость в этом убедиться, придется действовать по старинке: использовать раздел Элементы или редактировать запросы и ответы на них.

Личный опыт

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

Неклассические скриншоты

Сложность: 8/10
Оценка: 1/10

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

Скриншоты full page

Браузер: Chrome, Firefox

Как использовать?

1. В настройках выбрать Run command.
2. Запустить команду Capture full size screenshot.

1. В настройках добавить галочку пункту Сделать снимок экрана всей страницы.
2. Для создания скриншота кликать на кнопку камеры, которая появляется рядом с меню настроек.

Скриншоты узлов

Как использовать?

1. Зайти на вкладку Elements.
2. Выбрать необходимый узел, кликнуть правой кнопкой мыши.
3. Выбрать в выпадающем меню Сделать скриншот узла.

Личный опыт

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

Так что тут дизлайк — гораздо проще воспользоваться встроенными возможностями компьютера (если не нужно выделять что-то на скрине) или поставить свободно распространяемую утилиту Lightshot, которая позволит еще и выделять цветом необходимые элементы.

Присоединяйтесь к команде Selectel

Ищем единомышленников, чтобы делать команды и процессы еще круче.

Функциональное тестирование

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

HAR-архивы

Браузер: любой
Сложность: 1/10
Оценка: 9/10

При помощи DevTools можно не только просматривать пришедшие ответы с бэкенда, но и сохранять их в виде HAR-файла. Что может дать сохранение полного списка запросов и сопутствующей информации?

• Эту информацию можно отдать разработчику, если вы нашли трудно воспроизводимый баг. Возможно, с бэка пришло что-то особенное, какая-то проблема с куками и так далее. Все это сохраняется в HAR-файле и может быть использовано для локализации бага.
• Архив содержит все запросы пройденного сценария, что можно использовать для создания автотестов, отслеживания повторяемости теста и др.
• С помощью HAR можно организовать нагрузочное тестирование. Если вы хотите проверить не конкретный запрос/эндпоинт, а полностью приложение по реальным сценариям, можно записать HAR-архив, экспортировать его в необходимый формат и использовать в инструменте для нагрузочного тестирования. Это значительно ускорит процесс, особенно когда запросы содержат в себе огромное количество информации (куки, заголовки, параметры и т.д.). Не вбивайте все это вручную — используйте HAR-архив.

Как использовать?

Есть два варианта сохранения HAR-архивов.

Первый: Кнопка Export HAR…, расположенная над фильтрами.

Второй: Кликнуть правой кнопкой мыши по списку эндпоинтов и в выпадающем меню выбрать Save all as HAR with content.

Ограничения и минусы

• Информация сохраняется полностью. Этот пункт может быть как плюсом, так и минусом. Проблема в том, что нельзя выбрать сохраняемые запросы. И в их число могут войти конфиденциальные данные, логины, пароли и т.д. Поэтому, если в запросах есть информация о клиентах, шарить HAR-архив можно только с теми, кому разрешен доступ к этой информации. Если есть ваши личные логин и пароль, то после сохранения лучше вообще отредактировать файл.
• Архив может получиться объемным. Из-за того, что сохраняется вся информация, это может быть не только текст, но и медиа. Будьте готовы к тяжелому файлу.

Личный опыт

Я оценила всю прелесть фичи, когда мне нужно было в краткие сроки разобраться с основами нагрузочного тестирования и провести исследование одной из внутренних систем Selectel. Мне не пришлось вручную создавать и настраивать весь сценарий нагрузки. Я просто сохранила необходимый набор запросов и использовала его в JMeter, отредактировав должным образом. Благодаря этому мы смогли вовремя проверить и улучшить работу тестируемого приложения.

Редактирование запросов

Браузер: Firefox
Сложность: 6/10
Оценка: 5/10

Бывают ситуации, когда необходимо проверить данные, которых нет на бэкенде, или отправить на бэк значения, которые невозможно ввести на фронте. В таком случае можно самостоятельно изменить и отправить на бэк запрос с необходимыми данными. Безусловное преимущество этой фичи в том, что она бесплатна и всегда под рукой (если вы используете Firefox, конечно). Если необходимо проверить реакцию на один конкретный запрос, то с помощью этого инструмента в DevTools все это можно реализовать очень просто — без дополнительного времени и усилий.

Как использовать?

1. Открыть вкладку Сеть.
2. Выбрать нужный запрос, кликнуть по нему правой кнопкой мыши, нажать Изменить и снова отправить.
3. Отредактировать необходимые поля.
4. Нажать кнопку Отправить.

Ограничения и минусы

• Реализовано только в одном браузере. Если появляется необходимость отредактировать запрос и проверить реакцию фронтенда в другом браузере, все равно придется пользоваться сниффером.
• Можно отредактировать только запрос. Если нужно отредактировать ответ, придется пользоваться сниффером (снова).
• Плохо работает для запроса, который выполняется в стеке из нескольких. Проще поставить breakpoint в сниффере (опять) и отловить необходимые для исправления запросы, чем вручную запускать то, что надо, мучиться и в итоге получить некорректные результаты.

Личный опыт

Для меня фича оказалась не очень востребованной, поскольку я чаще пользуюсь редактированием именно ответов от бэкенда. Гораздо проще здесь пользоваться Charles Proxy. Поэтому независимо от браузера и задачи я тестирую с его помощью.

Фильтры

Браузер: любой
Сложность: 2/10
Оценка: 10/10

Раздел Сеть (он же Network) — один из самых часто используемых в DevTools. Там можно найти все запросы, которые отправляются на бэкенд из тестируемого приложения и возвращаются назад. Но чем больше приложение, тем больше разного рода информации отображается в Network. Чтобы найти то, что интересует вас в данный момент, можно использовать фильтры.

На самом деле это один из самых гибких инструментов в DevTools, потому что его можно настроить огромным количеством способов. Все зависит от того, какая информация на выходе вам необходима, ваших знаний и фантазии. С помощью фильтров можно отслеживать только ошибочные/только успешные запросы, запросы с определенных URL, запросы с определенным методом запроса (GET, POST, …), по размеру и другим параметрам.

Как использовать?

В поле Filter ввести название фильтра и ожидаемое значение через двоеточие.

Список возможных фильтров можно посмотреть по ссылке.

Ограничения и минусы

• Придется покопаться в документации. Чтобы знать, в каком браузере и каким фильтром можно воспользоваться, придется поизучать доку. С другой стороны, узнаете больше об интересующих вас фильтрах.
• Операция ИЛИ пока не реализована. На данный момент если ввести несколько элементов поиска, это будет эквивалентно операции И.

Личный опыт

Я не представляю жизни без этой фичи и постоянно ее использую. Без фильтров я бы тратила на поиск необходимой информации в 3-4 раза больше времени. С ними же, даже с минимальной настройкой, необходимые запросы отслеживаются сразу же.

Заключение

Фичи в DevTools полезны, если вы используете ручные тесты в работе. Их много, но не все одинаково удобны и эффективны. Я постаралась выделить самые любопытные из них и оценила на практике. Возможно, какие-то из них оцените и вы.