Регрессионное тестирование сайта на 1С-Битрикс

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

Регрессионный прогон предотвращает простои и финансовые потери. Стоимость рассчитывается индивидуально, но экономия от предотвращения одного критического сбоя может быть значительной. Наша команда имеет 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, СДЭК + Почта России, ЮКасса + Сбер). После обновления ядра регрессионный прогон на 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) и приоритеты. Для интернет-магазина обязательно: оформление заказа, оплата, доставка, личный кабинет, форма обратной связи.

Что входит в работу

Сроки

Защитите свой проект от неожиданных регрессий. Получите консультацию — мы составим тест-план и оценим объём работ за 1 день. Свяжитесь с нами, мы обязательно поможем.

Определение регрессионного тестирования можно найти на Wikipedia.