Автор: Шрай Шарма (Shray Sharma)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

Тест-автоматизация жизненно важна для результативного тестирования ПО в постоянно меняющихся условиях. Создание тест-автоматизации для непрерывной разработки – приоритет большинства компаний, располагающих отдельными командами обеспечения качества.

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

Возможно ли это? Да, возможно! Эта статья о том, как совместить Playwright, библиотеку тест-автоматизации с открытым исходным кодом, с языковыми моделями ИИ вроде Groq, Llama и Mistral, чтобы:

• Получать подсказки и результаты анализа кода по мере создания кода автоматизации.
• Создать набор тестов, которые самостоятельно восстанавливаются при помощи языковых моделей – вам не придется вручную вмешиваться каждый раз, когда код меняется, а соответствующий тест падает. Именно это и подразумевают под «самовосстановлением».

Что предлагает ИИ для оптимизации тест-автоматизации?

Тест-автоматизация – это теперь стандарт в тестировании. Одна из целей хорошей тест-автоматизации – это снижение необходимости вмешательства человека и поддержки.

На практике так не бывает. Как только скрипты автоматизации написаны, их требуется регулярно поддерживать, что приводит к дополнительным задачам, отнимающим время у необходимых проекту разработки и тестирования.

Тут в игру и вступает ИИ. Интеграция языковых ИИ-моделей с Playwright может создать мощный самовосстанавливающийся фреймворк. Надежная интеграция позволяет языковым моделям использовать разнообразные возможности инструментов тест-автоматизации вроде Playwright не только для верификации кода, но и для взаимодействия с текущим состоянием браузера. Эти стратегии дают моделям богатый контекст, а в результате точность их предложений увеличивается.

Преимущества интеграции:

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

Работа с языковыми моделями: максимизация преимуществ и решение распространенных проблем

Языковые модели дают значительные преимущества тем, кто пытается разрешить проблемы поддержки тест-автоматизации.

Инженерам-автоматизаторам модели предлагают:

• Анализ кода. Понимание и интерпретация сниппетов кода.
• Генерация предположений. Выдача предположений по автодополнению кода и оптимизации.
• Обнаружение ошибок. Идентификация потенциальных проблем, предложение решений.

И в конце концов эти мощные возможности можно скомбинировать в самовосстанавливающееся решение для тест-автоматизации.

Однако для разработки качественного решения нужно справиться с рядом распространенных проблем языковых моделей.

Устаревшая информация

Проблема

Вы можете изо всех сил стараться обучать вашу модель, используя последние данные из репозиториев. Однако эти данные со временем устаревают. К примеру, вашей автоматизации может требоваться последняя версия Java, а модель знает только о более старой версии.

Возможные решения

Регулярное переобучение языковых моделей:

• Обновления по расписанию. Переобучайте языковые модели на новых данных по расписанию. Если обученная модель не может правильно предсказать вероятность следующих слов, то качество со временем улучшится, если регулярно ее переобучать. Переобучение – наиболее очевидный способ добиться более качественных ответов. Так вы поддержите знания своей модели о новых языках, API, библиотеках, и т. д.
• Инкрементальное обучение. Инкрементально пополняйте модель новыми данными, не переобучайте ее с нуля. Инкрементальное обучение более эффективно и позволяет модели узнавать что-то новое постепенно.

Интеграция с активными источниками данных:

• API и данные. Если мы подключаем модель к API и репозиторию активных данных, то она будет получать более значимую информацию в режиме реального времени. К примеру, подключение к GitHub или более обширным репозиториям кода может дать ей доступ к последним сниппетам и документации.
• Обратная связь в реальном времени. Обратная связь через краудсорсинг позволяет пользователям отправлять отчеты об устаревших или неверных предположениях. Эту информацию можно использовать для обновления базы знаний модели в режиме реального времени.

Гибридные подходы:

• Статические и динамические данные. Комбинация статических обучающих данных с динамической информацией в режиме реального времени – это гибридный подход, напоминающий настоящего эксперта. Возможно, его личная копия книги устарела, но он получает современную информацию из живых презентаций.
• Обновления по запросу. Вы можете настроить модель так, чтобы она запрашивала обновления, если столкнулась с новыми для себя ситуациями.

