Два режима работы: требования против реализации

Применение LLM в тестировании обычно идет по одному из двух сценариев. Первый — генерация на основе требований (например, user story). Здесь модель разворачивает краткое описание функции в подробные чек-листы, сценарии Given–When–Then или тестовые данные. Это помогает проверить, соответствует ли продукт договоренностям. Однако здесь есть риск: если в требованиях не прописаны нюансы (например, аннулируется ли старая ссылка при смене email), модель может додумать логику от себя.

Второй режим — генерация на основе существующего кода. Модель читает функции или классы и пишет модульные тесты, подбирая входные значения и заглушки. Это полезно для регрессионного тестирования, чтобы отследить изменения в поведении системы. Но у этого метода есть критический недостаток: модель часто воспринимает текущую реализацию как истину. Если в коде заложена ошибка, ИИ создаст «зеленый» тест, который подтвердит это неправильное поведение.

Проблема «тестового оракула»

Основная сложность заключается в создании корректного «тестового оракула» — ожидаемого результата, с которым сравнивается поведение системы. Исследование Do LLMs generate test oracles that capture the actual or the expected program behaviour? показало, что модели выбирают правильный вариант менее чем в половине случаев при анализе Java-проектов. Если модель видит только код с ошибкой, она не может узнать верное бизнес-правило извне.

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

Где ИИ действительно полезен

Несмотря на риски, ИИ эффективно справляется с черновой работой, где требуется не принятие решений, а форматирование. К полезным задачам относятся:

  • Сбор очевидных позитивных сценариев и оформление чек-листов;
  • Подбор валидных и невалидных тестовых данных (адреса, даты, форматы API);
  • Приведение разрозненных заметок к единому шаблону документации;
  • Генерация заготовок автотестов под конкретный фреймворк.

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