Налаштування E2E-тестування для 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', '+380123456789');
  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 робочих дні. Для цього потрібен доступ до репозиторію та тестового середовища. Зв'яжіться з нами — розкажемо, які сценарії покриємо в першу чергу і скільки це займе часу за строками.

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

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