Web тестирование. Особенности архитектуры: «под прицелом» клиент. На что обращать внимание в запросах

Будучи автоматизированным тестировщиком вы ежедневно должны отлавливать различные баги, даже в своём фреймворке. Это ничего не говорит о вашей компетентности или о том, что компания вкладывает мало ресурсов в тестирование. В основном проблемы кроются в слабосвязанном коде, сложных процессах и интеграциях. Кроме того, процесс непрерывной интеграции требует много усилий и времени, чтобы гарантировать, что приложение корректно работает в различных средах. В свою очередь, с использованием новых технологий в разработке усложняется и написание автоматизированных тестов для web – приложений.

Всё это требует определённого опыта и практики.

Ниже перечислено 7 лайфхаков, которые используются для автоматизации web – тестов, и которые должны оправдать вложенные в неё инвестиции.

1. Выполнение реальных сценариев

Очень важно знать реальный сценарий, чтобы правильно заавтоматизировать тест-кейс. По возможности надо избегать mock-и и выполнять всё на “живом” приложении. В таком случае можно быть увереным в результате автотеста и в том, что проверка прошла, как надо.

1. Запускать автотесты ежедневно после последнего коммита

Тут двоякая ситуация. На некоторых проектах коммиты мержатся в течении всего дня. И такого понятия, как “дневной коммит” не существует. В таком случае следует выбрать время для запуска автотестов. С одной стороны это кажется утомительным, но с другой – очень полезно при частых обновлениях приложения. Баги отлавливаются на ранних стадиях, когда проблемные участки ещё не пустили корни.

1. Сокращение времени выполнения теста и увеличение тестового покрытия

Порой этого трудно добиться, тут нужен определённый опыт и технические знания. При правильном применении методологий тестирования и оптимального использования программных инструментов можно, если и не сократить время пробега теста до минимума, то хотя бы как-то его уменьшить. Также большую роль играет и вид тестирования: API и end-to-end тестирования гораздо быстрее UI – тестирования.

1. Проверить браузерную и платформенную совместимости

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

1. Составить отчёт по найденным багам в самом начале

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

1. Переиспользование тестовых методов и сценариев

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

1. Регулярная отчётность

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

7 хаков автоматизированного тестирования web-приложений, которые вы должны знать

http://сайт/wp-content/uploads/2017/04/website-test-automation-150x150.jpg

Будучи автоматизированным тестировщиком вы ежедневно должны отлавливать различные баги, даже в своём фреймворке. Это ничего не говорит о вашей компетентности или о том, что компания вкладывает мало ресурсов в тестирование. В основном проблемы кроются в слабосвязанном коде, сложных процессах и интеграциях. Кроме того, процесс непрерывной интеграции требует много усилий и времени, чтобы гарантировать, что приложение […]

Web-приложения — динамично развивающаяся сфера. Не все подходы и методы, применяемые для тестирования классических приложений могут быть применимы для тестирования web-приложений.

Web-приложение — это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером web-сервер, что уже является по сути двумя разнополыми программами, которые необходимо тестировать как отдельно, так и в связке.

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

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

Логика web-приложения распределена между сервером и клиентом, хранение данных осуществляется на сервере, обмен информацией происходит по сети.

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

Особенности тестирования web-приложений:

1. Технологические отличия .

Классическое приложение работает с использованием одной или семейства родственных технологий.

Web-приложение работает с использованием принципиально различных технологий.

1. Структурные отличия .

Классическое приложение “ монолитно е”. Состоит из одного или небольшого количества модулей. Не использует серверы БД, web-серверы и т.д.

Web-приложение — “ многокомпонентное ”. Состоит из большого числа модулей. Обязательно использует серверы БД, web-серверы, серверы приложений.

1. Отличия режимов работы.

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

Web-приложение работает в режиме “запрос-ответ”, т.е. известно о некотором наборе действий только после запроса на сервер.

1. Отличия формирования интерфейса .

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

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

1. Отличия работы с сетью .

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

Web-приложение активно использует сетевые каналы передачи данных.

1. Отличия запуска и остановки .

Классическое приложение запускается и останавливается редко.

Web-приложение запускается и останавливается по факту поступления каждого запроса, т.е. очень часто.

1. Разница в количестве пользователей .

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

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

1. Особенности сбоев и отказов .

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

