Тестирование сайтов на 1С-Битрикс — регресс после обновления ядра и маркетплейс-решений

Что обычно болит

Обновление ядра и модулей на 1С-Битрикс редко ломает всё сразу. Ломается точечно: перестаёт применяться купон, слетает шаблон компонента после автообновления, кастомный обработчик события перестаёт вызываться, composite отдаёт закешированную корзину. Всё это видно только на сквозном сценарии «нашёл товар → положил в корзину → оформил заказ → оплатил», и почти никогда — на странице, которую открыл разработчик.

Вторая типовая история — решения из Маркетплейса и правки в /local/. После обновления они отваливаются молча, а узнаёт об этом клиент.

Что даёт QA Деск

Смоук магазина, который не надо придумывать. Пакет тест-кейсов интернет-магазина — каталог, фильтр, корзина, оформление и оплата — и регресс регистрации и авторизации добавляются в проект из каталога и правятся под ваш сайт.

Версия ядра — поле дефекта. Сборка, окружение и платформа заполняются у дефекта отдельно, поэтому «упало на 24.100 на стейдже» — это фильтр, а не строчка в описании. При следующем обновлении видно, что именно ломалось в прошлый раз.

Ошибка прода приходит сама. Если на сайте стоит Sentry (PHP SDK ставится в проект и работает с 1С-Битрикс как с обычным PHP-приложением), ошибка уровня error или fatal становится дефектом выбранного проекта — с типом исключения, местом и ссылкой на issue. Одна ошибка — один дефект, повторные срабатывания дублей не плодят. Настройка — на странице Sentry.

Задачи разработке остаются там, где они были. Для команд, которые ведут разработку в Битрикс24, дефект связывается с задачей портала: в ленту задачи уходит комментарий со ссылкой, а исполнителю не нужно знать, что такое QA Деск, чтобы прочитать шаги. Это приложение на портале, а не интеграция по API.

Автотесты: то, что уже пишут для PHP

Приём не зависит от раннера — нужен отчёт в JUnit XML или Allure.

# PHPUnit → JUnit XML → QA Деск
vendor/bin/phpunit --log-junit reports/junit.xml
QADESK_TOKEN=qdit_… qadesk-cli upload --run "shop regress" --env stage ./reports

Браузерные проверки каталога и оформления заказа удобнее держать на Playwright: он не зависит от того, что внутри — компоненты Битрикса, вставки на jQuery или отдельный фронтенд.

Ключ кейса ставится в имени теста (QAD-C17), в property qadesk.case для JUnit или в label qadesk_case для Allure — тогда автотест и ручная проверка попадают в одну строку покрытия, а не считаются двумя разными мирами.

Что стоит проверять после каждого обновления

Оформление заказа гостем и авторизованным пользователем, включая оплату
Скидки, купоны и правила корзины — они чаще всего завязаны на обработчики событий
Кастомные компоненты и шаблоны из /local/: сравните с копией до обновления
Решения из Маркетплейса, которые трогают заказ или каталог
Кеш и composite: сценарий с корзиной под двумя разными пользователями
Почтовые события — письма о заказе после обновления теряются особенно обидно

Тот же список удобно держать не в документе, а тест-планом: прогон показывает, кто и когда проверил, а из упавшего шага заводится дефект с уже перенесёнными шагами.

Чего в продукте нет

QA Деск не обновляет ядро и не сравнивает файлы /bitrix/ — это работа обновлятора платформы;
отдельного модуля для Маркетплейса 1С-Битрикс нет; продукт живёт как облачный сервис и Коробка;
приложение на портале — это про Битрикс24, а не про «Управление сайтом»: для сайта на 1С-Битрикс используется обычный кабинет, и это нормальный сценарий.

С чего начать

Заведите проект под сайт и добавьте пакеты «смоук магазина» и «регистрация и авторизация».
Заполните у первых дефектов сборку и окружение — через два обновления это уже история, по которой видно закономерности.
Подключите Sentry, если он есть: половина дефектов после релиза придёт без участия человека.
Добавьте в пайплайн шаг выгрузки отчёта PHPUnit или Playwright — см. GitLab CI.

Попробуйте на своём проекте

Заведите проект, загрузите первый отчёт или заведите первый дефект — бесплатный тариф без карты. Нужно демо на ваших сценариях — напишите на hello@qadesk.ru.

Создать проект

Рядом по теме

Платформы

1С:Предприятие

Конфигурации 1С живут в том же реестре, что и остальной портфель: релиз платформы и конфигурации — поля дефекта, чек-листы регресса берутся готовыми, сценарии Vanessa Automation приезжают отчётом из вашего CI.

1С:Предприятие — регресс обновлений без таблиц в почте

Автотесты, CI и мониторинг

Playwright

Playwright пишет отчёт, QA Деск делает из него прогон: ключ кейса связывает автотест с ручной проверкой, повтор задания не плодит дубли, а упавший сценарий превращается в дефект.

Playwright — сценарии в браузере, результат в покрытии