Немного нетривиальная задача мне выпала. Девушка, можно сказать, моя гражданская жена, хочет стать тестировщиком. Сама не особо знает, каким именно, но хочет в 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) реальных сайтов, на кнопочки нажимаем, поля заполняем, по страницам ходим. Иногда я пишу тестовые странички, где надо мышой подвигать, покликать, ховеры разные и визибилити проверить, чтобы было посложнее. Все это надуманные примеры, но суть объясняет.
Периодически объясняю, что селениум - это не только вебдрайвер и что сущесвуют иные запускальщики тестов, это все для кругозора. Про само тестирование (какое бывает) я посоветовал лекции от Яндекса + пару тройку статей с Хабры, т.к. считаю, что брать книжку, где тестируют абстрактные светофоры - это бесполезно.
Я думаю, мой подход понятен, я учу читать доки и стараюсь из обрывков инфы в ее голове создать что-то, причем моя задача - это "знать суть + моментальная практика, а нюансы нужны только тогда, когда знаешь, что они существуют". Смотрим доки, если что не известно, то тут же надо гуглить, если нужна фундаментальная инфа, то статьи/обрывки книг по основам и так далее.
Так вот. Прав ли я вообще? Моя задача объяснить основы веба, в т.ч. программирования, популярные инструменты для тестирования, популярные парадигмы, чтобы можно было пойти джуном тестером. Я чувствую, что я не учитель, ибо у меня есть какое-то видение автоматически, как должно быть, и я строю все уже из него. Есть ощущение, что говорю очень много инфы сразу, что вводит в ступор. Есть ощущение, что я не могу передать все, что знаю, ибо всего очень много и часто все затягивается на длинные монологи, когда я что-то показываю, делаю, но у человека разрывает мозг. Кто-нибудь считает, что я дико не прав, возможно? Может, есть фундаментальная литература с основами по тестированию веба вообще? Она начинала читать "тестирование дот ком" от кого-то, по моему мнению ее вообще читать не стоит, ибо все, что там есть, можно увидеть на вики, немного подумав. Может, есть какие-то прямо суперские книги, такие как Кормен в алгоритмах, например? Или мне стоит вообще изменить подход?
Сам нахожусь в некотором замешательстве, ибо начал чувствовать, что я, скорее, "укладываю инфу в своей голове", чем что-то объясняю ей... %)
Описание курса:
В наше время редко современное приложение обходится без API. Это справедливо как для простого сайта так и для высоконагруженных распределенных систем. Тестирование API — является одной из главных задач в процессе обеспечения качества. Неудивительно, что спрос на тестировщиков, которые умеют тестировать API повышается изо дня в день. На данном курсе вы получите понимание о методах, инструментах и подходах в тестировании API, приобретете необходимые знания, что несомненно благоприятно отразится на Вашей стоимости как специалиста в тестировании.
Данный курс будет полезен слушателям знакомым с основами тестирования ПО, которые хотят расти дальше и повышать свои навыки.
Программа курса:
Занятие 1. Вводная. Протокол SOAP
Занятие 2: Протокол SOAP. Архитектура REST
Занятие 3. Знакомство с SoapUI. Работа с REST проектом
Занятие 4. Работа с REST проектом (XML)
Занятие 5. Работа с REST проектом (JSON)
Занятие 6. Работа с Groovy скриптами
Занятие 7. Дополнительные возможности
, информационный шум , логические ошибки , раскрытие информации , SQL Injection , "stress" , Нагрузочное тестирование , тестирование производительности , Объемное тестирование , Объемное стабильности , visual test , probing , sniffing , firebug , RDP , load generation , tester , quality manager , тестирование web-сервера , Моделирование Транзакций , Метод Метод "Анализ данных на стороне клиента"Анализ данных на стороне клиентаМетод "Анализ данных на стороне клиента" , Метод Анализ Сетевого Трафика , Проверка HTML-кода , профилировщик , граф вызовов , call graph , code coverage , подсветка синтаксиса , Вьювер , development tools , смещение элементов , иерархический список , breakpoint , билд , Internet Explorer Developer Tools , functional decomposition , data-driven , время выполнения , кэш , валидность , DHTML , css
Презентацию к данной лекции Вы можете скачать .
Вычислительные и коммуникационные системы используются все чаще и с каждым днем все глубже входят в нашу повседневную жизнь. Компании и отдельные пользователи все больше зависят в своей работе от web-приложений. Веб-приложения соединяют различные отделы внутри компаний, различные компании и простых пользователей. Веб-приложения очень динамичны, а их функциональные возможности непрерывно растут. Непрерывно возрастает потоковый трафик средств информации и запросов, формируемых переносными и встроенными устройствами. Вследствие этого возрастает сложность систем такого рода. Очевидно, что для понимания, анализа, разработки и управления такими системами нужны количественные методы и модели, которые помогают оценить различные сценарии функционирования, исследовать структуру и состояние больших систем. Наблюдаются тенденции к постоянному росту спроса на Веб-службы. Таким образом, проблемы, связанные с недостаточной производительностью будут возникать и в будущем, и, в конце концов, они станут превалирующими при планировании и вводе в эксплуатацию новых Веб-служб и увеличении пользователей Интернета. Веб-приложения становятся все более распространенными и все более сложными, играя, таким образом, основную роль в большинстве онлайновых проектов. Как и во всех системах, основанных на взаимодействии между клиентом и сервером, уязвимости Веб-приложений обычно возникают из-за некорректной обработки запросов клиента и/или недостаточной проверки входной информации со стороны разработчика.
В первой части данной лекции мы рассмотрим вопросы специфичные для тестирования и отладки Веб-приложений.
Будут рассмотрены принципы следующих подходов к тестированию Веб-приложений [ , ]:
Также будет приведен обзор средств автоматизации тестирования Веб-приложений.
С общими вопросами тестирования и верификации информационных систем предлагается ознакомиться в курсе Интернет Университета Информационных Технологий "Верификация программного обеспечения" .
Во второй части лекции будут рассмотрены подходы и инструментальные средства отладки CSS, а также отладки и профилирования JavaScript.
Функциональное тестирование ( functional testing ) – процесс верификации соответствия функционирования продукта его начальным спецификациям . Характерным примером может быть проверка того, что программа подсчета выплат по банковской ссуде выдает корректные выкладки на любые введенные сумму ссуды и срок ее возврата. Обычно подобные проверки проводятся вручную, иногда к этому подключаются конечные пользователи в качестве бета-тестеров. Однако программные системы становятся все сложнее, а комбинации различных входных параметров и поддерживаемых операционных систем нередко исчисляются десятками и сотнями.
Перечислим некоторые из методов функционального тестирования веб-приложений [ , ]:
Самым распространенным является подход, называемый Capture & Playback (другие названия – Record & Playback , Capture & Replay) . Суть этого подхода заключается в том, что сценарии тестирования создаются на основе работы пользователя с тестируемым приложением. Инструмент перехватывает и записывает действия пользователя, результат каждого действия также запоминается и служит эталоном для последующих проверок. При этом в большинстве инструментов, реализующих этот подход, воздействия (например, нажатие кнопки мыши) связываются не с координатами текущего положения мыши, а с объектами HTML-интерфейса (кнопки, поля ввода и т.д.), на которые происходит воздействие, и их атрибутами. При тестировании инструмент автоматически воспроизводит ранее записанные действия и сравнивает их результаты с эталонными, точность сравнения может настраиваться. Можно также добавлять дополнительные проверки – задавать условия на свойства объектов (цвет, расположение, размер и т.д.) или на функциональность приложения (содержимое сообщения и т.д.).
Основное достоинство этого подхода – простота освоения. Создавать тесты с помощью инструментов, реализующих данный подход, могут даже пользователи, не имеющие навыков программирования.
Вместе с тем, у подхода имеется ряд существенных недостатков. Для разработки тестов не предоставляется никакой автоматизации; фактически, инструмент записывает процесс ручного тестирования . Если в процессе записи теста обнаружена ошибка, то в большинстве случаев создать тест для последующего использования невозможно, пока ошибка не будет исправлена (инструмент должен запомнить правильный результат для проверки). При изменении тестируемого приложения набор тестов трудно поддерживать в актуальном состоянии, так как тесты для изменившихся частей приложения приходится записывать заново.
Часть программной системы, обеспечивающая работу интерфейса с пользователем – один из наиболее нетривиальных объектов для верификации . Нетривиальность заключается в двояком восприятия термина "пользовательский интерфейс".
С одной стороны пользовательский интерфейс – часть программной системы. Соответственно, на пользовательский интерфейс пишутся функциональные и низкоуровневые требования, по которым затем составляются тест-требования и тест-планы. При этом, как правило, требования определяют реакцию системы на каждый ввод пользователя (при помощи клавиатуры, мыши или иного устройства ввода) и вид информационных сообщений системы, выводимых на экран, печатающее устройство или иное устройство вывода. При верификации таких требований речь идет о проверке функциональной полноты пользовательского интерфейса – насколько реализованные функции соответствует требованиям, корректно ли выводится информация на экран.
С другой стороны пользовательский интерфейс – "лицо" системы, и от его продуманности зависит эффективность работы пользователя с системой. Факторы, влияющие на эффективность работы, в меньшей степени поддаются формализации в виде конкретных требований к отдельным элементам, однако должны быть учтены в виде общих рекомендаций и принципов построения пользовательского интерфейса программной системы. Проверка интерфейса на эффективность человеко-машинного взаимодействия получила название проверки удобства использования (usability verification, в русскоязычной литературе в качестве перевода термина usability часто используют слово "практичность").
Функциональное тестирование пользовательского интерфейса состоит из пяти фаз :
Все эти фазы точно такие же, как и в случае тестирования любого другого компонента программной системы. Отличия заключаются в трактовке некоторых терминов в применении к пользовательскому интерфейсу и в особенностях автоматизированного сбора информации на каждой фазе.
Так, тест-планы для проверки пользовательского интерфейса, как правило, представляют собой сценарии , описывающие действия пользователя при работе с системой. Сценарии могут быть записаны либо на естественном языке, либо на формальном языке какой-либо системы автоматизации пользовательского интерфейса. Выполнение тестов при этом производится либо оператором в ручном режиме, либо системой, которая эмулирует поведение оператора.
При сборе информации о выполнении тестовых примеров, как правило, применяются технологии анализа выводимых на экран форм и их элементов (в случае графического интерфейса) или выводимого на экран текста (в случае текстового), а не проверка значений тех или иных переменных, устанавливаемых программной системой.
Под полнотой покрытия пользовательского интерфейса понимается то, что в результате выполнения всех тестовых примеров каждый интерфейсный элемент был использован хотя бы один раз во всех доступных режимах.
Отчеты о проблемах в пользовательском интерфейсе могут включать в себя как описания несоответствий требований и реального поведения системы, так и описания проблем в требованиях к пользовательскому интерфейсу. Основной источник проблем в этих требованиях – их тестонепригодность, вызванная расплывчатостью формулировок и неконкретностью.
Тестирование пользовательского интерфейса может проводиться различными методами – как вручную при непосредственном участии оператора, так и при помощи различного инструментария, автоматизирующего выполнение тестовых примеров. Рассмотрим эти методы более подробно.
Ручное тестирование пользовательского интерфейса проводится тестировщиком-оператором, который руководствуется в своей работе описанием тестовых примеров в виде набора сценариев . Каждый сценарий включает в себя перечисление последовательности действий, которые должен выполнить оператор и описание важных для анализа результатов тестирования ответных реакций системы, отражаемых в пользовательском интерфейсе. Типичная форма записи сценария для проведения ручного тестирования – таблица, в которой в одной колонке описаны действия (шаги сценария ), в другой – ожидаемая реакция системы, а третья предназначена для записи того, совпала ли ожидаемая реакция системы с реальной и перечисления несовпадений.
При внесении изменений в пользовательский интерфейс при использовании первого метода в результате проведения регрессионного тестирования будет выявлено большое количество не прошедших тестов – достаточно изменения местоположения одного ключевого интерфейсного элемента, как все сценарии начнут работать неверно. Соответственно при таком методе автоматизации тестирования необходимо менять значительную часть сценариев в системе тестов при каждом изменении интерфейса системы. Такой метод автоматизации тестирования подходит для систем с устоявшимся и редко изменяемым интерфейсом.
Второй метод автоматизации тестирования более устойчив к изменению расположения интерфейсных элементов, но изменения тестовых примеров могут потребоваться и здесь в случае изменения логики работы интерфейсных элементов. Например, пусть в первой версии системы при нажатии на кнопку "Передать данные" передача данных начиналась сразу, и выводилось окно с индикатором прогресса. Сценарий тестового примера в этом случае включает в себя имитацию нажатия на кнопку и обращение к индикатору прогресса для получения значения прогресса в процентах.
Web-приложения — динамично развивающаяся сфера. Не все подходы и методы, применяемые для тестирования классических приложений могут быть применимы для тестирования web-приложений.
Web-приложение — это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером web-сервер, что уже является по сути двумя разнополыми программами, которые необходимо тестировать как отдельно, так и в связке.
Почти все современные программы ориентированы на работу с сетью. Хранение данных web-приложений осуществляется, преимущественно, на сервере, обмен информацией происходит по сети. Когда мы видим ошибку в сетевой среде, то зачастую сложно точно указать, где именно она произошла, и потому режим работы, или сообщение об ошибке которое мы получаем, может быть результатом ошибок, случившихся в разных частях сетевой системы.
Имея много общего с тестированием классических приложений, тестирование web-ориентированных приложений имеет свои особенности, связанные прежде всего со средой функционирования. Имея компонентные, структурные и технологические особенности, web-приложениям присущи особенности режимов работы, инсталляции, запуска, остановки и удаления, а также формирования интерфейсов. Работая всегда с сетью и с большим количеством пользователей, web-приложения подразумевают под собой разные права доступа для разных пользователей.
Логика web-приложения распределена между сервером и клиентом, хранение данных осуществляется на сервере, обмен информацией происходит по сети.
Одним из преимуществ подхода является тот факт, что клиенты не зависят от конкретной операционной системы пользователя, поэтому web-приложения являются межплатформенными сервисами.
Классическое приложение работает с использованием одной или семейства родственных технологий.
Web-приложение работает с использованием принципиально различных технологий.
Классическое приложение “ монолитно е”. Состоит из одного или небольшого количества модулей. Не использует серверы БД, web-серверы и т.д.
Web-приложение — “ многокомпонентное ”. Состоит из большого числа модулей. Обязательно использует серверы БД, web-серверы, серверы приложений.
Классическое приложение работает в режиме реального времени , т.е. известно о действиях пользователя сразу же, как только оно выполнено.
Web-приложение работает в режиме “запрос-ответ”, т.е. известно о некотором наборе действий только после запроса на сервер.
Классическое приложение использует для формирования интерфейса пользователя относительно устоявшиеся и стандартизированные технологии.
Web-приложение использует для формирования пользовательского интерфейса стремительно развивающиеся технологии, множество которых конкурирует между собой.
Классическое приложение практически не использует сетевые каналы передачи данных.
Web-приложение активно использует сетевые каналы передачи данных.
Классическое приложение запускается и останавливается редко.
Web-приложение запускается и останавливается по факту поступления каждого запроса, т.е. очень часто.
Классическое приложение: количество пользователей, одновременно использующих приложение, подвержено контролю, ограничено и легко прогнозируемо.
Web-приложение: количество пользователей, одновременно использующих приложение, сложнопрогнозируемо и может скачкообразно меняться в широких диапазонах.
Классическое приложение: выход из строя тех или иных компонентов сразу становится очевидным.
Web-приложение: выход из строя некоторых компонентов оказывает непредсказуемое влияние на работоспособность приложения в целом.
Классическое приложение — процесс инсталляции стандартизирован и максимально ориентирован на широкую аудиторию пользователей. Не требует специфических знаний. Добавление компонентов приложения выполняется стандартным способом с использованием одного и того же инсталлятора.
Web-приложение — процесс инсталляции часто недоступен конечному пользователю. Инсталляция требует специфических знаний. Процесс изменения компонент приложения не предусматривается или требует квалификации пользователей. инсталлятор отсутствует.
Классическое приложение: процесс деинсталляции стандартизирован и выполняется автоматически или полуавтоматически.
Web-приложение: процесс деинсталляции требует специфических знаний для вмешательства администратора и часто сопряжен с изменением кода среды функционирования приложения, БД, настройки системного ОС.
Классическое приложение: среда функционирования стандартизирована и не сильно влияет на функционирование приложения.
Web-приложение: среда функционирования очень разнообразна и может оказать серьезное влияние на работоспособность и серверной, и клиентской части.
Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:
Рассматриваемые решения обеспечивают похожий, на первый взгляд, ряд возможностей.
Примером для тестирования будет 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-сценарий, может быть таким:
Адрес тестируемой 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 может выглядеть примерно так:
Исходный код функционального теста, проверяющий аналогичный рассмотренному выше use-case-сценарий, может выглядеть так:
Среди особенностей кода легко заметить, что Nightwatch не поддерживает эмуляцию двойного щелчка по элементу - вместо этого приходится реализовывать обходной путь с inject-функцией на клиенте, выполняющую dispatchEvent на целевом элементе управления.
Удобной возможностью Nightwatch является поддержка XPath, который предоставляет значительно более широкие возможности по селекции элементов DOM-модели, по сравнению с CSS-селекторами - взять хотя бы извлечение элемента по его текстовому наполнению, что довольно часто встречается в функциональном тесте.
Установка
:
[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, однако работать с действиями, сложнее одиночного левого клика, довольно проблематично - взять хотя бы двойной щелчок.
Фреймворк 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-моделью, виртуальный курсор мыши, эмуляция разнообразных и сложных взаимодействий пользователя со страницей.
Добавить метки