Web-приложение: выход из строя некоторых компонентов оказывает непредсказуемое влияние на работоспособность приложения в целом.

1. Отличия в инсталляции .

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

Web-приложение — процесс инсталляции часто недоступен конечному пользователю. Инсталляция требует специфических знаний. Процесс изменения компонент приложения не предусматривается или требует квалификации пользователей. инсталлятор отсутствует.

1. Отличия в деинсталляции.

Классическое приложение: процесс деинсталляции стандартизирован и выполняется автоматически или полуавтоматически.

Web-приложение: процесс деинсталляции требует специфических знаний для вмешательства администратора и часто сопряжен с изменением кода среды функционирования приложения, БД, настройки системного ОС.

1. Особенности среды функционирования .

Классическое приложение: среда функционирования стандартизирована и не сильно влияет на функционирование приложения.

Web-приложение: среда функционирования очень разнообразна и может оказать серьезное влияние на работоспособность и серверной, и клиентской части.

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

Тестирование - это отклонение фактического результата от ожидаемого, другими словами - это процесс поиска багов (ошибок).

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

Курсы тестирования

Если вы хотите освоить профессию тестировщика , советуем записаться на курс тестирования от Lemon.School.
Курс не только даст общее понимание такого понятия, как тестирование, но и научит выявлять баги на всех этапах разработки.

Как тестировать сайт?

Тестирование может происходить самыми разными способами, однако не стоит забывать о самом процессе и стратегии тестирования. От него зависит последовательность ваших действий. На сегодняшний день, специалисты по тестированию веб-сайтов применяют такие виды как:

• Функциональное тестирование
• Тестирования удобства пользования (юзабилити)
• Тестирование производительности
• Тестирование интерфейса пользователя (UI testing)
• Тестирование безопасности.

Рассмотрим более подробно эти виды тестирования:

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

Один из важных и незаменимых видов тестирование. Самое главное правило функционального тестирования является правильные расчеты функций. К примеру, возьмем интернет магазин, у которого есть не только скидки на товар, но и множество статусов при покупке, n кол-во товаров. Все эти варианты следует учитывать. Ведь если функционал проекта не работает в определенном браузере, то он не будет работать нигде. Если брать определенный функционал для веб проектов, то в основном проверяется:

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

Юзабилити тестирование сайта

Тестирование удобства пользования (юзабилити) – это вид тестирования, который делает для сайта удобство и практичность в использовании. Основная цель показать пользователю:

• Понятен ли ваш сайт для окружающих и удобен ли?
• Удобная навигация?
• Какое впечатление создается у пользователя?
• Что может быть лишним или не нужным.

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

Нагрузочное тестирование сайтов

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

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

Тестирование пользовательского интерфейса

UI testing - это тестирование графического интерфейса пользователя, которая предполагает проверить сайт на соответствия требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли оно в едином стиле.

В большинстве случаев, тестирование интерфейса пользователя, осуществляется вместе со следующими видами тестирования(UI):

1. Тестирование на соответствие стандартам графических интерфейсов
2. Тестирование с различными разрешениями экрана
3. Тестирование кроссбраузерности, или совместимости с разными интернет браузерами и их версиями
4. Тестирование локализованных версий: точность перевода (мультиязычность, мультивалютность), проверка длины названий элементов интерфейса и т.д
5. Тестирование графического интерфейса пользователя на целевых устройствах (смартфоны, кпп, планшеты).

Тестирование сайта на уязвимости

Это ключ к надежности веб-сайтов. Основные правила этого тестирования - это проверка на уязвимость разных видов атак. Если это интернет-магазин, то, скорее всего, следует проверять запросы на Sql инъекцию (запросы к базе данных).

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

Вот, пожалуй, основные виды, которые используют для тестирования сайта.

Главная задача тестирования заключается в том, чтобы заказчику, как и пользователю, было предоставлено качество продукта. Для этого перед началом любого сайта следует составить чек-лист для тестирования:

• проверки веб-форм
• проверки правильности данных
• тестирования интерфейса пользователя
• тестирования оплаты
• тестирования версий для печати
• тестирования отчетов.

