Настройка end-to-end тестирования для 1С-Битрикс

Почему E2E-тестирование критично для Битрикс-проектов?

После каждого обновления модуля, шаблона или API-интеграции кто-то вручную проверяет корзину, оформление заказа и личный кабинет. Процесс занимает 2–3 часа, но всё равно пропускает регрессии: ни один тестировщик за один прогон не охватит пять браузеров, мобильные вьюпорты и авторизацию через соцсети. У нас за плечами более 50 проектов на Битрикс — примерно в трети случаев релиз задерживался именно из-за пропущенной регрессии, обнаруженной в последний момент. E2E-тесты решают эту проблему автоматически: они прогоняются за 15–20 минут, стабильно находят те самые кейсы, которые человек пропускает.

Как мы это делаем?

Настраиваем тестовую среду, выбираем инструмент, пишем Page Object Model для ключевых компонентов и интегрируем прогон в ваш CI/CD. Работаем под ключ — от аудита текущей архитектуры до передачи документации и обучения команды.

Playwright vs Cypress: что выбрать для Битрикс?

Playwright — оптимальный выбор для Битрикс-проектов. Он поддерживает все браузеры в одном запуске, работает headless и headful, имеет мощный локатор API, который не ломается при изменении DOM. Встроенная эмуляция мобильных устройств и сетевой перехват — то, что нужно для тестирования sale.order.ajax с его асинхронностью.

Cypress хорош для SPA, но для многостраничных Битрикс-сайтов его ограничения (один origin, отсутствие нативной работы с несколькими вкладками) создают проблемы. В наших проектах мы используем Playwright в 9 случаях из 10.

Инфраструктура тестовой среды

Тестовая среда — обязательно отдельная база данных с фиксированными данными. Никаких тестов на продакшене. Мы разворачиваем копию сайта с известными характеристиками: каталог из 50–100 товаров, несколько типов плательщиков, настроенные способы доставки и оплаты. Минимальная структура репозитория:

tests/
  e2e/
    fixtures/        # JSON с тестовыми данными
    pages/           # Page Object Model
    specs/           # сценарии
  playwright.config.ts

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

export default defineConfig({
  testDir: './tests/e2e/specs',
  timeout: 30_000,
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: process.env.TEST_BASE_URL || 'https://test.shop.example.com',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'mobile',   use: { ...devices['iPhone 13'] } },
  ],
});

Page Object Model для Битрикс

Стандартные компоненты bitrix:sale.order.ajax, bitrix:sale.basket.basket и bitrix:system.auth.form имеют устойчивые CSS-классы. Page Object изолирует локаторы от тестов — если в новой версии шаблона меняется верстка, правим один файл, а не все сценарии.

// tests/e2e/pages/CartPage.ts
import { Page, Locator } from '@playwright/test';

export class CartPage {
  readonly page: Page;
  readonly checkoutButton: Locator;
  readonly totalPrice: Locator;

  constructor(page: Page) {
    this.page           = page;
    this.checkoutButton = page.locator('.basket-checkout-btn');
    this.totalPrice     = page.locator('.basket-coupon-block-total-price-current');
  }

  async goto() {
    await this.page.goto('/personal/cart/');
  }

  async applyPromocode(code: string) {
    await this.page.fill('.basket-coupon-field-input', code);
    await this.page.click('.basket-coupon-apply-btn');
    await this.page.waitForResponse(resp =>
      resp.url().includes('ajax_basket') && resp.status() === 200
    );
  }
}

Ключевые сценарии

Добавление в корзину и оформление заказа:

// tests/e2e/specs/checkout.spec.ts
import { test, expect } from '@playwright/test';
import { CartPage } from '../pages/CartPage';

test('checkout flow', async ({ page }) => {
  // Добавляем товар со страницы каталога
  await page.goto('/catalog/electronics/headphones/sennheiser-hd-599/');
  await page.click('.catalog-element-offer-set-item:first-child'); // выбор SKU
  await page.click('.btn-buy');
  await expect(page.locator('.bx-basket-count')).toContainText('1');

  // Переход в корзину
  const cart = new CartPage(page);
  await cart.goto();
  await expect(cart.totalPrice).toBeVisible();

  // Оформление
  await cart.checkoutButton.click();
  await page.fill('#order-name', 'Иван Иванов');
  await page.fill('#order-email', '[email protected]');
  await page.fill('#order-phone', '+79001234567');
  await page.click('#pay-system-1'); // выбор способа оплаты

  await Promise.all([
    page.waitForURL(/\/order\/success\//),
    page.click('.btn-checkout-submit'),
  ]);

  await expect(page.locator('.sale-order-detail-result')).toBeVisible();
});

Авторизация и личный кабинет:

test('login and account access', async ({ page }) => {
  await page.goto('/personal/login/');
  await page.fill('#USER_LOGIN', '[email protected]');
  await page.fill('#USER_PASSWORD', 'testpassword123');
  await page.click('.login-btn');

  await expect(page).toHaveURL(/\/personal\//);
  await expect(page.locator('.personal-user-name')).toContainText('Иван');
});

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

Настраиваем прогон тестов при каждом пуше в main/staging. В случае падения артефакты (скриншоты, трейсы) сохраняются для анализа. Пример конфига GitHub Actions:

# .github/workflows/e2e.yml
name: E2E Tests
on:
  push:
    branches: [main, staging]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
        env:
          TEST_BASE_URL: ${{ secrets.TEST_BASE_URL }}
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Что входит в настройку E2E (что мы отдаём)

• Аудит текущей архитектуры: какие компоненты используются, как реализована асинхронность, какие сценарии критичны.
• Проектирование тестового покрытия: согласование списка сценариев с вашей командой.
• Написание Page Object Model для 5–10 ключевых компонентов.
• Реализация 15–30 тестовых сценариев (корзина, checkout, авторизация, фильтрация, промокоды, личный кабинет).
• Настройка CI/CD прогона (GitHub Actions / GitLab CI / Jenkins).
• Документация по запуску и поддержке тестов.
• Обучение команды: 2–3 часовой воркшоп по добавлению новых сценариев.

Какие сценарии покрывать в первую очередь?

Стабильность тестов — главная задача. Мы используем waitForResponse вместо waitForTimeout, локаторы по data-testid там, где стандартные CSS-классы меняются при обновлениях шаблона. При нестабильных тестах проблема почти всегда в асинхронности Битрикс AJAX, а не в Playwright.

Наш опыт и гарантии

Мы — сертифицированные партнёры 1С-Битрикс с опытом более 5 лет. За это время реализовали E2E-тестирование для 20+ проектов разной сложности — от небольших интернет-магазинов до корпоративных порталов на Битрикс24. Гарантируем стабильность тестов: после передачи они не падают на пустых изменениях. Если возникают вопросы — бесплатно консультируем в течение месяца после сдачи.

Как заказать настройку?

Оценим ваш проект за 1–2 рабочих дня. Для этого нужен доступ к репозиторию и тестовой среде. Свяжитесь с нами — расскажем, какие сценарии покроем в первую очередь и сколько это займёт времени по срокам.

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.

Сроки

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