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

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Разработка системы автоматического тестирования для 1С-Битрикс
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    944
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1074

Обновления ядра Битрикс выходят каждые две недели. После каждого апдейта — ручное регрессионное тестирование на 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-процесс

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

  1. Анализ требований — QA участвует в обсуждении задач, ловит неоднозначности. «Скидка применяется к товару или к заказу?» — такой вопрос на старте экономит два дня отладки
  2. Тест-кейсы до разработки — сценарии готовы до первой строки кода
  3. Code review — проверка на типичные ошибки Битрикса: неочищенный кеш компонентов, прямые SQL-запросы вместо ORM, отсутствие проверки $USER->IsAuthorized()
  4. Функциональное → регрессионное → деплой
  5. Мониторинг после релиза — ошибки в 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 недели

Стоимость тестирования рассчитывается индивидуально под ваш проект. Свяжитесь с нами — оценим объём работ за один рабочий день. Получите предварительный расчёт и тест-план бесплатно.