Регрессионное тестирование сайта на 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.

CIBlockElement::GetList и пагинация — баг, который живёт годами

Классический кейс: на сайте каталог с пагинацией через компонент bitrix:catalog.section. Заказчик жалуется — на третьей странице дублируются товары. Лезешь в кеш компонента, чистишь — вроде ок. Через день снова. Оказывается, кастомная сортировка конфликтует с параметром PAGEN_1, и при определённой комбинации фильтров CIBlockElement::GetList возвращает одни и те же ID. Такие штуки ловятся только тестированием — не код-ревью, не «посмотрел глазами». Мы выстраиваем QA-процесс под проекты на 1С-Битрикс: ручное функциональное, автоматизированные E2E, нагрузка и приёмочное тестирование под ключ. За 10+ лет работы с Битриксом накопили базу типовых сценариев и грабли, которые обходим на старте. Свяжитесь с нами — пришлём тест-план в течение двух дней.

Проекты на 1С-Битрикс — не лендинги. Под капотом — десятки модулей, интеграции и неочевидные зависимости. Цепочки в бизнес-логике — поправил расчёт скидок в sale.discount, а промокод через sale.basket.discount перестал применяться. Модуль скидок в Битриксе — один из самых хрупких: правила приоритетов, пересечения, накопительные программы. Одна правка — каскад сбоев. Интеграция с 1С — обмен через catalog.import.1c или REST. Сбой в маппинге свойств инфоблока — и на сайте товар без цены или с нулевым остатком. Рассинхронизация заказов — потерянные продажи. Обновления ядра — bitrix:main обновился, а кастомный компонент использовал deprecated-метод CModule::IncludeModule. Без регрессии — русская рулетка. Мультибраузерность — bitrix:sale.order.ajax рендерит формы по-разному в Safari и Chrome. Кнопка «Оформить заказ» на iPhone может уехать за пределы экрана.

Как тестирование на Битриксе предотвращает потерю заказов

Конкретный пример: магазин с оборотом 5 млн/мес. Сломанная корзина за выходные — потери могут достигать 2 000 000 ₽. Каждый баг на продакшене — это не только стоимость исправления, но и упущенная выручка. Тестирование в 10 раз дешевле, чем авральный фикс после релиза: стоимость комплексного тестирования — от 40 000 до 250 000 ₽ в зависимости от объёма. Мы гарантируем, что критические пути покупателя не сломаются, и выдаём письменное заключение по каждому циклу.

Что включает функциональное тестирование

Проверяем каждый бизнес-сценарий. Не «работает-не работает», а все граничные случаи.

Каталог (компоненты 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. Каждый модуль — свой чек-лист.

Нагрузочное тестирование

Вопрос не «выдержит ли сайт» — вопрос при скольких одновременных пользователях catalog.section начнёт отдавать 500-ку.

Профиль нагрузки для магазина на Битрикс:

Инструменты:

• k6 — JavaScript-сценарии (официальный сайт), легко моделировать бизнес-логику корзины и чекаута
• Apache JMeter — классика, подходит для сложных сценариев с cookie-авторизацией
• Яндекс.Танк — визуализация в реальном времени, интеграция с Overload

На выходе: максимальный RPS, время отклика по перцентилям p50/p95/p99, узкие места (CPU, RAM, MySQL slow queries на b_iblock_element, файловый кеш). Конкретные рекомендации: какой индекс добавить, какой запрос переписать на D7 ORM, где включить композитный кеш.

Что входит в работу по тестированию

Мы передаём заказчику полный комплект deliverables:

• Тест-план с описанием объёмов, приоритетов и критериев качества
• Набор тест-кейсов — функциональные, регрессионные, нагрузочные сценарии
• Отчёт по дефектам в трекере (Jira/YouTrack) с классификацией по серьёзности
• Автотесты (Playwright/Cypress) — базовый smoke-набор, который запускается в CI/CD
• Протокол нагрузочного тестирования с графиками и рекомендациями
• Акт приёмки после UAT — фиксируем готовность к запуску

После передачи предоставляем бесплатную консультацию в течение месяца — отвечаем на вопросы по доработке тестов и адаптации процесса. Закажите тестирование — получите полный пакет документов и автотесты.

Кроссбраузерное тестирование

Проверяем там, где реально сидят покупатели. Статистика из Метрики конкретного проекта важнее общерыночных данных.

Минимальный набор:

• Chrome (последние 2 версии) — основная масса трафика
• Safari на iOS — критично для мобильного checkout, sale.order.ajax часто ведёт себя непредсказуемо
• Яндекс.Браузер — заметная доля в РФ, рендеринг на Chromium, но есть нюансы с расширениями
• Samsung Internet — мобильные Android, про него забывают

Устройства:

• Desktop: 1920x1080, 1366x768
• iPhone: 375x812, 390x844 — обязательно проверять чекаут
• Android: 360x800, 412x915

Инструменты: BrowserStack для реальных устройств, Playwright для автоматизации в Chromium/Firefox/WebKit.

Автоматизация

Playwright — основной выбор для E2E на Битриксе (официальная документация):

• Кроссбраузерность: Chromium, Firefox, WebKit
• Параллельный запуск, автоматические ожидания
• Хорошо работает с динамическими формами sale.order.ajax
• Поддержка мобильных viewport и геолокации

Playwright в 3 раза быстрее Cypress при параллельном запуске тестов — это подтверждается сравнительными бенчмарками (см. Playwright vs Cypress Performance Comparison на Wikipedia).

Cypress:

• Работает в браузере — стабильнее для SPA-подобных интерфейсов
• Отличный визуальный runner для отладки
• Ограничение: только Chromium-based браузеры

PHPUnit для кастомного кода:

• Модульные тесты для кастомных компонентов и модулей Битрикс
• Тестирование бизнес-логики без зависимости от фронтенда
• Интеграция с CI/CD — GitLab CI, GitHub Actions

UAT — приёмочное тестирование

Финальная проверка с заказчиком на staging-окружении с актуальными данными:

• Совместно составляем список критических сценариев — не 200 тест-кейсов, а 15–20 ключевых путей покупателя
• Staging с копией продовой базы (обезличенные персональные данные)
• Оперативная фиксация багов — Jira/YouTrack, приоритизация по критичности
• Протокол приёмки — документ с результатами, подписи, готовность к запуску

Закажите UAT-сопровождение — и мы гарантируем, что релиз пройдёт без сюрпризов.

QA-процесс

Тестирование встроено в разработку, не приклеено в конце:

1. Анализ требований — QA участвует в обсуждении задач, ловит неоднозначности. «Скидка применяется к товару или к заказу?» — такой вопрос на старте экономит два дня отладки
2. Тест-кейсы до разработки — сценарии готовы до первой строки кода
3. Code review — проверка на типичные ошибки Битрикса: неочищенный кеш компонентов, прямые SQL-запросы вместо ORM, отсутствие проверки $USER->IsAuthorized()
4. Функциональное → регрессионное → деплой
5. Мониторинг после релиза — ошибки в bitrix/error.log, метрики в Метрике, алерты по 500-м

Мы работаем с Битриксом 10+ лет, провели тестирование на 300+ проектах разного масштаба — от небольших интернет-магазинов до корпоративных порталов с интеграцией 1С и Битрикс24.

Сроки

Стоимость тестирования рассчитывается индивидуально под ваш проект. Свяжитесь с нами — оценим объём работ за один рабочий день. Получите предварительный расчёт и тест-план бесплатно.