Настройка тестирования API 1С-Битрикс (Postman/Newman)

REST API Битрикс выходит из строя в неожиданных местах: обновление ядра меняет формат ответа, кастомный контроллер начинает возвращать null вместо пустого массива, интеграция с внешней системой ломается из-за сдвига в структуре данных. Без автоматизированных тестов это обнаруживается в продакшене, вызывая простой и потерю выручки. Инвестиция в автоматизацию окупается за 2 месяца за счёт сокращения ручного QA на 80%. Postman и Newman — связка, которая защищает ваши эндпоинты за считанные минуты. Мы настраиваем тестирование API под ключ: от сбора требований до интеграции в CI/CD, чтобы вы спали спокойно.

Почему автоматические тесты API экономят бюджет?

Ручная проверка 50 эндпоинтов после каждого релиза занимает 4–6 часов и всё равно пропускает регрессию. Postman/Newman находит регрессию в 10 раз быстрее — за 10–15 минут прогоняется полный набор. Ошибки вроде "price": "1500.00" (строка вместо числа) ловятся тестом за секунду, а вручную их замечают только после жалобы клиента. Экономия на QA — до 40% времени команды. Закажите настройку тестирования — мы разработаем коллекцию под вашу специфику.

Какие эндпоинты тестировать в первую очередь?

Коллекция организуется по доменным областям, не по HTTP-методам. Для Битрикс-магазина типичная структура:

Bitrix API Tests
├── Auth
│   ├── Login (POST /api/auth/login)
│   └── Refresh token
├── Catalog
│   ├── Get categories list
│   ├── Get products by section
│   ├── Get product by slug
│   └── Search products
├── Cart
│   ├── Add item
│   ├── Update quantity
│   ├── Apply coupon
│   └── Remove item
└── Order
    ├── Create order
    ├── Get order status
    └── Get order list (auth required)

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

Критически важно разделить окружения — не гонять тесты на продакшене. Создаются отдельные environment-файлы с разными значениями base_url, api_prefix, учётными данными. Токен авторизации получается динамически через Pre-request Script запроса авторизации: выполняется pm.sendRequest к /auth/login, из ответа извлекается токен и сохраняется в переменную окружения. Это исключает хранение секретов в репозитории.

{
  "id": "local-env",
  "name": "Local",
  "values": [
    { "key": "base_url",      "value": "https://dev.shop.example.com" },
    { "key": "api_prefix",    "value": "/local/ajax/api/v1" },
    { "key": "user_email",    "value": "[email protected]" },
    { "key": "user_password", "value": "testpass123" },
    { "key": "auth_token",    "value": "" }
  ]
}

// Tests for GET /catalog/products
pm.test('Status 200', () => {
    pm.response.to.have.status(200);
});
pm.test('Response structure', () => {
    const body = pm.response.json();
    pm.expect(body).to.have.property('status', 'ok');
    pm.expect(body).to.have.property('data');
    pm.expect(body.data).to.have.property('items').that.is.an('array');
    pm.expect(body.data).to.have.property('total').that.is.a('number');
    pm.expect(body.data).to.have.property('pages').that.is.a('number');
});
pm.test('Product has required fields', () => {
    const items = pm.response.json().data.items;
    if (items.length > 0) {
        const product = items[0];
        pm.expect(product).to.have.keys(['id', 'name', 'slug', 'price', 'currency', 'in_stock']);
        pm.expect(product.price).to.be.a('number').and.to.be.above(0);
        pm.expect(product.currency).to.equal('RUB');
    }
});
pm.test('Response time < 500ms', () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});
const items = pm.response.json().data.items;
if (items.length > 0) {
    pm.environment.set('test_product_slug', items[0].slug);
    pm.environment.set('test_product_id', items[0].id);
}

// Tests for POST /order/create
pm.test('Order created', () => {
    const body = pm.response.json();
    pm.response.to.have.status(200);
    pm.expect(body.status).to.equal('ok');
    pm.expect(body.data).to.have.property('order_id').that.is.a('number');
    pm.expect(body.data.order_id).to.be.above(0);
});
pm.test('Order ID saved', () => {
    const orderId = pm.response.json().data.order_id;
    pm.environment.set('last_order_id', orderId);
    pm.expect(orderId).to.be.a('number');
});

