Регресійне тестування сайту на 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.

Тестування сайтів на 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 грн. Інвестиція в тестування — це страховка вашого бізнесу.

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