Как мы справились с проблемой устаревших данных

См. раздел с подробным обзором ниже.

Галлюцинации

Проблема

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

Возможные решения

Чтобы справиться с галлюцинациями, можно добавить высококачественные данные, использовать инжиниринг подсказок с учетом контекста, и тонко настроить модель под конкретную доменную область. Можно также создать службу верификации, которая осуществит возвратный вызов модели, чтобы исправить проблему.

Как мы с этим справились

См. раздел с подробным обзором ниже.

Длительное ожидание ответа

Проблема

Это время, которое модель затрачивает на обработку запроса и генерацию ответа. Длительное ожидание ответа может выматывать, ограничивая полезность и простоту ассимиляции языковой модели в процессы высокого темпа.

Модели ресурсозатратны, но самовосстанавливающаяся автоматизация требует быстрых ответов.

Возможные решения

Оптимизация производительности модели:

• Обрезка и квантование модели. Снижение размера модели через обрезку (удаление редко используемых или опциональных параметров) может значительно повысить скорость ответа, незначительно влияя на его точность.
• Производительная архитектура. Идеально подойдут модели с производительной архитектурой, особенно оптимизированной по скорости вывода.

Улучшение железа и инфраструктуры:

• Высокопроизводительные расчеты. Высокопроизводительные ядра или специализированное железо вроде тензорных процессоров может помочь ускорить процессы.
• Распределенные системы. Распределение вывода модели на несколько серверов может снизить задержку и увеличить скорость ответа.

Как мы с этим справились

Наше решение не требовало большой языковой модели. Поэтому мы выбирали скоростные модели от Mistral, Llama и Groq. В частности, у Groq есть компонент логического вывода с автоматическим выключателем нагрузки, что снижает энергозатратность нашего решения.

На графике сравнение времени ответа и качества ответа различных языковых моделей.

Источник: https://artificialanalysis.ai/models

См. также раздел с подробным обзором ниже.

Низкое качество ответа из-за ограничений контекста

Проблема

«Длина контекста» относится к объему текста или кода, который модель способна распознать за раз. Адекватный размер контекста, или «контекстное окно», критически важен для генерации правильных ответов. Нам нужна возможность предоставлять достаточно контекста, чтобы модель приняла наилучшее из возможных решение.

Ограниченная длина контекста может привести к менее точным или неполным предположениям, так как у модели нет доступа ко всей необходимой для принятия информированного решения информации.

Возможные решения

Стратегии управления контекстом:

• Расширение контекстного окна. Расширение контекстного окна модели позволит ей обрабатывать и воспринимать больше информации за раз. Сейчас разрабатываются продвинутые модели и техники, способные эффективнее работать с большей контекстной длиной.
• Фрагментация контекста. Разбивка большого контекста на небольшие, управляемые фрагменты, которые можно последовательно или параллельно обрабатывать, может помочь модели удерживать релевантную информацию при длительных последовательностях. Однако тут можно столкнуться с проблемами ограничения интенсивности. Рост контекстного окна до настоящего времени был экспоненциальным, и моделям требовалось решать вопросы и качества, и длины контекстного окна.

Источник: www.cobusgreyling.com

Это значит, что для расширения контекстного окна управляемым способом нужно улучшать возможности железа.

Как мы с этим справились

См. раздел с подробным обзором ниже.

Наше решение: подробный обзор

Какой поддержкой наше решение занимается самостоятельно?

1. На первом уровне упавшие тесты проверяются языковой моделью, исправления тоже вносит она.

2. Изменения в кейсах автоматически адаптируются в тест-скрипты.

Что еще требует вмешательства человека?

• Если падение вызвано реальным багом тестируемого приложения, модель не сможет исправить тест-скрипт, и тестировщикам нужно оформить баг.
• Тестировщикам все еще нужно убеждаться, что обновления требований и дизайна отражаются на кейсах.
• Если модель не способна исправить упавший кейс после трех попыток, тестировщикам нужно взглянуть на кейс и исправить его самостоятельно (система верификации улучшает успешность исправлений кода, сейчас этот показатель равен 90%).

