Меня зовут Ганеш, и я ведущий интерфейсный инженер в Publicis Sapient. Я создаю приложения JavaScript уже много лет, но мало работал с автоматизированным тестированием пользовательского интерфейса.

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

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

Спасибо 🙌 frontendnachos за руководство в моем путешествии и помощь в сборке этой части.

В этом посте будут затронуты следующие области:

  • Объяснение автоматизированного тестирования пользовательского интерфейса
  • Необходимость автоматизированного тестирования пользовательского интерфейса
  • Различные типы автоматизированного тестирования пользовательского интерфейса
  • Различные компоненты среды тестирования пользовательского интерфейса
  • Краткий обзор некоторых инструментов тестирования пользовательского интерфейса

Примечание.Фрагменты кода, которые я добавил в сообщение, написаны с использованием JEST, поскольку я работал с ним. Но это не делает этот пост учебником по JEST. Так что НЕ СЧИТАЙТЕ этот пост исчерпывающим руководством по JEST.

Чтобы сделать описание концепции более понятным, я иногда нарушал некоторые рекомендации.

Давайте начнем.

Объяснение автоматизированного тестирования пользовательского интерфейса

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

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

  1. Презентативный –заботится о том, как все выглядит. Эти части не знают о бизнес-логике.Например. Поле ввода, ползунок диапазона, кнопка и т. д.
  2. Контейнер —заинтересован в том, как все работает. Эти части знают о бизнес-логике. например. Форма входа, список продуктов, модуль оплаты и т. д.
  3. Страница –различные страницы приложения состоят из презентационных и контейнерных модулей.например. Страница входа, страница панели инструментов, страница оформления заказа и т. д.

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

  1. Модуль – проверяет логику и поведение отдельного модуля, но не тех, от которых он зависит или с которыми взаимодействует.
  2. Интеграция – проверяет объединенную логику и поведение модуля, а также те, от которых он зависит и с которыми взаимодействует.
  3. Конец-в-конец – имитирует взаимодействие реального пользователя с приложением
    и проверяет пути пользователя.

Эти типы тестирования могут включать тесты, которые проверяют:

  1. Презентация – визуализация и внешний вид модуля.
  2. Поведение –проверка выходных значений по отношению к определенным входным значениям.
  3. Визуальная стабильность/регрессия – проверяет, как влияет на внешний вид модуля по мере добавления к нему дополнительных ядер.
  4. Тестирование производительности. Проверяет стабильность, отзывчивость и скорость модуля.

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

Итак, подытоживая, вот как это выглядит:

Необходимость автоматизированного тестирования пользовательского интерфейса

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

  1. Пользователь всегда должен видеть правильные данные в правильном формате.
  2. Вводимые пользователем данные должны быть надежно зафиксированы и обработаны.
  3. Пользователь всегда должен получать подтверждение после того, как его действия зарегистрированы или обработаны.

Когда все вышеперечисленные критерии соблюдены, все радуются и празднуют.

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

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

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

  1. Более медленное «время выхода на рынок» для новых функций
  2. Отсутствие уверенности, учитывая, что человеческая ошибка всегда возможна
  3. Дополнительные расходы

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

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

Как указано в объяснении автоматизированного тестирования пользовательского интерфейса, существует 3 типа тестирования пользовательского интерфейса — модульное, интеграционное и сквозное. Теперь давайте попробуем разобраться в них подробнее и сравнить их по разным признакам.

ЦЕЛЬ

  • Модульное тестирование. Чтобы протестировать самые маленькие модули и показать, что они по отдельности верны.
  • Интеграционное тестирование. Чтобы протестировать модули в группах и убедиться, что они работают правильно при объединении.
  • Сквозное тестирование. Чтобы проверить, есть ли какие-либо трудности на пути пользователя, взаимодействуйте с приложением так, как это сделал бы пользователь.

ЗАКЛЮЧЕНИЕ

  • Модульное тестирование. Касается функциональности самых маленьких независимых модулей. Не предназначен для освещения общесистемных проблем.
  • Тестирование интеграции. Помогает выявить потенциальные проблемы, которые могут возникнуть при взаимодействии различных модулей друг с другом.
  • Сквозное тестирование. Помогает выявить потенциальные проблемы, которые могут возникнуть, когда реальный пользователь перемещается по модулям и взаимодействует с пользовательским интерфейсом.

СЛУЧАЙ

  • Модульное тестирование. Может выполняться в любое время.
  • Интеграционное тестирование. Выполняется только после завершения модульного тестирования.
  • Сквозное тестирование. Выполняется только после завершения интеграционного тестирования.

