Проверка сайта на 1С-Битрикс: выявляем ошибки до клиентов

Функциональное тестирование 1C-Битрикс: где ломается сайт

Функциональное тестирование 1C-Битрикс начинается не с проверки вёрстки, а с бизнес-сценариев, где ошибка стоит дороже всего: оформление заказа, обмен с 1С, разграничение прав, внешние интеграции. Эти места ломаются тихо — страница открывается, кнопки нажимаются, а на стороне заказчика уже теряются заказы и расходятся остатки.

Корзина — классическая точка отказа. Товар добавляется, но при пересчёте скидки или смене способа доставки сумма пересчитывается неверно; промокод применяется к одной позиции вместо всей корзины; при параллельных заказах списывается лишний остаток. Клиент видит ошибку на сайте в момент оплаты — и уходит, а не сообщает о ней.

Обмен с 1С рвётся незаметно для витрины: цены и остатки перестают обновляться, заказы не выгружаются в учётную систему, расходятся номенклатура и склады. Ошибка накапливается сутками, пока менеджер не сверит данные вручную. Права доступа — третья зона риска: гость видит цены для оптовиков, менеджер региона получает доступ к чужой базе, а раздел для авторизованных открыт по прямой ссылке.

Интеграции с платежами, службами доставки и внешними сервисами добавляют свои сбои: платёж проходит, но статус заказа не меняется; расчёт доставки возвращает пустой ответ на нестандартный адрес. Каждый такой разрыв — это ручная работа поддержки, возвраты и потерянное доверие. Разбираем, как выявлять эти точки отказа до того, как их найдут клиенты.

Что даёт проверка: измеримый эффект для бизнеса

Функциональное тестирование 1C-Битрикс отвечает на один вопрос: что именно ломается у пользователя после очередного изменения. Регрессионный набор прогоняется на каждом релизе и закрывает типовые сценарии — оформление заказа, оплату, регистрацию, выгрузку каталога, обмен с 1C. Ошибки, которые раньше всплывали в проде через день-два после выкладки, отлавливаются до публикации, поэтому поток обращений в поддержку падает предсказуемо: тикетов становится меньше в разы, а не на проценты.

Скорость выпуска изменений растёт не за счёт «быстрее пишем код», а за счёт снятого страха выкатки. Когда есть автоматические проверки на ключевых путях и понятный протокол отката, релизы уходят чаще и мельче — правки в шаблонах, компонентах, правилах обмена с 1C перестают быть событием на весь день. Команда не тратит время на ручной перещёлкивание одних и тех же сценариев, а поддержка занимается развитием, а не разбором однотипных инцидентов.

Отдельный эффект — исчезновение целых классов отказов. Проверки на целостность данных при обмене с 1C убирают рассинхрон остатков и цен; тесты корзины и оплаты — зависшие заказы и потерянные платежи; контроль прав доступа — утечки через открытые разделы. Это не «стало чуть надёжнее», а другой профиль эксплуатации: стабильность сайта перестаёт зависеть от того, кто именно выложил релиз и в какую смену.

На практике это видно по метрикам: доля инцидентов, найденных пользователями, снижается, среднее время между релизами сокращается, а время на разбор одного обращения падает, потому что причина уже локализована тестом. Разбираем, как такой контур проверок выстраивается под конкретный сайт и его интеграции с 1C.

Режимы проверки: ручной прогон, автотесты, регресс

Три режима не заменяют, а дополняют друг друга: ручное тестирование ловит то, что не опишешь формальным сценарием, автотесты держат стабильность на длинной дистанции, регрессионное тестирование защищает уже работающие сценарии от новых правок. Выбор зависит от того, что меняется в релизе и какова цена ошибки на конкретном участке.

Как выбираем режим под задачу

Если релиз трогает бизнес-логику — оплату, личный кабинет, обмен с 1С — сначала ручной прогон новых сценариев, затем закрепление их автотестами. Так проверка не теряется со следующей правкой: сценарий один раз описан и дальше выполняется без человека.

Для регулярных обновлений ядра и модулей достаточно регресса по приоритетным путям и дымовых проверок после выката. Полный прогон всех сценариев на каждом релизе неоправдан — отбираем те, что задевают изменённый код.

Что даёт сочетание режимов

Ручное тестирование выявляет дефекты, которые автотесты пропускают: неверные тексты, смещённую вёрстку, нелогичные переходы. Автотесты фиксируют результат и убирают человеческий фактор на повторяющихся шагах.

Регрессионное тестирование закрывает главный риск — «поправили одно, сломали другое». Дымовые проверки дают быструю уверенность, что сайт жив после деплоя, и позволяют откатить релиз до того, как проблему увидит клиент.

Как проходит проверка: этапы инженерной работы

Проверка начинается не с запуска тестов, а с инвентаризации: какие компоненты и модули задействованы, где кеширование, какие интеграции с 1С и внешними сервисами, какие сценарии критичны для бизнеса. Без этого схема проверок получается формальной — покрывает то, что легко проверить, а не то, что ломается в проде. Поэтому первый этап всегда даёт карту системы и список рисков, а не отчёт о количестве прогонов.