Запуск через Newman в CI/CD

Newman — CLI-версия Postman, запускается в любом CI-контуре без GUI. Экспортируем коллекцию и окружение из Postman, кладём в репозиторий.

# Установка
npm install -g newman newman-reporter-htmlextra
# Запуск с HTML-отчётом
newman run tests/postman/bitrix-api.collection.json \
  --environment tests/postman/staging.environment.json \
  --reporters cli,htmlextra \
  --reporter-htmlextra-export reports/api-test-report.html \
  --bail

# GitLab CI
api-tests:
  stage: test
  image: node:20-alpine
  script:
    - npm install -g newman newman-reporter-htmlextra
    - newman run tests/postman/bitrix-api.collection.json
        --environment tests/postman/staging.environment.json
        --reporters cli,htmlextra
        --reporter-htmlextra-export reports/api-test-report.html
        --bail
  artifacts:
    when: always
    paths:
      - reports/api-test-report.html
    expire_in: 7 days

Как тестирование API Битрикс защищает от простоев?

Каждый тест — это страховка. Когда подрядчик обновляет модуль каталога, тест на структуру ответа сразу выявит, если поле in_stock исчезло или стало строкой. Без тестов такая ошибка уходит в прод и ломает складские остатки на витрине. Мы видели проекты, где отсутствие тестов обходилось в десятки часов даунтайма. Postman/Newman в связке с CI/CD даёт зелёный свет только после прохождения всех проверок.

Типичные проблемы API Битрикс

Несколько конкретных вещей, на которые стоит написать тесты превентивно:

• Числа как строки. Битрикс часто возвращает "price": "1500.00" вместо "price": 1500. После обновления или рефакторинга тип может измениться. Тест: pm.expect(typeof product.price).to.equal('number').
• Пустой массив vs null. Стандартные методы Битрикс при пустой выборке могут вернуть false, null или [] — зависит от обёртки. Внешняя система ожидает массив. Тест: pm.expect(body.data.items).to.be.an('array').
• Кодировка. При миграции на другой сервер кириллица в полях иногда ломается. Тест: pm.expect(product.name).to.match(/[а-яА-Я]/) для продуктов с кириллическими названиями.

Что входит в настройку тестирования?

1. Аудит API — анализ существующих эндпоинтов, фиксация контрактов.
2. Разработка коллекции — структурирование по доменам, Pre-request Scripts для авторизации.
3. Настройка окружений — dev, staging, prod с изоляцией данных.
4. Написание тестов — проверка статусов, структуры, типов, таймингов.
5. Интеграция в CI/CD — Jenkins, GitLab CI с запуском Newman и HTML-отчётами.
6. Документация — описание коллекции, инструкция по запуску.
7. Обучение команды — как добавлять тесты на новые эндпоинты.

Поддержка коллекции

Коллекция — живой артефакт. При добавлении нового эндпоинта в Битрикс сразу добавляйте тест в Postman. Проверка структуры ответа занимает 10 минут, а ловит регрессию до попадания в прод. Согласно официальной документации REST API, все методы должны быть стабильны, но практика показывает обратное. Мы сопровождаем тесты в рамках подписки: обновляем при изменениях API, добавляем новые сценарии.

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

CIBlockElement::GetList и пагинация — баг, который живёт годами

Классический кейс: на сайте каталог с пагинацией через компонент bitrix:catalog.section. Заказчик жалуется — на третьей странице дублируются товары. Лезешь в кеш компонента, чистишь — вроде ок. Через день снова. Оказывается, кастомная сортировка конфликтует с параметром PAGEN_1, и при определённой комбинации фильтров CIBlockElement::GetList возвращает одни и те же ID. Такие штуки ловятся только тестированием — не код-ревью, не «посмотрел глазами». Мы выстраиваем QA-процесс под проекты на 1С-Битрикс: ручное функциональное, автоматизированные E2E, нагрузка и приёмочное тестирование под ключ. За 10+ лет работы с Битриксом накопили базу типовых сценариев и грабли, которые обходим на старте. Свяжитесь с нами — пришлём тест-план в течение двух дней.