Краткий обзор нашего решения

1. Наши кейсы живут в Jira, и мы используем Zephyr Scale для управления тестами. При появлении новых или изменении существующих кейсов наше решение загружает их в локальное хранилище кейсов.

2. Затем Playwright координируется с Llama для генерации нужного Javascript. Система запуска тестов Playwright проверяет сгенерированный код.

3. Если эта система выдает ошибку, модель правит код, а тесты заново запускаются, максимум три раза.

4. Если сгенерированный код сработал успешно, он отправляется в Mistral, где конвертируется в скрипт Playwright. Новый код добавляется в файл тест-скрипта.

5. Предположим, что тест-скрипт актуален: если кейс падает в ходе прогона или верификации, Llama вызывается для верификации кода и понимания проблемы. Затем Llama исправляет код и отправляет тест в систему запуска для нового прогона. Если обновленный тест падает три раза подряд, процесс останавливается.

6. Если Llama не может исправить проблему после трех прогонов, то причина, возможно, в реальном баге продукта. Чтобы не тратить силы зря, Llama останавливает прогон и выдает ошибку упавшего кейса, чтобы пользователь мог с этим разобраться. Все падения и успешные срабатывания пишутся в Playwright, как при обычном прогоне.

7. После исправления кода новый скрипт заменяет предыдущий.

Пришло время демонстрации

Пожалуйста, посмотрите видео нашей реализации с ее пояснением. Если вам нужны субтитры, их можно включить в YouTube. Ниже я опишу решение подробнее.

Что конкретно мы показываем?

Один из самых впечатляющих аспектов демонстрации – это бесшовное взаимодействие языковых моделей с Playwright. Каждый инструмент задействует возможности другого, чтобы добиться оптимальных результатов.

Языковые модели могут исправлять код при наличии невалидных ответов.

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

На скриншоте ниже можно видеть, что языковая модель попыталась сгенерировать исправление, но при следующем прогоне тест остался неверным. Со второй попытки исправления кода тест прошел успешно, и код был принят.

Контекстное окно позволяет за раз прогонять только один кейс

Другое важное наблюдение – ограничения, вызванные контекстными особенностями. Языковые модели с трудом справлялись с более чем двумя кейсами одновременно из-за ограничения длины контекста и пропускной способности.

Поэтому мы разбираемся с кейсами последовательно, а не параллельно. Это можно улучшить, добавив мощностей для моделей с более крупными контекстными окнами. Но пока что реализация соответствует пропускной способности модели.

Время ответа ограничено оборудованием

Демонстрация также дает понять, как ограничения оборудования влияют на производительность интегрированной системы. Инструментам понадобилась примерно минута, чтобы выявить проблемы и сгенерировать правильный код. Время ответа, хоть и приемлемое, можно значительно улучшить, улучшая оборудование.

Как мы справлялись с распространенными проблемами ИИ

Ранее в статье я описал распространенные проблемы ИИ и их возможные решения. Вот как с ними справлялись мы.

Замена устаревших данных

Одной из проблем, с которыми мы столкнулись, была загрузка динамических компонентов во время прогона. Мы можем получить структуру DOM из кода в фоновом режиме, но в этом случае в ней будут отсутствовать динамические компоненты, загружающиеся во время работы, и в результате языковая модель будет реагировать на устаревшие данные.

У инструментов тест-автоматизации есть информация о текущей структуре DOM – это наиболее актуальное состояние данных. Поэтому мы воспользовались возможностью Playwright извлекать текущую структуру DOM, а затем передавали ее в языковую модель с каждым запросом.

const PageDOMBody = await pageDOM('body').html();

Сокращение галлюцинаций

Для борьбы с проблемой галлюцинаций мы внедрили систему верификации, которая основана на возможности Playwright независимо запускать сгенерированный JavaScript-код. Мы также использовали на всю катушку возможности моделей, связанные с анализом кода, генерацией предложений и обнаружением ошибок.

