Делал ли прогоны коллекций

Моё использование коллекций Postman и прогонов (коллекций)

Да, безусловно. Работа с Postman Collections и их прогонами (Collection Runs) — это неотъемлемая часть моей ежедневной практики как QA Engineer, особенно в контексте тестирования API. Это основной инструмент для автоматизации повторяющихся сценариев, регрессионного тестирования и интеграции в CI/CD пайплайны.

Ключевые сценарии использования прогонов коллекций:

• Регрессионное тестирование API: Я создаю коллекции, покрывающие основные функциональные сценарии (CRUD операции, валидации, негативные кейсы) для каждого микросервиса. Перед выпуском новой версии я запускаю полный прогон коллекции, чтобы убедиться, что существующий функционал не сломан.
• Дымовое тестирование (Smoke Testing): Для этого я выделяю в отдельную коллекцию или папку минимальный набор критичных API-запросов (например, проверка здоровья сервиса, аутентификация, ключевые GET-запросы). Такой прогон выполняется быстро и даёт понимание, готов ли сервис к более глубокому тестированию.
• Нагрузочное тестирование (с Newman или JMeter): Postman отлично подходит для создания сценариев, которые затем можно выполнить в нагрузочном режиме с помощью Newman (CLI-версия Postman) или конвертировать для JMeter. Это позволяет оценить стабильность API под нагрузкой.
• Интеграция в CI/CD: Используя Newman, я встраиваю прогоны коллекций в пайплайны Jenkins, GitLab CI или GitHub Actions. Это позволяет автоматически проверять API после каждого коммита или сборки и получать отчёт о результатах.

Пример организации коллекции и скриптов для прогона:

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

Структура коллекции:

• Папка: Auth (Предусловия)

    *   `POST /auth/login` (Получение токена)

• Папка: User CRUD (Основные сценарии)

    *   `POST /users` (Создание пользователя)
    *   `GET /users/{{userId}}` (Получение пользователя)
    *   `PUT /users/{{userId}}` (Обновление пользователя)
    *   `DELETE /users/{{userId}}` (Удаление пользователя)

• Папка: Negative Tests (Негативные сценарии)

    *   `POST /users` (Создание с невалидными данными)
    *   `GET /users/invalidID` (Запрос несуществующего пользователя)

Пример скрипта на уровне коллекции для сохранения переменных (вкладка "Tests"):

// Этот код выполнится после КАЖДОГО запроса в коллекции.
// Сохраняем authToken из ответа запроса на логин для последующих вызовов.
if (pm.response.code === 200 && pm.request.url.path.includes('auth/login')) {
    const responseData = pm.response.json();
    pm.collectionVariables.set('authToken', responseData.token);
    console.log('Auth token saved:', pm.collectionVariables.get('authToken'));
}

// Извлекаем ID созданного пользователя для использования в следующих запросах.
if (pm.response.code === 201 && pm.request.method === 'POST' && pm.request.url.path.includes('users')) {
    const responseData = pm.response.json();
    pm.collectionVariables.set('userId', responseData.id);
    console.log('User ID saved:', pm.collectionVariables.get('userId'));
}

Пример запуска коллекции через Newman (CLI):

# Базовый запуск с HTML-отчётом
newman run MyAPICollection.json \
  --environment StagingEnv.json \
  --reporters cli,html \
  --reporter-html-export newman_report.html

# Запуск с обработкой данных (Data File), например, для параметризованного тестирования
newman run MyAPICollection.json \
  --environment StagingEnv.json \
  --iteration-data users.csv \
  --globals Globals.json

Преимущества и мои best practices при работе с прогонами:

1. Изоляция тестовых данных: Я всегда использую отдельные environment-файлы для разных стендов (dev, staging, prod) и предпочитаю создавать тестовые данные прямо в сценарии через Pre-request Scripts, чтобы минимизировать зависимости между тестами.
2. Детальная валидация ответов: В Tests скриптах я проверяю не только статус-код (pm.response.to.have.status(200)), но и структуру JSON-ответа (схему), время отклика и бизнес-логику.
3. Логирование и отладка: Я активно использую console.log() в скриптах и анализирую детальный лог прогона в Newman или Postman Console для отладки сложных цепочек запросов.
4. Параметризация: Использование переменных коллекции, окружения и глобальных переменных (pm.variables.get/set) делает коллекции гибкими и переиспользуемыми.
5. Работа с асинхронностью: Для сценариев, где нужно дождаться выполнения асинхронной задачи (например, обработки файла), я реализую поллинг с помощью setTimeout или pm.sendRequest в цикле.

Таким образом, прогоны коллекций — это мощный механизм, который я использую для построения надёжного, автоматизированного и интегрированного в процесс разработки тестирования API.