Тестирование iFrames с помощью визуального ИИ

Как вы знаете, я прохожу курс Университета автоматизации тестирования Раджа Рао Современная функциональная автоматизация тестирования с помощью визуального ИИ. Сегодня мы обсудим тестирование iFrames.

В Главе 5 Раджа называет iFrames неизбежным злом. На самом деле, они действительно полезны. Вы, вероятно, знаете, что можете использовать iFrames для встраивания множества функций на свою страницу. Если вы ничего не знаете об iFrames, узнайте немного. Там есть эта страница из сети разработчиков Mozilla. Или вы можете обратиться к такой компании, как Elfsight, которая предоставляет виджеты iFrame, которые вы можете установить, чтобы добавить интерактивности на веб-страницу. В некоторых случаях вы можете использовать iFrames для отслеживания и аналитики.

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

Как, скажем, карта Google.

Краткий пример карты Google

Код для встраивания карты Google — это iFrame:

Посмотреть код на Gist.

Да, этот код встраивает карту Google карты Алис-Спрингс, Северная территория, Австралия. Место, которое я всегда хотел посетить. Я еще не успел.

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

Что важно, так это страницы, которые включают iFrames для расширенной функциональности. Они встроены в ваше веб-приложение — иногда вложенные. Как вы тестируете iFrame?

Возможные ошибки iFrame

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

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

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

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

Тестирование iFrames с помощью Selenium

Раджа представляет тест таблицы во вложенном iFrame. При изменении размера страницы изменяется размер iFrame верхнего уровня, а содержимое вложенного iFrame скрывается. В зависимости от подхода к проектированию эти скрытые данные могут быть невидимы, пока пользователь не прокрутит данные вручную. А в некоторых случаях полос прокрутки может и не быть — это означает, что пользователь должен вручную изменить размер страницы, чтобы увидеть данные.

Раджа использует устаревший подход к тестированию iFrames — использование Selenium для применения тестового поведения, а затем измерения отклика страницы. Есть несколько осложнений, которые он раскрывает.

Вложенная навигация iFrame

Во-первых, это проблема навигации по iFrames, особенно если вы их вложили. Каждый раз, когда вы перемещаетесь в iFrame, вы должны изменять контекст проверяемого iFrame. Вы должны помнить свой контекст. И вам нужно извлечь свой контекст, чтобы вернуться на страницу за пределами iFrame.

В следующем коде Raja показывает избыточный код, который необходимо добавить для навигации по различным вложенным iFrames. Сначала вы переходите к контексту главной страницы. Далее вы переходите к верхнему iFrame. Наконец, вы выбираете один из четырех встроенных iFrames. Теперь можно приступать к испытаниям.

Посмотреть код на Gist.

Вот фрагмент кода, используемого для изменения контекста:

Это много избыточного кода, необходимого для навигации по каждому iFrame.

Скрытый контент

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

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

Selenium тестирует версии приложения iFrame

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

Например, тестер может получить версию приложения с полосами прокрутки во вложенном iFrame. Инженер может решить не использовать полосы прокрутки и оставить эту задачу пользователю позже. Вместо проверки наличия полос прокрутки тестер может просто использовать текстовые локаторы для проверки существования содержимого в DOM.

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

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

Раджа описывает эти типы проблем с iFrames как обычно проблематичные для устаревших функциональных тестов.

Тестирование iFrames с визуальным ИИ

Поскольку Visual AI использует сравнение изображений для определения отображаемого вывода, наличие полос прокрутки не требует каких-либо действий или утверждений. Вместо этого, если полосы прокрутки невидимы, выбор iFrame должен выделить полосы прокрутки.

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

Вот картинка кода из курса.

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

глаза.checkWindow («iFrame»);

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

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

Вывод

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

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

Первоначально опубликовано на https://applitools.com 22 ноября 2019 г.