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

Рассматривается тот участок процесса поставки, когда тестируемые системы/сервисы уже прошли своё "личное" функциональное тестирование, а теперь нам нужно убедиться, что они слаженно работают вместе как единый продукт.
Речь пойдёт о том как подступиться к интеграционному (системному) тестированию совокупности взаимодействующих систем/сервисов,

• которое предполагается автоматизировать
• при этом не используя заглушки (stubs) и моки (mocks), т.е. в максимально "живом и натуральном" окружении.

Предположим, что мы знаем, что интеграция между приложениями в общем случае может происходить:

• прямыми вызовами API "точка-точка" по шаблону request-reply (запрос-ответ) или one-way (отправка в одну сторону).
  Обычно реализуется посредством REST API или RPC-взаимодействия.
• обменом через слой среднего уровня, например через системы управления очередями (message brokers) типа RabbitMQ и Apache Kafka или при посредстве КСШ (ESB) (которая, по-сути тоже является собой совокупность тех же message brokers)
• обменом файлами, складываемыми/читаемыми в условленном "месте".
  Таким местом может быть как некий общий локальный storage, так и удалённый, (от)куда файлы читаются/передаются по протколам FTP, SSH et cetera.
• на уровне баз данных:
  1. одна общая БД для нескольких систем (привет монолитам и всяческому легаси)
  2. баз несколько, но связанных процессами ETL/ELT

Обследуем сервисы/системы, составляющие наш условный Продукт, ища и изучая следующие информационные артефакты:

1. Сценарии использования (use cases) и БТ (бизнес-требования) по ним
2. Архитектура (общая, компонентная, интеграционная)
3. Диаграммы последовательности (sequence diagram) интеграционных взаимодействий
4. СТ (системные требования) к API, описание/контракты API
5. Объектная модель (object model)
6. Ролевая модель (role model)
7. Диаграмма развёртывания (DD, deployment diagram), руководства/инструкции по установке и администрированию

Изучение их позволит обрести понимание по каждому сервису/системе:

• список ВОПРОСОВ к команде сервиса/системы
• для чего вообще нужен, какие его самые важные фичи
• входящие интеграционные потоки
• исходящие интеграционные потоки
• как производит аутентификацию запросов
• как происходит авторизация
• какие протоколы где использует (требуются ли сертификаты и ключи)
• какими сущностями оперирует
• какие действия в GUI и/или запросы к API инициируют исходящие запросы в другие сервисы/системы
• для каких ролей эти действия должны быть доступны
• при каких способах развёртывания и каких именно настройках интеграция будет идти тем или иным образом

Это понимание И полученные ответы на ваши уточняющие вопросы должны позволить приступить к разработке тестовых сценариев:

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

Абстрактный пример обследуемой архитектуры

Предположим, мы имеем некий Продукт, состоящий из Системы А, Системы Б, Системы В. Продукт предоставляет Клиенту некое публичное API, в которое клиентское приложение постоянно пишет некие данные. Продукт также предоставляет Клиенту web-UI. Основным юзкейсом нашего Продукта является приём данных от Клиента, обработка их каким-то образом и предоставление в некотором человекочитаемом виде в web-UI. Также наш Продукт для каких-то внутренних потребностей собирает какие-то данные со своих Систем.
Для упрощения опустим интеграцию с системами аутентификации и авторизации.

скачать схему в формате diagrams.net (бывший draw.io)

В этом случае с точки зрения API / integration / E2E тестирования нас будут интересовать следующие элементы архитектуры:

• API 4 шт.
• Message broker 1 шт.
• Интеграционные потоки 4 шт.

Интеграционные тестовые сценарии можно поделить, например, на следующие группы:

1. E2E.
   Проверка такой фичи (бизнес-процесса) ИТ-Продукта, в процессе выполнения которой задействовано 3 и более систем: система, в которой было совершено инициирующее воздействие (обращение к API, манипуляция в UI), "промежуточные" системы, система, в которой был предоставлен конечный результат работы.
   Рекомендуется соотношение одна фича = один E2E-тест (базовый положительный случай), потому что E2E -- самые долгие и дорогие по автоматизации и поддержке тесты.
   Чуть подробнее

   Составление и поддержка E2E-тестов достаточно дороги, в связи с чем могут быть даны следующие рекомендации:

   • E2E-тестов не должно быть много
   • Время прохода E2E-тестов должно исчисляться минутами, а не часами
   • E2E-тесты должны кореллировать с CJM
   • E2E-тесты следует делать независимыми от предподготовленных данных, отсутствие или плохое качество которых часто является причиной ошибок. Если есть сервисы (воззможно, среди тестируемвых), которые предоставляют API по созданию объектов сущностей, то следует использовать его. Если такого нет, то нужные данные следует импортировать на уровне БД.

2. Auth.
   Тестовые сценарии на проверку возможности аутентификации и/или авторизации запросов к API. Можно совмещать с базовыми проверками ролевой модели, если это возможно сделать запросами к (web-UI) API.
3. API.
   Тесты на проверку того, что на запросы к методам API, составленные на основе требований и/или контракта этого API, приходит ответ, соответствующим требованиям/контракту.
   В этой группе проверяем такие методы API, которые НЕ инициируют подзапросов в другие Системы, в противном случае это уже будут integration-тесты. Т.о. в основном API-тесты у нас будут состоять из CRUD-операций над сущностями, которыми оперирует система-владелец API.
   Чуть подробнее

   Может включать в себя тестирование:

   1. WADL/WSDL SOAP API (XML)
   2. HTTP(S) REST API, сиречь HTTP-request вида:
      • POST host:9090/entity с body, содержащим text/json/xml
      • GET host:9090/entity/1
      • PUT host:9090/entity/1 с body, содержащим text/json/xml
   3. HTTP(S) non-REST API, сиречь HTTP-request вида:
      • POST host:9090/CreateEntity с body, содержащим text/json/xml
      • GET host:9090/GetEntity?id=1
      • POST host:9090/UpdateEntity с body, содержащим text/json/xml
   4. RPC-взаимодействия с сервером, например, в виде java-call клиентской библиотеки, см. gRPC

4. Integration.
   Тесты корректности интеграции двух систем. "Дёргаем" (по API / web-UI) первую систему, проверяем, что она корректно "пообщалась" с другой системой.
   Иногда может быть частным случаем E2E, если в фиче (бизнес-процессе) задействовано всего 2 системы.

Какие же тесты по группам будут для нашего примера

API

скачать схему в формате diagrams.net (бывший draw.io)

Integration

E2E