Полезна ли модель Page Object для автоматического тестирования для веб-приложений? - PullRequest
2 голосов
/ 20 октября 2011

Моя цель - создать набор тестов с использованием инструментов автоматизации браузера, таких как Selenium или Watir.

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

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

  1. Перейти на страницу входа, войти в систему как администратор

  2. Перейдите на страницу управления пользователями и нажмите «Создать нового пользователя»

  3. Перейдите на страницу «Новый пользователь» и заполните форму «Создать нового пользователя»

  4. Утверждение, что пользователь был сгенерирован

  5. Перейти на страницу управления пользователями, выбрать вновь созданного пользователя

  6. Нажмите «Удалить пользователя» и подтвердите удаление успешно

Как будет структурирован этот тест - я бы хотел, чтобы один экземпляр браузера работал, поэтому мне пришлось бы передавать объект браузера между каждым объектом страницы для запуска тестов в каждом классе Page?

Ответы [ 3 ]

2 голосов
/ 21 октября 2011

Для уточнения ответа Алистера (с чем я согласен)

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

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

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

В этом случае я хотел бы использовать объект страницы для создания быстрой ссылки на этот элемент страницы. Тогда, если вы кодируете шаг, такой как « Учитывая, что я просматриваю детали для пользователя: имя пользователя со страницы« Управление пользователями »», вы можете получить код, который выглядел примерно так (при использовании watir или watir-webdriver)

Given /^I view details for user: (.*) from the Manage Users page$/ do |user|
  manageUsersPage.userlist.link(:text, user).click
end

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

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

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

Given /^I view details for user: (.*) from the Manage Users page$/ do |user|
  manageUsersPage.userlist.cell(:text, username).parent.link(:class, 'view_user_details').click
end

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

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

Извините, возможно, вырыли немного слишком глубоко в "как сделать bdd", но я хочу выразить, что вы не делаете всю свою абстракцию только через объекты страницы. Это очень важная часть вещей, но ИМХО не полное решение для эффективной структуры.

1 голос
/ 20 октября 2011

Да, вам придется создать объект браузера (пример с Selenium WebDriver):

IWebDriver driver = new InternetExplorerDriver();

и передать его функциям, которые работают со страницами:

LoginPage.Login (params, IWebDriver driver);
UserManagementPage.CreateNewUser (params, IWebDriver driver);
UserManagementPage.DeleteUser (params, IWebDriver driver);

driver.Close();

ЭтоВаше решение использовать объектную модель страницы внутри этих функций (Login, CreateNewUser) или нет.Page Object Model - это маленький шаг к удобной среде, которая абстрагирует данные из кода.Эта модель полезна, только если вы выполняете много разных операций с одной и той же страницей.В любом случае, абстрагирование элементов страницы придет к вам естественным образом.

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

0 голосов
/ 23 апреля 2013

Есть пара ссылок, которые вы можете проверить и которые достаточно хорошо объясняют объектную модель страницы при использовании Selenium Webdriver:

Объект страницы Selenium WebDriver

http://relevantcodes.com/pageobjects-and-pagefactory-design-patterns-in-selenium/

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

Например: Вы находитесь на странице A -> вы совершаете некоторые действия -> вы нажимаете кнопку Отправить -> вы ожидаете, что будете на странице B -> затем вы делаете некоторые действия на этой странице (B) -> вы нажимаете кнопку Отправить -> вы находитесь на странице C -> вы делаете недопустимые действия на этой странице (C) -> нажимаете кнопку отправить -> вы ожидаете остаться на странице C ...

И так далее, и так далее ...

Надеюсь, это немного прояснит ситуацию.

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