Мы установили максимальное количество попыток исправления – 3. Обычно модель отлавливает галлюцинации за три попытки. Если проблема сохраняется – это, возможно, баг в коде продукта, или же что-то, о чем модели не хватает информации.

async function evaluateGroqCall(userInput,PageDOMBody,page){
    // создает секцию сообщений с разделами и дополнительным сообщением
    const messages = createGroqMessages(userInput, PageDOMBody,200000);
    let groqResponse = await groqCall( messages,PageDOMBody);
    let result;
    const maxAttempts = 3;
    let attempts = 0;
    while (attempts < maxAttempts) {
        try {
            result = await page.evaluate(groqResponse);
            // если оценка успешна и проблем не выявлено, прервать цикл
            break;
        } catch (e) {
            const errorMessage = e.message.split('\n')[0];
            if(errorMessage.includes("Verification failure"))
            {throw new Error(errorMessage)}
            console.log("Error during attempt", attempts + 1, "for generating code:", errorMessage);
            attempts++;
            if (attempts < maxAttempts) {
                messages.push({
                      role: "user",
                      content: `on running it the issue was this: ${errorMessage}. Refer again to the DOM and the error message and think of another way of doing the task`
                });
                groqResponse = await groqCall(messages, userInput);
                console.log("New generated response for attempt", attempts + 1, ": ", groqResponse);
            } else {
                 // если достигнуто максимальное количество попыток, выдать финальную ошибку
                throw new Error(`Failed after ${maxAttempts} attempts with error: ${errorMessage}`);
            }
        }
    }
    return groqResponse;
}

Оптимизация времени ответа

Если взять модели вроде OpenAI, то время ответа будет в пределах 2-3 секунд. Но нам нужно было решение побыстрее. Мы выбрали Mistral и Llama с GROQ, и стандартное время ответа измеряется в миллисекундах.

Настройка подходящего объема контекста

Контекстное окно у моделей вроде OpenAI – примерно 28 тысяч токенов, но так как наш контекст достигал 30 тысяч, нам нужна была способная на такое модель.

Для решения этой проблемы мы вычислили средний размер нашей DOM – примерно 20-30 тысяч токенов максимально. Это побудило нас выбрать модель Llama's llama-3.1-8b-instant – она может обрабатывать 150 тысяч токенов в минуту, что гарантирует безопасную работу.

Проще говоря, мы внедрили расширение контекстного окна, выбрав модель, способную работать с более крупным контекстом – при этом крупным ровно настолько, насколько нам нужно: модель Llama's llama-3.1-8b-instant.

Как адаптировать наше решение к вашему окружению

Фреймворк тест-автоматизации

У Playwright есть функция page.evaluate(), запускающая сгенерированный языковыми моделями код. Для тех же результатов можно использовать любой инструмент.

Playwright:

result = await page.evaluate(groqResponse);

В Selenium, используя execute_script:

result=driver.execute_script(script,*args)

В Cypress:

cy.window().then((win) => {
win.eval('console.log("Hello from Cypress!")');
});

Мы не ограничены каким-то конкретным инструментом автоматизации – мы просто пользуемся им, как средством запуска тестового кода, сгенерированного языковыми моделями.

Языковые модели и хостинг

В текущей реализации используются Llama и Mistral. Llama генерирует скрипты Playwright, а Mistral генерирует код JavaScript, который внедряется в функциональность запуска скриптов Playwright. Обе модели размещены в GROQ, что дает высокую производительность и быстрые результаты.

Выберите любую нравящуюся вам модель: https://console.groq.com/docs/quickstart. При желании можно даже разместить там свою собственную.

Что ждет наше решение в будущем?

В будущем мы планируем исследовать другие модели, способные управляться с большим контекстом и быстрее реагирующие.

К тому же по мере роста контекстного окна мы можем создавать тест-кейсы с языковыми моделями, которые знают наше решение во всей полноте, что позволит автоматизировать процесс полностью.

Обсудить в форуме