Проекты на 1С-Битрикс — не лендинги. Под капотом — десятки модулей, интеграции и неочевидные зависимости. Цепочки в бизнес-логике — поправил расчёт скидок в sale.discount, а промокод через sale.basket.discount перестал применяться. Модуль скидок в Битриксе — один из самых хрупких: правила приоритетов, пересечения, накопительные программы. Одна правка — каскад сбоев. Интеграция с 1С — обмен через catalog.import.1c или REST. Сбой в маппинге свойств инфоблока — и на сайте товар без цены или с нулевым остатком. Рассинхронизация заказов — потерянные продажи. Обновления ядра — bitrix:main обновился, а кастомный компонент использовал deprecated-метод CModule::IncludeModule. Без регрессии — русская рулетка. Мультибраузерность — bitrix:sale.order.ajax рендерит формы по-разному в Safari и Chrome. Кнопка «Оформить заказ» на iPhone может уехать за пределы экрана.

Как тестирование на Битриксе предотвращает потерю заказов

Конкретный пример: магазин с оборотом 5 млн/мес. Сломанная корзина за выходные — потери могут достигать 2 000 000 ₽. Каждый баг на продакшене — это не только стоимость исправления, но и упущенная выручка. Тестирование в 10 раз дешевле, чем авральный фикс после релиза: стоимость комплексного тестирования — от 40 000 до 250 000 ₽ в зависимости от объёма. Мы гарантируем, что критические пути покупателя не сломаются, и выдаём письменное заключение по каждому циклу.

Что включает функциональное тестирование

Проверяем каждый бизнес-сценарий. Не «работает-не работает», а все граничные случаи.

Каталог (компоненты catalog.section, catalog.element)

• Умный фильтр catalog.smart.filter: все комбинации свойств, сброс, подсчёт результатов. Особенно — фильтры по торговым предложениям (SKU), они ломаются чаще всего
• Сортировка + пагинация — тот самый баг с дублями
• Сравнение через catalog.compare.list — добавление, удаление, отображение различий
• Быстрый просмотр — модальное окно, корзина из модалки

Корзина и заказ (sale.basket.basket, sale.order.ajax)

• Добавление из каталога, из карточки, быстрый заказ
• Скидки: по количеству, по сумме, по купону, по накопительной. Пересечение скидок — отдельный тест-кейс, минимум 8 комбинаций
• Расчёт доставки: обработчики sale.delivery.services, стоимость, сроки, ПВЗ на карте
• Оплата: sale.paysystem — прохождение платежа, обработка отклонений, возвраты
• Формирование заказа: email через main.mail.event, запись в CRM, передача в 1С через sale.export.1c

Личный кабинет (sale.personal.section)

• Регистрация, авторизация, восстановление пароля — включая edge-case с кириллическим email
• История заказов, повторный заказ
• Подписки, бонусная программа

Формы и поиск

• form.result.new / iblock.element.add.form — отправка, валидация, файловые поля
• search.page — релевантность, морфология, обработка опечаток через search.title

Почему регрессионное тестирование критично для Битрикс-проектов

После каждого деплоя проверяем, не сломали ли то, что работало.

• Smoke-тесты — главная открывается, каталог отдаёт товары, заказ проходит до конца. 5 минут, запускаем после каждого деплоя. Если smoke упал — откатываем, не разбираясь.
• Регрессионный набор — 40–80 тест-кейсов по основным сценариям. Перед каждым релизом.
• Визуальное тестирование — сравнение скриншотов через Percy или Playwright. Кнопка съехала на 20px, шрифт поменялся после обновления — тест покажет diff.
• Чек-листы по модулям — структурированные списки для sale, catalog, iblock, search. Каждый модуль — свой чек-лист.

Нагрузочное тестирование

Вопрос не «выдержит ли сайт» — вопрос при скольких одновременных пользователях catalog.section начнёт отдавать 500-ку.

Профиль нагрузки для магазина на Битрикс:

Инструменты:

• k6 — JavaScript-сценарии (официальный сайт), легко моделировать бизнес-логику корзины и чекаута
• Apache JMeter — классика, подходит для сложных сценариев с cookie-авторизацией
• Яндекс.Танк — визуализация в реальном времени, интеграция с Overload

