Выполнение тестов на селеновый дым на основе UI с постоянно меняющимся пользовательским интерфейсом

Question

В настоящее время мы проводим тесты дыма с использованием Selenium Webdriver & JUnit против продукта B2C. Поскольку мы используем Selenium, скрипты полностью зависят от пользовательского интерфейса. Учитывая, что продукт вышел из технического запуска, рабочие процессы UI & продолжают меняться/развиваться на чрезвычайно высокой частоте.

Следствие: Тесты на дым, которые должны проверять святость приложения, продолжают терпеть неудачу. Команда тратит больше времени на исправление сценариев, а не на проверку сборки.

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

Примечание: интерфейс разработан в PHP

Answer 1

WebDriver работает примерно так: существует точка старта, WebDriver взаимодействует с ним (посредством имитации нажатия кнопки, например), а затем находит следующий элемент для взаимодействия с , Следующий элемент может находиться на следующей странице или на той же странице. Он может быть найден по-разному, по id или 3-му div, который является классом = «foo» и т. Д.

Тестирование аналогично загрузке страницы с помощью 200 OK, появляется ли строка «login» в определенном место и т. д.

Проблема с изменяющимся интерфейсом заключается в том, что все элементы «перемещаются». Иды меняются, а третий класс div foo исчезает. Это означает, что взаимодействия с webdriver терпят неудачу, и тесты, если они ищут определенные элементы, тоже не сработают.

Одним из решений является разработка и тестирование набора идентификаторов. Эти идентификаторы будут ссылаться на фиксированные элементы интерфейса. Все поиски в webdriver должны использовать идентификаторы. Команда разработчиков, пишущая PHP, поместит идентификаторы в правильные места.

Набор идентификаторов также может использоваться в качестве основы для своего рода спецификации и может использоваться для объяснения потока пользовательского интерфейса различными способами для разных держателей ставок.

Я не знаю ни одного конкретного продукта, который обрабатывает этот процесс управления идентификаторами в обоих тестах и ​​разработки кода, но сохраняя «лексикон», как это для описания элементов пользовательского интерфейса, не должно быть одной из основных задач

Answer 2

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

• С помощью UIMaps для моделирования пользовательского интерфейса приложения чрезвычайно прост в обращении изменен идентификаторы, классы CSS или аналогичные изменения

• PageObjects уменьшить усилие для больших изменений пользовательского интерфейса (например, когда поле ввода изменяется от TextBox на Dropdown поле)

• Использование ключевых слов Driven Testing для моделирования тестовых случаев без любые знания относительно технологического представительства. т.е. ключевое слово инкапсулирует действие с точки зрения пользователей - пример для ключевого слова может быть следующим: «loginWithValidUser()»

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