Функціональне тестування сайту на 1С-Бітрікс

Функціональне тестування сайту на 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.

Інструменти

Для автоматизації функціональних тестів на Бітрікс найчастіше використовують:

• 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\//);
});

Терміни