SmartBDD

Интерактивное приложение, которое позволяет пользователю генерировать BDD-сценарии в формате Gherkin в виде диалога с языковой моделью (GigaChat).

📝 Оцените приложение

Помогите нам стать лучше! Пожалуйста, заполните короткий опрос (3-5 минут):

👉 Оценить приложение

🏗️ Новая архитектура с MCP сервером

Приложение теперь состоит из двух компонентов:

1. Streamlit клиент (
   SmartBDD.py
   ) - веб-интерфейс для взаимодействия с пользователем
2. MCP сервер (
   mcp_server.py
   ) - серверная часть для управления контекстом, историей и RAG-поиском

Установка и запуск

Требования:

• Установлен VSCode (можно использовать любую другую IDE)
• Установлен Python версии >=3.10.0,<3.13.0
• Создано и активировано виртуальное окружение (venv):
  1. python -m venv ./.venv
  2. source ./.venv/bin/activate
     (для *nix, MacOS);
     .\.venv\Scripts\activate
     (для Win)

Шаги:

• Склонировать проект (
  git clone <...>
  )
• Настроить виртуальное окружение и установить необходимые зависимости (в корне проекта ввести:
  pip3 install -r requirements.txt
  )

Запуск приложения

1. Запуск MCP сервера

Откройте новый терминал и выполните:

Сервер запустится на http://localhost:8000

2. Запуск Streamlit клиента

Откройте другой терминал и выполните:

Приложение откроется в браузере по адресу http://localhost:8501

Интерфейс

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

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

Инструкция по формированию файла zapp_steps_functions.json

Файл

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

1. Структура каждого шага

Каждый шаг представлен в виде JSON-объекта со следующими полями:

• pattern
  : Шаблон строки шага с параметрами (например,
  "Я авторизовался под пользователем \"{user_name}\""
  ).
• docstring
  : Документация шага, описывающая его назначение, параметры и действия.
• step_type
  : Тип шага (
  given
  ,
  when
  ,
  then
  ,
  step
  ), определяющий его роль в сценарии.
• function_name
  : Имя функции, которая реализует логику шага.
• file
  : Файл, в котором находится функция.

2. Источники данных

Файл формируется на основе:

• Кода тестовых функций: Извлекаются имена функций, их параметры и docstring.
• Шаблонов шагов: Шаблоны шагов (например, для авторизации или создания кейса) определяются вручную или автоматически на основе кода.
• Метаданных: Тип шага (
  given
  ,
  when
  ,
  then
  ) и связанные файлы указываются явно.

3. Процесс формирования

1. Сбор функций:

   • Анализируются файлы (например,
     swtr.py
     ,
     spaces.py
     ), извлекаются функции, предназначенные для тестовых шагов.
   • Для каждой функции извлекаются docstring и параметры.

2. Создание шаблонов:

   • На основе параметров функций формируются шаблоны шагов (например,
     "{user_name}"
     для параметра
     user_name
     ).

3. Добавление метаданных:

   • Каждому шагу присваивается тип (
     given
     ,
     when
     ,
     then
     или
     step
     ).
   • Указывается файл, в котором находится функция.

4. Сохранение в JSON:

   • Все шаги сохраняются в массив JSON-объектов, как показано в файле.

4. Пример для нового шага

Допустим, есть функция в

:

Соответствующий шаг в

:

5. Поддержка актуальности

• При добавлении новых функций или изменении существующих файл
  zapp_steps_functions.json
  должен обновляться автоматически (с помощью скриптов) или вручную.
• Важно проверять уникальность шаблонов, чтобы избежать дублирования.

6. Использование

Файл используется:

• Для генерации документации по шагам.
• Для валидации тестовых сценариев.
• Как справочник для написания новых тестов.

Рекомендации по написанию запросов

Обозначать элементы интерфейса в кавычках

Все элементы интерфейса (кнопки, поля, вкладки и прочее), которые являются локаторами обязательно указывать в двойных кавычках:

❌ Нажал на сохранить.

✅ Нажал на кнопку "Сохранить"

Писать подробно и последовательно

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

❌ Пользователь нашел в поиске методы тестирования.

✅ Пользователь ввел в "Поле Поиска" значение "методы тестирования" и нажал на кнопку "Найти"

Прописывать все ожидаемые действия и результаты

Избегать обобщений. Нужно подробно описывать поведение пользователя и что он проверяет:

❌ Клонировать тест кейс с параметрами

✅ Пользователь переходит в раздел "Кейсы" в созданном пространстве, нажимает кнопку "Клонировать" и подтверждает клонирование. Он убеждается, что появляется новый кейс с названием "Summary (Клон)", переходит в него (по номеру 2), снова открывает вкладку "Шаги" и проверяет, что отображаются шаг "шаг 1" и параметр "key1", а также что значение ключа параметра — "key1", а значение параметра — "value1".

API MCP сервера

MCP сервер предоставляет следующие endpoints:

- Добавление сообщения в сессию,

GET /api/sessions/{session_id}/history

- Получение истории сессии,

POST /api/json/upload

- Загрузка JSON файла с шагами,

GET /api/json/files

- Список JSON файлов,

POST /api/context/generation

- Получение контекста для генерации,

POST /api/scenarios/store

- Сохранение сгенерированного сценария,

GET /api/health

- Проверка здоровья сервера,

Примечания

В зависимости от того, какой API ключ GigaChat используется, нужно в коде

поменять соответствующую строку