Немного нетривиальная задача мне выпала. Девушка, можно сказать, моя гражданская жена, хочет стать тестировщиком. Сама не особо знает, каким именно, но хочет в IT на начальные позиции. После некоторых раздумий остановились на тестировании интерфейсов веб-приложений, т.к. это, во-первых, тренд (время SPA), который будет только расти, а во-вторых, в вебе огромная свобода в тестировании. Иные виды приложений (мобильные, десктоп), решили отсечь, т.к. входной порог выше (узкие инструменты, менее популярные, более привязывающие к технологии). Иные виды тестирования - тем более. Во-первых, значительную часть тестов, которые "близко к коду" или "близко к критическим фичам", делают программисты, во-вторых, про далекие тесты (вроде нагрузочного, дымового и т.п.) можно забыть на начальном этапе. Сам я с вебом очень давно знаком, фулстек разработчик, как щас говорят. Из технологий: python/js/django/flask/backbone и всякое смежное. В основном пишу модульные тесты (питоний unittest), фронтенд тестил редко, ибо фриланс и проекты не такие большие, но есть опыт с mocha/jasmine + selenium, а также python + selenium для e2e тестирования. Для себя я много что пробую, но все-таки я не тестировщик, просто приходится знать и интересоваться, как оно, плюс есть вещи, где нельзя без тестирования.

Так вот, в общем, имеем мое понимание, как оно устроено и может быть устроено, и практически нулевые знания у девушки. У нее за плечами довольно техническое образование (безопасность в IT), что-то она кодила, про веб знает немного. Можно охарактеризовать так: html/css, немного питона (по моей инициативе), примерное представление о парадигмах программирования (ООП), что-то знает про сети (шлюз, роут, днс, дхцп, скорее всего, помнит даже, что такое бгп (sic!) и т.п.), но опыта нет ни в чем вообще. Есть аналитическое мышление, но нет уверенности, "нет наглости делать так, как кажется правильным и не бояться писать велики".

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

Но с моей точки зрения знать надо много: у меня есть ощущение, что тестировщик - это почти разработчик. Как можно тестить интерфейс без понимания того, как устроена верстка (html/css/svg, особенно фичи с селекторами)? Как можно тестировать сложные сценарии без знания основ взаимодействия фронтенда и бэкенда (кукисы, аякс, основы js, чтобы не пугаться, если что)? Кроме того, хорошо было бы знать что-нибудь про бекенд. Кроме того, в реальном месте вообще может оказаться какая-нибудь связка ангуляра, кармы тест раннера, жасмина или чего-то в этом роде, надо бы быть в теме.

Что я сделал: решил начать с питона, потому как JS учить как первый язык и умереть в прототипах, очень интересном приведении типов, 100 способах объявить приватный член и стрелять по ногам, с миллионами фреймворков/парадигм/стандартов/модулей/классов... Это очень сложный язык, я считаю. Начинать с популярной джавы - это вообще провал, потому как я сам с ним знаком на уровне универа всего лишь, во-вторых, я считаю, что это не лучший язык для разработки и обучения, кроме того, мы все-таки в области фронтенда. На питоне мы уже написали тестовый класс и юнит-тестик для него, чтобы примерно понимать суть тестирования. Потом я сказал, что если сделать наоборот, то это будет TDD. А если перед TDD подумать и описать, что надо, то это будет BDD. Понимаю, что нюансов много, но стараюсь сделать так, чтобы возникли вопросы у человека, и он пошел гуглить. По пути я объясняю некоторые фичи вроде того, зачем нужен self (для непитонистов - this - указатель на текущий объект), что такое типизация, ООП, даю ссылки на хабру, в доки, показываю, как дебажить, разбирать ошибки, в общем, стараюсь объяснить как можно больше всего из программирования вообще, могу параллельно залечивать на темы "а ты знаешь, вот в си есть указатели, и они там работают вот так...", потому как язык - это все фигня. С вероятностью значительной ей придется учить либо js, либо, прости господи, джаву. И все это будет очень просто, я считаю, если она будет знать базовые концепции.

Кроме того, мы поставили селениум вебдрайвер и сейчас пишем в том же питоне функциональные тесты (e2e) реальных сайтов, на кнопочки нажимаем, поля заполняем, по страницам ходим. Иногда я пишу тестовые странички, где надо мышой подвигать, покликать, ховеры разные и визибилити проверить, чтобы было посложнее. Все это надуманные примеры, но суть объясняет.

Периодически объясняю, что селениум - это не только вебдрайвер и что сущесвуют иные запускальщики тестов, это все для кругозора. Про само тестирование (какое бывает) я посоветовал лекции от Яндекса + пару тройку статей с Хабры, т.к. считаю, что брать книжку, где тестируют абстрактные светофоры - это бесполезно.

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

