Интеграционное тестирование проверяет не системы, а стык между ними: сайт работает, учёт работает, CRM работает — а заказы теряются, задваиваются или приезжают с суммой, которая не сходится на копейку. Отдельно каждую систему уже проверил её разработчик; на стыке же нет ответственного по умолчанию, и именно там живут дефекты, которые обнаруживаются через месяц эксплуатации на реальных деньгах.
Модельный пример на всю статью: интернет-магазин, 1С:УТ и CRM, обмен заказами, статусами и остатками, около 1 800 заказов в месяц. Обмен собран, разработчик отчитался, что «данные ходят». Ниже — десять проверок, которые нужно сделать до запуска, правила подготовки данных, отдельный сценарий недоступности одной из сторон и расчёт часов, которые всё это занимает у сотрудников заказчика.
Важная оговорка: это не тестирование системы целиком и не приёмка. Приёмка работ проверяет, что решение делает то, что заказано; интеграционное тестирование — что оно продолжает это делать, когда с другой стороны стыка происходит что-то незапланированное. Второе почти всегда выпадает из плана проекта, потому что не привязано ни к одному этапу целиком.
Десять проверок стыка
Список ниже закрывает подавляющее большинство дефектов обмена, которые всплывают после запуска. Каждая проверка — это сценарий с заранее записанным ожидаемым результатом: без записанного ожидания проверка превращается в «вроде работает».
| Проверка | Что делаем | Признак провала |
|---|---|---|
| Прохождение | Оформляем заказ на сайте, ждём регламентный интервал обмена, ищем его в учёте и в CRM | Заказа нет, или он пришёл без строк, или без данных клиента |
| Дубли | Отправляем один и тот же заказ дважды, имитируя повторную отправку после таймаута | В учёте два документа вместо одного |
| Порядок | Меняем статус заказа трижды подряд быстрее, чем проходит один цикл обмена | В учёте оказался не последний статус, а промежуточный |
| Кодировки | Товар с кавычками, длинным тире, буквой ё и латиницей в названии; адрес с номером дома через дробь | Нечитаемые символы, обрезанное название, обмен упал на этой позиции |
| Округления | Заказ со скидкой, дающей копейки, и товаром с дробным количеством | Сумма строк не сходится с итогом документа на 1–2 копейки |
| Часовые пояса | Заказ, оформленный в 23:40 по времени клиента из другого пояса | Дата документа в учёте сдвинута на сутки |
| Повтор при сбое | Выключаем принимающую сторону на час, включаем обратно | Данные за этот час потеряны и не догоняются автоматически |
| Откат | Отменяем заказ и оформляем возврат товара | Отмена не доехала, резерв на складе не снят, товар числится проданным |
| Нагрузка | Заливаем дневной объём заказов за 10 минут | Очередь встала, обмен отвалился по таймауту, часть данных потерялась |
| Права доступа | Прогоняем обмен под сервисной учётной записью с минимально нужными правами | Обмен работает только под полными правами администратора |
Записанное до прогона описание того, что должно получиться: «в учёте один документ от такого-то числа, сумма 12 480,50 ₽, резерв на складе Москва, статус „Новый“». Без него проверка вырождается в «посмотрели — вроде нормально», а спор о том, дефект это или задуманное поведение, возникает уже после запуска. Сценарии с ожидаемыми результатами пишутся один раз и переиспользуются при каждой доработке обмена.
Карта связей из трёх узлов: «Сайт магазина», «1С:УТ», «CRM». Между сайтом и учётом двусторонняя стрелка с подписями «заказы, клиенты» в одну сторону и «остатки, цены, статусы» в другую. Между учётом и CRM стрелка «сделки, оплаты». Под каждой стрелкой мелким шрифтом интервал обмена и пометка «ключ операции». Отдельным прямоугольником снизу — «Журнал обмена: 6 полей, сквозной идентификатор», к нему пунктиры от всех стрелок. На стрелках проставлены номера десяти проверок. Чертёжный стиль, подписи по-русски.
Тестовые данные: копия боевых, а не выдуманные записи
Проверка на придуманных записях всегда проходит успешно и ничего не значит. Придуманный товар называется «Товар 1», стоит 1 000 ₽ ровно, лежит на одном складе и не имеет ни аналогов, ни характеристик. Реальный каталог состоит ровно из тех случаев, которые ломают обмен: название на 180 символов с кавычками, цена со скидкой в 3,7 %, две единицы измерения, товар, у которого поставщик поменялся вчера.
- 1Берётся копия боевой базы, а не выборка «интересных» записей — интересные записи выбирает тот, кто уже знает, что сломается.
- 2Копия обезличивается: имена, телефоны, адреса и почта заменяются, суммы и структура остаются. Как это делается и что обязано пережить обезличивание — в разборе обезличенных данных для тестового контура.
- 3В набор обязательно добавляются 10–15 заведомо проблемных записей из живого каталога: самые длинные названия, дробные количества, товары с несколькими штрихкодами.
- 4Тестовый контур отделяется от боевого не только базой, но и каналами: почта, СМС и уведомления клиентам на нём выключаются. Иначе живые люди получат письма о заказах, которых не было, — а при прогоне нагрузочного сценария сразу несколько сотен писем за десять минут.
- 5Набор сохраняется: те же данные понадобятся при каждой доработке обмена, а не только один раз перед запуском.
Обмен, проверенный на чистой базе, ломается на перенесённой: там появляются дубли контрагентов, старые коды номенклатуры и записи, у которых нет обязательных для нового обмена реквизитов. Порядок правильный такой: сначала перенос данных, потом интеграционные тесты на том, что получилось. Обратный порядок гарантирует второй прогон.
Сценарий «одна система недоступна»
Это единственная проверка, которую пропускают почти всегда, и единственная, которая обязательно случится в реальности: обновление сайта, перезагрузка сервера, плановые работы у провайдера, истёкший токен доступа. Вопрос не в том, случится ли, а в том, что произойдёт с данными за эти часы.
- 1Останавливаем принимающую сторону на час
Не выключаем сеть целиком, а именно останавливаем службу приёма — так, как это происходит при обновлении. За этот час на сайте оформляется десяток заказов и меняются статусы у нескольких старых.
- 2Смотрим, что делает отправляющая сторона
Правильное поведение: не потерять, а накопить — сложить в очередь и повторять попытки с нарастающим интервалом. Неправильное: отправить один раз, получить ошибку и забыть. Именно здесь чаще всего и обнаруживается, что очереди нет вовсе.
- 3Включаем обратно и считаем
Всё, что накопилось, должно доехать без ручного вмешательства и без дублей — при этом порядок операций сохраняется: сначала заказ, потом смена его статуса, а не наоборот. Сверяем количество: сколько заказов оформлено за час простоя и сколько доехало.
- 4Проверяем, узнал ли об этом человек
Молчащий обмен обязан поднимать тревогу: письмо или сообщение ответственному, если очередь не разбирается дольше заданного времени. Без этого пункта первые два теряют смысл — накопленная очередь без уведомления обнаруживается на следующий день.
Схема из пяти блоков со стрелками слева направо: «Событие: заказ оформлен» → «Очередь: накапливаем, если приёмная сторона молчит» → «Повторы с нарастающим интервалом: 1, 5, 15, 60 минут» → «Разбор очереди по порядку операций» → «Приёмная сторона». Из блока очереди вниз отдельная стрелка к блоку «Уведомление ответственному, если очередь не разбирается дольше 30 минут». Под схемой пометка «5 часов молчания = 43 заказа в очереди». Чертёжный стиль, подписи по-русски.
Кто проверяет со стороны заказчика и сколько это часов
Прогон сценариев нельзя целиком отдать подрядчику: половина проверок требует знания того, как выглядит правильный результат в вашем бизнесе, а не в документации. Сумма документа сошлась — а должна ли она была сойтись именно так, знает бухгалтер. Резерв снялся — но по тому ли складу, знает кладовщик. Поэтому прогон делают ваши люди, а подрядчик готовит контур и чинит найденное.
Двадцать четыре часа — это три полных рабочих дня, распределённых по четырём людям и растянутых на неделю-полторы, потому что между первым и вторым прогоном подрядчик чинит найденное. Эти часы надо ставить в график заранее и предупреждать руководителей: тестирование, назначенное на конец квартала или на пик сезона, не проводится вообще — люди формально ставят галочки, и весь этап превращается в отчёт.
Две вертикальные полосы на одной рублёвой шкале. Левая «Интеграционное тестирование» — 41 776 ₽, разбита на пять сегментов с подписями 18 000 ₽ (подрядчик, штриховкой) и 8 100 ₽, 3 300 ₽, 3 376 ₽, 9 000 ₽ (часы заказчика, сплошной заливкой), сбоку скобка «24 часа сотрудников». Правая «Один инцидент: обмен молчал 5 часов» — 32 490 ₽, сегменты 28 800 ₽ «12 отменённых заказов» и 3 690 ₽ «ручной ввод 31 заказа». Внизу подпись «модель: 1 800 заказов в месяц». Чертёжный стиль, подписи по-русски.
Журналы обмена: что в них должно быть
Тестирование заканчивается запуском, а разбирать инциденты придётся ещё год. Единственное, что делает разбор возможным, — журнал обмена, который пишется с первого дня и хранит не только факт отправки, но и содержимое. Требования к нему стоит проверить на этапе тестирования: если журнала нет сейчас, после запуска его никто не добавит.
- Сквозной идентификатор операции, одинаковый во всех системах: по нему заказ находится за десять секунд в любой из трёх точек, а спор «мы отправили — вы не получали» разбирается за десять минут, а не за два дня.
- Время события и время обработки отдельно — расхождение между ними показывает, что очередь копится, ещё до того, как это заметят люди.
- Тело сообщения целиком, а не только результат: без него невозможно понять, пришли неверные данные или их неверно обработали.
- Результат с кодом ошибки, а не «ошибка обмена». Текст ошибки должен позволять отличить недоступность от отказа в правах и от неверных данных.
- Срок хранения и объём. Практический ориентир — 90 дней подробного журнала, дальше только сводка. Детали устройства журнала и разбор спорных случаев по нему — в материале про логи обменов и потерянные заявки.
Когда отдельное интеграционное тестирование не нужно
Три случая, когда 24 часа сотрудников можно не тратить и ограничиться проверкой прохождения плюс сценарием недоступности. Во всех трёх речь идёт о ситуациях, где либо стык примитивен, либо цена ошибки заведомо ниже цены прогона.
- Односторонний обмен справочными данными. Если из одной системы в другую раз в сутки уезжает список цен и ничего не возвращается, проверять порядок, откат и дубли нечего: достаточно прохождения, кодировок и повтора при сбое.
- Готовый типовой коннектор между массовыми системами, работающий у сотен компаний. Проверять его базовую механику бессмысленно — проверяйте только своё: нестандартные поля, свои статусы и свои округления.
- Меньше 20–30 операций в день. При таком объёме дефект обнаруживается человеком в тот же день и исправляется вручную быстрее, чем окупается прогон. Но сценарий недоступности проверяйте всё равно: он не про объём, а про потерю данных.
Во всех остальных случаях экономия на этом этапе мнимая: дефекты стыка не исчезают, они переносятся на первые недели эксплуатации, когда через систему уже идут реальные деньги, а разбираться приходится не в тестовом контуре, а по звонку недовольного клиента. Проверенный стык — такой же пункт готовности к запуску, как перенесённые данные и обученные люди; полная форма собрана в чек-листе готовности к запуску.
