Что подразумевается под взаимодействием с веб-страницей при тестировании
Что проверяют
Что вы вкладываете в слово «взаимодействие»: клики мышкой или полный контракт со страницей. Вопрос почти всегда ведёт к автоматизации, поэтому ждут перечисления действий, проверок и понимания, как всё это не сделать хрупким.
Как отвечать
Взаимодействие это цикл: найти элемент, дождаться его готовности, выполнить действие, проверить результат.
- поиск: локатор по идентификатору, по служебному атрибуту для тестов, по CSS-селектору, по роли и доступному имени, в крайнем случае XPath;
- действия: клик и двойной клик, ввод и очистка текста, выбор в списке, отметка флажка, загрузка файла, наведение, перетаскивание, прокрутка, нажатия клавиш;
- контекст страницы: вкладки и окна, встроенные фреймы, системные диалоги, cookies и хранилище браузера, размер окна;
- сеть и данные: ожидание ответа, перехват и подмена запросов, чтобы проверить поведение при ошибке сервера или пустом списке;
- проверки: видимость, текст, атрибут, состояние элемента, адрес страницы, а не только факт того, что действие прошло.
Отдельно скажите про готовность: элемент должен существовать в дереве, быть видимым, не перекрытым и включённым. Современные библиотеки проверяют это сами перед действием, в остальных случаях пишутся явные ожидания условия.
Где спотыкаются
Ставят паузы на фиксированное время. Тест выходит и медленным, и мигающим сразу: на нагруженном стенде страница не успевает, на быстром время тратится впустую. Ждать надо условие, а не секунды.
Второе: цепляются за хрупкие локаторы. Абсолютный XPath, сгенерированные классы и надпись на кнопке ломаются от любой правки вёрстки или от перевода интерфейса. Стабильные атрибуты для тестов согласуются с разработчиками заранее.
Третье: проверяют действие вместо результата. Клик состоялся, тест зелёный, а запись не создалась. Сюда же обход проблем кликом через JavaScript: он срабатывает по перекрытому элементу и прячет ровно тот дефект, с которым пользователь столкнётся первым.