Прибыль:
- Возможность создавать надежный тестовый код пользовательского интерфейса с использованием искусственного интеллекта, включая data-testid, открытое ожидание и утверждение, которое проверяет реальный результат пользователя.
- Возможность избежать хрупких тестов (плохой селектор, слепое ожидание) и упростить поддержку тестов в структуре объектной модели страницы.
- Возможность тестировать каждый тест пользовательского интерфейса, созданный путем взлома кода, а также обнаруживать и исправлять ложно пройденные тесты.
Каждый щелчок, каждое заполнение формы, каждый переход на страницу, который пользователь совершает в браузере, нельзя тестировать снова и снова вручную — именно поэтому существует автоматизация тестирования пользовательского интерфейса (пользовательский интерфейс; эти тесты имитируют поведение пользователя путем программного управления реальным браузером). Selenium, Playwright и Cypress — наиболее распространенные инструменты для этой работы. Искусственный интеллект (ИИ) хорошо умеет писать код для этих инструментов: вы описываете тестовый пример, ИИ дает вам черновик работоспособного сценария автоматизации. Но здесь снова вступает в игру главное предупреждение этого модуля: тестовый код пользовательского интерфейса, который создает ИИ, часто может представлять собой хрупкие тесты, которые «загораются зеленым, но проверяют не то» или развеваются на ветру. Ваша задача — не запускать этот код, а убедиться, что он действительно надежно проверяет правильность.
В этом модуле мы стремимся создать надежные, удобные в сопровождении и по-настоящему проверяющие тесты пользовательского интерфейса с помощью ИИ; Вы научитесь избегать хрупких испытаний.
Три столпа надежного тестирования пользовательского интерфейса
1. Правильный локатор элемента. Тест использует селектор для поиска элемента на странице. ИИ часто создает хрупкие селекторы: длинные пути XPath (адрес слишком зависит от структуры страницы), селекторы, основанные на именах классов CSS (ломаются при изменении дизайна). Надежный способ — это стабильные атрибуты, такие как data-testid, которые разработчик добавил для тестирования. Явно навязывайте это ИИ.
2. Явное ожидание. Источником уязвимости номер один при тестировании пользовательского интерфейса является время. Постоянное ожидание(3) (слепое ожидание) — плохая практика: иногда этого недостаточно, иногда это пустая трата времени. Правильный способ — использовать явное ожидание, которое говорит «подождите, пока этот элемент не появится». Драматург делает это по большей части автоматически; В Selenium вы должны явно запросить это.
3. Значимое утверждение. Тест должен проверить результат, который действительно увидит пользователь — например, «номер заказа появился на экране», а не просто «страница загружена». Если тест, созданный ИИ, не имеет утверждения или неважен, этот тест выдает псевдопроход (1-й блок).
Внимание: когда вы впервые видите тест пользовательского интерфейса, созданный искусственным интеллектом, проверьте максимум три вещи: зафиксированы ли селекторы (data-testid), включено ли ожидание (без слепого сна) и проверяется ли утверждение фактический результат пользователя? Если с этими тремя все в порядке, тест, вероятно, надежен.
Объектная модель страницы
По мере того, как тесты становятся больше, написание селекторов внутри каждого теста становится кошмаром для обслуживания. Объектная модель страницы (POM — шаблон проектирования, который собирает селекторы и действия для каждой страницы/экрана в один класс) удерживает селектор в одном месте; Когда интерфейс меняется, вы обновляете его в одном файле. Попросите ИИ создавать тесты в структуре POM, а не напрямую; Это существенно упрощает обслуживание.
Слабая подсказка / Сильная подсказка
Слабое: «Напишите Selenium-тест для страницы входа».
Сильный: «Напишите тест процесса входа в систему с помощью Playwright (TypeScript). Селекторы используют только data-testid; не контролируйте то, что видит пользователь, а не заголовок страницы».
Мощная подсказка; Инструмент предоставляет язык, политику выбора, стратегию ожидания, архитектуру (POM) и выразительное ожидание утверждения.
Данные испытаний и независимость от окружающей среды
Надежный UI-тест не только пишется правильно, но также создает и очищает собственные тестовые данные. Тесты, созданные ИИ, часто связаны с пользователем или записью, которая, как предполагается, уже существует в среде («войдите в систему как администратор»). Это предположение нарушается, когда тест выполняется в другой среде или после другого теста (проблема зависимости порядка в модуле 9). Правда в том, что каждый тест создает необходимые ему данные в начале теста (или подготавливает их с помощью вызова API) и очищает их в конце. Явно проинструктируйте ИИ «настроить любые данные, от которых зависит этот тест, внутри теста; не предполагайте готовые данные извне».
Еще один важный момент — не проводить тестирование пользовательского интерфейса на реальных пользовательских данных. Если в тестовой среде используется копия производственной базы данных, эти записи представляют собой данные реальных людей; снимки экрана и тестовые записи могут раскрыть эти данные. Используйте синтетические (вымышленные) тестовые аккаунты; он одновременно защищает конфиденциальность и делает тесты воспроизводимыми. Проведение теста «отмены заказа» с использованием реальной учетной записи клиента является как этической, так и операционной ошибкой.
Совет: делайте как можно меньше тестов пользовательского интерфейса; Оставьте фактическую проверку API и модульным тестам, которые работают быстро и стабильно. Тестирование пользовательского интерфейса является дорогостоящим и хрупким — используйте его только для проверки действительно сквозного пользовательского потока (логика пирамиды тестирования).
Сравнение автомобилей
особенность
селен
драматург
кипарис
языки
Java, С#, Питон, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
автоматический режим ожидания
Нет (от руки)
Да (сильный)
Да
Мультибраузер
широкий
Хром/Файрфокс/Вебкит
Хром-доминантный
склонность к ломкости
Высокий (ручной режим ожидания)
низкий
низкий
Легкость обучения
средний
легко
легко
параллельная работа
Требуется сетка
встроенный
Резидент/платный
Запрашивая код у AI, четко укажите, какому автомобилю он принадлежит; В противном случае это может привести к созданию запутанного и неработающего кода.
Четыре копируемых шаблона
1) Генерация твердого теста пользовательского интерфейса:
Ваша роль: старший инженер по автоматизации тестирования. Напишите тесты с помощью [инструмент + язык] для следующего потока: [поток]. Правила: - Только селекторы данных-testid; Использование класса XPath/CSS. - Никакого слепого сна; Используйте явное/автоматическое ожидание. - Применить объектную модель страницы. - Пусть каждое утверждение проверяет фактический результат пользователя. В начале каждого теста укажите, какие критерии приемки вы проверяете.
2) Контроль хрупкости:
Проверьте следующий тест пользовательского интерфейса на хрупкость: - Имеется ли нестабильный селектор (длинный
3) Преобразование в объект страницы:
Преобразуйте следующий простой тестовый код в структуру объектной модели страницы. Переместите селекторы и действия в классы страниц; Пусть тестовый файл читает только поток сценария. [Инструмент/язык].Код: [вставить код]
4) Доказательство псевдоперехода:
Докажите, что этот тест пользовательского интерфейса действительно подтверждает: какое единственное изменение я внесу в код приложения, чтобы этот тест стал КРАСНЫМ? Если вы не можете найти изменение, которое нарушит тест, тест неадекватен; добавить недостающие утверждения. Тест: [вставить тест]
три мини-кейса
Случай 1 — Освобождение от хрупкого селектора. Из 40 тестов, проведенных одной командой с использованием ИИ, 70% были сломаны после обновления интерфейса; ни одна из них не была настоящей ошибкой, все они были хрупкими селекторами XPath. Команда преобразовала тесты в базу данных с помощью шаблона «проверка уязвимости». За следующие три обновления интерфейса количество ложных разрывов упало до нуля; время обслуживания сократилось с 6 часов до 30 минут в неделю.
Случай 2. Ложное прохождение теста пользовательского интерфейса. ИИ провел тест «добавить в корзину»; тест был зеленым. Когда был запущен шаблон «поддельного подтверждения прохода», тест, по-видимому, проверял только нажатие кнопки и заголовок страницы, но никогда не проверял, увеличился ли счетчик корзины или нет. Даже если логика тележки была полностью нарушена, тест пройден. Добавлено истинное утверждение (значок корзины равен «1»).
Случай 3. Ловушка слепого ожидания. В тесте Selenium, созданном AI, после каждого шага был сон(2); 60 тестов заняли 14 минут и все равно время от времени ломались. После перехода на open wait (ожидание, пока элемент станет кликабельным) время сократилось до 5 минут и хрупкость исчезла. Слепое ожидание было медленным и ненадежным.
Распространенные ошибки
- Согласие на хрупких селекционеров. Использование длинных XPath, сгенерированных ИИ, как есть; Тесты завершаются сбоем при первом изменении интерфейса.
- Оставляя слепого «сна». «Разрешение» тайминга с фиксированным ожиданием; одновременно медлителен и нерешителен.
- Тривиальное утверждение. Просто убедитесь, что страница загрузилась; не проверять фактический результат пользователя (фальшивый проход).
- Расти без ПОМ. Распределить селекторы по каждому тесту; Ручное обновление десятков файлов при изменении интерфейса.
- Инструмент не указан. Не сообщать ИИ, какой инструмент/язык вам нужен; получаю грязный, нерабочий код.
- Доверие, когда вы запускаете сгенерированный код и проходите. Не тестирование путем взлома кода.
В итоге
Автоматизация тестирования пользовательского интерфейса проверяет поведение пользователя, управляя реальным браузером с программой. ИИ генерирует этот код быстро, но есть две большие ловушки: ненадежные тесты (плохой селектор, слепое ожидание) и ложное прохождение тестов (неполное/тривиальное утверждение). Тремя столпами надежного тестирования пользовательского интерфейса являются селектор фиксации (data-testid), явное ожидание и утверждение, проверяющее фактический результат пользователя. Наличие тестов, созданных в объектной модели страницы, радикально упрощает обслуживание. Протестируйте каждый сгенерированный тест, задав вопрос «какое изменение нарушит это?»
Задача приложения
Выберите пользовательский поток из вашего собственного проекта (например, вход в систему или поиск). Попросите ИИ написать тесты с помощью шаблона «генерация надежного теста пользовательского интерфейса». Затем: (1) проверьте и исправьте селекторы и ожидания с помощью «проверки хрупкости», (2) докажите, что каждый тест действительно подтверждается с помощью «доказательства псевдопрохождения», (3) взломайте код и обратите внимание, что тест становится красным. Сообщайте о количестве проведенных и исправленных тестов, а также о количестве обнаруженных вами уязвимостей и псевдопроходов.
контрольный список
- [ ] Я четко дал ИИ инструмент, язык, политику выбора и архитектуру (POM).
- [ ] Я проверил, что селекторы проверены на данных.
- [ ] Я позаботился о том, чтобы использовать явное/автоматическое ожидание вместо слепого сна.
- [ ] Я проверил, что каждое утверждение проверяет фактический результат пользователя.
- [ ] Я тестировал каждый тест, взламывая код; Я видел, как он стал красным.
- [ ] Я собрал тесты в структуре Page Object Model.