Руководство по веб-интерфейсу Mockarty

Добро пожаловать в руководство по веб-интерфейсу Mockarty. Независимо от того, являетесь ли вы QA-инженером, создающим свой первый мок, разработчиком, интегрирующим Mockarty в CI/CD пайплайн, или архитектором, проектирующим мультипротокольные тестовые среды, это руководство шаг за шагом проведёт вас через каждую страницу и функцию веб-интерфейса.

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

Ключевые термины

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

• Мок (Mock) – Имитированный API-эндпоинт, который возвращает заранее определённые ответы вместо вызова реального сервиса. Моки позволяют тестировать приложение без зависимости от внешних систем.
• Стаб (Stub) – В Mockarty термины «стаб» и «мок» используются как синонимы. Оба обозначают настроенный эндпоинт, возвращающий контролируемый ответ.
• Условие (Condition) – Правило, определяющее, когда мок должен совпасть с входящим запросом. Например, «совпадать только когда тело запроса содержит status: active».
• Пространство имён (Namespace) – Изолированное рабочее пространство, которое разделяет моки, хранилища и тестовые коллекции между командами или проектами.
• Хранилище (Store) – Механизм хранения ключ-значение, позволяющий мокам запоминать состояние между запросами. Mockarty предоставляет три типа хранилищ: Global, Chain и Mock.
• Faker – Встроенная библиотека функций для генерации реалистичных случайных данных (имена, email, UUID и др.) для ответов моков.

Содержание

• Начало работы
  • Доступ к интерфейсу
  • Аутентификация
  • Первый вход и начальная настройка
• Обзор интерфейса
  • Боковая панель навигации
  • Верхняя панель
  • Меню пользователя
  • Переключатель темы
  • Переключатель языка
• Панель мониторинга
• Моки
• Конструктор
• Неопределённые запросы
• Хранилища
• Генератор
• API Tester
• Запуски тестов
• Тест-кейсы
• Тест-планы
• Рекордер
• Fuzzing
• Контрактное тестирование
• Хаос-инженерия
• Утилиты
• Шаблоны
• Настройки
• Панель администратора
• Панель поддержки
• ИИ-функции
• Чат с ассистентом
• API-токены
• Роли и разрешения
• Советы и лучшие практики

Начало работы

Доступ к интерфейсу

После запуска экземпляра Mockarty откройте веб-браузер и перейдите по адресу:

http://localhost:5770/ui/

Замените localhost:5770 на ваш реальный хост и порт, если вы настроили пользовательский HTTP-порт через переменную окружения HTTP_PORT или обращаетесь к удалённому развёртыванию. Инструкции по установке и развёртыванию см. в Руководстве по развёртыванию. Полная таблица URL-адресов для разных типов развёртывания — в разделе Полезные функции и советы.

Интерфейс полностью адаптивен и работает во всех современных десктопных браузерах (Chrome, Firefox, Safari, Edge). Хотя интерфейс оптимизирован для использования на десктопе, базовые операции работают и на экранах планшетного размера.

Аутентификация

Mockarty поддерживает несколько стратегий аутентификации. Ваш администратор настроит один или несколько из следующих методов:

Локальная аутентификация

Метод аутентификации по умолчанию. Пользователи входят в систему с помощью имени пользователя (или электронной почты) и пароля. Пароли надёжно хешируются и хранятся в базе данных. Локальная аутентификация поддерживает:

• Настраиваемые администратором требования к сложности пароля.
• Блокировку учётной записи после нескольких неудачных попыток входа.
• Сброс пароля по электронной почте (при включённых email-уведомлениях).

OAuth 2.0

Mockarty поддерживает аутентификацию OAuth 2.0 с тремя встроенными провайдерами, настраиваемыми через переменные окружения:

• Google (OAUTH_GOOGLE_ENABLED, OAUTH_GOOGLE_CLIENT_ID, OAUTH_GOOGLE_SECRET)
• Yandex (OAUTH_YANDEX_ENABLED, OAUTH_YANDEX_CLIENT_ID, OAUTH_YANDEX_SECRET)
• VK (OAUTH_VK_ENABLED, OAUTH_VK_CLIENT_ID, OAUTH_VK_SECRET)

Кроме того, любой OAuth2/OIDC провайдер может быть добавлен через панель администратора в разделе Identity Providers – например GitHub, GitLab, Keycloak, Azure AD, Okta и другие. Для настройки универсального провайдера требуется указать: Auth URL, Token URL, UserInfo URL, Client ID, Client Secret и Scopes. Mockarty автоматически определяет стандартные поля информации о пользователе (id/sub, email, name, avatar) из ответа UserInfo провайдера.

При настройке на странице входа появляется кнопка «Войти через …». После аутентификации у внешнего провайдера пользователи автоматически создаются в Mockarty, если у них ещё нет учётной записи.

LDAP / Active Directory

Для корпоративных сред Mockarty может аутентифицировать пользователей через сервер LDAP или Active Directory. Атрибуты пользователя (имя, электронная почта, группы) синхронизируются из каталога. Членство в группах может быть сопоставлено с ролями Mockarty для автоматического назначения ролей.

SAML SSO

SAML 2.0 Single Sign-On обеспечивает аутентификацию через провайдеры идентификации, такие как Okta, OneLogin, Azure AD и другие. При настройке пользователи перенаправляются на страницу входа провайдера идентификации и возвращаются в Mockarty после успешной аутентификации.

Двухфакторная аутентификация (2FA)

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

• Одноразовые пароли на основе времени (TOTP) через приложения-аутентификаторы (Google Authenticator, Authy и др.).
• Одноразовые коды по электронной почте (при включённых email-уведомлениях).

2FA может быть принудительно включена администратором для всех пользователей или определённых ролей.

Первый вход и начальная настройка

При первом входе в Mockarty:

1. Учётные данные по умолчанию: Если используется локальная аутентификация, учётная запись администратора по умолчанию обычно имеет логин admin / пароль admin. Измените этот пароль сразу после первого входа.

2. Выбор пространства имён: Mockarty организует все ресурсы (моки, хранилища, тестовые коллекции) в пространства имён. После входа вы окажетесь в пространстве имён по умолчанию. Вы можете создать дополнительные пространства имён на странице настроек.

3. Создание первого мока: Перейдите на страницу конструктора, чтобы создать свой первый мок, или используйте страницу генератора для импорта моков из существующей OpenAPI спецификации, WSDL файла или другого поддерживаемого формата. Пошаговое руководство см. в Быстром старте.

4. Изучение панели мониторинга: Страница панели мониторинга предоставляет обзор вашего экземпляра Mockarty, включая статистику разрешения моков и метрики состояния системы.

Обзор интерфейса

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

Боковая панель навигации

Боковая панель содержит 16 пунктов навигации, организованных в логические группы:

Метки Preview: Страницы, отмеченные «Preview», отображают бейдж Preview в боковой панели. Эти функции полностью работоспособны, но находятся в состоянии preview/beta и могут существенно измениться в будущих версиях.

Видимость Fuzzing, Контрактного тестирования и Хаос-инженерии: Пункты навигации Fuzzing, Контрактное тестирование и Хаос-инженерия скрыты по умолчанию и отображаются только при включении соответствующей функции через лицензию или флаги функций. Контрактное тестирование и Хаос-инженерию также можно включить в настройках пользователя.

Ссылка на документацию: Ссылка на документацию (/ui/docs) расположена в отдельной секции в самом низу боковой панели, под основным списком навигации. Она предоставляет доступ к встроенному браузеру документации.

Боковую панель можно свернуть до режима отображения только иконок, нажав кнопку переключения внизу, что даёт больше пространства для основной области контента.

Активная страница подсвечивается в боковой панели характерным акцентным цветом. В нижней части боковой панели отображается номер текущей версии Mockarty.

Верхняя панель

Верхняя панель присутствует на каждой странице и содержит:

• Селектор пространства имён: Выпадающее меню, показывающее текущее активное пространство имён. Переключайтесь между пространствами имён для просмотра и управления ресурсами, принадлежащими каждому из них. Все операции создания моков, работы с хранилищами и тестовыми коллекциями привязаны к пространству имён.

• Глобальный поиск: Поле ввода поиска, позволяющее быстро находить моки по имени, идентификатору, маршруту или тегу в текущем пространстве имён. Результаты появляются по мере ввода со ссылками на страницы деталей найденных моков.

• Индикатор уведомлений: Показывает ожидающие уведомления, такие как завершённые запуски тестов, статус резервного копирования или системные оповещения.

Меню пользователя

Нажатие на имя пользователя или аватар в правом верхнем углу открывает выпадающее меню с пунктами:

• Профиль: Просмотр и редактирование профиля пользователя, включая отображаемое имя и адрес электронной почты.
• API-токены: Управление персональными API-токенами для программного доступа к REST API Mockarty.
• Язык: Переключение языка интерфейса. Mockarty поставляется с переводами на английский и русский языки. Дополнительные языки могут быть добавлены через систему i18n.
• Тема: Переключение между светлой и тёмной темами. Ваш выбор сохраняется в браузере и сохраняется между сессиями.
• Настройки 2FA: Включение или отключение двухфакторной аутентификации для вашей учётной записи.
• Выход: Завершение текущей сессии.

Переключатель темы

Mockarty поддерживает две визуальные темы:

• Светлая тема: Чистый, яркий интерфейс, оптимизированный для хорошо освещённых помещений.
• Тёмная тема: Пониженная яркость с тёмным фоном, оптимизированная для слабого освещения и снижения нагрузки на глаза.

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

Переключатель языка

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

• English (en) – по умолчанию
• Русский (ru)

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

Панель мониторинга

Путь: /ui/dashboards

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

Карточки системной аналитики

В верхней части панели мониторинга ряд сводных карточек показывает ключевые метрики с первого взгляда:

• Всего моков: Количество активных моков в текущем пространстве имён.
• Всего запросов: Совокупное количество запросов, разрешённых моками с момента последнего сброса.
• Активные пространства имён: Количество пространств имён, содержащих хотя бы один мок.
• Активные пользователи: Количество пользователей, которые входили в систему за последние 30 дней.
• Неопределённые запросы: Количество недавних запросов, не совпавших ни с одним моком (404).
• Записи хранилищ: Общее количество пар ключ-значение во всех хранилищах пространства имён.

Каждая карточка показывает текущее значение и индикатор тренда (стрелка вверх/вниз с процентным изменением по сравнению с предыдущим периодом).

График статистики разрешения моков

Временной график показывает активность разрешения моков за выбранный временной диапазон (последний час, 24 часа, 7 дней или 30 дней). На графике отображаются:

• Разрешённые запросы (совпали с моком и вернули ответ).
• Неразрешённые запросы (не найден подходящий мок, возвращён 404).
• Проксированные запросы (перенаправлены на реальный бэкенд-сервис).
• Ошибочные ответы (моки, которые по замыслу вернули коды ошибок).

Вы можете навести курсор на любую точку графика, чтобы увидеть точное количество и временную метку. Нажмите на серию в легенде, чтобы переключить её видимость.

Тренды объёма запросов

Столбчатая или линейная диаграмма (настраиваемая), показывающая объём запросов, агрегированный по часам или дням. Это помогает выявить шаблоны трафика, пиковые периоды использования и аномалии.

Распределение по протоколам

Кольцевая диаграмма разбивает разрешение моков по типу протокола:

• HTTP / REST
• gRPC
• MCP
• GraphQL
• SOAP
• SSE
• WebSocket
• Kafka
• RabbitMQ
• SMTP

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

Самые используемые моки

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

• Имя и идентификатор мока.
• Тип протокола.
• Маршрут или метод.
• Общее количество запросов.
• Временная метка последнего разрешения.

Нажмите на любую строку, чтобы перейти на страницу деталей мока.

Моки

Путь: /ui/mocks

Страница моков является центральным узлом для просмотра, поиска, фильтрации и управления всеми моками в текущем пространстве имён.

Просмотр всех моков

Основное представление отображает моки в виде списка (или карточек). Каждая запись мока показывает:

• Имя: Человекочитаемое имя мока.
• Идентификатор: Уникальный идентификатор мока.
• Протокол: Тип протокола (HTTP, gRPC, MCP и др.), обозначенный иконкой и подписью.
• Маршрут / Метод: Шаблон маршрута для сопоставления (например, /api/users/list) и HTTP-метод (GET, POST и т.д.) или эквивалент для других протоколов.
• Статус: Активен, отключён или истёк (превышен TTL или достигнут лимит использования).
• Теги: Цветные теги для категоризации.
• Создан / Обновлён: Временные метки создания и последнего изменения мока.
• Количество запросов: Сколько раз этот мок был разрешён.

