HTTP 200, но корзина не работает: проверка заказа

HTTP 200 подтверждает успешный ответ на запрос, но не весь процесс покупки. Главная может открываться, товар — добавляться в корзину, а заказ не сохраняться из-за сбоя расчёта доставки или интеграции. Владельцу магазина нужен контроль бизнес-сценария: от выбора товара до появления заказа там, где его обрабатывает команда.

Минимальная проверка: открыть карточку → добавить товар → изменить количество → выбрать доставку → оформить тестовый заказ → сверить данные в CMS и CRM. Оплату и отправку уведомлений тестируют в заранее согласованном режиме, без случайных списаний и сообщений реальным клиентам.

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

Мониторинг URL быстро сообщает, что сервер перестал отвечать или начал возвращать ошибку. Синтетический сценарий воспроизводит последовательность действий, а RUM собирает сведения о поведении и скорости у настоящих посетителей. Эти методы отвечают на разные вопросы: «доступна ли страница», «можно ли пройти выбранный путь» и «что происходит у аудитории».

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

Как выбрать первый сценарий

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

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

Учебный протокол проверки корзины

Ниже пример для тестового товара стоимостью 1 000 ₽. Числа условные; это не замер магазина клиента и не инструкция списать деньги на действующем сайте.

Для передачи корзины в CRM используйте отдельные критерии из статьи «Товары, сумма и источник в Битрикс24». Успешное создание сделки не доказывает правильность товарных строк. Аналогично письмо «Спасибо за заказ» ещё не подтверждает запись в базе магазина.

Как запускать проверки безопасно

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

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

Что должно быть в уведомлении об ошибке

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

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

Как встроить проверку в обновления сайта

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

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

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

Частые вопросы

Документация

• MDN: HTTP 200
• Google: синтетический мониторинг