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

Тестування проєктів на 1С-Бітрікс

CIBlockElement::GetList і пагінація — баг, який живе роками

Класичний кейс: на сайті каталог із пагінацією через компонент bitrix:catalog.section. Замовник скаржиться — на третій сторінці дублюються товари. Лізеш у кеш компонента, чистиш — начебто ок. Через день знову. Виявляється, кастомне сортування конфліктує з параметром PAGEN_1, і при певній комбінації фільтрів CIBlockElement::GetList повертає ті самі ID. Такі штуки ловляться тільки тестуванням — не код-рев'ю, не «подивився очима».

Ми вибудовуємо QA-процес під проєкти на 1С-Бітрікс: ручне функціональне, автоматизовані E2E, навантажувальне та приймальне тестування.

Чому на Бітріксі тестування критичне

Проєкти на 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. Кожен модуль — свій чек-лист.

Навантажувальне тестування

Питання не «чи витримає сайт», а «при скількох одночасних користувачах catalog.section почне віддавати 500-ку».

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

Інструменти:

• k6 — JavaScript-сценарії, легко моделювати бізнес-логіку кошика та чекауту
• Apache JMeter — класика, підходить для складних сценаріїв із cookie-авторизацією
• Yandex.Tank — візуалізація в реальному часі, інтеграція з Overload

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

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

Перевіряємо там, де реально сидять покупці. Статистика з Метрики конкретного проєкту важливіша за загальноринкові дані.

Мінімальний набір:

• 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 і геолокації

Cypress:

• Працює в браузері — стабільніше для SPA-подібних інтерфейсів
• Чудовий візуальний runner для відладки
• Обмеження: тільки Chromium-based браузери

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

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

UAT — приймальне тестування

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

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

QA-процес

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

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

Терміни

Баг на продакшені — це не тільки вартість виправлення. Це втрачені замовлення, поки баг живе. На проєкті з оборотом 5 млн/міс зламаний кошик за вихідні — втрати, які не покриє жоден бюджет на тестування.