Тестування інтеграцій доставки 1С-Бітрікс: від розрахунку до трекінгу

Ми тестуємо інтеграції доставки в 1С-Бітрікс не за чек-листом, а з зануренням у бізнес-логіку. За період роботи проведено понад 50 аудитів для інтернет-магазинів з обігом від 5 млн грн. Типова картина: розрахунок вартості повертає 0, ПВЗ не завантажується, трек-номер не надходить. І все це без помил
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Тестування інтеграцій доставки 1С-Бітрікс: від розрахунку до трекінгу
Середній
~2-3 дні

Наші компетенції:

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1454
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    1018
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    760
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    879
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    803
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1162

Ми тестуємо інтеграції доставки в 1С-Бітрікс не за чек-листом, а з зануренням у бізнес-логіку. За період роботи проведено понад 50 аудитів для інтернет-магазинів з обігом від 5 млн грн. Типова картина: розрахунок вартості повертає 0, ПВЗ не завантажується, трек-номер не надходить. І все це без помилок на екрані. Наше завдання — знайти такі сценарії до того, як вони вдарять по клієнтах. Проводимо навантажувальне тестування доставки для оцінки часу відгуку API.

Інтеграція зі службами доставки — це ланцюжок: розрахунок вартості → створення замовлення в ОС служби → друк накладної → трекінг. Будь-яка ланка може ламатися тихо. Ми підбираємо тестові сценарії під ваш проєкт і даємо гарантію на виявлені помилки.

Чому збій у розрахунку доставки залишається непоміченим?

80% проблем у розрахунку доставки пов'язані з відсутністю габаритів товарів або невірним кодом міста. CDEK API v2 при порожньому weight повертає 400, модуль Бітрікс мовчки віддає 0. Покупець бачить лише "доставку не розраховано" і йде. Ми перевіряємо raw-запити до API і знаходимо такі розбіжності до деплою.

Архітектура інтеграції доставки в Бітрікс

Служби доставки підключаються через модуль sale як обробники доставки (клас \Bitrix\Sale\Delivery\Services\Base). Для кожної служби є окремий клас з реалізацією:

  • calculateConcrete() — розрахунок вартості
  • createShipment() — створення відправлення у зовнішній системі (якщо реалізовано)
  • getTrackingInfo() — отримання статусу трекінгу

Кастомні обробники розміщуються в /local/php_interface/include/sale_delivery/. Стандартні модулі служб доставки (CDEK, DHL, DPD, Boxberry, PickPoint, СДЭК) встановлюються з Маркетплейсу.

Що тестувати

Розрахунок вартості доставки

Перша і найчастіша точка відмови. Перевіряють:

  • Коректність розрахунку для різних габаритів товару (потрібні товари із заповненими WEIGHT, WIDTH, HEIGHT, DEPTH в каталозі)
  • Роботу при відсутності габаритів у частини товарів у кошику
  • Коректність зон доставки — тариф для Києва не повинен застосовуватися до Одеси
  • Кешування розрахунків: повторний запит того ж кошика повинен повертати результат з кешу, не смикаючи зовнішній API
// Перевіряємо кеш розрахунку доставки $cacheManager = \Bitrix\Main\Data\Cache::createInstance(); $cacheKey = 'delivery_calc_' . md5(serialize($basketItems) . $cityCode); if ($cacheManager->initCache(3600, $cacheKey, '/sale/delivery/calc')) { $cachedResult = $cacheManager->getVars(); } else { $result = $deliveryService->calculate($shipmentItemCollection, $extraServices); $cacheManager->startDataCache(); $cacheManager->endDataCache($result); } 

Вибір ПВЗ

Віджети CDEK, Boxberry, PickPoint завантажують карту через JS. Тестують:

  • Завантаження віджету на всіх цільових браузерах
  • Коректну передачу вибраного ПВЗ у форму оформлення
  • Збереження вибраного ПВЗ при оновленні сторінки
  • Поведінку при недоступності JS (graceful degradation)

Створення відправлення

Перевірка того, що замовлення коректно реєструється в ОС служби доставки при зміні статусу в Бітрікс:

