Самовосстановление селекторов в UI Automation - PullRequest
0 голосов
/ 19 марта 2019

Я делаю автоматизацию пользовательского интерфейса в JS, где я распознаю объект / элемент на основе XPATH или CSS-селектора. По многим нежелательным причинам - тесты терпят неудачу из-за изменения XPATH в другой среде.

Я ищу идею или подход - где мои сценарии автоматизации самостоятельно излечиваются, чтобы распознать измененный XPATH / CSS-селектор и обновляются или запускаются с измененным селектором.

Есть ли способ - я могу сделать это во время выполнения, чтобы самостоятельно исцелить мои существующие сценарии автоматизации Javascript.

1 Ответ

1 голос
/ 19 марта 2019

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

На мой взгляд, лучший способ подойти к этому -

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

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

  3. Наконец, я думаю, что мы просто должны принятьопределенный уровень уязвимости и необходимого обслуживания для автоматизации пользовательского интерфейса.Цель Google для «нестабильных» тестов пользовательского интерфейса составляет 1% или менее.Selenium - отличный инструмент для автоматизации браузера, но для написания надежных, поддерживаемых и надежных тестов пользовательского интерфейса требуется много планирования и стратегии.И я думаю, учитывая, какие изменения могут сломаться, какие селекторы важны при разработке тестов и стратегий локаторов.Инструмент, который автоматически делает это, был бы потрясающим, и я полагаю, что есть команды, работающие над созданием способа сделать это с помощью искусственного интеллекта, но пока ничего публично не доступно.

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