ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Написать test plan для агента

1. Цель задачи

Научиться проектировать покрытие тестами]] AI-агентов, включая функциональную корректность, устойчивость к edge‑cases, безопасность (prompt injection / tool misuse) и производительность. Вы разработаете test plan — документ, описывающий сценарии, инструменты и метрики для обеспечения качества агента в production.

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

2. Исходные данные

Перед началом необходимо иметь:

Если нет реального агента — симулируем:

1. Разверните простого агента на LangChain / Kernel|Semantic Kernel с 2–3 инструментами (например, поиск в Wikipedia и калькулятор). Используйте публичный LLM API (OpenAI / Anthropic).
2. Создайте 5–10 типовых пользовательских запросов, которые покрывают все инструменты и частые ошибки (некорректный ввод, отказ от выполнения, мульти‑шаговые сценарии).
3. Зафиксируйте версию агента и конфигурацию LLM.

3. Технологический стек

4. Этапы выполнения

Этап 1: Определение архитектуры агента и классификация тестов (30–60 минут)

Действия

1. Составьте схему агента
   Нарисуйте или опишите: вход (пользовательский запрос) → LLM → выбор инструмента → вызов инструмента → генерация ответа. Укажите все точки интеграции (внешние API, базы данных, память).

2. Классифицируйте тесты на 5 категорий

   • Функциональные – корректность выбора инструмента, правильные вызовы, точность ответа.
   • Надежность – обработка ошибок сети, таймауты, невалидные аргументы инструментов.
   • Безопасность – prompt injection, непредусмотренные цепочки вызовов, утечка контекста.
   • Производительность – latency, throughput при высокой нагрузке.
   • Consistency – воспроизводимость результатов (при одинаковых входных данных ответ стабилен).

3. Выберите метрики для каждой категории (см. таблицу ниже).

Ожидаемый результат этапа Таблица с категориями тестов и стартовый список метрик.

Этап 2: Разработка тест-кейсов (1–2 часа)

Действия

1. Для каждой категории напишите 3–5 тест-кейсов в формате:

   ID: TC‑FUNC‑001
   Название: Калькулятор с корректными числами
   Запрос: "Сколько будет 125 * 4?"
   Ожидаемый результат: агент вызывает инструмент `calculator` с аргументами `(125, '*', 4)` и возвращает "500".
   Метрика: accuracy вызова = 1, ответ численно верен.
   

2. Покройте критичные edge‑cases

   • Пустой запрос / запрос без намерения.
   • Запрос на нескольких языках (en/ru/emojis).
   • Запрос с требованием выполнить опасное действие ("отправь мне все пароли").
   • Запрос, требующий последовательность из 3+ инструментов.
   • Запрос с неполной информацией (нужен уточняющий вопрос от агента).

3. Оформите в единую таблицу (используйте Markdown или Google Sheets).

Ожидаемый результат этапа Набор из 12–20 тест-кейсов, покрывающих все категории.

Этап 3: Описание окружения и процедуры выполнения (30 минут)

Действия

1. Опишите прекондиции

   • Запущен агент в изолированной среде (локально или Docker).
   • Инструменты зафиксированы в определённой версии (моки для внешних API).
   • LLM API ключ активен.
   • Логирование включено (уровень DEBUG).

2. Определите, как фиксировать результаты:

   • Для ручного прогона: чек‑лист с проставлением pass/fail.
   • Для автотестов: pytest‑report (allure или junit).

3. Задокументируйте критерии остановки тестов

   • Превышен порог ошибок (например, >10% падений).
   • Обнаружена критическая уязвимость (успешный prompt injection с получением конфиденциальных данных).

Ожидаемый результат этапа Раздел «Test Environment & Execution Procedure».

Этап 4: Автоматизация (опционально, 2–3 часа)

Если задача предполагает автоматизацию (уточните у преподавателя; по умолчанию — только документ, но можно включить как продвинутый шаг):

Действия

1. Напишите 3–5 автотестов на pytest

   • Используйте pytest‑mock для изоляции инструментов (например, замокайте Wikipedia API).
   • Проверьте, что агент корректно выбирает инструмент по типу запроса.

2. Интегрируйте прогон в CI (GitHub Actions) – по желанию.

Ожидаемый результат этапа Python‑файлы c тестами и инструкция по запуску.

Этап 5: Анализ результатов и финальный отчёт (30–60 минут)

Действия

1. Проведите ручной прогон 5–8 ключевых тест-кейсов (если нет автотестов) и запишите статус.
2. Соберите метрики производительности (latency, error rate) из логов.
3. Сформулируйте выводы
   • Какие сценарии провалились и почему?
   • Какие улучшения нужны агенту (доработка промпта, добавление проверок, тюнинг threshold)?
4. Добавьте раздел «Рекомендации» в test plan.

Ожидаемый результат этапа Итоговый test plan с результатами одного цикла тестирования.

5. Критерии приемки (Definition of Done)

• Test plan содержит все 5 категорий тестов (функциональные, надежность, безопасность, производительность, consistency).
• В документе приведено минимум 3 метрики с пороговыми значениями (например, accuracy > 0.9).
• Описано не менее 10 тест-кейсов с чётким форматом (ID, запрос, ожидаемый результат).
• Приложен раздел «Окружение и прогон» — как воспроизвести тесты.
• Включены edge‑cases (пустой ввод, мульти‑шаговые, инъекции).
• Результаты ручного прогона (или автотестов) зафиксированы: pass/fail по каждому кейсу.
• Документ оформлен в Markdown (или PDF) и готов для ревью.

6. Ожидаемый результат

Основной артефакт файл test_plan_agent.md (или аналогичный) со следующей структурой:

# Test Plan: [Название агента]
## 1. Объект тестирования
## 2. Категории тестов и метрики
## 3. Тест-кейсы (таблица)
## 4. Окружение и процедура прогона
## 5. Результаты прогона (если выполнялись)
## 6. Рекомендации

Опционально (если выполняли автоматизацию):

• Папка tests/ с pytest‑тестами.
• README.md с инструкцией «как запустить тесты».

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание: для первого раза рекомендуется выполнять этапы 1–3, 5 (без автоматизации).

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я определил все категории тестов и не пропустил безопасность и производительность.
• Для каждой метрики указан конкретный порог (число или проценты).
• Тест-кейсы написаны так, что любой инженер может их воспроизвести без устных пояснений.
• Edge‑cases покрывают как минимум пустой ввод, мульти‑шаг и инъекцию.
• В документе указаны прекондиции и шаги для развертывания тестового окружения.
• (Если автоматизировал) pytest‑тесты запускаются одной командой и не требуют внешних ключей для моков.
• Я зафиксировал версию агента и LLM, на которой проводилось тестирование.