Вернуться к списку Вернуться к статьям

Тестирование интеграции 1С и сайта: сценарии перед запуском | S-WEBS24

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

Как оформить тест-кейс

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

Например, для повторной выгрузки товара указывают идентификатор тестовой позиции, исходную цену, действие «повторить передачу без изменения данных» и ожидаемый результат «новая карточка не создана». Такую формулировку можно проверить по карточке, логу и числу объектов, не опираясь на впечатление участника теста.

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

Каталог и характеристики

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

Цена и наличие

Отдельные кейсы нужны для изменения цены, скидки, округления, обнуления остатка, резерва и отмены заказа. В каждом случае фиксируют время, за которое витрина должна отразить изменение по правилам конкретного проекта. Если действует задержка, её не маскируют ручным редактированием на сайте.

Заказы, статусы и сбой передачи

Минимальная проверка включает обычный заказ, отмену, частичную оплату и повторную передачу. Для сценария сбоя заранее определяют безопасный способ имитации, критерий остановки и порядок восстановления. Нельзя проверять восстановление на рабочем заказе покупателя без согласованного плана.

Критерии приёмки

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

Для подготовки используйте материалы о настройке обмена, номенклатуре и вариантах, контроле цены и сценариях остатков. Технические параметры конкретной связки необходимо сверять с документацией «1С-Битрикс» и конфигурацией проекта перед публикацией.