Настройка визуального регрессионного тестирования 1С-Битрикс

Представьте: вы обновили CSS в шаблоне, изменили компонент или просто добавили новый jQuery-плагин. Кнопка «Купить» съехала на 3 пикселя, блок с ценой перекрыл галерею на мобильных, шрифт в карточке товара стал на 2px меньше. Глазом не поймать, а клиенты жалуются на кривую вёрстку. Визуальное регрессионное тестирование (VRT) решает эту проблему: делает скриншот страницы до и после изменений, сравнивает попиксельно и подсвечивает расхождения. Мы внедряем такую проверку на проектах Битрикс и делимся опытом. За многие годы мы реализовали более 150 проектов, и каждый сталкивался с визуальными регрессиями после обновлений. Экономия на тестировании — от 40 000 ₽ в месяц. Автоматизация тестирования — единственный способ гарантировать стабильность вёрстки без ручного перебора всех страниц.

"Визуальное регрессионное тестирование — стандартная практика для гарантии неизменности UI." — Playwright Documentation

Почему визуальное регрессионное тестирование необходимо для Битрикс-проектов?

Битрикс-сайты — это сложные шаблоны с кастомизацией, компонентами и динамическим контентом. Даже точечное изменение вёрстки может сломать адаптив, перекрыть элементы или испортить отображение на мобильных. Ручная проверка всех страниц после каждого деплоя — дорого и медленно. Автоматизация решает эту проблему: скриншоты снимаются за минуты, а diff подсвечивает отклонения. VRT экономит до 20 часов ручного тестирования в месяц на среднем проекте. Кроме того, оно отлавливает регрессии, которые невозможно заметить глазами — например, смещение на 1px или изменение отступов.

Инструменты для VRT

Playwright со встроенными snapshot-тестами — наиболее интегрированный вариант, если фреймворк уже используется для E2E. По опыту, он в 3-5 раз быстрее Percy для небольших проектов и не требует ежемесячной подписки. Для большинства Битрикс-проектов этого достаточно. Если нужна расширенная платформа с diff-аналитикой и хостингом снимков — подойдёт Percy, но его стоимость при активном использовании может быть выше.

Как настроить snapshot-тесты в Playwright

Вот пошаговая инструкция для быстрого старта:

1. Установите Playwright: npm init playwright@latest.
2. Настройте конфигурационный файл playwright.config.ts:

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  snapshotPathTemplate: '{testDir}/__snapshots__/{testFilePath}/{arg}{ext}',
  expect: {
    toHaveScreenshot: {
      maxDiffPixels: 50,      // допуск: 50 пикселей разницы
      threshold: 0.01,         // 1% различий на пиксель
      animations: 'disabled',  // отключаем CSS-анимации
    },
  },
});

3. Создайте тесты для ключевых страниц: главная, каталог, карточка товара, корзина, чекаут.

Базовые visual-тесты для Битрикс

// tests/visual/catalog.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Catalog visual', () => {

  test('catalog section page', async ({ page }) => {
    await page.goto('/catalog/electronics/');
    await page.waitForLoadState('networkidle');
    await page.evaluate(() => {
      document.querySelectorAll('.catalog-item-label-sale').forEach(el => {
        (el as HTMLElement).style.visibility = 'hidden';
      });
    });
    await expect(page).toHaveScreenshot('catalog-section.png');
  });

  test('product card', async ({ page }) => {
    await page.goto('/catalog/electronics/headphones/model-x100/');
    await page.waitForLoadState('networkidle');
    const timer = document.querySelector('.sale-timer');
    if (timer) await page.evaluate(() => (document.querySelector('.sale-timer') as HTMLElement).style.display = 'none');
    await expect(page).toHaveScreenshot('product-card.png', { fullPage: false });
  });

  test('cart page', async ({ page }) => {
    await page.request.post('/local/ajax/cart-add.php', {
      data: { product_id: 123, quantity: 1 }
    });
    await page.goto('/personal/cart/');
    await page.waitForLoadState('networkidle');
    await expect(page).toHaveScreenshot('cart.png');
  });

});

Мобильный viewport

Отдельный проект в конфиге для мобильного вида:

// playwright.config.ts
projects: [
  {
    name: 'desktop-chrome',
    use: { viewport: { width: 1440, height: 900 } },
  },
  {
    name: 'mobile-iphone',
    use: {
      ...devices['iPhone 14'],
      viewport: { width: 390, height: 844 },
    },
    testMatch: '**/visual/**',
  },
];

Маскирование динамических элементов

Битрикс-страницы содержат элементы, которые меняются каждый раз: счётчики посетителей, таймеры акций, «Сегодня просматривают» и подобное. Их нужно маскировать:

await expect(page).toHaveScreenshot('homepage.png', {
  mask: [
    page.locator('.bx-visitor-counter'),
    page.locator('.product-views-count'),
    page.locator('.sale-countdown-timer'),
    page.locator('.personal-greeting'),
  ],
});

CI/CD интеграция

Пример пайплайна для GitHub Actions:

# .github/workflows/visual.yml
visual-tests:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: npm ci
    - run: npx playwright install chromium
    - run: npx playwright test tests/visual/
      env:
        TEST_BASE_URL: ${{ secrets.STAGING_URL }}
    - uses: actions/upload-artifact@v4
      if: failure()
      with:
        name: visual-diff
        path: test-results/

При падении теста в test-results/ будут три файла: эталон, актуальный снимок и diff с подсвеченными различиями.

Что делать при ложных срабатываниях?

Ложные срабатывания возникают из-за динамического контента (счётчики, таймеры) или случайных изменений (например, разный контент в виджете новостей). Решение: маскируйте такие элементы (как показано выше) или увеличьте maxDiffPixels. Если же дизайн изменился намеренно, обновите эталонные скриншоты командой npx playwright test --update-snapshots tests/visual/ и закоммитьте новые снимки в репозиторий — ревьюер увидит в diff не только код, но и визуальные изменения.

Что входит в настройку под ключ

• Аудит текущего состояния и выделение 10-15 ключевых страниц
• Написание snapshot-тестов для десктопа и мобильных версий
• Настройка CI/CD (GitHub Actions, GitLab CI)
• Маскирование динамических элементов и настройка допусков
• Интеграция с уведомлениями (Telegram, Slack, Bitrix24)
• Документация и обучение команды

Стоимость настройки — от 30 000 ₽. Многолетний опыт с Битрикс, 150+ реализованных проектов. Закажите настройку — и мы гарантируем стабильность вёрстки. Получите консультацию по вашему проекту — пишите, оценим его за 1 день.

Стратегия внедрения

Начинайте с главной, страницы каталога, карточки товара и корзины — это 80% того, что ломается при обновлениях шаблона. При намеренном изменении дизайна эталоны обновляются командой npx playwright test --update-snapshots tests/visual/. Обновлённые скриншоты коммитятся в репозиторий как часть PR — ревьюер видит в diff'е не только код, но и визуальные изменения.

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.

Сроки

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