Дальше выстраиваем последовательность так, чтобы каждый этап опирался на результат предыдущего.

1. Аудит сайта — разбираем структуру, версии ядра и модулей, историю правок, текущие ошибки в логах. Фиксируем, что уже работает нестабильно: это будущие точки отказа.
2. Схема проверок — описываем, какие пути покрываем, какие сценарии считаем критичными, что проверяем вручную, а что автоматизируем. Согласуем приоритеты: сначала то, что напрямую влияет на заказы и данные.
3. Настройка окружения — поднимаем копию, максимально близкую к боевой: те же версии, те же настройки кеша и очередей, та же база 1С. Проверка на «чистой» сборке ловит несуществующие проблемы и пропускает реальные.
4. Прогон тестов — функциональное тестирование 1C-Битрикс идёт по согласованным сценариям: оформление заказа, обмен с 1С, права доступа, формы, интеграции. Каждое падение фиксируем с шагами воспроизведения, а не просто «не работает».
5. Разбор и приоритизация — делим найденное на блокеры, критичные и косметические. Блокеры чиним сразу, остальное — с оценкой и очередностью.
6. Повторный прогон — подтверждаем, что правки не сломали соседние сценарии. Регресс здесь дешевле, чем откат на проде.
7. Передача результатов — отчёт с воспроизводимыми шагами, список исправленного, оставшиеся риски и рекомендации по мониторингу.

Такая последовательность даёт предсказуемый результат: к моменту выкладки у команды есть не «вроде всё проверили», а список покрытых путей и явно названные зоны, которые остались вне проверки. Опишите вашу задачу — вернёмся с оценкой и планом проверки под ваш контур.

Что остаётся на руках: артефакты и регламенты

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

• Тест-кейсы по критичным сценариям: оформление заказа, оплата, регистрация, интеграция с 1С, выгрузка каталога. Каждый шаг с ожидаемым результатом и пометкой, воспроизводится ли дефект повторно.
• Отчёт о проверке: что тестировали, на каком окружении, какие дефекты нашли, что исправлено, что осталось с пометкой приоритета. Без «всё хорошо» — с привязкой к конкретным страницам и сценариям.
• Карта рисков: узкие места, которые не ломаются сейчас, но дадут сбой при росте нагрузки или обновлении ядра — тяжёлые запросы к каталогу, синхронизация с 1С по расписанию, кэш компонентов.
• Регламент релиза: порядок выкладки, обязательные проверки перед публикацией, точки отката, кто подтверждает выпуск. Правило «сначала на тестовый контур, потом на боевой» перестаёт держаться на памяти одного инженера.
• Чек-лист приёмки: короткий список из 10-15 пунктов, который проходит руководитель или менеджер перед сдачей задачи — формы отправляются, письма доходят, оплата проходит, старая версия страницы открывается.
• Настроенный мониторинг: оповещения о падении сайта, ошибках в логах, недоступности обмена с 1С. Инцидент ловится до звонка клиента, а не после.
• Резервные копии и проверка восстановления: расписание, срок хранения, где лежат копии и как развернуть их на чистом окружении. Копия, которую ни разу не восстанавливали, копией не считается.
• Доступы и документация: учётные записи с ролями, схема окружений, инструкция по типовым операциям — обновление контента, добавление раздела, правка цен.

Комплект остаётся у заказчика и не привязан к нам: новый подрядчик или штатный разработчик входит в проект по этим документам, а не восстанавливает логику по коду. Регламент релиза и чек-лист приёмки обычно переживают несколько смен команды — именно они удерживают качество, когда проверка давно позади.

Кейс: как проверка убрала сбои обмена с 1С

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

Что было до проверки

Мы начали с функционального тестирования обмена: прогнали полный цикл синхронизации на тестовом контуре, разобрали журналы и воспроизвели сценарии, которые в обычной работе проходили «на удачу». Выявили накопленные сбои — от дублей позиций до обрывов на середине пакета, когда часть данных записывалась, а часть нет. Отдельно проверили поведение при повторном запуске: без корректной обработки повтор обмена множил ошибки вместо того, чтобы их исправлять.

Что изменили

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

Что стало

Число обращений в поддержку по расхождениям цен и остатков сократилось примерно в пять раз. Время простоя обмена при сбое уменьшилось с нескольких часов до минут — задача поднимается сама, без участия инженера. Доля успешных циклов синхронизации выросла до стабильных значений, а ручные правки каталога практически исчезли из ежедневной работы менеджеров.

Чем отличается проверка перед релизом от регулярного регресса?

Проверка перед релизом отвечает на один вопрос: можно ли выкатывать эту сборку сегодня. Инженеры прогоняют критичные сценарии — оформление заказа, оплату, авторизацию, выгрузку каталога, обмен с 1С — на том же наборе данных, что и продакшн. Задача — поймать регресс, который внесло конкретное изменение, и не пропустить его к клиентам. Такой прогон разовый: он привязан к дате выката и закрывается вместе с релизом.