Так вот. Прав ли я вообще? Моя задача объяснить основы веба, в т.ч. программирования, популярные инструменты для тестирования, популярные парадигмы, чтобы можно было пойти джуном тестером. Я чувствую, что я не учитель, ибо у меня есть какое-то видение автоматически, как должно быть, и я строю все уже из него. Есть ощущение, что говорю очень много инфы сразу, что вводит в ступор. Есть ощущение, что я не могу передать все, что знаю, ибо всего очень много и часто все затягивается на длинные монологи, когда я что-то показываю, делаю, но у человека разрывает мозг. Кто-нибудь считает, что я дико не прав, возможно? Может, есть фундаментальная литература с основами по тестированию веба вообще? Она начинала читать "тестирование дот ком" от кого-то, по моему мнению ее вообще читать не стоит, ибо все, что там есть, можно увидеть на вики, немного подумав. Может, есть какие-то прямо суперские книги, такие как Кормен в алгоритмах, например? Или мне стоит вообще изменить подход?

Сам нахожусь в некотором замешательстве, ибо начал чувствовать, что я, скорее, "укладываю инфу в своей голове", чем что-то объясняю ей... %)

Современные web-приложения зачастую содержат множество "движущихся частей" и сторонних зависимостей. В процессе рефакторинга и добавления/изменения функциональности в таком приложении может произойти поломка существующих use-case сценариев и нестабильная работа в определенных браузерах.

Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:

Рассматриваемые решения обеспечивают похожий, на первый взгляд, ряд возможностей.

• Автоматизированное функциональное тестирование с последовательным и параллельным выполнением тестов и их группировкой, интеграция с Gulp и Mocha.
• Поддержка большинства десктопных и мобильных браузеров; выполнение взаимодействия с реальным DOM API (web-приложение открывается в нескрытом окне браузера в обычной вкладке - тест максимально приближен к жизни).
• Широкая поддержка селекторов элементов страницы: document.querySelector, CSS-селекторы и даже XPath; комбинация этих вариантов позволяет сохранить работоспособность функционального теста при внесении изменений в разметку.
• Автоматическое ожидание готовности DOM-модели браузера, синхронная подача команд визуального взаимодействия (щелчки по кнопкам, ввод в текстовые поля); удобные инструменты для ожидания клиентского JS-кода и сетевой AJAX-активности.
• Поддержка iframe-ов - за счет выбора текущего контекста DOMWindow - окна для теста и выполнении команд в его пределах с возможностью переключения в любой момент.
• Возможности для расширения - оба решения предоставляют возможности по добавлению поддержки кастомных браузеров и расширению собственной функциональности, в том числе добавления новых команд.

Пример функционального теста

Примером для тестирования будет web-приложение вида TodoMVC, с сервером на node.js и клиентской SPA-страницей на React+Redux-е. Для приближения условий тестирования к реальным, во все redux-овские action-ы добавлены случайные задержки, эмулирующие сетевое взаимодействие с backend-ом (за основу взято это).

В дальнейшем будет предполагаться, что тестовое web-приложение запущено по адресу http://localhost:4000/ . Функциональный тест будет простым и включать в себя добавление todo-элемента, правку его содержимого, отметку как выполненное/невыполненное задание и удаление.

Языком для написания тестов в обоих фреймворках является JS (ES2016 и ES5 соответственно для TestCafe и Nightwatch), однако это прекрасно подходит для web-приложений, написанных на любом языке. Если Вы давно не разрабатывали на JS, то необходимо учитывать, что современные редакции ушли очень далеко от старого ES3, и включают удобные средства для написания кода, объектно-ориентированного и функционального программирования и многое другое.

Установка TestCafe производится всего одной командой npm install -g testcafe . После выполнения загрузки и установки необходимых зависимостей, выполнение теста производится командой testcafe / в соответствующей директории.

Исходный код функционального теста, проверяющего изложенный выше use-case-сценарий, может быть таким:

