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

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

Регресійний прогін запобігає простоям та фінансовим втратам. Вартість розраховується індивідуально, але економія від запобігання одному критичному збою може скласти десятки тисяч гривень. Автоматизоване тестування в 5 разів ефективніше за ручне, а 80% дефектів виявляються до релізу. Наша команда має 10+ років досвіду в розробці на 1С-Бітрікс та провела регресійне тестування для 150+ проектів.

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

Бітрікс — жива платформа. Кожне оновлення ядра зачіпає десятки компонентів, а модулі з Маркетплейсу можуть конфліктувати з кастомним кодом. Типові сценарії збоїв:

• Застарілі методи ядра. Бітрікс позначає методи як deprecated і через декілька версій видаляє. Легасі-код у /local/ на старому API D6 перестає працювати.
• Конфлікти шаблонів. Після оновлення компонентів sale або catalog шаблони в /local/templates/ можуть не збігатися з новою структурою $arResult.
• Агенти та планувальник. При оновленні таблиця b_agent іноді втрачає прапорці активних агентів або змінюється сигнатура виклику.

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

Розберемо типові регресії на прикладах. Застарілі методи ядра.

// Застарілий код 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'], ]); 

Конфлікти шаблонів. Після оновлення компонента bitrix:catalog.section структура $arResult може змінитися, і шаблон перестане рендерити товари. Це одна з найчастіших проблем при оновленні торгового каталогу.

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

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

Які рівні регресійного тестування існують?

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

Кейс: оновлення ядра (з нашої практики, наш клієнт)

Один із наших клієнтів — інтернет-магазин будівельних матеріалів (15 000 SKU, СДЕК + Пошта Росії, ЮKassa + Сбер). Після оновлення ядра регресійний прогін на staging виявив:

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

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

Які інструменти вибрати для автоматизації регресії?

Ручні прогони — база, але для частих релізів без автоматизації не обійтися. Рекомендуємо:

Playwright для UI-тестів з фіксацією скріншотів при помилках. Він у 3 рази швидший за Selenium і стабільніший для Бітрікс-форм.

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

PHPUnit + BitrixTestCase для тестування компонентів і хелперів. Запуск у CI/CD при кожному пуші в 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-visual-comparisons ловить зміни у верстці, які непомітні функціональним тестам.

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

1. Визначити критичні сценарії на основі бізнес-логіки та частоти використання.
2. Налаштувати staging оточення, ідентичне продакшну (база даних, конфіги).
3. Запустити smoke-тести для перевірки доступності ключових сторінок та основних флоу.
4. Виконати повний регресійний прогін (ручний або автоматизований).
5. Проаналізувати результати, зафіксувати дефекти та повернути на доопрацювання.

Тест-план включає список усіх критичних сценаріїв, опис очікуваних результатів, оточення (staging, prod) та пріоритети. Для інтернет-магазину обов'язково: оформлення замовлення, оплата, доставка, особистий кабінет, форма зворотного зв'язку. Ручне тестування також залишається важливим для перевірки UX.

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

Строки

Захистіть свій проект від несподіваних регресій. Отримайте консультацію — ми складемо тест-план та оцінимо обсяг робіт за 1 день. Зв'яжіться з нами, ми обов'язково допоможемо.

Визначення регресійного тестування можна знайти на Wikipedia.