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

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

Оновлення ядра Бітрікс з версії 23.x до 24.x, встановлення нового модуля з Маркетплейсу, зміна PHP з 8.1 до 8.2 — будь-яка з цих дій здатна тихо зламати те, що працювало місяцями. Регресійне тестування — це систематична перевірка, що після змін старий функціонал продовжує працювати. На Бітрікс-проєктах воно особливо важливе через часті оновлення ядра (релізи виходять щотижня) та велику кількість точок розширення через події та агенти.

Що ламається при оновленнях Бітрікс

Практика показує кілька стійких патернів регресій.

Застарілі методи ядра. Бітрікс методично позначає методи як deprecated і через кілька версій видаляє. Проблема — у легасі-коді /local/, написаному на старому API D6:

// Застарілий код D6 (ламається при оновленнях)
$el = new CIBlockElement();
$el->GetList([], ['IBLOCK_ID' => 5], false, false, ['ID', 'NAME']);

// Актуальний D7 ORM
\Bitrix\Iblock\ElementTable::getList([
    'filter' => ['=IBLOCK_ID' => 5],
    'select' => ['ID', 'NAME'],
]);

Конфлікти шаблонів. Після оновлення компонентів Бітрікс (модуль sale, catalog) шаблони в /local/templates/ можуть перестати збігатися з новою логікою компонента. Класичний приклад — зміна структури $arResult у компоненті bitrix:catalog.section.

Агенти та планувальник. При оновленні ядра таблиця b_agent іноді втрачає прапорці активних агентів або змінюється сигнатура виклику. Перевіряють після кожного великого оновлення:

SELECT name, active, last_exec, next_exec, agent
FROM b_agent
WHERE active = 'Y'
ORDER BY next_exec;

Структура регресійного набору

Регресійний набір для Бітрікс-проєкту розбивають на рівні:

Smoke-тести (5–10 хвилин) — мінімальний набір, запускається після кожного деплою:

• Відкриття головної сторінки (HTTP 200)
• Додавання товару до кошика
• Авторизація наявного користувача
• Оформлення замовлення (до кроку оплати)
• Відкриття адміністративної панелі

Базовий регрес (2–4 години) — запускається перед кожним релізом:

• Повний флоу оформлення замовлення з кожним типом доставки та оплати
• Розумний фільтр із кількома параметрами
• Особистий кабінет: історія, редагування профілю
• Основні форми: зворотній дзвінок, підписка, контакти

Повний регрес (1–2 дні) — при великих оновленнях ядра або значних змінах кодової бази.

Кейс: оновлення ядра 23.700 → 24.100

Проєкт — інтернет-магазин будівельних матеріалів, ~15 000 SKU, CDEK + Укрпошта, ЮКаса + Сбер. Після оновлення ядра регресійний прогін виявив:

1. Розумний фільтр перестав працювати — причина: змінився формат параметрів компонента bitrix:catalog.smart.filter, шаблон у /local/templates/ використовував видалену властивість arResult['FORM_ATTRIBUTES']
2. Email-повідомлення про скасування замовлення дублювалися — подія OnOrderStatusChange викликалася двічі через нову поведінку в \Bitrix\Sale\Order::save()
3. Агент синхронізації з 1С завис — нова версія PHP 8.2 кидала TypeError при передачі null у strpos(), агент тихо падав, таблиця b_agent показувала його «активним»

Усі три проблеми були спіймані до викладки на продакшн саме тому, що регресійний прогін запускався на staging-оточенні з prod-дампом бази.

Інструментарій та автоматизація

Для автоматизації регресійних тестів на Бітрікс-проєктах рекомендується:

Playwright для UI-тестів із фіксацією скриншотів при помилках:

// playwright.config.js
module.exports = {
    use: {
        baseURL: 'https://staging.shop.com',
        screenshot: 'only-on-failure',
        video: 'on-first-retry',
    },
    retries: 1,
};

PHPUnit + BitrixTestCase для тестування компонентів та хелперів. Запуск у CI/CD (GitHub Actions, GitLab CI) при кожному пуші в main:

# .gitlab-ci.yml
regression:
  stage: test
  script:
    - php vendor/bin/phpunit --testsuite=regression
    - npx playwright test --reporter=html
  artifacts:
    when: on_failure
    paths:
      - playwright-report/

Візуальне регресійне тестування з @playwright/test + плагін playwright-visual-comparisons — порівняння скриншотів ключових сторінок до і після оновлення.

Терміни