Автоматизированное ИИ-тестирование, значение первое: ИИ, который автоматизирует ваше тестирование
Покрытие, сгенерированное по вашему продукту; шаги, выраженные как намерения, чтобы косметические изменения их не ломали; сбои, возвращаемые в форме, пригодной для того, кто будет их исправлять. Тестируемое ПО обычное и детерминированное, ИИ находится в инструментарии.
Именно это делает большинство продуктов в этой категории, и именно это нужно большинству команд.
Значение второе: тестирование системы, содержащей ИИ
Здесь недетерминирован уже сам продукт. Один и тот же вход даёт разный выход, поэтому проверка «ожидаемое равно фактическому» перестаёт быть доступной и нужен другой тип утверждений.
Свойства, а не равенство
Проверяйте, что результат имеет нужную структуру, ссылается на источник, укладывается в ограничение по длине и отказывает там, где должен отказать.
Распределения, а не отдельные прогоны
Один прогон почти ни о чём не говорит. Запускайте многократно и отслеживайте долю успешных прогонов.
Регрессия, а не абсолютные значения
Вопрос в том, ухудшило ли ситуацию это изменение, а не в том, идеально ли всё работает.
Ошибка, общая для обоих случаев
Считать, что пройденная проверка что-то значит, ни разу не убедившись, что она вообще способна упасть. В детерминированном случае так появляются наборы тестов, полные утверждений, которые никогда не покраснеют. В недетерминированном — системы оценки, которые высоко оценивают что угодно.
Сломайте что-нибудь намеренно. Это займёт минуту и остаётся единственным доказательством того, что проверка любого из двух видов действительно связана с тем, что она якобы измеряет.
Где провести границу в смешанном продукте
Большинство продуктов с ИИ по большей части состоят не из ИИ, и полезнее явно провести границу, чем позволять недетерминированности расползаться дальше.
Всё вокруг этой функции — обычное ПО: аутентификация, хранилище, ограничения частоты запросов, интерфейс, который отображает результат. Всё это тестируется традиционно, и если считать весь продукт непредсказуемым только потому, что непредсказуем один компонент, вы теряете много дешёвого и надёжного покрытия.
Внутри границы переходите к свойствам и долям. Вход подаётся, выход меняется, и вы проверяете, что он имеет нужную структуру, ссылается на что-то реальное и отказывает там, где должен. Один раз зафиксировать, где проходит эта граница, — именно это удерживает команду от того, чтобы избыточно тестировать детерминированные части статистическими методами или недотестировать ИИ-часть из-за того, что точные утверждения постоянно падали.
Какой из двух случаев у вас
Если ваш продукт дважды даёт один и тот же ответ, у вас первый случай и вам нужно сгенерированное покрытие, выполняемое против работающего приложения. Если нет — у вас второй случай, и вместо «прошло или не прошло» нужны проверки свойств и доли.
Многие продукты сочетают и то и другое: детерминированное приложение с одной ИИ-функцией внутри. Тестируйте детерминированные части обычным способом, а ИИ-функцию рассматривайте как отдельную задачу, вместо того чтобы растягивать один подход на оба случая.
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Для тех, кто не хочет устанавливать ничего локально, то же самое закрывает панель управления, а полный набор команд лежит в репозитории CLI.
Два пути, и выбор на самом деле сводится к тому, кто владеет пайплайном. Подключение GitHub App из панели управления вообще не требует изменений в репозитории, потому что реагирует на деплой, который ваша сборка и так публикует. Добавление шага GitHub Actions помещает проверку в репозиторий, где она проходит ревью наравне с остальной сборкой.
Какое из значений покрывает TestSprite
Первое. TestSprite использует ИИ для проверки обычного ПО: покрытие генерируется по вашему продукту, шаги выражены как намерения, выполнение идёт против развёрнутого приложения, а сбой возвращается в форме, с которой может работать кодовый агент.
Для продукта с ИИ-функцией это покрывает всё вокруг неё, то есть бóльшую часть продукта: аутентификацию, хранилище, ограничение частоты запросов, интерфейс, сценарии, по которым реально ходит пользователь. Auto-Authentication, Dynamic Variables, Dependency Chains и Auto-Cleanup решают проблемы состояния на стороне API.
Самой функции нужны проверки свойств и доли, а это уже другая оснастка. Явно проведённая граница и позволяет получить дешёвое, надёжное покрытие детерминированного большинства вместо того, чтобы считать непредсказуемым весь продукт.
Что из этого делает TestSprite?
Первое. Он проверяет детерминированное поведение приложения на работающем продукте, включая приложения, внутри которых есть ИИ-функции.
Как тестировать LLM-функцию?
Проверками свойств, которые выполняются многократно и отслеживают доли, а не отдельные результаты. Отказы, формат и наличие ссылок на источники обычно проверяются легче, чем качество ответа.
Может ли один набор тестов покрыть оба случая?
Детерминированные части — да. Недетерминированной функции нужна своя оснастка со своим представлением о том, что считается пройденным результатом.
Какая доля успешных прогонов разумна для ИИ-функции?
Та, что была у вас раньше. Абсолютные цели, заимствованные из бенчмарков, редко переносятся на ваш продукт.
Считается ли один упавший прогон багом?
Для недетерминированной функции сам по себе — нет. Сигнал — это сдвинувшаяся доля; один прогон — шум.
Две темы, одно название.
Автоматизированное ИИ-тестирование — это либо ИИ, который тестирует ваше ПО, либо тестирование ПО, содержащего ИИ. Первому нужно сгенерированное покрытие против работающего приложения, второму — свойства и доли. И тому и другому нужны проверки, про которые вы убедились, что они способны упасть.