Налаштування тестування 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+ впроваджень, працюємо під ключ.

Тестування сайтів на 1С-Бітрікс

CIBlockElement::GetList і пагінація — баг, який живе роками

Класичний кейс: на сайті каталог із пагінацією через компонент bitrix:catalog.section. Замовник скаржиться — на третій сторінці дублюються товари. Лізеш у кеш компонента, чистиш — начебто ок. Через день знову. Виявляється, кастомне сортування конфліктує з параметром PAGEN_1, і при певній комбінації фільтрів CIBlockElement::GetList повертає ті самі ID. Такі штуки ловляться тільки тестуванням — не код-рев'ю, не «подивився очима».

Зламана пагінація, некоректний розрахунок знижок, помилки інтеграції з 1С — кожен з цих багів коштує бізнесу реальних грошей. Ми знаємо, як їх знайти і виправити до того, як вони вплинуть на продажі. Наша команда має понад 10 років досвіду з Бітрікс і понад 50 успішних QA-проєктів. Ми вибудовуємо QA-процес під проєкти на 1С-Бітрікс: ручне функціональне, автоматизовані E2E, навантажувальне та приймальне тестування.

Чому сайти на 1С-Бітрікс потребують професійного тестування?

Проєкти на 1С-Бітрікс — не лендінги. Під капотом — десятки модулів, інтеграції та неочевидні залежності:

• Ланцюжки в бізнес-логіці — виправив розрахунок знижок у sale.discount, а промокод через sale.basket.discount перестав застосовуватися. Модуль знижок у Бітріксі — один із найкрихкіших: правила пріоритетів, перетини, накопичувальні програми. Одна правка — каскад збоїв.
• Інтеграція з 1С — обмін через catalog.import.1c або REST. Збій у маппінгу властивостей інфоблоку — і на сайті товар без ціни або з нульовим залишком. Розсинхронізація замовлень — втрачені продажі.
• Оновлення ядра — bitrix:main оновився, а кастомний компонент використовував deprecated-метод CModule::IncludeModule з нестандартними параметрами. Без регресії — російська рулетка.
• Мультибраузерність — bitrix:sale.order.ajax рендерить форми по-різному в Safari і Chrome. Кнопка «Оформити замовлення» на iPhone може з'їхати за межі екрана.

Як функціональне тестування вирішує типові проблеми?

Перевіряємо кожен бізнес-сценарій. Не «працює-не працює», а всі граничні випадки.

Каталог (компоненти 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. Кожен модуль — свій чек-лист.

Як визначити вузькі місця продуктивності магазину на Бітрікс?

Ми моделюємо навантаження, щоб зрозуміти, при якому RPS catalog.section почне віддавати 500-ку. Використовуємо реалістичні профілі на основі вашої аналітики.

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

Інструменти: k6 (JavaScript-сценарії для кошика та чекауту), Apache JMeter (складні сценарії з cookie-авторизацією), Yandex.Tank (візуалізація в реальному часі). На виході — максимальний RPS, час відгуку за перцентилями p50/p95/p99, вузькі місця (CPU, RAM, MySQL slow queries на b_iblock_element, файловий кеш). Конкретні рекомендації: який індекс додати, який запит переписати на D7 ORM, де ввімкнути композитний кеш.

У проєкті з 100 000 товарами додавання індекса на b_iblock_element_property.IBLOCK_ELEMENT_ID скоротило час виконання фільтра з 8 секунд до 0.3 секунди — ми знайшли це саме під час навантажувального тестування.

Автоматизоване, кросбраузерне та приймальне тестування

Кросбраузерність перевіряємо там, де реально сидять покупці. Статистика з Метрики конкретного проєкту важливіша за загальноринкові дані. Мінімальний набір: Chrome (останні 2 версії), Safari на iOS, Яндекс.Браузер, Samsung Internet. Пристрої: Desktop 1920×1080 та 1366×768, iPhone 375×812 та 390×844 (обов'язково чекаут), Android 360×800 та 412×915. Інструменти: BrowserStack для реальних пристроїв, Playwright для автоматизації в Chromium/Firefox/WebKit.

Автоматизація базується на Playwright — кросбраузерність, паралельний запуск, автоматичні очікування, добре працює з динамічними формами sale.order.ajax. У порівнянні з ручним тестуванням, автоматизація скорочує час виконання регресії втричі. PHPUnit використовуємо для модульних тестів кастомних компонентів і бізнес-логіки — інтеграція з CI/CD (GitLab CI, GitHub Actions). Тестовий набір із 50 сценаріїв виконується за 15 хвилин замість годин ручної перевірки.

Фінальна перевірка (UAT) проводиться із замовником на staging з копією продової бази. Спільно складаємо 15–20 ключових шляхів покупця, фіксуємо баги в Jira/YouTrack, оформляємо протокол приймання.

QA-процес: як ми вбудовуємо тестування в розробку

Тестування не приклеюється наприкінці — воно стартує з аналізу вимог.

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

Закажіть тестування сьогодні — і ми підготуємо тест-план за 2 дні.

Терміни та вартість тестування

Що входить у роботу: детальний тест-план із чек-листами за модулями, автоматизований набір E2E-тестів (Playwright/Cypress) під ваш стек, звіт із результатами, скріншотами помилок і рекомендаціями, інтеграція тестів у ваш CI/CD (GitLab CI, GitHub Actions, Bitbucket Pipelines), супровід UAT — до трьох ітерацій виправлень без додаткової оплати, документація процесу тестування для вашої команди.

Баг на продакшені — це не тільки вартість виправлення. Середнє виправлення критичного дефекту коштує від 20 000 грн, а втрати від зламаного кошика за вихідні на проєкті з оборотом 5 млн/міс можуть сягати 400 000 грн. Інвестиція в тестування — це страховка вашого бізнесу.

Зв'яжіться з нами, щоб отримати комерційну пропозицію та детальний план тестування для вашого проєкту.