Введение: что такое интеграция?
Интеграционн��е тестирование — это этап проверки взаимодействия двух или более отдельных систем. Его главная цель — выловить ошибки, которые возникают не внутри систем (они по отдельности могут работать идеально), а между ними.
Классическая ситуация:
«Я данные отправил!»
«А я не получил!»
«А они зависли где-то, потому что формат не тот!»
Пример из практики: комплексный проект по рефакторингу системы управления доступами. Интеграция приложения по управлению доступами на основе ролей и привилегий (это наша Новая система) с другими информационными системами (ИС) в контуре предприятия (например, управление учетными записями, авторизация пользователей и прочие).
Чтобы интегрироваться со смежными системами, нужно реализовать переход на новую систему управления на основе OpenFga, где определяется модель авторизации.
Схема реализации системы управлениями доступами и привилегиями.
1. Реальная картина мира
Самая большая сложность — часто никто не понимает, как вся система выглядит в целом и должна работать в сборе.
Поэтому первоочередная задача — как можно глубже разобраться в том, что делает ВАША команда и ВАША часть системы (компонент). Всегда начинайте с тестирования внутри своего компонента, особенно если система состоит из нескольких микросервисов! Не бойтесь рисовать блок-схемы для осознания связей входов и выходов.
2. Что? Где? Когда?
Архитектура и подход к тестированию (метод «снизу вверх») Архитектура тестирования «снизу вверх» — это стратегия, при которой вы сначала тщательно проверяете все мелкие «кирпичики» вашей программы, затем собираете из них «стены» и проверяете, как они стыкуются, и так до тех пор, пока не получите и не проверите готовое «здание». Это надежный и фундаментальный подход, который гарантирует, что у вашей программы будет крепкий «фундамент».
Условная схема работы системы для наглядности
По данной схеме интеграционное тестирование выглядит так:
Проверка переноса изменений по триггерам из системы-источника из старой базы в новую Базу ✓
Проверка функции создания кортежей (данные пользователя) ✓
Проверка работы всех микросервисов, отвечающих за учет и доставку кортежей в OpenFGA (каждый сервис по отдельности и их работа в связке и все обратные связи) ✓
Проверка итоговых результатов корректной отработки системы:
Фиксация того, что из OpenFGA пользователь получает адекватный ответ ✓
Интеграция со сторонними информационными системами! ✓
Дополнительно: консультирование команды по нагрузочному тестированию на каждый из компонентов и системы в целом. ✓
3. Процесс тестирования и стратегия
В идеале все действия выполняются в соответствии с согласованным ТЗ, по которому написано полное и красивое покрытие тестовыми сценариями. Но часто возникают нюансы неожиданных апдейтов.😊
При этом главное — соблюдать принцип последовательности.
Спойлер: тестировать надо все!
На каждый узел создается список сценариев по требованиям ТЗ, пока идет разработка, занимаемся документацией.
Каждый узел тестируется по разработанному тест-плану.
Тестируется связка разработанного раннее функционала с текущей реализацией узла (интеграция).
Тестируется вся система по цепочке от первого до последнего узла — сквозное тестирование.
Проводится интеграционное тестирование со сторонней информационной системой.
Методика:
1. На каждый узел системы (предварительно оттестированный по отдельности) подаются одни и те же триггеры.
2. Далее проводится последовательная остановка и запуск микросервисов по отдельности с проверкой результатов их работы в БД и логах Kibana. 3. Каждый микросервис проходит этап проверки отказоустойчивости и корректной обработки ошибочных сценариев.
Тестируем путем подачи данных (консистентных и не консистентных) от источника или прямого апдейта базы данных и фиксируем изменения в базе при работе всей системы и на каждом из узлов.
Такой подход позволяет:
1. Выявить точки отказа.
2. Проверить механизмы восстановления работоспособности всей системы.
Результат:
1. Система работает корректно, стабильно, в соответствии с ТЗ.
2. Система готова к дальнейшей интеграции со смежниками.
4. Бизнес-логика vs Техническая реализация
Очень важно в процессе интеграционного тестирования держать в голове желания и потребности бизнеса, ибо легко погрязнуть в технических нюансах и позабыть, зачем «…мы здесь сегодня собрались…».
Бизнес говорит, а разработчики слышат по-своему. Берите в переводчики бизнес-аналитика, техлида и тест-лида. Станьте тем, кто соединяет миры. (Кстати, всегда назначаем встречу, иначе это будет просто переписка в мессенджере длиною в жизнь).
Помни:
Понять суть источника и результата обработки данных должен ты… Смысл в бизнес-логике ищи.
5. Входные/выходные данные: зона повышенного риска в тестировании интеграций
Обязательно выполняйте много интеграционных тестов и регрессов, пока не поймете, как оно работает на самом деле, и так ли оно должно работать по ТЗ.
Далее показывайте свои тест-кейсы коллегам из смежных систем и пытаетесь интегрироваться, но внезапно может возникнуть множество вопросов.
Например, в процессе выяснится, что:
Ваш UUID — это строка, а у них — число.
Тестовая учетная запись, которую вы используете, не имеет нужных прав.
Вы дергаете не тот эндпоинт из-за опечатки в документации.
Мораль: чем лучше кросс-коммуникация, тем раньше выявляются проблемы и находятся их решения.
6. Не Кафкой единой: протоколы и документация
Единые протоколы общения интегрируемых систем API (у нас gRPC SDK OpenFGA) крайне важны при совместной работе. Сравнивайте документацию по взаимодействию со смежниками (подсказка: она должна совпадать или, по крайней мере, быть максимально похожей в своей сути).
Важно! При любых столкновениях с интегрируемыми системами описывайте ВСЕ, что видите (это вам очень пригодится), и фиксируйте важные моменты в базе знаний тестировщиков.
Обязательно документируйте:
Входные и выходные параметры (атрибуты и их типы).
Протоколы и методы взаимодействия интегрируемых систем.
Описание обработки ошибок API.
Любые флоу и алгоритмы взаимодействия.
Тестовые стратегии, планы, сценарии (держать в актуальном состоянии).
7. Человеческий фактор: «Вы все делаете не так!» – «Нет, это ВЫ!»
При объединении двух и более команд и их систем спасет честный бартер.
Подойдите к коллегам и предложите: «Давайте обменяемся нашими артефактами: ТЗ, планами интеграционного тестирования и тест-кейсами (желательно оформленными по общим шаблонам предприятия)».
Важное условие: убедитесь, что ваши собственные кейсы — образец совершенства.
Чем глубже и лучше вы протестировали свою систему, чем лучше вы ее понимаете, тем легче общаться с коллегами из смежных ИС.
В правильном кейсе четко описаны:
Предусловия: учетная запись создана, права выданы, доступы к БД/стендам есть, стенд обновлен.
Входные/выходные данные: конкретные значения, а не «какие-нибудь данные».
Шаги: понятные и воспроизводимые.
Ожидаемый результат: сформулирован так, чтобы кейс не падал из-за чего-то неучтенного.
8. На пути к мастерству: советы интеграционному падавану
Интеграция — это общение и стрессоустойчивость. Не ведитесь на провокации и всегда знайте, на чьей стороне мяч (и часто он не на вашей). Главное, четкая аргументация, факты.
Единая точка д��ступа и правила хранения. Документы, стенды и БД должны быть доступны всем участникам. «А у меня не открывается» — это проблема, которую нужно решить в первую очередь.
Документация — ваш щит. Без документации вы — чепуха, а с ней — праведные тестировщики!
Работайте с БА и лидами над тест-планами. Они должны быть подробными, с описанием всех ресурсов и предусловий.
Качественное предварительное тестирование. Это сэкономит всем кучу времени и нервных клеток + респект и уважение от команды. Будьте примером!
Декомпозиция. При анализе сложных процессов разбивайте их на простые понятные функции. Так вы сможете лучше понять принцип работы системы и оптимально подобрать тестовые сценарии.
Ретро и демо. Больно, но полезно. Встраивайте в процесс, даже если все сопротивляются.
Заключение
Удачи в этом нелегком деле! И помните: то, что должно быть на входе, далеко не всегда является тем же самым на выходе... Особенно после прохождения через пять микросервисов и пару реляционных баз.
