Блог

Мы тестируем с помощью selenium и используем дизайн объекта страницы. То есть у нас есть файл библиотеки, который содержит весь функционал определенной страницы на нашем сайте. Под «функциональностью» я также подразумеваю процессы — у нас есть библиотека «Page Object» для «Login», «Register», … которые на самом деле не являются страницами.

Проблема начинается, когда у нас есть несколько проектов с одинаковой функциональностью. Например, у нас есть мобильная версия нашего сайта, версия для ipad… Процесс высокого уровня остается прежним (например, для входа в систему вам по-прежнему: 1) введите имя пользователя 2) введите пароль 3) нажмите enter), но пути xp меняются на разных сайтах. В большинстве случаев тесты одинаковы, за исключением очень небольшого количества различий (например, в login-mobile у вас нет 4), отметьте галочкой запомнить меня).

У нас есть решение (я проиллюстрирую основную идею ниже), которое включает в себя наследование объектов страницы. Я был бы рад услышать, как вы решаете эту проблему.

Наше решение:

• Мы заменяем объект selenium объектом, который мы называем user
• Каждый проект получает своего собственного пользователя: т.Е. mobileUser, ipadUser и т.д.. Все они наследуются от родительского (абстрактного) пользователя.
• Наши библиотечные файлы представляют собой классы, которые наследуются друг от друга.
• Поскольку «основной» скрипт одинаков для всех проектов, мы вызываем один и тот же фрагмент кода для каждого проекта, каждый раз присваивая ему другой тип пользователя.
• Поскольку в каждом проекте есть пользователь, мы «импортируем» правильный файл библиотеки через пользователя

Например:

 def testLogin(user):
    user.lib.Login.LoginAction("username", "password")
  

Имя библиотеки — «Login», а функция, которую мы хотим вызвать, — «loginAction». Если user это mobileUser, то Login это будет мобильная библиотека входа в систему. Если user является пользователем ipadUser, это будет библиотека входа для iPad и так далее.

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

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