В идеале, вам следует назначить значения id элементам, которые вас интересуют. Алгоритм должен быть таким, чтобы два элемента не могли получить то же самое id, но что назначение значений id может быть предсказано так, что два элемента в одном и том же месте в двух одинаково структурированных DOM-деревьях получат то же самое id. Это может быть чем-то таким же банальным, как нумерация всех button элементов из 1 в порядке документа. id - это то, что вы используете, чтобы однозначно идентифицировать button.
Если вы не можете знать элементы, о которых вы заботитесь заранее, тогда вам нужно использовать другой метод. Я сделал что-то подобное для одного из моих приложений. Я создаю путь, где каждый шаг пути является индексом узла DOM среди дочерних элементов его родителя. Этот путь можно использовать для однозначной идентификации элемента. В вашем случае, корень, который служит в качестве первой опорной точки может быть body элемента. Путь будет выглядеть примерно так: /1/4/1/2, который (чтение назад) относится к дочернему 2 ребенка 1 ребенка 4 ребенка 1 из body. (Индексы основаны на 0.) Можно было бы создать путь в формате, который был бы совместим с XPath, если у вас есть для этого какое-то использование. Например, /ul[2]/li[5]/ul[2]/li[3]. (Напоминание: индексы XPath основаны на 1). В моем проекте мне не нужна совместимость XPath (и это не выгодно никоим образом в моем проекте).
Существует одна важная оговорка: Дерево DOM с обеих сторон должно иметь одинаковую структуру.
например. Если с одной стороны, у вас есть:
<body>
<ul>
<li>foo</li>
<li>bar</li>
</ul>
<body>
Тогда вы должны иметь то же самое с другой стороны, потому что если кто-то нажимает на последнем li и вам нужно определить элемент на другой стороне, вы будете иметь проблема, если DOM дерево, представляющий это:
<body>
<p>foo</p>
<body>
Как вы убедитесь, что ваши деревья имеют ту же структуру, полностью зависит от конкретного применения.
Первый метод, который я описал с использованием значений id, более терпим к различиям в структуре. Если вам нужны только около button элементов, и с обеих сторон у вас есть button элементов, которые отображаются в заказе «Оформить заказ», «Пустая корзина», «Удалить элемент» и что они выполняют одни и те же функции с обеих сторон, какие предки у них есть в их соответствующем дереве DOM. Однако порядок и количество элементов button все еще имеют значение.
Почему вы хотите иметь дело с сокетами в этом случае? Если ваш webapp обрабатывает всю эту интеграцию внутри себя и внешней системы, а среда настраивается для сценария тестирования во время выполнения, тогда вы должны просто запустить ваш webapp с интеграцией на месте и протестировать его, имитируя пользователя, взаимодействующего с браузером. Вам просто нужно сопоставить элементы с идентификаторами и использовать их, чтобы однозначно идентифицировать элемент страницы. – guilhebl
А? Это не через веб-приложение. Браузер, размещенный на компьютере человека B, будет использоваться для просмотра определенных веб-сайтов и выполнения определенных сценариев селена. Как еще у меня будет человек B и человек? Обмен данными без использования сокетов? Хотя отображение элементов с идентификатором звучит как хорошая идея. –