Ми тестуємо інтеграції доставки в 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 або порожній масив тарифів. Причини в порядку частоти:
- Не заповнені габарити товарів — CDEK API v2 при відсутності
weight/lengthповертає 400, модуль мовчки повертає 0 - Невірний код міста — CDEK використовує власні коди міст (не КЛАДР, не ФІАС); перевіряють через
POST /v2/location/cities - Тариф не активовано в договорі — спроба розрахувати тариф
136(Посилка склад-склад) при непідключеній послузі дає помилку авторизації, не 403 -
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 грн на виправленні в продакшні. Зв'яжіться з нами для попередньої оцінки проєкту — отримайте консультацію з типових проблем вашої інтеграції. Замовте тестування зараз.







