Розробка системи автоматичного тестування для 1С-Бітрікс

Ми пропонуємо послуги з автоматичного тестування 1С-Бітрікс, включаючи регресійне тестування Bitrix, тестування інтеграції з 1С, та використовуємо такі інструменти, як PHPUnit Бітрікс, Codeception Bitrix, Playwright Bitrix для юніт-тестів Bitrix, функціональних тестів Bitrix та e2e тестів Bitrix. Наші рішення з CI/CD для Бітрікс забезпечують швидку автоматизацію.

Оновлення ядра Бітрікс виходять кожні два тижні. Після кожного апдейту — ручне регресійне тестування на 4–8 годин. Інтеграція з 1С через CommerceML додає ризики. Ми автоматизуємо регрес як мінімум у 24 рази швидше: тести виконуються за 10–15 хвилин замість чотирьох годин. Автоматизоване тестування виконує регрес у 24 рази швидше, ніж ручне. За понад 8 років роботи ми автоматизували регрес для більш ніж 30 проектів. Без автоматизації проект втрачає до 20% бюджету на тестуванні. Середній бюджет на автоматизацію для проекту середнього розміру — $2,000–$5,000, а економія на регресі становить до 80%.

Чому Бітрікс вимагає особливого підходу до тестування

Головна проблема — монолітна архітектура. Всі компоненти зав'язані на глобальний стан: \Bitrix\Main\Application::getInstance(), \CMain, $DB. Юніт-тести неможливо запустити без ініціалізації ядра. Потрібна спеціальна інфраструктура. Другий момент — часті оновлення. Кожен апдейт може зламати інтеграцію з 1С або кастомні рішення. Третій — складність ізоляції. Без автоматизації кожен новий реліз — стрес. Ми вирішуємо ці проблеми за допомогою перевіреного стеку інструментів.

Стек інструментів

Для Бітрікс-проектів актуальна комбінація:

• PHPUnit — юніт-тести для ізольованої бізнес-логіки.
• Codeception — функціональні та інтеграційні тести (має модуль для Bitrix).
• Playwright — e2e тести браузерної поведінки.
• PHPStan — статичний аналіз (не тест, але частина CI).

Замовте розробку системи тестування вже сьогодні — це окупиться після двох оновлень.

Як налаштувати PHPUnit для Бітрікс

Головна проблема юніт-тестування Бітрікс — код залежить від глобального стану: \Bitrix\Main\Application::getInstance(), \CMain, $DB. Запустити тест без ініціалізації ядра не можна.

Рішення — завантажувати ядро в bootstrap-файлі тестів:

// tests/bootstrap.php
$_SERVER['DOCUMENT_ROOT'] = dirname(__DIR__);
define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS', true);
define('BX_WITH_ON_AFTER_EPILOG', false);

require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';

phpunit.xml:

<phpunit bootstrap="tests/bootstrap.php">
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/unit</directory>
        </testsuite>
    </testsuites>
</phpunit>

Що тестувати юніт-тестами

Бізнес-логіка, ізольована в класах без прямої залежності від ядра:

class ArticleResolverTest extends TestCase
{
    public function testResolveValidArticle(): void
    {
        $resolver = new ArticleResolver($this->createMockRepository());
        $result = $resolver->resolve('ABC-123', CATALOG_IBLOCK_ID);
        $this->assertSame(456, $result->getSkuId());
    }

    public function testResolveUnknownArticleReturnsNull(): void
    {
        $resolver = new ArticleResolver($this->createEmptyRepository());
        $this->assertNull($resolver->resolve('UNKNOWN', CATALOG_IBLOCK_ID));
    }
}

Ключовий патерн: впровадження залежностей замість прямих викликів статичних методів Бітрікс — це і робить код тестованим. Економія на регресі може досягати 80%.

Функціональні тести з Codeception

Codeception з модулем для Бітрікс дозволяє тестувати HTTP-сценарії без браузера:

// tests/functional/OrderCheckoutCest.php
class OrderCheckoutCest
{
    public function addToCartAndCheckout(FunctionalTester $I): void
    {
        $I->amOnPage('/catalog/product-slug/');
        $I->click('Додати в кошик');
        $I->seeInDatabase('b_sale_basket', ['PRODUCT_ID' => 123]);

        $I->amOnPage('/order/');
        $I->fillField('NAME', 'Тест Тестов');
        $I->fillField('EMAIL', '[email protected]');
        $I->click('Оформити замовлення');
        $I->seeInDatabase('b_sale_order', ['STATUS_ID' => 'N']);
    }
}

E2E тести з Playwright

Для критичних користувацьких шляхів — e2e тести, які запускають справжній браузер:

// tests/e2e/checkout.spec.js
test('full checkout flow', async ({ page }) => {
    await page.goto('/catalog/product-slug/');
    await page.click('.add-to-cart-btn');
    await expect(page.locator('.cart-count')).toHaveText('1');

    await page.goto('/order/');
    await page.fill('[name="NAME"]', 'Test User');
    await page.fill('[name="EMAIL"]', '[email protected]');
    await page.click('.submit-order-btn');
    await expect(page).toHaveURL(/\/order\/success\//);
});

Як інтегрувати тести в CI/CD?

Тести запускаються автоматично при пуші в репозиторій. Ми використовуємо GitHub Actions або GitLab CI. Налаштування займає 2–4 години. В результаті кожен коміт проходить перевірку: юніт-тести за 30 секунд, функціональні — за 3 хвилини, e2e — за 5–10 хвилин. При виявленні помилок збірка зупиняється, і розробник отримує сповіщення.

Згідно з документацією 1С-Бітрікс, тестове середовище має бути ізольоване від бойового. Тому всі тести виконуються на копії бази даних з тестовими даними.

Для детального ознайомлення з налаштуваннями конвеєра CI/CD використовуйте офіційну документацію GitHub Actions або GitLab CI.

Порівняння ручного та автоматичного тестування

Автоматизація окупається за 2–3 місяці.

Типові етапи розробки системи тестування

Покроковий план:

1. Аудит коду та архітектури.
2. Налаштування інфраструктури та bootstrap.
3. Рефакторинг для впровадження залежностей.
4. Написання юніт-тестів для бізнес-логіки.
5. Функціональні тести (Codeception).
6. E2E-тести (Playwright).
7. Інтеграція в CI/CD.

Скільки коштує автоматизація тестування Бітрікс?

Вартість автоматизації залежить від обсягу проекту. Середній бюджет для проекту середнього розміру — $2,000–$5,000, а економія на регресі становить до 80%. Інвестиції окупаються за 2–3 місяці.

Що входить у розробку системи тестування

• Аудит поточного коду та виділення тестованих модулів.
• Налаштування bootstrap-середовища PHPUnit для завантаження Бітрікс у тестовому режимі.
• Рефакторинг коду для впровадження залежностей та тестованості.
• Написання юніт-тестів для ключової бізнес-логіки.
• Налаштування Codeception для функціональних тестів HTTP-сценаріїв.
• E2E тести на Playwright для критичних користувацьких шляхів.
• Інтеграція в CI/CD (GitHub Actions, GitLab CI).
• Документація та навчання команди.

Ми гарантуємо стабільність тестів при оновленнях ядра. Сертифіковані спеціалісти з досвідом 5+ років та більш ніж 30 проектів з автоматизації Бітрікс.

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

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

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