Интеграция считается проверенной, когда стороны одинаково понимают результат обмена и поведение при отказе. Ответ сервера не всегда означает обработку сообщения, а отсутствие ответа не всегда означает её отсутствие. Поэтому испытания должны охватывать бизнес-результат, доставку и восстановление.
Согласуйте контракт обмена
При передаче заявок из портала в сервисную систему опишите обязательные поля, идентификатор сообщения, формат дат, допустимые статусы и правила повторной отправки. Уточните момент подтверждения: сообщение принято в очередь или заявка уже создана. Эти события дают разные гарантии, и методика не должна подменять одно другим.
Определите владельцев обеих сторон и канала связи. Зафиксируйте поддерживаемые версии формата и реакцию на неизвестное поле. Согласуйте, какой компонент отвечает за сверку недоставленных сообщений и кто принимает решение о ручном восстановлении обмена.
Подготовьте представительные данные
Создайте набор штатных, граничных и ошибочных сообщений. Включите пустое обязательное поле, неверную дату, длинное описание, повторный идентификатор и изменение статуса уже существующей заявки. Для каждого случая укажите ожидаемый результат в обеих системах. Не проверяйте только код ответа транспортного интерфейса.
Используйте тестовые данные, которые не запустят реальные уведомления, оплату или производственную операцию. Если применяются заглушки, перечислите неохваченные свойства реального получателя. Перед совместным испытанием подтвердите права, маршруты, сертификаты и доступность журналов обеих сторон.
Испытайте потерю связи и повтор
Начните штатный обмен и контролируемо прервите канал после передачи сообщения. Проверьте ситуацию, когда получатель успел создать заявку, но отправитель не получил подтверждение. Повтор не должен приводить к нежелательному дублированию бизнес-операции, если такое требование предусмотрено контрактом. Наблюдайте записи обеих систем по общему идентификатору.
Отдельно испытайте недоступность получателя, переполнение допустимой очереди и ошибку данных. Проверьте интервалы и ограничения повторов, чтобы восстановление не создало всплеск нагрузки. Условия остановки и допустимый объём очереди согласуйте с владельцами, не назначая универсальные значения.
Проверьте восстановление и сверку
После восстановления канала сравните количество и содержание заявок на обеих сторонах. Учитывайте принятые, отвергнутые, ожидающие и обработанные сообщения отдельно. Одинаковое количество записей ещё не доказывает совпадение полей и статусов. Проверьте выборку содержимого и доступные механизмы контроля целостности.
Проведите ручное повторение одного проблемного сообщения по согласованной инструкции. Убедитесь, что оператор видит причину ошибки и не может случайно отправить весь поток заново. Если восстановление требует специального доступа, определите владельца и журналирование действий.
Закрепите результат в приёмочном комплекте
Сохраните редакцию контракта, тестовые сообщения, журналы обмена и фактические записи получателя. В протоколе покажите, какие сценарии выполнены с реальным партнёром, а какие только с заглушкой. Найденный дефект превращайте в повторяемую проверку, чтобы последующая смена формата не вернула прежнюю ошибку.
Типовые промахи: проверка только успешного запроса, отсутствие общего идентификатора, неограниченные повторы и незаметная потеря отвергнутых сообщений. Перед передачей поддержке выполните сценарий диагностики без разработчика. Инструкция должна объяснять поиск сообщения, сверку состояния и безопасное восстановление, а не только способ перезапуска службы.
Подготовьте эксплуатационную сверку обмена
Для рабочего запуска назначьте владельца ежедневных либо событийных проверок в согласованном режиме. Он должен видеть очередь необработанных сообщений, причины отказа и состояние связи. Выберите контрольную заявку и проследите её путь от отправителя до итогового статуса получателя. Различие состояний оформляйте отдельным вопросом, а не исправляйте незаметным ручным редактированием данных.
Уточните порядок сверки после длительного перерыва. Сначала определяют фактические состояния сообщений, затем выбирают безопасный способ продолжения. Полный повтор потока может создать дубликаты или нагрузку. При смене версии формата повторите критичные сценарии с обеими командами. Сохраняйте совместимые редакции контракта и историю результатов, чтобы поддержка понимала, какое поведение действительно подтверждено.
Проверка перед завершением
- ✓Проверяйте бизнес-результат на обеих сторонах.
- ✓Испытайте потерю подтверждения после обработки.
- ✓Разделяйте доставку, принятие и завершение операции.
Частые вопросы
Достаточен ли успешный ответ интерфейса?+
Можно ли принять обмен с заглушкой?+
Продукт · Цены · Все материалы