Поиск и фильтрация

Страница моков предоставляет мощные возможности поиска и фильтрации:

• Текстовый поиск: Введите текст в поле поиска для фильтрации моков по имени, идентификатору, маршруту или тегу. Поиск нечувствителен к регистру и поддерживает частичное совпадение строк.
• Фильтр по протоколу: Фильтрация по одному или нескольким типам протоколов с помощью выпадающего списка или чипов фильтра.
• Фильтр по статусу: Показ только активных, отключённых или истёкших моков.
• Фильтр по тегам: Фильтрация по одному или нескольким тегам. Теги можно комбинировать с логикой И или ИЛИ.
• Опции сортировки: Сортировка по имени, дате создания, дате обновления или количеству запросов (по возрастанию или убыванию).

Организация по папкам

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

• Создание папки: Нажмите кнопку «Новая папка» для создания папки. Папки могут быть вложены на любую глубину.
• Перемещение моков: Перетаскивайте моки в папки или используйте контекстное меню для перемещения моков между папками.
• Переименование папки: Дважды щёлкните по имени папки или используйте контекстное меню для переименования.
• Удаление папки: Удаление папки перемещает её содержимое в родительскую папку (моки не удаляются).

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

Детальный просмотр мока

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

• Вкладка конфигурации: Настройки, специфичные для протокола (маршрут, метод, имя сервиса и др.), приоритет, TTL, лимиты использования и конфигурация прокси.
• Вкладка условий: Все условия сопоставления (условия по телу, заголовкам, параметрам запроса с действиями проверки).
• Вкладка ответа: Тело ответа, код состояния, заголовки и любые конфигурации OneOf-ответов.
• Вкладка экстракторов: Экстракторы хранилищ, захватывающие данные из запросов в Global, Chain или Mock хранилища.
• Вкладка логов: Недавние логи запросов с временными метками, деталями запроса и совпавшими условиями.
• Вкладка истории: История версий с просмотром различий и возможностью отката.

Со страницы деталей вы можете:

• Редактировать: Открывает мок в конструкторе для редактирования.
• Клонировать: Создаёт копию мока с новым идентификатором.
• Отключить / Включить: Временно отключить мок без его удаления.
• Удалить: Мягкое удаление мока (можно восстановить).
• Экспортировать: Скачать конфигурацию мока в формате JSON.

История версий и откат

Каждое изменение мока создаёт новую версию. Вкладка истории показывает:

• Номер версии и временную метку.
• Пользователя, внёсшего изменение.
• Представление различий, выделяющее что изменилось между версиями.
• Кнопку «Откат» для восстановления мока до любой предыдущей версии.

Откат создаёт новую версию (промежуточные версии не удаляются), поэтому вы всегда можете отменить откат.

Логи запросов по моку

Вкладка логов на странице деталей мока показывает недавние запросы, разрешённые этим моком:

• Временная метка и длительность.
• Метод запроса, путь, заголовки и тело.
• Совпавшие условия и результаты их проверки.
• Возвращённый ответ.
• Значения хранилищ, прочитанные или записанные во время разрешения.

Логи можно фильтровать по временному диапазону и экспортировать в формате JSON или CSV.

Массовые операции

Выберите несколько моков с помощью чекбоксов для выполнения массовых операций:

• Удалить: Мягкое удаление всех выбранных моков.
• Восстановить: Восстановление ранее удалённых моков.
• Теги: Добавление или удаление тегов у всех выбранных моков.
• Переместить: Перемещение выбранных моков в папку.
• Отключить / Включить: Переключение активного статуса выбранных моков.

Конструктор

Путь: /ui/constructor

Конструктор – это место, где вы создаёте и редактируете моки. Вместо того чтобы писать JSON вручную, вы заполняете пошаговую форму: выбираете протокол, задаёте маршрут, определяете условия и создаёте ответ. Это основной инструмент, который вы будете использовать в повседневной работе с Mockarty.

AI-функция: Нажмите кнопку Generate Mock для создания мока по текстовому описанию на естественном языке, или используйте Improve Mock для оптимизации существующей конфигурации. Подробнее в разделе AI-функции.

Выбор протокола

Первый шаг в создании мока — выбор протокола. Конструктор поддерживает все протоколы, которые Mockarty может имитировать:

Прямые протоколы — обслуживаются нодой Mockarty по адресу /stubs/{namespace}/...:

• HTTP: RESTful HTTP-эндпоинты с параметрами маршрута, строками запроса и заголовками.
• GraphQL: Запросы и мутации, сопоставляемые по типу и имени операции.
• SOAP: SOAP/XML-сервисы, сопоставляемые по действию и пути.
• SSE: Server-Sent Events с сопоставлением по имени события.
• MCP: Инструменты, ресурсы и промпты Model Context Protocol.

Протоколы с генерируемым сервером — моки создаются здесь, в Конструкторе, но для обслуживания реального протокольного трафика необходимо сгенерировать и запустить автономный сервер с помощью mockarty-server-generator. Сгенерированный сервер обращается к ноде Mockarty за резолвингом моков. См. Руководство по генератору серверов.

• gRPC: Унарные и потоковые gRPC-методы с protobuf-данными.
• Kafka: Полезная нагрузка сообщений для Kafka-топиков, которую резолвит Kafka-адаптер при потреблении из реального кластера Apache Kafka. Привязка по имени сервера. Нужен запущенный Kafka-кластер.
• RabbitMQ: Полезная нагрузка сообщений для очередей/обменников, которую резолвит RabbitMQ-адаптер при потреблении из реального RabbitMQ. Привязка по имени сервера. Нужен запущенный RabbitMQ.
• Socket: WebSocket, TCP и UDP коммуникация с сопоставлением по событиям.
• SMTP: Имитация SMTP-сервера электронной почты с сопоставлением по отправителю, получателю и содержимому сообщения.

После выбора протокола конструктор показывает поля конфигурации, специфичные для данного протокола.

Конфигурация HTTP-мока

Для HTTP-моков настройте следующие поля:

