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

Уявіть: ви оновили CSS у шаблоні 1С-Бітрікс, змінили компонент або просто додали новий jQuery-плагін. Кнопка «Купити» з'їхала на 3 пікселі, блок із ціною перекрив галерею на мобільних, шрифт у картці товару став на 2px менше. Оком не вловити, а клієнти скаржаться на криву верстку. Візуальне регресійне тестування (VRT) вирішує цю проблему: робить скріншот сторінки до та після змін, порівнює попіксельно й підсвічує розбіжності. Ми впроваджуємо таку перевірку на проєктах Бітрікс і ділимося досвідом. За багато років ми реалізували понад 150 проєктів, і кожен стикався з візуальними регресіями після оновлень. Економія на тестуванні може бути значною: орієнтовно до $500 на місяць на середньому проєкті. Автоматизація тестування — єдиний спосіб гарантувати стабільність верстки без ручного перебору всіх сторінок.

Чому візуальне регресійне тестування необхідне для Бітрікс-проєктів?

Бітрікс-сайти — це складні шаблони з кастомізацією, компонентами та динамічним контентом. Навіть точкова зміна верстки може зламати адаптив, перекрити елементи або зіпсувати відображення на мобільних. Ручна перевірка всіх сторінок після кожного деплою — дорого і повільно. Автоматизація вирішує цю проблему: скріншоти знімаються за хвилини, а diff підсвічує відхилення. VRT економить до 20 годин ручного тестування на місяць на середньому проєкті. Крім того, воно виловлює регресії, які неможливо помітити очима — наприклад, зсув на 1px або зміну відступів. Наш досвід показує: 95% візуальних регресій виявляються автоматично. Час тестування скорочується на 70%.

Інструменти для VRT

Playwright із вбудованими snapshot-тестами — найбільш інтегрований варіант, якщо фреймворк уже використовується для E2E. За досвідом, Playwright в 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/**',
  },
];

Окремий мобільний тест для iPhone та Android.

Маскування динамічних елементів

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

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)
• Документація та навчання команди

Вартість налаштування під ключ — від $1500 (визначається після аналізу). Понад 10 років досвіду з 1С-Бітрікс, 150+ реалізованих проєктів. На ринку з 2013 року. Замовте налаштування — і ми гарантуємо стабільність верстки. Отримайте консультацію по вашому проєкту — пишіть, оцінимо його за 1 день.

Стратегія впровадження

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

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

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