Комплексне тестування та аудит 1С-Бітрікс: знаходимо помилки до релізу

Ви запускаєте реліз, а наступного дня клієнти скаржаться, що кошик не перераховує знижку при зміні кількості товару. Знайома ситуація? Ми тестуємо Бітрікс-проекти понад 8 років і перевірили 150+ сайтів. На ринку з 2016 року. Без чіткого тест-плану, розбитого за модулями, такі баги вислизають — особливо в нестандартних сценаріях. Ми пропонуємо системний підхід: тестування кожного модуля окремо та інтеграційних зв'язок. Наша методика дозволяє скоротити бюджет на підтримку до 40% за рахунок раннього виявлення помилок. Економія на підтримці сягає до 40% — це зменшує щомісячні витрати на 40 000 грн для середнього інтернет-магазину. Замовте тестування та отримайте звіт з рекомендаціями — це окупається за рахунок зниження кількості інцидентів.

Чому функціональне тестування критичне для Бітрікс?

Бітрікс — складна платформа з безліччю модулів. Помилка в одному може вплинути на інші. Наприклад, неправильний запит до інфоблоку призводить до дублювання товарів на лістингу. Або збій в подіях замовлення — покупець не отримує листа. Ручне тестування без плану пропустить такі кейси. Після зміни властивостей товарів необхідно перебудувати фасетний індекс — типова точка відмови. Як зазначено в документації, розумний фільтр потребує періодичної перебудови індексу. Автоматизація знижує ризик людської помилки та прискорює регрес у 3 рази порівняно з ручним тестуванням, а точність виявлення багів на 50% вища. Ми гарантуємо якість тестування — сертифіковані фахівці 1С-Бітрікс.

Які модулі Бітрікс перевіряємо?

Каталог та інфоблоки (iblock)

• Коректність фільтрації за властивостями (IBLOCK_PROPERTY, розумний фільтр)
• Робота сортування за ціною, популярністю, новизною — перевіряємо SQL у b_iblock_element
• Пагінація без дублювання елементів на стику сторінок
• SEO-теги та мета-дані на сторінках розділів та елементів
• Коректне відображення торгових пропозицій (SKU) для товарів з варіантами

Кошик та оформлення замовлення (sale)

• Додавання товару, зміна кількості, видалення
• Застосування купонів (b_sale_discount_coupon)
• Коректний перерахунок знижок при зміні складу кошика
• Вибір доставки та оплати, збереження вибору при перезавантаженні
• Перевірка обмежень на мінімальну суму замовлення
• Створення замовлення без реєстрації (гість)

Особистий кабінет (subscribe, sale, socialservices)

• Реєстрація, авторизація, відновлення пароля
• Історія замовлень, повторне замовлення
• Редагування профілю, зміна email/пароля
• Авторизація через OAuth (ВКонтакті, Google, Яндекс)

Пошук (search)

• Повнотекстовий пошук — результати, релевантність
• Морфологія (українська мова, стемінг)
• Пошук з помилкою — якщо підключений модуль «Морфологічний пошук»
• Відсутність результатів — коректна сторінка «нічого не знайдено»

Технічні перевірки

Ряд перевірок не можна виконати лише кліками — потрібен доступ до бази та логів.

Перевірка дублювання елементів на лістингу

При використанні кількох інфоблоків через CIBlockElement::GetList з JOIN по торгових пропозиціях часто з'являються дублі. Перевіряють запитом:

SELECT ie.id, COUNT(*) as cnt
FROM b_iblock_element ie
JOIN b_catalog_price cp ON cp.product_id = ie.id
WHERE ie.iblock_id = 5
GROUP BY ie.id
HAVING COUNT(*) > 1;

Перевірка роботи розумного фільтра

Після зміни властивостей товарів або додавання нових елементів розумний фільтр може показувати застарілі дані. Перевіряють перебудову індексу:

// Примусовий перерахунок фасетного індексу
\Bitrix\Iblock\PropertyIndex\Manager::markAsInvalid($iblockId);
\Bitrix\Iblock\PropertyIndex\Manager::updateIndex($iblockId);

Перевірка подій замовлення

Після оформлення тестового замовлення перевіряємо наявність потрібних подій у b_sale_order_change_data та коректність відправлених email-повідомлень через /bitrix/admin/mail_event_message_list.php.

Як автоматизувати тестування на Бітрікс?

Автоматизація в 3 рази скорочує час регресійного тестування порівняно з ручним. Для функціональних тестів використовуємо:

• Playwright — для end-to-end тестів браузерного флоу (кошик, оформлення)
• PHPUnit — для unit-тестів компонентів та хелперів
• Postman / Bruno — для тестування REST API (якщо проект використовує кастомний API)

Базовий e2e-тест оформлення замовлення на Playwright:

test('checkout flow', async ({ page }) => {
    await page.goto('/catalog/product-slug/');
    await page.click('[data-role="add-to-cart"]');
    await page.goto('/cart/');
    await expect(page.locator('.cart-item')).toHaveCount(1);
    await page.click('[data-role="checkout"]');
    await page.fill('#phone', '+79001234567');
    await page.fill('#email', '[email protected]');
    await page.selectOption('#delivery', 'pickup');
    await page.click('[type="submit"]');
    await expect(page).toHaveURL(/\/personal\/order\/detail\//);
});

Як ми тестуємо: покроковий процес

1. Аналіз архітектури сайту та інтеграцій — виявляємо критичні шляхи.
2. Складання тест-плану за модулями з пріоритетами.
3. Ручне тестування за сценаріями — фіксуємо баги.
4. Автоматизація регресійних тестів (Playwright, PHPUnit).
5. Підготовка звіту з рекомендаціями та повторне тестування після фіксів.

Що входить в роботу

• Документація: детальний тест-план, баг-репорти зі скріншотами та логами
• Доступ до тестового середовища на час тестування
• Навчання вашої команди роботі з автотестами (за потреби)
• Підтримка після тестування протягом 30 днів

Що ви отримуєте?

Перед замовленням тестування переконайтеся, що у вас є доступ до адмінки та бази даних. Підготуйте тестові дані (товари, купони, користувачі). Визначте критичні сценарії (оформлення замовлення, оплата). Зберіть логи за допомогою bitrix_debug. Залиште заявку — ми підготуємо тест-план за один день.

Строки

Зв'яжіться з нами для оцінки вашого проекту — ми підберемо оптимальний набір тестів під ваш бюджет. Замовте тестування під ключ і отримайте детальний звіт з рекомендаціями. Економія на підтримці після тестування сягає 40%. Додатково ми проводимо навантажувальне тестування Бітрікс для оцінки працездатності під навантаженням.

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

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