АБСТРАКЦИЯ

  • Модульное тестирование. Эти тесты являются тестами белого ящика. Подробности реализации модуля известны.
  • Интеграционное тестирование — своего рода тесты серого ящика. Необходимо иметь фундаментальное понимание реализации модуля.
  • Сквозное тестирование — тесты черного ящика. Детали реализации модуля неизвестны.

ЗАВИСИМОСТИ

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

СЛОЖНОСТЬ ОТЛАДКИ

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

ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ

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

ИНСТРУМЕНТЫ

  • Модульное тестирование — JEST, JASMINE и т. д.
  • Интеграционное тестирование — JEST, JASMINE и т. д.
  • Сквозное тестирование — CYPRESS, WEBDRIVERIO и т. д.

ПРИМЕР

Рассмотрим следующий пользовательский интерфейс:

Источник: https://flipkart.com

  1. Модульное тестирование проверяет такие компоненты, как поля ввода, ссылки, кнопки и функции API входа в систему, изолированно от поддельных внешних взаимодействий, таких как вызовы API и т. д.
  2. Интеграционное тестирование проверяет всю форму входа.
  3. Сквозное тестирование, т. е. проверка всего пути пользователя будет включать выполнение следующих шагов, как это сделал бы реальный пользователь:
  • Приземлиться на странице входа,
  • Нажмите «Забыли?» связь,
  • Перейдите на страницу забытых учетных данных и сбросьте учетные данные по ссылке электронной почты.

Элементы автоматизированного тестирования пользовательского интерфейса

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

Прецедент

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

Тестирование

Сборка связанных тестовых случаев называется набором тестов. Управляемость повышается, когда соответствующие тестовые наборы группируются вместе внутри набора тестов. Группировка может быть выполнена по времени выполнения, типу и т. д. Например.

Утверждение

Слово «утверждение» означает твердое и определенное убеждение. Библиотека утверждений помогает нам определить, правильны ли наши представления о наших реализациях. Например, если я утверждаю, что квадратный корень из 49 равен 7, это всего лишь мое убеждение, и библиотека утверждений помогает мне определить, верно ли оно.

Тестовые двойники

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

Заглушки

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

Шпионы

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

Мокает

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

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

Тестовый бегун

Для запуска JS-приложения требуется браузер или сервер NodeJS. Этому способствует тестовый бегун. Он берет наборы тестов и запускает их в среде (либо в браузере, либо на сервере NodeJS).

Моделирование модели DOM

Браузер преобразует элементы HTML в узлы DOM, которыми можно управлять с помощью JavaScript. Нам нужен DOM или API, близкий к нему, для тестирования пользовательского интерфейса, чтобы запускать события для элементов и тестировать визуальную регрессию. В соответствии с используемой средой тестирования доступ к DOM может быть осуществлен посредством рендеринга пользовательского интерфейса в браузере, с помощью автономного браузера или с использованием таких инструментов, как JSDOM.

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

Краткий обзор некоторых инструментов тестирования пользовательского интерфейса

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

  1. Test Runner для запуска тестовых случаев.
  2. Утверждение Библиотека
  3. Механизм имитации определенного поведения (Тестовые двойники)
  4. Моделирование DOMбиблиотека/инструмент
  5. Песочница/оболочка/среда для запуска тестовых случаев.
  6. Отчеты, в которых количественно оценивается качество на основе выходных данных тестовых наборов.

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

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

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

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

Ссылки на вышеуказанные инструменты:

  • JASMINE (среда тестирования, библиотека утверждений, двойники тестов)
  • MOCHA (среда тестирования, средство выполнения тестов)
  • CHAI (библиотека утверждений)
  • КАРМА (выполнение тестов)
  • JEST(Среда тестирования, Библиотека утверждений, Средство выполнения тестов, Дублирование тестов, Отчет о тестировании)
  • VITEST(Среда тестирования, Библиотека утверждений, Средство выполнения тестов, Дублирование тестов, Отчет о тестировании)
  • СТАМБУЛ (отчет об испытаниях)
  • СИНОН (тестовые двойники)
  • JSDOM (моделирование DOM)
  • КУКЛОДЧИК (моделирование DOM)
  • CYPRESS(Среда тестирования, Библиотека утверждений, Средство выполнения тестов, Дублирование тестов, Отчет о тестировании)

Заключение

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

Начать работу с автоматическими тестами пользовательского интерфейса просто и легко. Это не что иное, как JS-код. Пользовательский интерфейс приложения необходимо тестировать на разных уровнях — единичном (наименьший фрагмент кода), интеграции (логически сгруппированные модули) и сквозном (моделирование поведения пользователя).

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

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