Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Перевод статьи «Why I’m Betting on LLMs for UI Testing».
Сейчас в мире GenAI есть два лагеря: «Всецело преданные» и «Скептики». Одни видят в GenAI решение всех мировых проблем, другие категорически отказываются ей доверять и придерживаются традиционных подходов. Я же занимаю прагматичную позицию где-то посередине. Мне нравится использовать GenAI (ежедневно), но я также стараюсь понимать её ограничения и сохранять реализм. Чем чаще я её применяю, тем больше воодушевляюсь её будущим.
Как и с любой новой технологией, я смотрю вперёд, ведь многие текущие ограничения со временем исчезнут. Так что стоит «Играть на опережение».
Мы много говорим о том, как GenAI генерирует код, но почти не обсуждаем, как она создаёт и выполняет тесты. А ведь во втором она, на мой взгляд, куда лучше, чем в первом.
Я экспериментировал с использованием GenAI для тестирования пользовательских интерфейсов. О генерации юнит тестов с помощью GenAI написано много, а вот про интеграционное и end-to-end тестирование почти ничего. Я ожидал, что LLM справятся с этим хорошо.
UI тестирование критически важно, потому что это последний рубеж перед выпуском в продакшен. Если следовать «Пирамиде тестирования», у вас будет много юнит тестов, затем интеграционных. Но именно в интерфейсе собирается вся функциональность, и здесь часто находят проблемы, ускользнувшие от других тестов.
Мой первый опыт UI тестирования был в 1997 году в Microsoft, где я тестировал Office 2000. Тогда я сразу заметил две вещи:
- Фреймворки для управления UI были неудобными
- Тесты были хрупкими
За последние 30 лет в этой сфере мало что изменилось. Сейчас, руководя тестированием Amazon Store, я часто об этом задумываюсь.
LLM можно «скормить» разные данные для генерации тестов:
- Спецификации, дизайн документы, продакшен код
- Существующие тесты
- Информацию о покрытии кода (чтобы тестировать непроверенные пути)
- Операционные проблемы (чтобы указать на потенциальные уязвимости)
Главный вопрос: в каком формате должны быть автосгенерированные интеграционные тесты?
Путь №1: Генерация тестов в виде кода
LLM создаёт тесты (например, на Selenium, Appium), которые затем выполняются как обычно.
Плюсы:
- Код можно проверить
- После генерации тесты становятся детерминированными (вы точно знаете, что выполняется)
- Людям так привычнее
Минусы:
- Человеку проще писать тесты на естественном языке, чем разбираться в Selenium/Appium
- Тот, кто проверяет код, должен знать конкретный фреймворк
- Тестовый код нужно поддерживать (апгрейды, изменения в продакшен коде — всё это ваша головная боль)
Путь №2: Генерация тестов на естественном языке + выполнение другим LLM
Плюсы:
- Любой может прочитать и понять тест
- Нет привязки к фреймворкам — не нужно поддерживать код
- LLM могут адаптироваться к изменениям в UI (например, если пропал элемент, LLM может найти альтернативный путь)
Минусы:
- Неопределённость (LLM может пойти «не туда»)
Чтобы проверить это я написал простой тест и дал его LLM на выполнение. Важно смотреть не только на действия, но и на рассуждения модели (они приведены в «бабблах»).
Шаг 1: Ввод книга «Harry Potter» в поиск.
Шаг 2: Клик на кнопку «Search».
Шаг 3: Проверка, что нужная книга есть в выдаче.
Шаг 4: Выбор книги (ирония: LLM выбрала самый дешёвый вариант, чтобы «сэкономить мне деньги»).
Шаг 5: Попытка добавить в корзину, но кнопка «Add to cart» была ниже (не видна на экране). LLM нажала на «Add Prime» (ошибочно, но логично).
Шаг 6: Самостоятельно поняла ошибку, догадалась проскроллить вниз.
Шаг 7: Нашла «Add to Cart» — Это уже успех!
Шаг 8: Проверила добавление в корзину четырьмя разными способами (лучше, чем сделал бы человек!).
Этот простой тест демонстрирует мощь LLM в области тестирования пользовательских интерфейсов.
Проблема — это непредсказуемость. Как гарантировать, что LLM будет следовать правильному пути при навигации по вашему приложению во время тестирования? В моём небольшом примере, когда бот нажал кнопку «Add Prime», это стало намёком на то, что при навигации по интерфейсу бот действительно может сбиться с пути.
Ещё более забавный случай произошёл при другом запуске: бот не смог войти с предоставленными именем пользователя и паролем, поэтому он попытался самостоятельно создать совершенно новую учётную запись. Когда и это не удалось, он фактически попытался пообщаться со службой поддержки, чтобы решить проблему. Это действительно впечатляет — такой целеустремлённый маленький бот!
Для решения этой проблемы мы с коллегами рассматриваем введение «лимита шагов выполнения» для каждого теста. В моём примере тест успешно выполнялся за 8 шагов. Если же бот превышает установленный лимит (например, 20 шагов), это сигнализирует о вероятном отклонении от корректного сценария. Такой подход позволяет контролировать выполнение тестов, автоматически прерывая процессы, которые вышли за разумные временные рамки. Это поднимает важный вопрос: по мере увеличения зависимости от LLM в тестировании, нам необходимо чётко определять «запрещённые действия»: какие операции бот не должен выполнять ни при каких обстоятельствах.
Другое перспективное решение — внедрение системы двойного контроля, где отдельная LLM (условно назовём её «судьёй») будет оценивать логику и действия основной тестирующей модели. Такой подход «LLM арбитр» уже набирает популярность и успешно применяется для различных задач.
Также у нас есть уникальная возможность для объективного сравнения двух подходов к тестированию. В нашем распоряжении находятся сотни тысяч legacy тестов, разработанных на таких фреймворках, как Appium и Selenium. Эти тесты можно автоматически преобразовать в их естественно-языковые аналоги. Затем имеет смысл организовать параллельный запуск обоих вариантов тестов, как традиционных, так и новых. В процессе такого эксперимента мы сможем тщательно сравнить полученные метрики и результаты. Подобное исследование предоставит нам верифицируемые данные, которые подтвердят или опровергнут возможность полного перехода на тестирование с использованием естественного языка.
Заменит ли это людей тестировщиков? Мне не нравится слово «заменить», но это определенно изменит характер их работы. В некоторых организациях целые армии ручных тестировщиков выполняют одни и те же повторяющиеся задачи, чтобы подтвердить готовность к каждому релизу. Иногда это происходит потому, что автоматизация тестов слишком дорога; иногда потому что продукт меняется слишком быстро, чтобы вообще успеть написать автоматизированные тесты, а иногда из-за отсутствия дальновидности и нежелания инвестировать. Но любая ситуация, когда релиз зависит от человека, не масштабируема и неустойчива. К тому же, она нестабильна… люди печально известны своей непредсказуемостью и тоже совершают ошибки.
Я хочу, чтобы GenAI взяла на себя эти повторяющиеся тесты, а тестировщики смогли сосредоточиться на применении своей интуиции и накопленного опыта в том, как продукты могут ломаться, чтобы исследовать систему более свободно и творчески.
Стоит отметить, что текущая реализация тестов на основе LLM пока демонстрирует более низкую производительность по сравнению с традиционными методами автоматизированного тестирования, а использование графических процессоров для их выполнения существенно увеличивает стоимость. Эти технологические ограничения создают определенные сложности на данном этапе внедрения. Однако мы уверены, что ситуация изменится в ближайшем будущем благодаря постоянному совершенствованию алгоритмов и аппаратного обеспечения.
Мы уже оптимизируем LLM тестирование через кэширование и новые методы обработки данных, не дожидаясь идеальных условий. Даже сейчас экономия на разработке тестов перекрывает затраты на ресурсы. Это временный компромисс — технологии быстро развиваются. Уже сегодня гибкость и скорость создания тестов важнее текущих ограничений производительности.
LLM тестирование открывает принципиально новые возможности, недоступные традиционным методам. Исследователи Amazon продемонстрировали революционный подход: они создали тестовых агентов с разными пользовательскими профилями. Один и тот же тест может интерпретироваться по-разному в зависимости от заданной «персоны», что позволяет выявлять уникальные кейсы ошибок.
Особенно показателен пример с доступностью: вместо разработки отдельных тестов для проверки интерфейсов для незрячих пользователей, достаточно запустить стандартные тесты от лица соответствующего профиля. Такой подход фундаментально меняет парадигму тестирования, разделяя тестовые сценарии и условия их выполнения. Более того, он позволяет комплексно оценивать не только функциональность, но и требования доступности в рамках обычных тестовых прогонов.
Для меня прогресс в UI тестировании на основе LLM — это не вопрос «если», а вопрос «когда».
Свою карьеру в тестировании я начал в Microsoft в 1997 году. Помню, как устанавливал сырую debug сборку Office 2000: при первом запуске Word пять минут грохотал жесткий диск, после чего выдавал сообщение о критической ошибке. На следующий день новая сборка хотя бы запустилась, но через три минуты работы неизбежно зависала.
Однако спустя годы упорной работы тысяч инженеров, бесчисленных итераций и улучшений, этот самый код превратился в стабильный продукт, который использовали миллионы. Сегодня, спустя десятилетия, процесс разработки ПО по сути не изменился: те же циклы тестирования, исправлений и доработок, просто на новом технологическом уровне.
Я одновременно воодушевлен и напуган. Но думаю, пора погружаться.