Регресс — это не разовая акция, а постоянный контур качества. Он живёт независимо от релизов: набор проверок зафиксирован, выполняется по расписанию и после каждого изменения в коде, конфигурации или на стороне 1С. Смысл в том, что система меняется не только когда вы её трогаете: обновляется ядро платформы, приходят новые версии модулей, поставщик меняет выгрузку, обновляется сама 1С. Любое из этих событий может сломать сценарий, который вчера работал.

Разница проявляется в частоте и охвате. Перед релизом проверяют то, что затронуто правкой, — быстро и точечно. Регресс прогоняет весь критичный путь целиком, включая интеграции и фоновые задачи, и делает это регулярно, а не от случая к случаю. Именно поэтому регресс ловит деградацию, которую разовая проверка физически не увидит: расхождение остатков после обмена, таймауты на выгрузке, ошибки в письмах и уведомлениях.

Практический вывод простой: разовая проверка снижает риск конкретного релиза, а постоянный контур качества снижает риск всей системы. Первое без второго оставляет слепые зоны между выкатами — и именно там обычно и всплывают проблемы, о которых узнаёт клиент раньше, чем команда.

Частые технические сомнения заказчиков

Перед стартом работ почти всегда всплывают одни и те же вопросы — про нагрузку, доступы, интеграции и совместимость с тем, что уже работает. Ниже — ответы так, как мы их даём на технических встречах.

Какие доступы вам нужны и насколько это безопасно?

Нужен доступ к среде разработки и тестовому контуру, а к продуктиву — только на время выкладки. Работаем через отдельные учётные записи с ограниченными правами, без общего пароля администратора. Все действия фиксируются в журналах, доступ отзывается по завершении этапа — вы в любой момент видите, кто и что делал.

Не сломаются ли текущие интеграции?

Сначала инвентаризируем всё, что обменивается данными с сайтом: склад, оплата, доставка, CRM, внешние сервисы. Для каждой интеграции проверяем формат обмена, обработку ошибок и поведение при недоступности внешней стороны. Изменения выкатываем так, чтобы старые и новые вызовы работали параллельно, — тогда откат не рвёт связи.

Совместимо ли это с нашей инфраструктурой и версией платформы?

Перед оценкой сверяем требования с вашим окружением: версия ядра, конфигурация сервера, окружение базы данных, установленные модули. Если обновление обязательно, планируем его отдельным этапом с проверкой на копии боевого контура. Так вы видите реальные ограничения до начала работ, а не в момент выкладки.

Что если после релиза что-то пойдёт не так?

Держим точку отката: резервная копия базы и файлов перед выкладкой, версионирование изменений. Если после релиза появляется отклонение, возвращаемся к предыдущему состоянию за минуты, а причину разбираем на копии. Это стандартная часть регламента, а не отдельная услуга.

Опишите вашу задачу и текущий контур — вернёмся с оценкой, планом проверок и списком необходимых доступов.

Обсудим задачу: вернёмся с оценкой и планом

Проверка начинается с разбора текущего состояния: какие модули и компоненты задействованы, как устроены шаблоны, где хранятся данные, какие интеграции с 1С уже работают. Без этого плана не будет — функциональное тестирование 1C-Битрикс строится вокруг конкретной конфигурации проекта, а не по общему чек-листу. Опишите задачу в свободной форме: что беспокоит сейчас, что менялось в последнее время, какие сценарии клиентов ломаются чаще всего. Этого достаточно, чтобы вернуться с оценкой и планом проверки.

Дальше мы фиксируем объём работ и сроки, согласуем приоритеты и только после этого выходим на тестирование. В план входит:

• инвентаризация компонентов, модулей и кастомных доработок с оценкой риска;
• проверка пользовательских сценариев: заказ, оплата, регистрация, личный кабинет, формы;
• тестирование обмена с 1С — выгрузки, синхронизация номенклатуры, цен, остатков, заказов;
• проверка прав доступа и ролей: что видит гость, менеджер, администратор;
• прогон по браузерам и устройствам, включая мобильные сценарии;
• нагрузочная проверка ключевых страниц и точек входа;
• отчёт с перечнем дефектов, их приоритетами и рекомендациями по устранению.

По итогам вы получаете не абстрактное «всё работает», а список конкретных мест, где поведение системы расходится с ожидаемым, с указанием шагов воспроизведения. Это позволяет планировать доработки по факту, а не по догадкам.

Расскажите, что происходит с сайтом сейчас и какой результат нужен — вернёмся с оценкой, планом проверки и сроками.

Стек подбираем под задачу: ручные прогоны, автотесты, профилирование, средства мониторинга обмена. Работаем на профессиональном оборудовании — клиент получает стабильный и воспроизводимый результат, а не разовые замеры.