Тестирование интеграции сайта: матрица проверок, независимая среда и приёмка

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

Задача бизнеса и границы тестирования интеграции сайта

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

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

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

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

Карта интеграций и матрица интеграционных тестов

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

Что фиксируют в карте

По каждой интеграции записывают:

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

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

Как устроена матрица интеграционных тестов

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

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

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

Тестовые данные и независимая среда

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

Почему нужна отдельная среда

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

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

Какие тестовые данные подготовить

Набор данных должен покрывать не только типичный случай. Полезно заранее собрать:

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

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

Недоступность, повторы и изменение формата

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

Недоступность внешней системы

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

Повторная передача

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

Изменение формата

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

Какой уровень проверки выбрать: таблица решения

Не каждую интеграцию нужно проверять одинаково глубоко. Уровень проверки выбирают по критичности обмена и по тому, насколько дорого стоит ошибка. Таблица ниже помогает принять это решение до начала работ.

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

Учебный пример: обмен заказами и статусами

Ниже — учебный пример. Компания, количество объектов и данные условны и приведены только для иллюстрации порядка действий.

Входные условия

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

Действия

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

Наблюдаемый результат

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

Проверка

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

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

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

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

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

Типичные ошибки и ограничения

Ошибки в тестировании интеграции сайта повторяются из проекта в проект. Полезно знать их заранее.

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

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

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

Какие исходные данные подготовить для оценки

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

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

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

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