import { expect } from "chai"; import { Selector } from "testcafe"; const MAX_TIME_AJAX_WAIT = 2500; // 2.5 seconds by default const querySelector = Selector((val) => document.querySelector(val), { timeout: MAX_TIME_AJAX_WAIT }); const querySelectorCondition = Selector((val, checkFunc) => { const foundElems = document.querySelectorAll(val); if(!foundElems) return null; for(let i=0; i < foundElems.length; i++) { if(checkFunc(foundElems[i])) return foundElems[i]; } return null; }, { timeout: MAX_TIME_AJAX_WAIT }); fixture `Example page` .page `http://localhost:4000/`; test("Emulate user actions and perform a verification", async t => { await t.setNativeDialogHandler(() => true); const inputNewTodo = await querySelector("header.header input.new-todo"); await t.typeText(inputNewTodo, "New TODO element\r\n"); const addedTodoElement = await querySelectorCondition("section.main label", (elm) => (elm.innerText === "New TODO element")); await t.doubleClick(addedTodoElement); const addedTodoEditInput = await querySelectorCondition("section.main input", (elm) => (elm.value === "New TODO element")); await t.typeText(addedTodoEditInput, " changed\r\n"); const addedTodoCheckboxAC = await querySelectorCondition("section.main input:not()", (elm) => (elm.nextSibling.innerText === "New TODO element changed")); await t.click(addedTodoCheckboxAC); const addedTodoCheckboxBC = await querySelectorCondition("section.main input", (elm) => (elm.nextSibling.innerText === "New TODO element changed")); await t.click(addedTodoCheckboxBC); const addedTodoDelBtn = await querySelectorCondition("button.destroy", (elm) => (elm.previousSibling.innerText === "New TODO element changed")); await t.click(addedTodoDelBtn); });

Адрес тестируемой web-страницы определяется в fixture-части, за которыми следуют функциональные тесты, по завершении каждого из которых web-страница автоматически восстанавливается в исходное состояние. Для поиска DOM-элементов на странице используются testcafe-специфические Selector-ы, использующиеся в качестве обертки для функции, которая будет выполнять запрос к DOM-модели, возможно используя аргументы.

В этом примере первый селектор представляет обертку над document.querySelector, а второй - над document.querySelectorAll с callback-функцией, помогающей выбрать нужный элемент из списка. Обертка Selector принимает опции, здесь в частности устанавливается максимальное время, в течении которого testcafe будет ожидает появление элемента с заданными характеристиками в DOM-модели.

Сам функциональный тест представляет собой набор асинхронных вызовов Selector-ов, между которыми производятся действия посредством test controller-а, инстанцированного переменной t. Назначение большинства его методов очевидно из названий (click, typeText и т.д.), а t.setNativeDialogHandler используется для предотвращения генерации alert-подобных окон, которые могут “подвесить” тест - что очень удобно.

Установка Nightwatch тоже начинается с простой команды npm install -g nightwatch , однако для запуска функциональных тестов еще потребуется Selenuim-server (можно загрузить , на компьютере должен быть установлен Java SE runtime) и webdriver-ы для каждого из браузеров, в которых будет запускаться тест.

Для запуска тестов сначала надо создать конфигурационный файл nightwatch.json, описывающий расположение тестов, пути и настройки для selenium-server и webdriver-ов, а далее использовать простую команду nightwatch в текущей директории.
Если использовать Microsoft Web Driver (Edge), то nightwatch.json может выглядеть примерно так:

{ "src_folders" : ["nightwatch-tests"], "output_folder" : "reports", "custom_commands_path" : "", "custom_assertions_path" : "", "page_objects_path" : "", "globals_path" : "", "selenium" : { "start_process" : true, "server_path" : "nightwatch-bin/selenium-server-standalone-3.0.1.jar", "log_path" : "", "port" : 4444, "cli_args" : { "webdriver.edge.driver" : "nightwatch-bin/MicrosoftWebDriver.exe" } }, "test_settings" : { "default" : { "selenium_port" : 4444, "selenium_host" : "localhost", "desiredCapabilities": { "browserName": "MicrosoftEdge", "acceptSslCerts": true } } } }

Исходный код функционального теста, проверяющий аналогичный рассмотренному выше use-case-сценарий, может выглядеть так:

