Обновления ядра Битрикс выходят каждые две недели. После каждого апдейта — ручное регрессионное тестирование на 4–8 часов. Интеграция с 1С через CommerceML добавляет риски. Мы автоматизируем регресс как минимум в 24 раза быстрее: тесты выполняются за 10–15 минут вместо четырёх часов. За более чем 8 лет работы мы автоматизировали регресс для более чем 30 проектов. Без автоматизации проект теряет до 20% бюджета на тестировании.
Почему Битрикс требует особого подхода к тестированию
Главная проблема — монолитная архитектура. Все компоненты завязаны на глобальное состояние: \Bitrix\Main\Application::getInstance(), \CMain, $DB. Unit-тесты невозможно запустить без инициализации ядра. Нужна специальная инфраструктура. Второй момент — частые обновления. Каждый апдейт может сломать интеграцию с 1С или кастомные решения. Третий — сложность изоляции. Без автоматизации каждый новый релиз — стресс. Мы решаем эти проблемы с помощью проверенного стека инструментов.
Стек инструментов
Для Битрикс-проектов актуальна комбинация:
- PHPUnit — unit-тесты для изолируемой бизнес-логики.
- Codeception — функциональные и интеграционные тесты (имеет модуль для Bitrix).
- Playwright — e2e тесты браузерного поведения.
- PHPStan — статический анализ (не тест, но часть CI).
Закажите разработку системы тестирования уже сегодня — это окупится после двух обновлений.
Как настроить PHPUnit для Битрикс
Главная проблема unit-тестирования Битрикс — код зависит от глобального состояния: \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>
Что тестировать unit-тестами
Бизнес-логика, изолированная в классах без прямой зависимости от ядра:
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 часа. В результате каждый коммит проходит проверку: unit-тесты за 30 секунд, функциональные — за 3 минуты, e2e — за 5–10 минут. При обнаружении ошибок сборка останавливается, и разработчик получает уведомление.
Согласно документации 1С-Битрикс, тестовое окружение должно быть изолировано от боевого. Поэтому все тесты выполняются на копии базы данных с тестовыми данными.
Сравнение ручного и автоматического тестирования
| Критерий |
Ручное тестирование |
Автоматическое тестирование |
| Время регресса |
4–8 часов |
10–15 минут |
| Периодичность |
После каждого релиза |
При каждом коммите |
| Вероятность ошибки |
Высокая (человеческий фактор) |
Низкая (воспроизводимость) |
| Стоимость одного цикла |
Высокая (трудозатраты) |
Низкая (серверное время) |
| Поддержка обновлений |
Требуется ручная перепроверка |
Автоматический запуск, правка 1–3 тестов |
Автоматизация окупается за 2–3 месяца.
Типичные этапы разработки системы тестирования
| Этап |
Длительность |
Результат |
| Аудит кода и архитектуры |
1–2 дня |
Список модулей для покрытия |
| Настройка bootstrap и инфраструктуры |
1–2 дня |
Рабочее тестовое окружение |
| Рефакторинг для внедрения зависимостей |
3–5 дней |
Тестируемый код |
| Unit-тесты для бизнес-логики |
5–10 дней |
Набор стабильных unit-тестов |
| Функциональные тесты (Codeception) |
3–5 дней |
Проверка HTTP-сценариев |
| E2E-тесты (Playwright) |
3–5 дней |
Покрытие критических путей |
| Интеграция в CI/CD |
1–2 дня |
Автоматический запуск при пуше |
| Документация и обучение |
1–2 дня |
Готовность команды к поддержке |
Что входит в разработку системы тестирования
- Аудит текущего кода и выделение тестируемых модулей.
- Настройка bootstrap-окружения PHPUnit для загрузки Битрикс в тестовом режиме.
- Рефакторинг кода для внедрения зависимостей и тестируемости.
- Написание unit-тестов для ключевой бизнес-логики.
- Настройка Codeception для функциональных тестов HTTP-сценариев.
- E2E тесты на Playwright для критических пользовательских путей.
- Интеграция в CI/CD (GitHub Actions, GitLab CI).
- Документация и обучение команды.
Мы гарантируем стабильность тестов при обновлениях ядра. Сертифицированные специалисты с опытом 5+ лет и более 30 проектов по автоматизации Битрикс.
Готовы автоматизировать тестирование вашего Битрикс-проекта? Свяжитесь с нами — оценим проект бесплатно и предложим решение под ключ. Получите консультацию прямо сейчас.
CIBlockElement::GetList и пагинация — баг, который живёт годами
Классический кейс: на сайте каталог с пагинацией через компонент bitrix:catalog.section. Заказчик жалуется — на третьей странице дублируются товары. Лезешь в кеш компонента, чистишь — вроде ок. Через день снова. Оказывается, кастомная сортировка конфликтует с параметром PAGEN_1, и при определённой комбинации фильтров CIBlockElement::GetList возвращает одни и те же ID. Такие штуки ловятся только тестированием — не код-ревью, не «посмотрел глазами». Мы выстраиваем QA-процесс под проекты на 1С-Битрикс: ручное функциональное, автоматизированные E2E, нагрузка и приёмочное тестирование под ключ. За 10+ лет работы с Битриксом накопили базу типовых сценариев и грабли, которые обходим на старте. Свяжитесь с нами — пришлём тест-план в течение двух дней.
Проекты на 1С-Битрикс — не лендинги. Под капотом — десятки модулей, интеграции и неочевидные зависимости. Цепочки в бизнес-логике — поправил расчёт скидок в sale.discount, а промокод через sale.basket.discount перестал применяться. Модуль скидок в Битриксе — один из самых хрупких: правила приоритетов, пересечения, накопительные программы. Одна правка — каскад сбоев. Интеграция с 1С — обмен через catalog.import.1c или REST. Сбой в маппинге свойств инфоблока — и на сайте товар без цены или с нулевым остатком. Рассинхронизация заказов — потерянные продажи. Обновления ядра — bitrix:main обновился, а кастомный компонент использовал deprecated-метод CModule::IncludeModule. Без регрессии — русская рулетка. Мультибраузерность — bitrix:sale.order.ajax рендерит формы по-разному в Safari и Chrome. Кнопка «Оформить заказ» на iPhone может уехать за пределы экрана.
Как тестирование на Битриксе предотвращает потерю заказов
Конкретный пример: магазин с оборотом 5 млн/мес. Сломанная корзина за выходные — потери могут достигать 2 000 000 ₽. Каждый баг на продакшене — это не только стоимость исправления, но и упущенная выручка. Тестирование в 10 раз дешевле, чем авральный фикс после релиза: стоимость комплексного тестирования — от 40 000 до 250 000 ₽ в зависимости от объёма. Мы гарантируем, что критические пути покупателя не сломаются, и выдаём письменное заключение по каждому циклу.
Что включает функциональное тестирование
Проверяем каждый бизнес-сценарий. Не «работает-не работает», а все граничные случаи.
Каталог (компоненты 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-ку.
Профиль нагрузки для магазина на Битрикс:
| Сценарий |
Доля |
Целевой отклик |
Что ломается первым |
| Главная |
20% |
< 1 сек |
Композитный кеш, если не настроен |
| Каталог с фильтрами |
30% |
< 2 сек |
MySQL — тяжёлые JOIN по b_iblock_element_property |
| Карточка товара |
25% |
< 1.5 сек |
Запросы к торговым предложениям |
| Добавление в корзину |
10% |
< 1 сек |
Блокировки таблицы b_sale_basket |
| Оформление заказа |
5% |
< 3 сек |
Обработчики доставки (внешние API) |
| Поиск |
10% |
< 2 сек |
b_search_content без индексов |
Инструменты:
-
k6 — JavaScript-сценарии (официальный сайт), легко моделировать бизнес-логику корзины и чекаута
- Apache JMeter — классика, подходит для сложных сценариев с cookie-авторизацией
- Яндекс.Танк — визуализация в реальном времени, интеграция с Overload
На выходе: максимальный RPS, время отклика по перцентилям p50/p95/p99, узкие места (CPU, RAM, MySQL slow queries на b_iblock_element, файловый кеш). Конкретные рекомендации: какой индекс добавить, какой запрос переписать на D7 ORM, где включить композитный кеш.
Что входит в работу по тестированию
Мы передаём заказчику полный комплект deliverables:
- Тест-план с описанием объёмов, приоритетов и критериев качества
- Набор тест-кейсов — функциональные, регрессионные, нагрузочные сценарии
- Отчёт по дефектам в трекере (Jira/YouTrack) с классификацией по серьёзности
- Автотесты (Playwright/Cypress) — базовый smoke-набор, который запускается в CI/CD
- Протокол нагрузочного тестирования с графиками и рекомендациями
- Акт приёмки после UAT — фиксируем готовность к запуску
После передачи предоставляем бесплатную консультацию в течение месяца — отвечаем на вопросы по доработке тестов и адаптации процесса. Закажите тестирование — получите полный пакет документов и автотесты.
Кроссбраузерное тестирование
Проверяем там, где реально сидят покупатели. Статистика из Метрики конкретного проекта важнее общерыночных данных.
Минимальный набор:
- 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 и геолокации
Playwright в 3 раза быстрее Cypress при параллельном запуске тестов — это подтверждается сравнительными бенчмарками (см. Playwright vs Cypress Performance Comparison на Wikipedia).
Cypress:
- Работает в браузере — стабильнее для SPA-подобных интерфейсов
- Отличный визуальный runner для отладки
- Ограничение: только Chromium-based браузеры
PHPUnit для кастомного кода:
- Модульные тесты для кастомных компонентов и модулей Битрикс
- Тестирование бизнес-логики без зависимости от фронтенда
- Интеграция с CI/CD — GitLab CI, GitHub Actions
UAT — приёмочное тестирование
Финальная проверка с заказчиком на staging-окружении с актуальными данными:
- Совместно составляем список критических сценариев — не 200 тест-кейсов, а 15–20 ключевых путей покупателя
- Staging с копией продовой базы (обезличенные персональные данные)
- Оперативная фиксация багов — Jira/YouTrack, приоритизация по критичности
- Протокол приёмки — документ с результатами, подписи, готовность к запуску
Закажите UAT-сопровождение — и мы гарантируем, что релиз пройдёт без сюрпризов.
QA-процесс
Тестирование встроено в разработку, не приклеено в конце:
-
Анализ требований — QA участвует в обсуждении задач, ловит неоднозначности. «Скидка применяется к товару или к заказу?» — такой вопрос на старте экономит два дня отладки
-
Тест-кейсы до разработки — сценарии готовы до первой строки кода
-
Code review — проверка на типичные ошибки Битрикса: неочищенный кеш компонентов, прямые SQL-запросы вместо ORM, отсутствие проверки
$USER->IsAuthorized()
-
Функциональное → регрессионное → деплой
-
Мониторинг после релиза — ошибки в
bitrix/error.log, метрики в Метрике, алерты по 500-м
Мы работаем с Битриксом 10+ лет, провели тестирование на 300+ проектах разного масштаба — от небольших интернет-магазинов до корпоративных порталов с интеграцией 1С и Битрикс24.
Сроки
| Задача |
Сроки |
| Тест-план |
2–3 дня |
| Функциональное тестирование (средний магазин) |
3–5 дней |
| Базовый набор E2E-автотестов (Playwright) |
2–3 недели |
| Нагрузочное тестирование + отчёт |
1–2 недели |
| Кроссбраузерное |
2–3 дня |
| UAT-сопровождение |
3–5 дней |
| QA-процесс с нуля |
3–4 недели |
Стоимость тестирования рассчитывается индивидуально под ваш проект. Свяжитесь с нами — оценим объём работ за один рабочий день. Получите предварительный расчёт и тест-план бесплатно.