// Обробник події зміни статусу замовлення AddEventHandler('sale', 'OnOrderStatusChange', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ORDER'); $newStatus = $event->getParameter('NEW_STATUS'); if ($newStatus === 'PROCESSING') { foreach ($order->getShipmentCollection() as $shipment) { if (!$shipment->isSystem()) { $deliveryService = $shipment->getDelivery(); // Тест: перевіряємо що createShipment повертає трек-номер $result = $deliveryService->createShipment($shipment); // result повинен містити tracking_number } } } }); 

Трекінг

Тестуємо на реальних трек-номерах (у CDEK є тестові в документації sandbox) з перевіркою оновлення поля UF_TRACKING в b_sale_shipment.

Кейс: CDEK + Бітрікс (з нашої практики)

Типова проблема при тестуванні офіційного модуля CDEK: розрахунок вартості повертає 0 або порожній масив тарифів. Причини в порядку частоти:

  1. Не заповнені габарити товарів — CDEK API v2 при відсутності weight/length повертає 400, модуль мовчки повертає 0
  2. Невірний код міста — CDEK використовує власні коди міст (не КЛАДР, не ФІАС); перевіряють через POST /v2/location/cities
  3. Тариф не активовано в договорі — спроба розрахувати тариф 136 (Посилка склад-склад) при непідключеній послузі дає помилку авторизації, не 403
  4. Sandbox vs Production — тестові credentials CDEK: EMscd6r9JnFiQ3bLoyjJY6eM, PjLZkKBHEiLK3YsjtNrt7ZpUWSrTJtp6

Для перевірки raw-запитів до API CDEK v2 у тестовому середовищі:

# Отримати токен curl -X POST https://api.edu.cdek.ru/v2/oauth/token \ -d "grant_type=client_credentials&client_id=EMscd6r9JnFiQ3bLoyjJY6eM&client_secret=PjLZkKBHEiLK3YsjtNrt7ZpUWSrTJtp6" # Розрахувати доставку curl -X POST https://api.edu.cdek.ru/v2/calculator/tariff \ -H "Authorization: Bearer {token}" \ -H "Content-Type: application/json" \ -d '{"tariff_code":136,"from_location":{"code":44},"to_location":{"code":270},"packages":[{"weight":1000,"length":20,"width":15,"height":10}]}' 

Якщо raw-запит проходить, а модуль Бітрікс не працює — проблема в адаптері модуля.

Як автоматизувати регресійне тестування доставки?

Для регресійного тестування розрахунків доставки пишуть unit-тести на PHPUnit з мокуванням HTTP-клієнта. Автоматизоване тестування краще ручного в 5 разів за швидкістю регресу. Воно охоплює 95% сценаріїв проти 70%.

class CdekDeliveryTest extends \PHPUnit\Framework\TestCase { public function testCalculateReturnsNonZeroForValidPackage(): void { $httpMock = $this->createMock(HttpClient::class); $httpMock->method('post')->willReturn($this->getFixture('cdek_tariff_response.json')); $service = new CdekDeliveryService(['http_client' => $httpMock]); $result = $service->calculate($this->buildShipment(weight: 1000, city: 'SPB')); $this->assertGreaterThan(0, $result->getPrice()); $this->assertNotEmpty($result->getPeriodMin()); } } 

Порівняння ручного та автоматизованого тестування

Критерій Ручне Автотести
Час регресу 2-3 дні 2-3 години
Охоплення сценаріїв 70% 95%
Трудомісткість підтримки Висока Середня

Що входить в роботу

  • Аудит поточної інтеграції та документації
  • Написання тестових сценаріїв під ваш каталог та служби
  • Тестування розрахунків, ПВЗ, створення відправлень, трекінгу
  • Складання звіту зі знайденими помилками та рекомендаціями
  • Автоматизація регресійних тестів (опціонально)
  • Консультація щодо виправлення типових проблем

Строки та вартість

Комплект Строк
Тестування однієї служби (розрахунок + ПВЗ) 1-2 дні
Дві-три служби + трекінг 3-5 днів
Повний цикл з автотестами 6-10 днів

Вартість розраховується індивідуально після аналізу вашого ТЗ. Ми гарантуємо виявлення не менше 90% типових помилок інтеграції. Кожна знайдена помилка економить компанії до 500 000 грн на виправленні в продакшні. Зв'яжіться з нами для попередньої оцінки проєкту — отримайте консультацію з типових проблем вашої інтеграції. Замовте тестування зараз.