• Маршрут: Шаблон URL-пути для сопоставления. Поддерживает подстановочные сегменты (например, /api/users/*) и точные пути.
• HTTP-метод: HTTP-метод для сопоставления (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS или ANY для сопоставления всех методов).
• Код состояния: Код HTTP-состояния для возврата (например, 200, 201, 400, 404, 500).
• Заголовки ответа: Пары ключ-значение для заголовков ответа (Content-Type, Cache-Control и др.).
• Тело ответа: Тело ответа в формате JSON, XML, простого текста или бинарных данных. Поддерживает переменные Faker и интерполяцию JsonPath.

Конфигурация gRPC-мока

Для gRPC-моков:

• Имя сервиса: Полное имя gRPC-сервиса (например, mypackage.MyService).
• Имя метода: Имя RPC-метода (например, GetUser).
• Тело ответа: JSON-представление protobuf-сообщения ответа. Имена полей должны соответствовать proto-определению.
• Код ошибки: Опциональный код состояния gRPC для возврата (OK, CANCELLED, UNKNOWN, INVALID_ARGUMENT и др.).
• Сообщение об ошибке: Опциональное сообщение об ошибке при возврате gRPC-ошибки.

Конфигурация MCP-мока

Для MCP (Model Context Protocol) моков:

• Имя сервера: Имя MCP-сервера для маршрутизации.
• Имя инструмента: Имя MCP-инструмента для имитации.
• Схема входных данных: JSON Schema, описывающая входные параметры инструмента.
• Тело ответа: Содержимое ответа инструмента, поддерживающее переменные Faker и ссылки на хранилища.
• URI ресурса: Для моков типа ресурса — шаблон URI для сопоставления.
• Имя промпта: Для моков типа промпта — идентификатор промпта.

Конфигурация GraphQL-мока

Для GraphQL-моков:

• Тип операции: Query, Mutation или Subscription.
• Имя операции: Именованная операция для сопоставления (необязательно; если не указано, сопоставляется с любой операцией указанного типа).
• Тело ответа: Тело ответа GraphQL в стандартном формате { "data": { ... } }.
• Ответы с ошибками: Настройка ответов с ошибками, специфичными для GraphQL, в формате { "errors": [ ... ] }.

Конфигурация SOAP-мока

Для SOAP-моков:

• SOAP Action: Значение заголовка SOAPAction для сопоставления.
• Путь: Путь эндпоинта для сопоставления.
• Тело ответа: XML-конверт ответа. Поддерживает переменные Faker внутри XML-элементов.
• WSDL: Опциональное содержимое WSDL для валидации и автодополнения.

Конфигурация Kafka-мока

Для Kafka-моков:

• Топик: Имя Kafka-топика для сопоставления.
• Имя сервера: Логическое имя сервера для маршрутизации (привязывает мок к конкретному экземпляру Kafka-сервера).
• Тело ответа: Значение сообщения для возврата, поддерживающее JSON или простой текст с Faker-интерполяцией.
• Ключ: Опциональный ключ сообщения.
• Заголовки: Опциональные заголовки Kafka-сообщения.

Конфигурация RabbitMQ-мока

Для RabbitMQ-моков:

• Очередь / Обменник: Имя очереди или обменника для сопоставления.
• Ключ маршрутизации: Шаблон ключа маршрутизации.
• Имя сервера: Логическое имя сервера для маршрутизации.
• Тело ответа: Тело сообщения для возврата.
• Заголовки: Опциональные заголовки AMQP-сообщения.

Конфигурация SSE-мока

Для SSE (Server-Sent Events) моков:

• Имя события: Тип SSE-события для сопоставления.
• Имя сервера: Логическое имя сервера для маршрутизации.
• Тело ответа: Данные события для отправки.
• Повторное подключение: Опциональный интервал переподключения в миллисекундах.
• Идентификатор: Опциональный идентификатор события для отслеживания на стороне клиента.

Конфигурация Socket-мока

Для WebSocket и сырых сокет-моков:

• Имя сервера: Логическое имя сервера для маршрутизации (определяет, какой сгенерированный Socket-сервер обрабатывает этот мок).
• Имя события: Имя события для сопоставления (для маршрутизации сообщений WebSocket/TCP/UDP).
• Тело ответа: Сообщение для отправки обратно, поддерживающее JSON или текст.

Конфигурация SMTP-мока

Для SMTP-моков:

• Имя сервера: Логическое имя SMTP-сервера для маршрутизации.
• Отправитель (From): Шаблон адреса электронной почты отправителя для сопоставления.
• Получатель (To): Шаблон адреса электронной почты получателя для сопоставления.
• Тема: Тема письма для сопоставления.
• Тело ответа: SMTP-ответ для возврата, поддерживающий переменные Faker и ссылки на хранилища.

Вкладка условий

Условия определяют, когда мок должен быть выбран для данного запроса. Несколько условий можно комбинировать (все условия должны совпасть, чтобы мок был выбран — логика И).

Условия по телу (JsonPath)

Сопоставление по определённым полям в теле запроса с помощью выражений JsonPath:

• JsonPath: Выражение пути для проверки тела запроса (например, $.user.name, $.items[0].id).

• Действие проверки: Операция сравнения. Mockarty поддерживает ровно 8 действий проверки:

  Действие	Значение в JSON	Описание	Пример
  Equals	equals	Точное совпадение. Для строк сравнивает буквально. Для объектов и массивов выполняет глубокое сравнение.	$.user.role equals "admin"
  Contains	contains	Для строк – поиск подстроки. Для объектов – проверяет, что ожидаемые поля являются подмножеством. Для массивов – проверяет наличие элемента.	$.user.name contains "john"
  Not Equals	not_equals	Отрицание equals. Совпадает, когда значение НЕ равно ожидаемому.	$.status not_equals "deleted"
  Not Contains	not_contains	Отрицание contains. Совпадает, когда значение НЕ содержит ожидаемую подстроку или подмножество.	$.tags not_contains "deprecated"
  Any	any	Всегда совпадает, независимо от значения. Действует как подстановочный знак – ожидаемое значение игнорируется.	$.request_id any
  Not Empty	notEmpty	Совпадает, когда значение непустое: не null, непустая строка, непустой массив или непустой объект.	$.user.email notEmpty
  Empty	empty	Совпадает, когда значение пустое: null, пустая строка "", пустой массив [] или пустой объект {}.	$.error empty
  Matches	matches	Сопоставление с регулярным выражением. Ожидаемое значение – шаблон регулярного выражения.	$.email matches "^[a-z]+@example\\.com$"

  Примечание: Устаревший псевдоним match также принимается и работает идентично matches.

• Ожидаемое значение: Значение для сравнения.

Условия по заголовкам

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

• Имя заголовка: Имя HTTP-заголовка (регистронезависимое для HTTP, регистрозависимое для gRPC-метаданных).
• Действие проверки: Те же варианты, что и для условий по телу.
• Ожидаемое значение: Значение заголовка для сравнения.

Условия по параметрам запроса

Сопоставление по параметрам URL-запроса (только HTTP):

• Имя параметра: Ключ параметра запроса.
• Действие проверки: Те же варианты, что и для условий по телу.
• Ожидаемое значение: Значение параметра для сравнения.

Можно добавить несколько условий каждого типа. Все условия должны быть выполнены для совпадения мока.

Расширенные поля условий (только API)

При создании условий через REST API (не в веб-интерфейсе) каждый объект условия поддерживает дополнительные поля:

Пример через API:

{
  "path": "$.body.data",
  "assertAction": "equals",
  "value": "expected",
  "decode": "base64",
  "sortArray": true,
  "valueFromFile": "/templates/expected-response.json"
}

Примечание: decode, sortArray и valueFromFile не доступны в визуальном конструкторе Web UI. Используйте REST API (POST /api/v1/mocks) для установки этих полей.

Вкладка ответа

Вкладка ответа предоставляет полноценный редактор для создания ответа мока:

Редактор тела ответа

Редактор кода (с подсветкой синтаксиса для JSON и XML) для написания тела ответа. Редактор поддерживает:

• Переменные Faker: Вставка динамических данных с помощью выражений $.fake.*. Например:

  • $.fake.UUID – генерирует случайный UUID.
  • $.fake.FirstName – генерирует случайное имя.
  • $.fake.Email – генерирует случайный адрес электронной почты.
  • $.fake.Number – генерирует случайное целое число.
  • Полный список см. в Справочнике Faker-функций.

• Интерполяция JsonPath: Ссылка на данные из входящего запроса (полный синтаксис см. в Руководстве по JsonPath):

  • $.req.fieldName – извлечение поля из тела запроса.
  • $.queryParams.page – извлечение параметра запроса.
  • $.reqHeader.Authorization[0] – извлечение заголовка запроса.

• Ссылки на хранилища: Доступ к значениям из любого из трёх типов хранилищ (подробнее см. Системы хранилищ):

  • $.gS.keyName – чтение из Global Store.
  • $.cS.keyName – чтение из Chain Store.
  • $.mS.keyName – чтение из Mock Store.

• Математические и логические операции: Динамическое вычисление значений:

  • $.sum(a, b) – сложение.
  • $.multiply(a, b) – умножение.
  • $.increment(key) – атомарное увеличение счётчика в хранилище.
  • $.subtract(expr1, expr2) – вычитание expr2 из expr1 (напр. $.subtract($.gS.counter, 1) для уменьшения на 1).

Код состояния

Установка кода HTTP-состояния (или кода состояния gRPC для gRPC-моков). Интерфейс предоставляет выпадающий список с распространёнными кодами и их описаниями.

Заголовки ответа

Добавление пользовательских заголовков ответа в виде пар ключ-значение. Распространённые заголовки можно выбрать из выпадающего списка для удобства.

Задержка ответа

Настройка искусственной задержки (в миллисекундах) перед отправкой ответа. Полезно для имитации медленных сервисов и тестирования обработки таймаутов.

OneOf-ответы

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

• Упорядоченные: Ответы возвращаются в определённом порядке, циклически возвращаясь к первому после использования всех. Полезно для имитации изменений состояния (например, первый вызов возвращает «pending», второй — «completed»).
• Случайные: Случайный ответ выбирается для каждого запроса. Полезно для имитации нестабильных сервисов или переменного поведения.

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

Режим прокси

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

• Целевой URL: Базовый URL бэкенд-сервиса для перенаправления запросов.
• Задержка ответа: Настраивается на вкладке Response (в миллисекундах) для имитации сетевой задержки или медленной обработки. Применяется как к статическим, так и к проксированным ответам.
• Заголовки ответа: Переопределение или добавление заголовков через вкладку Response — полезно для настройки CORS, добавления заголовков трассировки или изменения токенов аутентификации в проксированном ответе.

Режим прокси полезен для:

• Записи и сравнения реальных и мокированных ответов.
• Тестирования поведения при таймаутах (добавление задержки к реальным ответам).
• Добавления «токсичности» к реальным сервисам (прерывистые ошибки, медленные ответы).
• Записи реальных ответов при их прохождении.
• Изменения заголовков ответа без изменения бэкенда.

Экстракторы хранилищ

Экстракторы хранилищ захватывают данные из входящих запросов и сохраняют их в один из трёх типов хранилищ для последующего использования:

• Global Store (gS): Постоянное состояние в рамках пространства имён. Значения сохраняются между запросами и моками. Идеально для счётчиков, флагов функций и общего состояния.
• Chain Store (cS): Состояние в рамках цепочки запросов. Значения сохраняются между связанными моками в рабочем процессе (например, создание -> получение -> обновление). Связываются по идентификатору цепочки.
• Mock Store (mS): Эфемерное состояние на один запрос. Значения существуют только во время обработки одного разрешения мока. Полезно для промежуточных вычислений.

Для каждого экстрактора настройте:

• Источник: Откуда извлекать данные (тело, заголовок, параметр запроса, параметр пути).
• JsonPath: Выражение JsonPath для вычисления (для извлечения из тела).
• Тип хранилища: gS, cS или mS.
• Ключ: Ключ, под которым будет сохранено извлечённое значение.

TTL и лимиты использования

Управление жизненным циклом мока:

• TTL (Time to Live): Мок автоматически истекает после указанного срока (например, 1 час, 24 часа, 7 дней). После истечения мок больше не разрешает запросы. Полезно для временных тестовых сценариев.
• Лимит использования: Мок истекает после указанного количества разрешений. После достижения лимита последующие запросы не сопоставляются. Полезно для одноразовых тестовых сценариев.

Когда мок истекает (по TTL или лимиту использования), он остаётся видимым в списке моков с пометкой «истёкший». Его можно вручную повторно включить или удалить.

Настройка приоритета

Когда несколько моков совпадают с одним и тем же запросом, приоритет определяет, какой из них будет выбран:

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

Теги

Теги обеспечивают гибкую систему категоризации:

• Добавляйте один или несколько тегов к любому моку с помощью поля ввода тегов.
• Теги имеют цветовую кодировку для визуального различения.
• Используйте теги для сквозных задач (например, «payment», «v2», «regression», «flaky»).
• Фильтруйте моки по тегу на странице моков.
• Массово применяйте теги с помощью функции массовых операций.

Неопределённые запросы

Путь: /ui/undefined

Страница неопределённых запросов показывает все входящие запросы, которые не совпали ни с одним моком и получили ответ 404. Это бесценно для обнаружения недостающих моков и понимания ожиданий ваших потребителей.

Список запросов

Основное представление показывает неопределённые запросы в таблице:

• Временная метка: Когда запрос был получен.
• Метод: HTTP-метод (или эквивалент для протокола).
• Путь / Маршрут: Запрошенный URL-путь.
• IP-адрес источника: IP-адрес клиента.
• Заголовки: Ключевые заголовки запроса (Content-Type, Authorization и др.).
• Количество: Сколько раз этот точный шаблон запроса был замечен.

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

Детали запроса

Нажмите на любой неопределённый запрос, чтобы увидеть полные детали:

• Полные заголовки запроса.
• Полное тело запроса (форматированное для JSON/XML).
• Параметры запроса.
• Параметры пути (если URL совпадает с известным шаблоном).
• Метаданные (для gRPC/MCP запросов).

Создание мока из неопределённого запроса

Самая мощная функция страницы неопределённых запросов: нажмите кнопку «Создать мок» на любом неопределённом запросе, чтобы открыть конструктор, предварительно заполненный:

• Шаблоном маршрута запроса (с обнаруженными параметрами пути).
• HTTP-методом.
• Предложенным телом ответа на основе структуры запроса.
• Обнаруженными условиями из тела запроса.

Этот рабочий процесс значительно ускоряет процесс устранения пробелов в покрытии.

Игнорирование запросов

Для запросов, которые вы не хотите имитировать (проверки здоровья от балансировщиков нагрузки, мониторинговые пробы и т.д.), нажмите «Игнорировать», чтобы скрыть их из списка. Игнорируемые шаблоны можно управлять на странице настроек.

Массовая очистка

Используйте кнопку «Очистить всё», чтобы удалить все неопределённые запросы из списка. Это полезно после массового импорта или когда вы устранили все пробелы в покрытии. Очистка необратима.

Хранилища

Путь: /ui/stores

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

Страница хранилищ предоставляет единый интерфейс для управления всеми тремя типами хранилищ. Подробную документацию по поведению и паттернам использования хранилищ см. в Системах хранилищ.

Global Store (gS)

Global Store предоставляет постоянное хранилище ключ-значение в рамках пространства имён:

• Область: Значения доступны всем мокам в пространстве имён.
• Сохранение: Значения сохраняются до явного удаления или очистки пространства имён.
• Варианты использования: Счётчики (например, порядковые номера заказов), флаги функций, общая конфигурация, состояние между моками.

Из интерфейса вы можете:

• Просмотреть все записи: Увидеть все пары ключ-значение в Global Store для текущего пространства имён.
• Создать запись: Добавить новую пару ключ-значение вручную.
• Редактировать запись: Изменить значение существующего ключа.
• Удалить запись: Удалить пару ключ-значение.
• Поиск: Фильтровать записи по имени ключа.

Ссылка в моках: Используйте $.gS.keyName в телах ответов для вставки значения ключа Global Store.

Chain Store (cS)

Chain Store предоставляет состояние в рамках цепочки запросов для многошаговых рабочих процессов:

• Область: Значения доступны мокам, принадлежащим одной цепочке (связанным идентификатором цепочки, передаваемым в заголовках или теле запроса).
• Сохранение: Значения сохраняются на протяжении цепочки.
• Варианты использования: Многошаговые рабочие процессы (создание заказа -> получение заказа -> обновление заказа -> удаление заказа), состояние сессии, контекст диалога.

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

Ссылка в моках: Используйте $.cS.keyName в телах ответов для вставки значения ключа Chain Store для текущей цепочки.

Mock Store (mS)

Mock Store предоставляет эфемерное состояние на один запрос:

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

Mock Store не отображается непосредственно в интерфейсе хранилищ (так как значения эфемерны), но документирован здесь для полноты.

Ссылка в моках: Используйте $.mS.keyName в телах ответов для вставки значений, установленных экстракторами во время обработки текущего запроса.

Использование хранилищ в ответах моков

Все три типа хранилищ можно ссылать в телах ответов моков, используя синтаксис $.gS.*, $.cS.* и $.mS.*. Например:

{
  "orderId": "$.gS.lastOrderId",
  "status": "$.cS.orderStatus",
  "processedBy": "$.mS.handlerName",
  "sequenceNumber": "$.increment(gS.orderCounter)"
}

Хранилища также можно использовать в условиях для создания логики сопоставления с сохранением состояния.

См. также: Системы хранилищ | Руководство по JsonPath

Генератор

Путь: /ui/generator

Страница генератора позволяет массово создавать моки, импортируя из различных форматов спецификаций. Вместо создания моков по одному в конструкторе импортируйте существующую API-спецификацию для генерации десятков или сотен моков за считанные секунды.

Выбор источника импорта

Генератор предоставляет навигацию по вкладкам для различных источников импорта:

OpenAPI / Swagger

Импорт моков из спецификаций OpenAPI 2.0 (Swagger) или OpenAPI 3.0/3.1:

• Загрузка файла: Загрузите файл спецификации в формате JSON или YAML с локальной машины.
• Импорт по URL: Укажите URL для загрузки спецификации (например, https://api.example.com/swagger.json).
• Возможности: Автоматическая генерация моков для всех определённых эндпоинтов с:
  • Шаблонами маршрутов с параметрами пути.
  • Сопоставлением HTTP-методов.
  • Телами ответов на основе определений схемы (со значениями Faker для реалистичных данных).
  • Маппингом кодов состояния из определённых ответов.
  • Условиями валидации тела запроса.

WSDL

Импорт SOAP-моков из WSDL файлов:

• Загрузите WSDL-файл или укажите URL.
• Генерирует моки для всех определённых операций.
• Создаёт XML-шаблоны ответов, соответствующие схеме.
• Устанавливает условия по заголовку SOAPAction.

Proto (gRPC)

Импорт gRPC-моков из файлов определений Protocol Buffer:

• Загрузите один или несколько .proto файлов.
• Генерирует моки для всех определённых сервисов и методов.
• Создаёт JSON-тела ответов, соответствующие определениям сообщений.
• Обрабатывает вложенные сообщения, перечисления и повторяющиеся поля.
• Загружайте proto-файлы как есть — option go_package необязательна, любой формат принимается, а языковые опции удаляются автоматически. Подробности в документации Генератор серверов.

GraphQL

Импорт GraphQL-моков из определений схемы:

• Загрузка файла: Загрузите файл схемы .graphql или .gql.
• Интроспекция по URL: Укажите URL GraphQL-эндпоинта, и Mockarty выполнит запрос интроспекции для обнаружения схемы.
• Генерирует моки для запросов и мутаций.
• Создаёт тела ответов, соответствующие определениям типов.

HAR (HTTP Archive)

Импорт моков из HAR-файлов, захваченных инструментами разработчика браузера или прокси-программами:

• Загрузите .har файл, экспортированный из Chrome DevTools, Firefox, Charles Proxy, Fiddler или любого HAR-совместимого инструмента.
• Каждая захваченная пара запрос/ответ становится моком.
• Сохраняет оригинальные заголовки, коды состояния и тела ответов.
• Автоматически дедуплицирует идентичные запросы.

MCP

Импорт MCP-моков из JSON-файлов конфигурации:

• Загрузите JSON-файл, описывающий MCP-инструменты, ресурсы и промпты.
• Генерирует моки со схемами входных данных и шаблонами ответов.

Socket

Импорт WebSocket или сырых сокет-моков из файлов конфигурации:

• Загрузите JSON-конфигурацию, описывающую события и форматы сообщений.
• Генерирует моки на основе событий с телами ответов.

Предварительный просмотр перед генерацией

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

• Имя и идентификатор мока.
• Протокол и маршрут/метод.
• Предварительный просмотр тела ответа.
• Предварительный просмотр условий.

Вы можете:

• Выбрать/снять выбор отдельных моков для включения или исключения их из генерации.
• Редактировать предварительный просмотр для настройки отдельных моков перед созданием.
• Проверить конфликты с существующими моками.

См. также: Генератор серверов | Справочник API

Стратегия слияния

При генерации моков, которые могут конфликтовать с существующими (тот же маршрут и метод), выберите стратегию слияния:

• Пропустить существующие: Не создавать моки, которые конфликтуют с существующими. Существующие моки остаются без изменений.
• Принудительная перезапись: Заменить существующие моки новыми сгенерированными. Старые моки мягко удаляются.

Назначение пространства имён и тегов

Перед генерацией вы можете:

• Выбрать пространство имён: Выбрать, в каком пространстве имён создавать моки (по умолчанию — текущее пространство имён).
• Назначить теги: Добавить один или несколько тегов ко всем сгенерированным мокам для лёгкой идентификации (например, «imported», «openapi», «v2.1»).

API Tester

Путь: /ui/api-tester

API Tester – это встроенная в Mockarty альтернатива инструментам вроде Postman. Вы можете отправлять запросы на любые эндпоинты (ваши моки или реальные сервисы), организовывать их в коллекции, писать автоматизированные тестовые скрипты и переключаться между окружениями – всё это не покидая Mockarty.

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

Трёхпанельная компоновка

API Tester использует трёхпанельную компоновку:

1. Левая панель (боковая панель коллекций): Иерархическое дерево коллекций и запросов. Создавайте папки внутри коллекций для логической организации запросов.

2. Центральная панель (редактор запроса): Настройка и отправка отдельных запросов. Содержит вкладки для различных аспектов запроса.

3. Правая панель (просмотр ответа): Просмотр ответа после отправки запроса, включая тело, заголовки, тайминги и результаты тестов.

Коллекции

Коллекции – это контейнеры для организации связанных запросов:

• Создание: Нажмите «Новая коллекция» для создания новой коллекции. Дайте ей описательное имя (например, «Сервис пользователей», «Процесс оплаты»).
• Переименование: Дважды щёлкните по имени коллекции для редактирования.
• Удаление: Щёлкните правой кнопкой мыши и выберите «Удалить». Коллекции можно восстановить из корзины.
• Дублирование: Создание копии всей коллекции со всеми запросами.
• Поделиться: Предоставление доступа к коллекции другим пользователям в том же пространстве имён (экспортом или назначением доступа).
• Папки: Создание папок внутри коллекций для группировки связанных запросов (например, «Аутентификация», «CRUD-операции», «Ошибочные случаи»).

Запросы

API Tester поддерживает все протоколы, которые Mockarty может имитировать:

HTTP-запросы

• URL: Введите полный URL или путь (относительно базового URL окружения).
• Метод: Выберите HTTP-метод (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS).
• Заголовки: Добавьте заголовки запроса в виде пар ключ-значение. Распространённые заголовки можно выбрать из выпадающего списка.
• Тело: Введите тело запроса в формате JSON, XML, form-data или необработанного текста. Предоставляется редактор кода с подсветкой синтаксиса.
• Аутентификация: Настройка аутентификации (None, Bearer Token, Basic Auth, API Key, OAuth 2.0).
• Параметры запроса: Добавьте параметры запроса в виде пар ключ-значение. Параметры могут включать переменные окружения.

gRPC-запросы

• Введите адрес сервера, имя сервиса и имя метода.
• Предоставьте тело запроса в формате JSON, соответствующее определению protobuf-сообщения.
• Добавьте пары ключ-значение метаданных.
• Просмотрите ответ в отформатированном JSON.

GraphQL-запросы

• Введите URL GraphQL-эндпоинта.
• Напишите запрос или мутацию в редакторе GraphQL (с подсветкой синтаксиса и автодополнением).
• Добавьте переменные в формате JSON.
• Просмотрите ответ с секциями data и errors.

SOAP-запросы

• Введите URL SOAP-эндпоинта.
• Напишите SOAP-конверт в XML-редакторе.
• Установите заголовок SOAPAction.
• Просмотрите XML-ответ.

WebSocket-запросы

• Введите URL WebSocket (ws:// или wss://).
• Подключитесь к серверу и отправляйте/получайте сообщения интерактивно.
• Просматривайте историю сообщений с временными метками и индикаторами направления.

SSE-запросы

• Введите URL SSE-эндпоинта.
• Подключитесь и просматривайте входящие события в реальном времени.
• События отображаются с их типом, данными и идентификатором.

Kafka-запросы

• Настройте адрес брокера и топик.
• Публикуйте сообщения с ключом, значением и заголовками.
• Потребляйте сообщения из топика с управлением смещением.
• Просматривайте потреблённые сообщения в прокручиваемом списке.

RabbitMQ-запросы

• Настройте URL подключения, обменник и ключ маршрутизации.
• Публикуйте сообщения с заголовками и свойствами.
• Потребляйте сообщения из очереди.
• Просматривайте потреблённые сообщения с метаданными.

MCP-запросы

• Введите URL MCP-сервера.
• Выберите имя инструмента и укажите входные параметры.
• Просмотрите ответ инструмента.

Переменные окружения

Окружения позволяют определять наборы переменных, которые могут подставляться в запросы:

• Создание окружений: Определите окружения, такие как «Local», «Staging», «Production», с различными значениями переменных.
• Синтаксис переменных: Используйте {{variableName}} в URL, заголовках, теле и параметрах запроса. Переменные заменяются значениями активного окружения в момент отправки.
• Распространённые переменные: {{baseUrl}}, {{apiKey}}, {{authToken}}, {{userId}}.
• Секретные переменные: Пометьте переменные как секретные для маскировки их значений в интерфейсе и логах.
• Активное окружение: Выберите активное окружение из выпадающего списка в верхней панели API Tester. Одновременно активно только одно окружение.

Пре-реквест скрипты

Пре-реквест скрипты выполняются перед отправкой запроса, позволяя:

• Динамически устанавливать заголовки, параметры запроса или значения тела.
• Генерировать токены аутентификации или подписи.
• Устанавливать переменные окружения или коллекции программно.
• Связывать запросы, используя данные из предыдущих ответов.

Скрипты используют JavaScript-подобный синтаксис со встроенным API для доступа к свойствам запроса и переменным окружения.

Тестовые скрипты

Тестовые скрипты выполняются после получения ответа, позволяя писать проверки:

• Проверки кода состояния: Проверка кода состояния ответа.
• Проверки тела: Проверка определённых полей в теле ответа с помощью JsonPath.
• Проверки заголовков: Проверка заголовков ответа.
• Проверки времени: Проверка, что время ответа находится в допустимых пределах.
• Извлечение переменных: Сохранение значений ответа в переменные окружения или коллекции для использования в последующих запросах.

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

История запросов

API Tester поддерживает историю всех отправленных запросов:

• Просмотр предыдущих запросов с их ответами.
• Повторная отправка исторического запроса одним нажатием.
• Сравнение ответов между несколькими выполнениями.
• История привязана к текущему пользователю и пространству имён.

Импорт

API Tester поддерживает импорт из множества форматов:

• Postman: Импорт коллекций Postman (формат JSON v2.0 и v2.1) с запросами, папками, окружениями и пре-реквест/тестовыми скриптами.
• SoapUI: Импорт проектов SoapUI с SOAP и REST запросами.
• OpenAPI: Импорт спецификации OpenAPI для генерации коллекции с одним запросом на эндпоинт.
• WSDL: Импорт WSDL-файла для генерации SOAP-запросов.
• gRPC: Импорт .proto файлов для генерации gRPC-запросов.
• GraphQL: Импорт схемы GraphQL или интроспекция эндпоинта.
• MCP: Импорт файла конфигурации MCP.
• HAR: Импорт HAR-файла для воссоздания захваченных запросов.
• Формат Mockarty: Импорт коллекций, экспортированных из другого экземпляра Mockarty.

Экспорт коллекций

Экспорт коллекций в нативном JSON-формате Mockarty для резервного копирования, обмена или миграции между окружениями.

Генерация моков из ответов

После получения ответа в API Tester нажмите «Создать мок» для генерации мока на основе:

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

Это полезно при записи реального поведения API и его преобразовании в моки.

Запуски тестов

Путь: /ui/test-runs

Страница запусков тестов показывает результаты всех тестовых запусков, включая запуски коллекций, запланированные запуски и нагрузочные тесты.

AI-функция: Нажмите кнопку Analyze Report на любом тестовом запуске для AI-диагностики ошибок и проблем производительности. Подробнее в разделе AI-функции.

Список тестовых запусков

Основное представление отображает все запуски тестов в таблице:

• Идентификатор запуска: Уникальный идентификатор тестового запуска.
• Коллекция: Тестируемая коллекция.
• Тип: Запуск коллекции, запланированный запуск или нагрузочный тест.
• Статус: Выполняется, завершён, не пройден или отменён.
• Начало / Окончание: Временные метки тестового запуска.
• Длительность: Общее время выполнения.
• Успех / Неудача: Количество пройденных и непройденных проверок.
• Инициатор: Пользователь или расписание, инициировавшие запуск.

Фильтруйте запуски тестов по статусу, типу, коллекции или диапазону дат.

Детальный отчёт о тесте

Нажмите на любой тестовый запуск, чтобы увидеть детальный отчёт:

• Сводка: Общее количество пройденных/непройденных, время выполнения и статус.
• Результаты по каждому запросу: Каждый запрос в коллекции с:
  • Деталями запроса (метод, URL, тело).
  • Деталями ответа (код состояния, тело, заголовки).
  • Результатами проверок (пройдено/не пройдено с ожидаемыми и фактическими значениями).
  • Временем выполнения.
• Детали ошибок: Для непройденных проверок — подробные сообщения об ошибках, объясняющие, что пошло не так.
• Представление временной шкалы: Визуальная временная шкала, показывающая порядок выполнения запросов и тайминги.

Оценка APDEX

Для нагрузочных тестовых запусков (см. Нагрузочное тестирование) отчёт включает оценку APDEX (Application Performance Index):

• Оценка: Значение от 0 до 1, где 1 — идеальная удовлетворённость.
• Рейтинг: Отлично (> 0.94), Хорошо (> 0.85), Удовлетворительно (> 0.70), Плохо (> 0.50), Неприемлемо (<= 0.50).
• Детализация: Количество удовлетворённых, терпимых и разочарованных ответов на основе настроенного порога.
• Порог (T): Целевое время ответа в миллисекундах. Ответы быстрее T — «удовлетворённые», быстрее 4T — «терпимые», медленнее 4T — «разочарованные».

Статистика задержек

Отчёты нагрузочных тестов включают детальную статистику задержек:

• Среднее: Среднее время ответа по всем запросам.
• Медиана (p50): Время ответа 50-го перцентиля.
• p95: 95-й перцентиль (95% запросов были быстрее этого значения).
• p99: 99-й перцентиль (99% запросов были быстрее этого значения).
• Мин / Макс: Самое быстрое и самое медленное время ответа.
• Стандартное отклонение (StdDev): Мера разброса времени ответа.
• Коэффициент вариации (CV): StdDev в процентах от среднего, показывающий стабильность.

Экспорт отчётов

Экспорт отчётов о тестах в формате JSON:

• JSON: Машиночитаемый формат для интеграции с CI/CD и распространения среди заинтересованных сторон.

Отмена запущенных тестов

Для длительных тестов нажмите кнопку «Отмена», чтобы остановить выполнение. Частичные результаты сохраняются и могут быть просмотрены в отчёте.

Тест-кейсы

Путь: /ui/test-cases

Раздел «Тест-кейсы» — встроенная в Mockarty система управления тестированием (TMS). Позволяет организовывать ручные и автоматизированные тест-кейсы в иерархию папок, отслеживать их выполнение и интегрировать с рабочими процессами команды.

Ключевые возможности

• Дерево папок (до 8 уровней вложенности) — отражает структуру проекта или модулей. Перетаскивание для изменения порядка, контекстное меню по правой кнопке. Множественный выбор через Ctrl+Click для групповых операций.
• Конструктор кейсов — шаги с полями «Действие» и «Ожидаемый результат», вложения, зависимости между шагами, режим выполнения (авто / ручной / полуавтоматический).
• Общие шаги — переиспользуемые фрагменты шагов, встраиваемые по ссылке в несколько кейсов. Изменения распространяются автоматически.
• История версий — каждое сохранение создаёт версионный снимок. Сравнение любых двух версий и откат к любому предыдущему состоянию.
• Рабочий процесс ревью — отправка кейса на проверку, комментарии, одобрение или отклонение. Панель ревью показывает историю и исполнителей.
• Ссылки на внешние трекеры — связывание кейсов с задачами Jira, GitHub, Linear или GitLab. Заголовки и статусы привязанных задач отображаются как живые чипы.

Запуск тест-кейсов

Тест-кейсы можно выполнять:

• Разово — из конструктора кнопкой Запустить.
• В составе тест-плана — добавьте тип элемента test_case в план.
• Пакетом (синтетический план) — выберите несколько кейсов и запустите групповой прогон.

Результаты попадают в общий отчёт о прогоне тестов наравне с другими типами тестов.

Подробнее: Управление тест-кейсами · Шаги тест-кейсов · Runtime-вид прогона · Вложения

Тест-планы

Путь: /ui/test-plans

Тест-планы оркестрируют любую комбинацию типов тестов — функциональных (API Tester), нагрузочных (k6), фаззинговых, хаос- и контрактных — в единый повторяемый воркфлоу. Каждый план получает стабильный числовой ID (#42), по которому CI/CD-пайплайны могут ссылаться на него.

Что входит в план

• Элементы — отдельные шаги плана. Каждый элемент указывает на ресурс (коллекцию API Tester, конфиг нагрузочного теста, конфиг фаззинга и т.д.) и имеет порядок и опциональные зависимости.
• Режим выполнения — fifo (последовательно, по умолчанию), parallel (все элементы одновременно) или dag (учитывает dependsOn и гейты).
• Гейты — условия, блокирующие следующий элемент при неудаче предыдущего (например, остановить нагрузочный тест, если smoke-тест упал).
• Расписания — привязка одного или нескольких расписаний (cron / разовых / интервальных) для автоматического запуска.
• Переопределения — перепостановка переменных и выбор подмножества элементов для целевых повторных прогонов.

Запуск плана

Нажмите Запустить в детальном виде плана, или запустите через CLI (mockarty-cli testplan run) или API (POST /api/v1/test-plans/:id/run). Вид прогона показывает живой прогресс с состоянием каждого элемента и единым потоком логов. Итоговый отчёт объединяет результаты всех элементов в единый Allure-совместимый экспорт.

Подробнее: Тест-планы · Расширенные тест-планы · Тест-планы в CI/CD · Вид прогона · Отчёт о прогоне

Рекордер

Путь: /ui/recorder

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

AI-функция: Нажмите кнопку Analyze Traffic на записанных сессиях для AI-анализа трафика, аудита безопасности или обнаружения сценариев. Подробнее в разделе AI-функции.

Управление сессиями

Запись организована в сессии:

• Старт: Нажмите «Начать запись» для начала новой сессии. Настройте режим записи и порт.
• Стоп: Нажмите «Стоп» для завершения текущей сессии записи. Захваченные записи сохраняются.
• Перезапуск: Остановить и немедленно начать новую сессию с той же конфигурацией.
• Удаление: Удалить сессию и все её захваченные записи.

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

Режимы записи

Режим обратного прокси

Mockarty работает как обратный прокси перед целевым сервисом:

• Настройте целевой URL (реальный бэкенд-сервис).
• Все запросы, отправленные на порт рекордера, перенаправляются на целевой сервис.
• И запрос, и ответ захватываются.
• Ответ целевого сервиса возвращается клиенту без изменений (если не настроены правила модификации заголовков).

Режим прямого прокси

Mockarty работает как HTTP(S) прямой прокси:

• Настройте ваш клиент (браузер, приложение или набор тестов) на использование Mockarty в качестве HTTP-прокси.
• Весь HTTP-трафик захватывается при прохождении.
• Для HTTPS-трафика Mockarty выполняет MITM-перехват с использованием сгенерированного сертификата.

Типы захватываемого трафика

Рекордер захватывает:

• HTTP запросы/ответы: Метод, URL, заголовки, тело, код состояния, тайминги.
• WebSocket сообщения: Установление соединения, отдельные сообщения (в обоих направлениях), закрытие соединения.
• SSE события: Тип события, данные, идентификатор и значения повторного подключения.

Список записей

Захваченные записи отображаются в списке:

• Временная метка: Когда запись была захвачена.
• Метод: HTTP-метод или индикатор протокола.
• URL: Полный URL запроса.
• Статус: Код состояния ответа (цветовая кодировка: зелёный для 2xx, жёлтый для 3xx, красный для 4xx/5xx).
• Длительность: Время ответа в миллисекундах.
• Размер: Размер тела ответа.

Записи можно фильтровать по методу, диапазону кодов состояния, шаблону URL и типу контента.

Детали записи

Нажмите на любую запись, чтобы увидеть полные детали:

• Вкладка запроса: Метод, URL, заголовки (форматированная таблица), параметры запроса и тело (с подсветкой синтаксиса).
• Вкладка ответа: Код состояния, заголовки и тело (с подсветкой синтаксиса для JSON/XML/HTML).
• Вкладка таймингов: DNS-поиск, TCP-соединение, TLS-рукопожатие, время до первого байта и общая длительность.

Правила модификации заголовков/метаданных

Настройте правила для модификации заголовков при прохождении трафика через рекордер:

• Добавить заголовок: Внедрить новый заголовок в запросы или ответы.
• Удалить заголовок: Удалить заголовок из запросов или ответов.
• Заменить заголовок: Изменить значение заголовка с помощью замены строки или регулярного выражения.

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

Управление MITM-сертификатами

Для записи HTTPS в режиме прямого прокси:

• Генерация CA-сертификата: Mockarty генерирует корневой CA-сертификат для MITM-перехвата.
• Загрузка CA-сертификата: Загрузите сертификат для установки в браузер или системное хранилище доверия.
• Статус сертификата: Просмотр срока действия и отпечатка текущего сертификата.

Настройка пула портов

Настройте диапазон портов, доступных для сессий рекордера. Каждая сессия требует выделенного порта для проксирования трафика.

Параметры экспорта

Захваченный трафик можно экспортировать в нескольких форматах:

• HAR-файл: Стандартный формат HTTP Archive, совместимый с инструментами разработчика браузера, Charles Proxy и другими инструментами.
• Скрипт нагрузочного тестирования: Генерация скрипта нагрузочного тестирования из захваченного трафика.
• Тестовый скрипт с проверками: Генерация тестовых скриптов API Tester с проверками на основе захваченных ответов.
• Коллекция API Tester: Создание коллекции API Tester с одним запросом на каждую захваченную запись.

Создание моков из записей

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

• Маршрута, метода и заголовков захваченного запроса.
• Кода состояния, заголовков и тела захваченного ответа.
• Автоматически обнаруженных параметров пути.

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

См. также: Рекордер трафика

Обновления в реальном времени

Во время активной сессии записи новые записи появляются в списке в реальном времени через WebSocket-обновления. Обновление страницы не требуется. Живой индикатор показывает статус записи и количество записей.

Fuzzing

Путь: /ui/fuzzing

Фаззинг – это техника автоматизированного тестирования безопасности. Вместо ручного перебора граничных случаев Mockarty отправляет тысячи сгенерированных или случайных входных данных на эндпоинты вашего API и отслеживает неожиданное поведение – сбои, утечки ошибок или уязвимости безопасности. Это быстрый способ найти ошибки, которые обычное тестирование часто пропускает.

AI-функция: Нажмите кнопку Analyze Finding на любой находке фаззинга для AI-анализа первопричин и рекомендаций по устранению. Подробнее в разделе AI-функции.

Конфигурации фаззинга

Создание и управление конфигурациями фаззинг-тестов:

• Целевой URL: Эндпоинт для фаззинга.
• Метод: HTTP-метод (или тип протокола для не-HTTP целей).
• Позиции полезной нагрузки: Отметьте позиции в запросе (URL, заголовки, тело), куда будут внедряться фаззинг-данные. Позиции отмечаются синтаксисом-заполнителями.
• Базовый запрос: Шаблон запроса, в который будут внедряться фаззинг-данные.
• Аутентификация: Настройка аутентификации для целевого сервиса (Bearer token, Basic Auth, API Key и др.).
• Ограничение частоты: Управление частотой запросов, чтобы не перегружать целевой сервис.
• Таймаут: Максимальное время ответа, после которого запрос считается тайм-аутом.

Категории полезных нагрузок

Mockarty включает встроенные словари полезных нагрузок для распространённых категорий уязвимостей:

• SQL Injection: Фрагменты SQL-синтаксиса, UNION-based полезные нагрузки, слепые SQL Injection паттерны, временн*ые полезные нагрузки.
• XSS (Cross-Site Scripting): Script-теги, обработчики событий, закодированные полезные нагрузки, полиглот XSS-строки.
• Buffer Overflow: Длинные строки, повторяющиеся символы, спецификаторы формат-строк.
• Path Traversal: Последовательности обхода каталогов (../, ..%2f), абсолютные пути, инъекции нулевого байта.
• Command Injection: Метасимволы оболочки, разделители команд, выполнение через обратные кавычки, цепочки через pipe.
• Format Strings: Спецификаторы формата в стиле printf, атаки через ширину/точность.
• Header Injection: CRLF Injection, полезные нагрузки для контрабанды заголовков.
• XXE (XML External Entity): Объявления сущностей, внешние ссылки, параметрические сущности.
• SSRF (Server-Side Request Forgery): Внутренние IP-адреса, URL облачных метаданных, полезные нагрузки DNS rebinding.
• Authentication Bypass: Учётные данные по умолчанию, манипуляции с JWT, токены фиксации сессии.

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

Импорт целей

Быстрая настройка целей фаззинга путём импорта из существующих источников:

• Команды cURL: Вставьте команду cURL для извлечения URL, метода, заголовков и тела.
• Спецификация OpenAPI: Импортируйте API-спецификацию и выберите эндпоинты для фаззинга.
• Коллекции API Tester: Выберите запросы из ваших коллекций API Tester в качестве целей фаззинга.
• Сессии рекордера: Используйте захваченный трафик как основу для фаззинга.
• Существующие моки: Выберите моки и проведите фаззинг их эндпоинтов.

Обнаружение, специфичное для протокола

• Интроспекция GraphQL: Автоматическое обнаружение запросов, мутаций и типов путём выполнения запроса интроспекции к GraphQL-эндпоинту.
• Рефлексия gRPC: Обнаружение сервисов и методов с помощью рефлексии gRPC-сервера.

Запуск фаззинг-тестов

Запуск фаззинг-теста из конфигурации:

• Мониторинг прогресса: Индикатор прогресса в реальном времени показывает процент завершения, количество отправленных запросов и прошедшее время.
• Статистика в реальном времени: Просмотр текущей частоты запросов, распределения кодов ответов и количества ошибок во время выполнения теста.
• Остановка: Остановка выполняемого фаззинг-теста с сохранением частичных результатов.

аномалии

После завершения фаззинг-теста (или во время выполнения) аномалии перечислены со следующей информацией:

• Серьёзность: Критическая, Высокая, Средняя, Низкая или Информационная.
• Категория: Тип обнаруженной уязвимости (SQL Injection, XSS и др.).
• Полезная нагрузка: Точная полезная нагрузка, вызвавшая находку.
• Ответ: Код состояния ответа и фрагмент тела.
• Доказательство: Конкретные паттерны в ответе, указывающие на потенциальную уязвимость (сообщения об ошибках, трассировки стека, отражённый ввод).

Сортировка находок

Проверка и классификация каждой аномалии:

• Подтверждено: Отметить как реальную уязвимость, которую необходимо устранить.
• Ложное срабатывание: Отметить как ложную тревогу (поведение ожидаемо или безвредно).
• Проигнорировано: Отклонить находку без классификации.

Статус сортировки сохраняется между сессиями и может быть экспортирован вместе с отчётом о находках.

Воспроизведение находок

Нажмите «Воспроизвести» на любой находке, чтобы повторно отправить точный запрос, вызвавший её. Это полезно для:

• Проверки воспроизводимости аномалии.
• Тестирования после применения исправления.
• Более детального исследования поведения.

Экспорт отчёта о находках

Экспорт всех находок (или отфильтрованных подмножеств) в виде:

• JSON: Машиночитаемый формат для интеграции с инструментами безопасности и CI/CD пайплайнами.
• CSV: Формат, совместимый с электронными таблицами, для отслеживания и отчётности.

Запланированные фаззинг-запуски

Настройте фаззинг для запуска по расписанию (ежедневно, еженедельно или по пользовательскому cron-выражению). Запланированные запуски:

• Выполняются автоматически в настроенное время.
• Отправляют уведомление по завершении (при включённых email-уведомлениях).
• Результаты доступны на страницах Fuzzing и запусков тестов.
• Сравнивайте аномалии между запусками для отслеживания состояния безопасности во времени.

Режим быстрого фаззинга

Для быстрого тестирования без детальной настройки:

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

См. также: Фаззинг API

Контрактное тестирование

Путь: /ui/contract-testing

Preview: Эта функция находится в состоянии preview/beta. Она скрыта по умолчанию и может быть включена в настройках пользователя или через флаги функций.

Контрактное тестирование проверяет соответствие моков API-спецификациям, управляет контрактами потребителей и обеспечивает двунаправленные проверки безопасности деплоя. Поддерживает все протоколы: OpenAPI, gRPC, GraphQL, MCP, AsyncAPI, WSDL.

Вкладки

Страница контрактного тестирования содержит 6 вкладок:

1. Валидация моков

Загрузите API-спецификацию и проверьте, что моки ей соответствуют. Поддерживает все типы спецификаций. Выбор моков по тегам или через файловый браузер. Доступен ИИ-анализ результатов.

2. Можно деплоить?

Двунаправленная проверка готовности к деплою:

• Как потребитель: Выберите контракт и проверьте совместимость со всеми провайдерами. Отвечает: «сломают ли меня мои зависимости?»
• Как провайдер: Выберите API из реестра и опционально вставьте новую спеку. Отвечает: «сломаю ли я потребителей?» Полезно для анализа влияния перед деплоем.

3. Совместимость

Сравнение двух версий API-спецификации для выявления ломающих изменений. Два режима:

• Вставить: Вставить старую и новую спеки рядом.
• Из реестра: Выбрать API из реестра и сравнить две версии из истории.

Поддерживает все протоколы. Показывает структурный diff с индикаторами ломающих изменений.

4. Контракты

Управление контрактами потребителей в двух форматах:

• Контракты Mockarty (пакеты зависимостей): Создание через 4-шаговый визуальный визард — выбор провайдеров из реестра, выбор эндпоинтов, настройка обязательных полей, проверка и сохранение. Один контракт может покрывать несколько API провайдеров.
• Pact v3: Стандартный формат, совместимый с Pact Broker, для команд использующих pact-js, pact-jvm, pact-python.

Оба формата участвуют в единой матрице Can-I-Deploy и панели здоровья.

5. Реестр API

Внутренний маркетплейс API, где команды публикуют спецификации. Функции:

• Публикация API с контролем видимости (публичные, внутренние, ограниченные).
• Адаптивный UX под тип протокола.
• Авто-обновление для URL-записей — Mockarty периодически получает свежие спеки.
• История версий с визуализацией дифов и откатом.
• Процесс ревью (черновик → на проверке → активный/устаревший).
• Подписка на изменения API с уведомлениями о ломающих изменениях.

6. История и здоровье

• История: Таймлайн всех запусков валидации с раскрываемыми результатами, график трендов (60 дней).
• Панель здоровья: Статус-светофор (зелёный/жёлтый/красный) для каждого контракта.
• Мониторы: Настройка cron-валидаций с уведомлениями.

Визард создания контракта

Визард проводит через 4 шага:

1. Выбор провайдеров — поиск и выбор API из реестра (любой протокол).
2. Выбор эндпоинтов — просмотр распарсенных эндпоинтов, отметка нужных.
3. Настройка требований — обязательные поля ответа, ожидаемые статус-коды, типы. Поля из спеки предзаполнены.
4. Проверка и сохранение — имя контракта, обзор, сохранение.

ИИ-функции

• ИИ-анализ: ИИ-анализ результатов валидации с рекомендациями (отображается как markdown).
• Авто-триаж: Автоматическая классификация находок по серьёзности и приоритету.

См. также: Руководство по контрактному тестированию

Хаос-инженерия

Путь: /ui/chaos

Preview: Эта функция находится в состоянии preview/beta. Она скрыта по умолчанию и может быть включена в настройках пользователя или через флаги функций. Требуется PRO-лицензия и подключённый кластер Kubernetes.

Хаос-инженерия позволяет тестировать отказоустойчивость системы путём внедрения контролируемых сбоев в вашу инфраструктуру Kubernetes. Вместо ожидания аварий для обнаружения слабых мест вы проактивно проводите эксперименты, которые уничтожают поды, внедряют сетевые задержки, нарушают DNS или создают нагрузку на ресурсы – и наблюдаете, восстанавливается ли система корректно.

Топология кластера

Первая вкладка показывает визуализацию вашего Kubernetes-кластера в реальном времени с помощью интерактивного графа (на базе Cytoscape.js):

• Пространства имён, деплойменты, поды: Отображаются как узлы направленного графа с автоматической компоновкой.
• Индикаторы здоровья: Узлы окрашены по статусу (зелёный = здоров, жёлтый = деградация, красный = отказ).
• Выбор: Клик по любому узлу показывает его детали (метки, использование ресурсов, события) в боковой панели.
• Масштабирование и навигация: Используйте колёсико мыши или экранные элементы управления для навигации по большим кластерам.
• Обновление: Топология обновляется по запросу или с настраиваемым интервалом.

Типы экспериментов

Mockarty поддерживает 12 типов внедрения сбоев:

Создание эксперимента

Для создания нового хаос-эксперимента:

1. Выберите тип сбоя: Выберите из 12 поддерживаемых типов.
2. Определите цели: Выберите целевые поды по пространству имён, селектору меток или конкретным именам подов. Установите ограничение радиуса поражения (например, затронуть не более 50% подходящих подов).
3. Настройте параметры: Каждый тип сбоя имеет специфические параметры (например, длительность задержки в миллисекундах, процент потери пакетов, количество ядер CPU для нагрузки).
4. Установите длительность: Как долго сбой должен быть активен до автоматического отката.
5. Добавьте steady-state пробы: Определите проверки здоровья, которые валидируют систему во время и после эксперимента (HTTP-пробы, запросы метрик Prometheus, проверки количества подов).
6. Защитные механизмы: Настройте списки запрещённых пространств имён, максимальный радиус поражения и условия автоматического отката.

Запуск экспериментов

Запустите эксперимент и отслеживайте его в реальном времени:

• Временная шкала прогресса: Визуальная шкала, показывающая начало внедрения сбоев, проверки steady-state и откат.
• Результаты проб в реальном времени: Steady-state пробы выполняются непрерывно и отображают статус pass/fail по мере продвижения эксперимента.
• Экстренная остановка: Заметная красная кнопка немедленно откатывает все активные сбои в случае проблем.
• Автоматический откат: Эксперименты автоматически откатываются по истечении длительности или при провале steady-state пробы (настраивается).

Результаты экспериментов

После завершения эксперимента результаты включают:

• Вердикт: Pass (система оставалась здоровой) или Fail (steady-state пробы обнаружили деградацию).
• Временная шкала: Полный журнал событий с временными метками для внедрения сбоев, проверок проб и отката.
• Детали проб: Результаты каждой пробы с ожидаемыми и фактическими значениями.
• Затронутые ресурсы: Список подов/контейнеров, которые были целями эксперимента.
• Время восстановления: Сколько времени потребовалось системе для возврата в устойчивое состояние после отката.

Пресеты

Mockarty включает готовые пресеты экспериментов для распространённых сценариев:

• Chaos Monkey: Случайное уничтожение пода в выбранном пространстве имён.
• Network Partition: Изоляция сервиса от его зависимостей.
• Scale to Zero: Уничтожение всех подов деплоймента и измерение времени восстановления.
• Slow Network: Внедрение возрастающей задержки для обнаружения порогов таймаутов.
• Resource Starvation: Нагрузка CPU и памяти для проверки автомасштабирования.

Пресеты можно настроить перед запуском и сохранить как новые шаблоны.

Планирование

Настройка экспериментов для запуска по расписанию:

• Cron-выражения: Стандартный синтаксис cron для гибкого планирования.
• Уведомления: Получайте оповещения через настроенные каналы уведомлений при завершении экспериментов.
• Анализ трендов: Сравнивайте результаты между запланированными запусками для отслеживания улучшений отказоустойчивости.

Отчёты

Экспорт результатов экспериментов в нескольких форматах:

• JSON: Машиночитаемый формат для интеграции с CI/CD.
• HTML: Человекочитаемый отчёт с графиками и визуализацией временной шкалы.
• JUnit XML: Совместим с парсерами результатов тестов CI/CD (Jenkins, GitLab CI и др.).

См. также: Руководство по хаос-инженерии

Утилиты

Путь: /ui/utils

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

Форматирование и валидация JSON

• Вставьте или введите JSON в поле ввода.
• Нажмите «Форматировать» для красивого отображения JSON с правильными отступами.
• Нажмите «Минифицировать» для сжатия JSON в одну строку.
• Ошибки валидации подсвечиваются с номерами строк и описанием ошибок.
• Копирование отформатированного результата в буфер обмена одним нажатием.

Генератор UUID

• Генерация случайных значений UUID v4.
• Генерация нескольких UUID за раз (настраиваемое количество).
• Копирование отдельных UUID или всего списка в буфер обмена.

Кодировщик/декодировщик Base64

• Кодирование: Вставьте обычный текст и закодируйте его в Base64.
• Декодирование: Вставьте строку Base64 и декодируйте её в обычный текст.
• Поддержка стандартного и URL-safe вариантов Base64.
• Обработка многострочного ввода.

Кодировщик/декодировщик URL

• Кодирование: Кодирование специальных символов в URL или компоненте URL.
• Декодирование: Декодирование процентно-закодированных символов обратно в исходную форму.
• Кодирование/декодирование полного URL или отдельных компонентов.

Декодировщик JWT

• Вставьте JWT (JSON Web Token) для декодирования его заголовка, полезной нагрузки и подписи.
• Заголовок и полезная нагрузка отображаются как отформатированный JSON.
• Время истечения показывается в человекочитаемом формате с указанием, истёк ли токен.
• Проверка подписи не выполняется (декодировщик не валидирует подписи).

Конвертер временных меток

• Конвертация между Unix-временными метками (секунды и миллисекунды) и человекочитаемыми форматами даты/времени.
• Отображение текущей временной метки с обновлением в реальном времени.
• Поддержка нескольких форматов даты/времени (ISO 8601, RFC 2822, пользовательский).
• Конвертация с учётом часовых поясов с селектором часового пояса.

Генераторы хэшей

Генерация криптографических хэшей из входного текста:

• MD5: 128-битный хэш (не рекомендуется для безопасности, полезен для контрольных сумм).
• SHA-1: 160-битный хэш.
• SHA-256: 256-битный хэш (рекомендуется для общего использования).

Ввод можно вставить или ввести. Хэш вычисляется в реальном времени по мере ввода.

Шаблоны

Путь: /ui/templates

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

Управление файлами шаблонов

• Загрузка: Загрузите файлы .tmpl с локальной машины. Шаблоны хранятся в базе данных Mockarty и доступны во всём пространстве имён.
• Скачивание: Скачайте существующие шаблоны для редактирования или резервного копирования.
• Удаление: Удалите шаблоны, которые больше не нужны.
• Предварительный просмотр: Просмотр содержимого шаблона с подсветкой синтаксиса.

Справка по шаблонам

Шаблоны используют синтаксис text/template Go с пользовательскими функциями Mockarty:

• Функции Faker: Все функции Faker, доступные во встроенных телах ответов, также доступны в шаблонах (например, {{fake "UUID"}}, {{fake "FirstName"}}).
• Интерполяция JsonPath: Доступ к данным запроса внутри шаблонов (например, {{jsonpath "$.user.id"}}).
• Ссылки на хранилища: Чтение и запись значений хранилищ в шаблонах.
• Управляющие конструкции: Использование условий Go-шаблонов ({{if}}, {{else}}), циклов ({{range}}) и других конструкций для сложной логики ответов.
• Композиция шаблонов: Включение одного шаблона в другой с помощью {{template "name"}}.

Использование шаблонов в моках

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

Настройки

Путь: /ui/settings

Ограничение доступа: Страница настроек видна только пользователям с системной ролью Admin или Support. Пользователи со стандартной ролью «User» или «Auditor» не видят пункт «Настройки» в боковой панели и не могут получить доступ к этой странице.

Страница настроек – это место, где вы настраиваете поведение вашего пространства имён: кто имеет доступ, как долго хранятся логи, какие вебхуки срабатывают при событиях и как настроен AI-ассистент. Владельцы пространств имён и администраторы используют эту страницу часто.

Настройки привязаны к текущему выбранному пространству имён и влияют на всех пользователей в нём.

Управление пространствами имён

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

Управление пользователями в пространстве имён

Управление тем, какие пользователи имеют доступ к текущему пространству имён и их ролями:

• Просмотр участников: Просмотр всех пользователей, назначенных текущему пространству имён, с их ролями.
• Добавление пользователя: Пригласить пользователя в пространство имён, выбрав его учётную запись и назначив роль.
• Изменение роли: Обновить роль пользователя в пространстве имён.
• Удаление пользователя: Отозвать доступ пользователя к пространству имён.

Роли пространства имён:

Политики очистки

Настройка автоматической очистки временных данных:

• Хранение логов запросов: Как долго хранить логи запросов моков (например, 7 дней, 30 дней, бессрочно).
• Хранение неопределённых запросов: Как долго хранить записи несопоставленных запросов.
• Хранение отчётов о тестах: Как долго хранить результаты запусков тестов.
• Обработка истёкших моков: Автоматически удалять или архивировать моки, превысившие TTL или лимиты использования.

Вебхуки

Настройка HTTP-обратных вызовов, срабатывающих при определённых событиях (подробнее см. Вебхуки и обратные вызовы):

• Типы событий: Разрешение мока, создание мока, удаление мока, завершение запуска тестов, получение неопределённого запроса.
• Целевой URL: URL для отправки POST-запроса вебхука.
• Заголовки: Пользовательские заголовки для включения в запрос вебхука (например, токены аутентификации).
• Формат полезной нагрузки: JSON-полезная нагрузка с деталями события, временными метками и данными соответствующего ресурса.
• Политика повторных попыток: Количество повторных попыток и стратегия отсрочки для неудачных доставок вебхуков.

Каналы уведомлений

Настройка каналов доставки уведомлений для системных событий, оповещений и результатов запусков тестов:

• Telegram: Подключение Telegram-бота для получения уведомлений в чат или группу.
• Email: Настройка email-уведомлений через SMTP для пользователей и команд.
• Вебхуки: Отправка данных о событиях на внешние HTTP-эндпоинты.
• Slack: Отправка уведомлений в каналы Slack через входящие вебхуки.
• Discord: Отправка уведомлений в каналы Discord через вебхуки.

Каждый канал можно включить или отключить независимо, а события можно направлять в определённые каналы. Подробнее см. Каналы уведомлений.

Конфигурация LLM

Настройка параметров AI-ассистента (чата с ассистентом):

• Выбор модели: Выберите модель LLM для использования (OpenAI, Claude, OpenRouter или пользовательский провайдер).
• API-ключ: Укажите API-ключ для выбранного LLM-провайдера.
• Температура: Настройка креативности/случайности AI-ответов (0.0 для детерминированных, 1.0 для креативных).
• Настройки контекста: Настройка объёма контекста моков, получаемого AI-ассистентом.

Интеграции

Управление токенами интеграции для runner-агентов и mock-резолверов (см. Руководство по интеграциям и Архитектура масштабирования для настройки многоузлового развёртывания):

• Создание токена: Генерация нового токена интеграции (формат mki_*) для runner-агента или mock-резолвера.
• Просмотр токенов: Просмотр всех активных токенов интеграции с их типом, областью действия и временной меткой последнего использования.
• Отзыв токена: Немедленное отключение токена интеграции.
• Типы токенов: Test runner (для выполнения тестовых запусков на удалённых агентах), Mock resolver (для распределённого разрешения моков), Orchestrator (для многоузловой координации).

Панель администратора

Путь: /ui/admin

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

Управление пользователями

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

• Создание пользователя: Добавление новых учётных записей с именем пользователя, электронной почтой и начальным паролем.
• Редактирование пользователя: Обновление информации профиля, электронной почты и отображаемого имени пользователя.
• Установка пароля: Сброс пароля пользователя (генерация временного пароля или отправка ссылки для сброса).
• Отключить / Включить: Временное отключение учётной записи пользователя без её удаления. Отключённые пользователи не могут войти в систему.
• Удаление пользователя: Полное удаление учётной записи пользователя и всех связанных данных.
• Системные роли: Назначение системных ролей пользователям:

Управление пространствами имён

Системное администрирование пространств имён:

• Просмотр всех пространств имён: Просмотр всех пространств имён в системе с количеством участников и статистикой ресурсов.
• Создание пространства имён: Создание нового пространства имён и назначение начального владельца.
• Удаление пространства имён: Мягкое удаление пространства имён и всех его ресурсов. Удалённые пространства имён могут быть восстановлены в течение периода хранения.
• Восстановление пространства имён: Восстановление ранее удалённого пространства имён со всеми его ресурсами.

Настройки очистки

Настройка глобальных политик очистки, применяемых ко всем пространствам имён:

• Хранение логов: Период хранения по умолчанию для логов запросов моков.
• Хранение неопределённых запросов: Период хранения по умолчанию для несопоставленных запросов.
• Хранение отчётов о тестах: Период хранения по умолчанию для результатов запусков тестов.
• Расписание очистки: Настройка времени выполнения задач очистки (cron-выражение).

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

Журналы аудита

Просмотр и экспорт журнала аудита системы:

• Типы событий: Входы пользователей, операции CRUD с моками, изменения пространств имён, административные действия, использование API-токенов.
• Фильтры: Фильтрация по пользователю, типу события, диапазону дат и пространству имён.
• Экспорт: Загрузка журналов аудита в формате CSV или JSON для соответствия требованиям и отчётности.
• Хранение: Журналы аудита хранятся независимо от других политик очистки.

Выполнение задач

Просмотр истории запланированных фоновых задач:

• Типы задач: Очистка, резервное копирование, запланированные тесты, проверки здоровья.
• Статус: Завершена, не удалась, выполняется или в очереди.
• Детали: Время выполнения, длительность и сообщения об ошибках.
• Ручной запуск: Запуск задачи вручную вне расписания.

Здоровье базы данных

Мониторинг и обслуживание здоровья базы данных:

• Статус индексов: Просмотр всех индексов базы данных с их размером, статистикой использования и состоянием.
• Статистика таблиц: Количество строк, размеры таблиц, количество мёртвых кортежей и время последнего vacuum/analyze.
• Рекомендации по обслуживанию: Предложения по оптимизации индексов, очистке vacuum и другим задачам обслуживания.
• Пул соединений: Текущее использование и конфигурация пула соединений.

Конфигурация электронной почты

Настройка email-уведомлений (требуется EMAIL_ENABLED=true):

• Настройки SMTP: Хост, порт, имя пользователя, пароль и конфигурация TLS.
• Адрес отправителя: Адрес «From» для всех исходящих писем.
• Тестовое письмо: Отправка тестового письма для проверки конфигурации SMTP.
• Шаблоны писем: Настройка HTML-шаблонов, используемых для уведомительных писем (сброс пароля, коды 2FA, приглашения, уведомления о запусках тестов).

Профили LLM

Настройка глобальных профилей AI-моделей:

• Настройки провайдера: Конечные точки API, ключи и идентификаторы моделей для поддерживаемых LLM-провайдеров.
• Модель по умолчанию: Установка модели по умолчанию, используемой, когда пространства имён не указывают собственную.
• Отслеживание использования: Просмотр использования токенов и оценки стоимости по пространствам имён.
• Лимиты частоты: Настройка лимитов частоты вызовов LLM API по пространствам имён.

Настройки телеметрии

Настройка интеграции с OpenTelemetry:

• Экспортёр: Выбор экспортёра телеметрии (Jaeger, Zipkin, OTLP или отключено).
• Конечная точка: URL конечной точки коллектора телеметрии.
• Частота выборки: Процент запросов для трассировки (1-100%).
• Пользовательские атрибуты: Добавление пользовательских атрибутов ко всем спанам телеметрии.

Интеграции (Admin)

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

• Просмотр всех токенов интеграции во всех пространствах имён.
• Создание токенов для системных интеграций (общие runners, оркестраторы).
• Мониторинг использования токенов и временных меток последней активности.
• Отзыв токенов во всей системе.

Панель поддержки

Путь: /ui/support

Панель поддержки доступна пользователям, которым назначена системная роль Support. Пользователи с ролью Support имеют полный доступ на чтение и могут управлять пользователями, пространствами имён, настройками очистки, LLM-профилями, вебхуками и состоянием базы данных в рамках своей области.

Что такое роль Support?

Роль Support предназначена для тимлидов, QA-лидов или назначенных специалистов поддержки, которым необходим обзор системы для помощи другим пользователям без полного административного доступа. Пользователи с ролью Support видят больше информации о системе, чем обычные пользователи, но ограничены в изменении конфигурации, которая может повлиять на всю платформу.

Возможности роли Support

Пользователи с ролью Support могут:

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

Чего не может роль Support

Роль Support намеренно не предоставляет:

• Изменение общесистемных настроек (телеметрия, конфигурация электронной почты).
• Выполнение деструктивных административных операций с системными ресурсами.

Как назначить роль Support

Только администраторы могут назначить роль Support:

1. Перейдите в Панель администратора (/ui/admin).
2. Откройте раздел Управление пользователями.
3. Найдите пользователя, которому хотите повысить роль, и нажмите Редактировать.
4. В выпадающем списке Системная роль выберите Support.
5. Сохраните изменения. Пользователь увидит пункт навигации «Поддержка» в своей боковой панели при следующей загрузке страницы.

ИИ-функции

Mockarty интегрирует искусственный интеллект по всей платформе с выделенными кнопками на каждой основной странице. Каждая ИИ-кнопка следует единому паттерну: нажмите для выполнения операции, нажмите на иконку шестерёнки для настройки параметров.

Паттерн ИИ-кнопок

Каждая ИИ-функция предоставляет:

1. Кнопка действия — нажмите для запуска ИИ-операции
2. Шестерёнка настроек — выберите LLM-профиль, введите пользовательский промпт и управляйте интеграциями MCP-инструментов
3. Отображение результата — ответы ИИ отображаются в формате Markdown

Где найти ИИ-кнопки

• Конструктор: Generate Mock, Improve Mock
• API Tester: Generate Script, Generate Perf Script, Diagnose Error, API Diff, Log Analysis, Generate Collection
• Запуски тестов: Analyze Report (в модальном окне отчёта)
• Fuzzing: Analyze Finding, Batch Analyze, Batch Auto-Triage
• Рекордер: Analyze Traffic, Security Audit, Find Scenarios
• Производительность: Analyze Results

Настройка поведения ИИ

Нажмите на иконку шестерёнки на любой ИИ-кнопке, чтобы:

• Выбрать ИИ-профиль: Выберите, какую LLM использовать (быстрые vs. мощные модели)
• Добавить пользовательский промпт: Предоставьте дополнительные инструкции (например, “Focus on security”, “Respond in Russian”, “Compare against SLA: p95 < 200ms”)
• Выбрать MCP-инструменты: Включите внешние инструменты для запроса данных в реальном времени

Настройки сохраняются для каждой функции — настройки “Generate Script” не повлияют на “Diagnose Error”.

Полное руководство по всем ИИ-функциям, пользовательским промптам и советам см. в документации по ИИ-функциям.

Чат с ассистентом

Чат с ассистентом — это AI-помощник, доступный на каждой странице через плавающую кнопку чата в правом нижнем углу экрана.

Доступ к чату

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

Возможности

Чат с ассистентом использует настроенную LLM (OpenAI, Claude или OpenRouter) для помощи в следующих задачах:

• Создание моков: Опишите нужный мок на естественном языке (например, «Создай GET-эндпоинт для /api/users, который возвращает список из 10 пользователей со случайными именами и email»). Ассистент создаёт и настраивает мок автоматически.
• Редактирование моков: Попросите ассистента изменить существующие моки (например, «Добавь условие к моку /api/users, чтобы возвращать 404, когда ID пользователя равен 0»).
• Ответы на вопросы: Задавайте вопросы о функциях Mockarty, синтаксисе JsonPath, функциях Faker или использовании хранилищ.
• Устранение неполадок: Опишите проблему (например, «Мой мок не сопоставляется с запросами»), и ассистент поможет диагностировать проблему.
• Массовые операции: Попросите ассистента создать несколько связанных моков в одном разговоре.

История разговора

Чат поддерживает историю разговора для текущей сессии. Вы можете:

• Прокручивать предыдущие сообщения.
• Ссылаться на более ранние части разговора.
• Начать новый разговор, нажав «Очистить чат».

Сессии чата с агентом сохраняются в базе данных. При повторном открытии сессии автоматически загружаются до 100 предыдущих сообщений.

Режим автоматического одобрения

По умолчанию каждый вызов инструмента, выполняемый AI-ассистентом, требует ручного одобрения — вы видите кнопки Принять и Отклонить для каждого действия. Для ускоренной работы переключитесь в режим Auto Approve:

1. Откройте панель чата с ассистентом.
2. Найдите выпадающий список Auto Approve вверху.
3. Переключите с Manual на Auto Approve.

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

Совет: Используйте автоматическое одобрение в sandbox/development пространствах имён для быстрого прототипирования. Сохраняйте ручной режим в рабочих пространствах для безопасности.

Серверная и клиентская LLM

Чат с ассистентом поддерживает два режима работы LLM:

Серверный (по умолчанию):

• Вызовы API LLM маршрутизируются через сервер Mockarty
• Используется профиль LLM, настроенный администратором
• API-ключ от пользователя не требуется

Клиентский:

• Вызовы API LLM выполняются напрямую из вашего браузера к провайдеру LLM
• Вы предоставляете собственный API-ключ и URL провайдера
• Выполнение инструментов по-прежнему происходит на сервере
• Полезно, когда вы хотите использовать собственную учётную запись OpenAI/Claude

Для клиентского режима выберите пользовательский профиль в настройках чата и укажите свой API-ключ.

Доступные инструменты

AI-ассистент имеет доступ к следующим встроенным инструментам:

Доступные инструменты зависят от контекста текущей страницы. Например, на странице Конструктора ассистент имеет доступ к полям формы и инструментам настройки мока.

Осведомлённость о контексте

Чат с ассистентом осведомлён о:

• Текущей странице, которую вы просматриваете.
• Выбранном пространстве имён и его ресурсах.
• Доступных функциях Faker и синтаксисе шаблонов.
• Возможностях и ограничениях API Mockarty.

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

Советы для эффективных промптов

• Будьте конкретны: «Создай GET /api/users/list эндпоинт, который возвращает данные пользователя с фейковым именем и email» работает лучше, чем «создай мок пользователя»
• Описывайте поведение: «Верни 404, когда ID = ’not-found’, иначе верни 200 с данными пользователя»
• Ссылайтесь на существующие моки: «Измени мок /api/orders, добавив условие для отменённых заказов»
• Просите объяснений: «Объясни, как работает Chain Store для многошагового процесса оформления заказа»
• Запрашивайте массовые операции: «Создай CRUD-эндпоинты для ресурса products (GET список, GET по ID, POST, PUT, DELETE)»

API-токены

API-токены обеспечивают программный доступ к REST API Mockarty. Они используются для автоматизации, интеграции с CI/CD и интеграции с внешними инструментами. Полный список доступных эндпоинтов см. в Справочнике API.

Доступ к управлению токенами

Управление API-токенами доступно из выпадающего меню пользователя (нажмите на ваше имя пользователя в правом верхнем углу и выберите «API-токены»).

Генерация нового токена

Нажмите «Сгенерировать токен» для создания нового API-токена:

• Имя: Дайте токену описательное имя (например, «CI/CD Pipeline», «Postman Collection»).
• Срок действия: Опционально установите дату истечения. Истёкшие токены автоматически отзываются.
• Область действия: Токены наследуют разрешения пользователя, который их создал.

После генерации токен отображается один раз. Скопируйте его немедленно, так как позже его нельзя будет получить.

Формат токена

API-токены используют формат mk_* (например, mk_7_<случайная-base64-строка>). Включите токен в API-запросы с помощью заголовка Authorization:

Authorization: Bearer mk_<ваш-токен>

Или как параметр запроса:

?api_token=mk_<ваш-токен>

Просмотр и отзыв токенов

Страница управления токенами показывает все ваши активные токены:

• Имя токена и дата создания.
• Временная метка последнего использования.
• Дата истечения (если установлена).

Нажмите «Отозвать» для немедленного отключения токена. Отозванные токены не могут быть восстановлены.

Роли и разрешения

Mockarty реализует комплексную систему управления доступом на основе ролей (RBAC) с двумя уровнями: системные роли и роли пространства имён.

Системные роли

Системные роли назначаются администраторами и определяют глобальные разрешения:

Для пользователей с системной ролью «User» разрешения определяются назначениями ролей в пространствах имён.

Роли пространства имён

Роли пространства имён назначаются для каждого пространства имён и определяют, что пользователь может делать внутри него:

Скрытые страницы

Определённые пункты боковой панели скрыты в зависимости от системной роли пользователя. Эти ограничения применяются на стороне сервера через логику Go-шаблонов (а не скрытие через CSS), поэтому HTML не отрисовывается для неавторизованных пользователей.

Заблокировано для Auditor (403 при переходе на страницу):

• Конструктор, Неопределённые запросы, Хранилища, Генератор и Шаблоны возвращают 403 Forbidden при попытке аудитора перейти на эти страницы.
• Настройки полностью скрыты из боковой панели.
• Аудиторы сохраняют доступ только для просмотра: Панель мониторинга, Моки, API Tester, Запуски тестов, Рекордер, Fuzzing, Контрактное тестирование, Chaos Engineering, Утилиты и Панель администратора (только журналы аудита).

Скрыто от User (стандартная роль):

• Настройки скрыты. Доступ зарезервирован только для ролей Admin и Support.
• Панель администратора скрыта.

Скрыто по умолчанию (флаги функций):

• Пункты навигации Fuzzing и Контрактное тестирование скрыты по умолчанию (style="display: none") и отображаются динамически при включении функции через лицензию или настройки пользователя.

Панель администратора: Скрыта от всех пользователей без роли Admin (отображается по проверке роли на стороне клиента).

Советы и лучшие практики

Организация

• Используйте пространства имён для организации моков по проекту, команде или окружению. Каждый микросервис или граница API может иметь собственное пространство имён, сохраняя моки изолированными и управляемыми.
• Используйте теги для сквозной категоризации, охватывающей пространства имён. Теги вроде «regression», «smoke-test», «v2» или «deprecated» помогают быстро находить связанные моки.
• Используйте папки на странице моков для создания логической иерархии. Повторяйте структуру ресурсов вашего API (например, /users, /orders, /payments).

Проектирование моков

• Используйте Faker для реалистичных тестовых данных вместо жёстко закодированных значений. Ответы с $.fake.FirstName, $.fake.Email и $.fake.UUID более репрезентативны для реальных сценариев и помогают обнаруживать ошибки сериализации/парсинга.
• Используйте Global Store для общего состояния, такого как счётчики и флаги функций. Например, используйте $.increment(gS.orderCounter) для генерации последовательных идентификаторов заказов в нескольких моках.
• Используйте Chain Store для многошаговых рабочих процессов. Проектируйте моки так, чтобы создание заказа сохраняло его идентификатор в cS.orderId, а последующие моки GET/UPDATE/DELETE ссылались на $.cS.orderId.
• Используйте условия разумно. Начинайте с широких моков (без условий) и добавляйте конкретные с более высоким приоритетом по мере детализации ваших тестовых сценариев.
• Используйте OneOf-ответы для имитации реалистичного поведения. Реальные сервисы не всегда возвращают один и тот же ответ; OneOf со случайным выбором имитирует это естественно.

Импорт и начальная настройка

• Импортируйте OpenAPI-спецификации для быстрой начальной настройки моков для всего API. Это экономит значительное время по сравнению с созданием моков по одному.
• Используйте рекордер для захвата реального трафика и его преобразования в моки. Это самый быстрый способ создания моков, точно отражающих фактическое поведение сервиса.
• Импортируйте коллекции Postman, если ваша команда уже имеет коллекции для тестирования API. API Tester Mockarty совместим с Postman и может импортировать коллекции без проблем.

Тестирование

• Планируйте запуски тестов для непрерывной валидации. Запускайте тестовые коллекции по расписанию (например, каждый час или ежедневно) для обнаружения дрейфа конфигурации моков.
• Используйте окружения в API Tester для переключения между целями. Определите окружения «Local» (указывающее на Mockarty), «Staging» (указывающее на ваше промежуточное окружение) и «Production» с той же коллекцией.
• Пишите тестовые скрипты для валидации не только кодов состояния, но и структуры ответов, типов данных и бизнес-логики.

Безопасность

• Используйте фаззинг регулярно для тестирования ваших API на распространённые уязвимости. Даже мок-сервисы могут выявить пробелы в валидации входных данных.
• Включите 2FA для всех пользователей с доступом на запись к мокам. Скомпрометированный мок может возвращать вредоносные ответы.
• Ротируйте API-токены периодически и отзывайте токены, которые больше не используются.
• Используйте изоляцию пространств имён, чтобы команды не могли случайно изменить моки друг друга.

Производительность

• Мониторьте панель мониторинга регулярно для понимания паттернов трафика и выявления активно используемых моков.
• Используйте режим прокси с осторожностью. Хотя это мощный инструмент, проксирование добавляет задержку. Используйте его для тестовых сценариев, а не для постоянного пропуска трафика.
• Устанавливайте TTL на временные моки, чтобы поддерживать чистоту пространства имён. Моки, созданные для одноразовых тестов, должны истекать автоматически.
• Используйте политики очистки для автоматического удаления старых логов запросов, неопределённых запросов и отчётов о тестах. Это поддерживает базу данных в лёгком состоянии и запросы быстрыми.

См. также

• Быстрый старт – Начните работу с Mockarty за несколько минут.
• Справочник API – Полная документация REST API для программного доступа.
• Справочник Faker-функций – Все доступные Faker-функции для динамических данных в ответах.
• Руководство по JsonPath – Синтаксис JsonPath для извлечения данных запроса и условий.
• Системы хранилищ – Подробное руководство по хранилищам Global, Chain и Mock.
• Генератор серверов – Генерация автономных серверов gRPC, Kafka, RabbitMQ, SMTP и других протоколов.
• Руководство по развёртыванию – Инструкции по развёртыванию через Docker и на сервере.
• Руководство администратора – Системное администрирование и конфигурация.
• Руководство по интеграциям – Runner-агенты, mock-резолверы и интеграции со сторонними сервисами.
• Архитектура масштабирования – Многоузловое развёртывание и распределённое разрешение моков.
• Управление тест-кейсами – Папочная TMS с версионированием шагов, общими шагами и рабочими процессами ревью.
• Тест-планы – Оркестрация многотипных тест-прогонов в виде DAG-воркфлоу с интеграцией CI/CD.
• Фаззинг API – Автоматизированное тестирование безопасности с фазз-нагрузками.
• Контрактное тестирование – Валидация моков на соответствие API-спецификациям.
• Хаос-инженерия – Внедрение сбоев и тестирование отказоустойчивости Kubernetes.
• Нагрузочное тестирование – Нагрузочное тестирование и оценка APDEX.
• Рекордер трафика – Захват и воспроизведение реального API-трафика.
• Каналы уведомлений – Настройка уведомлений через Telegram, email, Slack, Discord и вебхуки.