module.exports = { "Demo test" : function (client) { client.url("http://localhost:4000/") .waitForElementVisible("body", 1000) // May use CSS selectors for element search .waitForElementVisible("header.header input.new-todo", 1000) .setValue("header.header input.new-todo", ["New TODO element", client.Keys.ENTER]) // Or use Xpath - it"s more powerful tool .useXpath() .waitForElementVisible("//section[@class=\"main\"]//label", 2000) .execute(function() { // For dispatch double click - Nightwatch doesn"t support it by default var evt = new MouseEvent("dblclick", {"view": window, "bubbles": true,"cancelable": true}); var foundElems = document.querySelectorAll("section.main label"); if(!foundElems) return; var elm = null; for(var i=0; i < foundElems.length; i++) { if(foundElems[i].innerText === "New TODO element") { elm = foundElems[i]; break; } } elm.dispatchEvent(evt); }) .waitForElementVisible("//section[@class=\"main\"]//input[@type=\"text\"]", 2000) .clearValue("//section[@class=\"main\"]//input[@type=\"text\"]") .setValue("//section[@class=\"main\"]//input[@type=\"text\"]", ["New TODO element changed", client.Keys.ENTER]) .waitForElementVisible("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\" and not(@checked)]", 2000) .click("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\" and not(@checked)]") .waitForElementVisible("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\"]", 2000) .click("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\"]") .waitForElementVisible("//section[@class=\"main\"]//label" + "/following-sibling::button[@class=\"destroy\"]", 2000) .click("//section[@class=\"main\"]//label" + "/following-sibling::button[@class=\"destroy\"]") .waitForElementNotPresent("//section[@class=\"main\"]//label", 2000) .pause(2000) .end(); } }

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

Удобной возможностью Nightwatch является поддержка XPath, который предоставляет значительно более широкие возможности по селекции элементов DOM-модели, по сравнению с CSS-селекторами - взять хотя бы извлечение элемента по его текстовому наполнению, что довольно часто встречается в функциональном тесте.

Сравнение функциональности TestCafe и Nightwatch

Установка :
[T]estCafe : Достаточно одной команды npm install -g testcafe , и можно сразу приступать к написанию и запуску тестов в текущей директории web-проекта
[N]ightwatch : Хотя установка npm-модуля делается просто - npm install -g nightwatch , потребуется мануальная загрузка selenium-standalone-server, webdriver-ов для всех интересующих браузеров, ручное создание конфигурационного файла (А может даже загрузка Java, если она не установлена)

Выборка DOM-элементов :
T : Используется механизм Selector-ов - оберток над клиентскими JS-функциями, выбирающими один или множество DOM-узлов; это обеспечивает практически неограниченные возможности для селекции, начиная от простой обертки над document.querySelector или document.getElementById , и заканчивая произвольной логикой прохода по DOM-элементам. При этом TestCafe самостоятельно обеспечивает проверку наличия/отсутствия элементов по заданному Selector-у в течении указанного времени.
N : На выбор предоставляется CSS selectors или XPath - в принципе, второго варианта достаточно для решения большинства задач по выборке элементов на странице, хотя это конечно не сравнится с возможностью задания сложной произвольной логики поиска.

Язык написания тестов :
T : Из коробки предоставляется возможность написания тестов непосредственно на языке ES2016, что позволяет писать простой и читабельный код тестов на том же языке, что и само web-приложение Это также удобно в случаях, когда требуется импортировать определенный модуль из тестируемого проекта.
N : Устаревший ES5-синтаксис и exports-конструкции в исходном коде функционального теста (Возможность прикрутить ES6 все-таки есть, но на костылях)

Поддержка асинхронных операций :
T : Все API-функции основаны на Promise-ах, что позволяет описывать произвольную асинхронную логику работы теста, и при этом интегрировать собственные функции со стороны node.js. Благодаря поддержке ES2016, этот код можно записывать при помощи async и await конструкций в последовательном стиле.
N : В тесте можно реализовать последовательность команд по анализу и управлению содержимым web-страницы, однако они складываются во внутреннюю очередь событий, и интегрировать собственные асинхронные функции с ними проблематично.

Вставка клиентского кода на лету :
T : Легко осуществляется при помощи соответствующего API, поддерживается создание и последующее выполнение клиентских функций, однократное исполнение injected-кода, замена существующих функций в исходной web-странице, а также исполнение клиентских функций в callback-ах node.js-функций с привязкой к тестовому контроллеру.
N : Есть функциональность для выполнение JS-кода на клиентской стороне, или даже вставки целого script-блока, но средств интеграции с тест-контроллером не предоставляется. Подходит для простого синхронного интегрируемого JS-кода, но в более общем случае интеграция проблематична.

Описания утверждений и ожиданий :
T : По умолчанию - обычный язык утверждений chai/expect, можно использовать и любую другую совместимую библиотеку утверждений.
N : Расширенный язык assert и expect , включающий средства для описания состояния страницы, в том числе наличия элемента и фокуса на нем, принадлежность к CSS-классу и так далее. Выглядит удобно, однако в первую очередь обусловлено отсутствием полноценной поддержки асинхронных операций в тесте, при необходимости наличия утверждений и ожиданий.

Управление тестируемой web-страницей :
T : Предполагает возможность mock-а для блокирующих исполнение сценариев функций alert , confirm и так далее, с возможностью задания возвращаемого значения. Поддерживаются сложные манипуляции с DOM-моделью, эмуляция пользовательского взаимодействия с элементами управления, и даже возможность приостановки JS-сценария за счет обертывания клиентских JS-функций
N : Поддерживаются команды для непосредственного управления отображаемым окном браузера и подлежащей DOM-моделью, интеграция с клиентским JS-сценарием затруднена

Работа с курсором мыши :
T : Предоставляется виртуальный курсор, посредством которого осуществляются hover, click и drag-события для целевым визуальных элементов страницы. В процессе выполнения теста можно наблюдать за перемещением курсора и выполняемыми действиями.
N : Средства для работы с курсором вообще есть - это функции из webdriver api, однако работать с действиями, сложнее одиночного левого клика, довольно проблематично - взять хотя бы двойной щелчок.

Реализация взаимодействия с браузером в TestCafe и NightWatch

Фреймворк NightWatch основывается на известной, в некоторой мере уже традиционной, библиотеке Selenium webdriver, преимущества которой включают устоявшееся API, высокую степень документированности и обширное Q&A в интернете, а также универсальный и достаточно низкоуровневый доступ к браузеру… Взаимодействие с браузерами организуется посредством webdriver-ов, по одному на каждый обозреватель.
Основной недостаток - webdriver-ы существуют далеко не для всех браузеров, а также требуют отдельного обновления при смене версии самого браузера, а еще для работы необходимо наличие внешней зависимости от Java. Более подробно о технологии webdriver можно прочесть в http://www.w3.org/TR/webdriver/

Метод TestCafe более универсален, поскольку может потенциально работать с любым браузером, поддерживающим HTML5 и ES 5+, в то время как NightWatch требует соответствующий webdriver. Кроме того, это позволяет прогонять тесты не только на локальном браузере, но на любом браузере в сети, включая любые мобильные - без установки какого-либо ПО на телефоне.

Пример тестирования вышерассмотренного web-приложения в браузере на Android показан в следующем видео: https://youtu.be/2na5jkqvUx0

Однако testcafe-hammerhead имеет и потенциальные недостатки: накладные расходы на анализ и модификацию исходного JS-кода тестируемой страницы, производимые в свою очередь JS-коде ядра Testcafe, а также теоретически некорректная работа тестируемой web-страницы или интеграции теста, если исходный код был проксирован неверно. (К примеру, замещение alert-окна в testcafe можно обойти таким примером http://pastebin.com/p6gLWA75 - и неумешленно или специально “подвесить” его выполнение)

Выводы

Конечно, selenium-webdriver, на котором основан Nightwatch, является популярным и широко известным решением, имеющем стандартный API-интерфейс, что несомненно является его достоинством. Кроме того, в смежных областях задач, например автоматизации целевого web-ресурса в заданном браузере - фактически написании бота для удаленного web-сайта - selenium-webdriver подходит лучше.

Однако для функционального тестирования разрабатываемого или поддерживаемого web-приложения TestCafe несомненно впереди по широкому ряду причин:

1) Запуск тестов в любом браузере, в том числе мобильных телефонах и планшетах, причем это может производиться пакетным образом для всех интересуемых браузеров и не требует установки никакого дополнительного ПО.
2) Удобство написания теста на ES2016, включающее async/await-конструкции для последовательной записи кода, импорт программных элементов из самого проекта, передачу функций в клиент и обратно и так далее - широкие возможности по интеграции и управлению клиентским web-приложением.
3) Широкая поддержка selector-ов для визуальных элементов, легкое взаимодействие с DOM-моделью, виртуальный курсор мыши, эмуляция разнообразных и сложных взаимодействий пользователя со страницей.

selenium-webdriver

javascript

es6

es2016

automation

automation testing

Добавить метки