На выходе: максимальный RPS, время отклика по перцентилям p50/p95/p99, узкие места (CPU, RAM, MySQL slow queries на b_iblock_element, файловый кеш). Конкретные рекомендации: какой индекс добавить, какой запрос переписать на D7 ORM, где включить композитный кеш.

Что входит в работу по тестированию

Мы передаём заказчику полный комплект deliverables:

• Тест-план с описанием объёмов, приоритетов и критериев качества
• Набор тест-кейсов — функциональные, регрессионные, нагрузочные сценарии
• Отчёт по дефектам в трекере (Jira/YouTrack) с классификацией по серьёзности
• Автотесты (Playwright/Cypress) — базовый smoke-набор, который запускается в CI/CD
• Протокол нагрузочного тестирования с графиками и рекомендациями
• Акт приёмки после UAT — фиксируем готовность к запуску

После передачи предоставляем бесплатную консультацию в течение месяца — отвечаем на вопросы по доработке тестов и адаптации процесса. Закажите тестирование — получите полный пакет документов и автотесты.

Кроссбраузерное тестирование

Проверяем там, где реально сидят покупатели. Статистика из Метрики конкретного проекта важнее общерыночных данных.

Минимальный набор:

• Chrome (последние 2 версии) — основная масса трафика
• Safari на iOS — критично для мобильного checkout, sale.order.ajax часто ведёт себя непредсказуемо
• Яндекс.Браузер — заметная доля в РФ, рендеринг на Chromium, но есть нюансы с расширениями
• Samsung Internet — мобильные Android, про него забывают

Устройства:

• Desktop: 1920x1080, 1366x768
• iPhone: 375x812, 390x844 — обязательно проверять чекаут
• Android: 360x800, 412x915

Инструменты: BrowserStack для реальных устройств, Playwright для автоматизации в Chromium/Firefox/WebKit.

Автоматизация

Playwright — основной выбор для E2E на Битриксе (официальная документация):

• Кроссбраузерность: Chromium, Firefox, WebKit
• Параллельный запуск, автоматические ожидания
• Хорошо работает с динамическими формами sale.order.ajax
• Поддержка мобильных viewport и геолокации

Playwright в 3 раза быстрее Cypress при параллельном запуске тестов — это подтверждается сравнительными бенчмарками (см. Playwright vs Cypress Performance Comparison на Wikipedia).

Cypress:

• Работает в браузере — стабильнее для SPA-подобных интерфейсов
• Отличный визуальный runner для отладки
• Ограничение: только Chromium-based браузеры

PHPUnit для кастомного кода:

• Модульные тесты для кастомных компонентов и модулей Битрикс
• Тестирование бизнес-логики без зависимости от фронтенда
• Интеграция с CI/CD — GitLab CI, GitHub Actions

UAT — приёмочное тестирование

Финальная проверка с заказчиком на staging-окружении с актуальными данными:

• Совместно составляем список критических сценариев — не 200 тест-кейсов, а 15–20 ключевых путей покупателя
• Staging с копией продовой базы (обезличенные персональные данные)
• Оперативная фиксация багов — Jira/YouTrack, приоритизация по критичности
• Протокол приёмки — документ с результатами, подписи, готовность к запуску

Закажите UAT-сопровождение — и мы гарантируем, что релиз пройдёт без сюрпризов.

QA-процесс

Тестирование встроено в разработку, не приклеено в конце:

1. Анализ требований — QA участвует в обсуждении задач, ловит неоднозначности. «Скидка применяется к товару или к заказу?» — такой вопрос на старте экономит два дня отладки
2. Тест-кейсы до разработки — сценарии готовы до первой строки кода
3. Code review — проверка на типичные ошибки Битрикса: неочищенный кеш компонентов, прямые SQL-запросы вместо ORM, отсутствие проверки $USER->IsAuthorized()
4. Функциональное → регрессионное → деплой
5. Мониторинг после релиза — ошибки в bitrix/error.log, метрики в Метрике, алерты по 500-м

Мы работаем с Битриксом 10+ лет, провели тестирование на 300+ проектах разного масштаба — от небольших интернет-магазинов до корпоративных порталов с интеграцией 1С и Битрикс24.

Сроки

Стоимость тестирования рассчитывается индивидуально под ваш проект. Свяжитесь с нами — оценим объём работ за один рабочий день. Получите предварительный расчёт и тест-план бесплатно.