Неинтеграционное тестирование интеграционных потоков. Или интеграционное?

Я работаю в тестировании 2 года – это не много и немало, но достаточно, чтобы понимать, что такое интеграционное тестирование и уметь с этим работать. 

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

И вот, я пришел работать в АШАН ТЕХ и узнал об интеграционных потоках – сущности, которая заставляет задуматься о том, относится ли это к интеграции, имеет свои особенности тестирования и, что самое интересное, не встретилось мне ни в одной статье (но может где-то и есть).

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

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

Здесь они делятся на два вида: Airflow потоки и Streamflow потоки.

Airflow потоки – это все потоки, которые запускаются по триггеру при необходимости работы с ними. Для работы с ними мы используем Apache Airflow (что можно было понять по названию потоков) как самый удобный инструмент для работы с batch-процессами. 

Я не буду описывать как работает Apache Airflow – здесь много статей об этом, но если вы хотите понимать, что будет происходить дальше – советую их прочитать. 

Но по сути, наш поток — это просто Python-проект, который представлен в Apache Airflow в виде основной сущности DAG (некоторое смысловое объединение ваших задач, которые вы хотите выполнить в строго определенной последовательности по определенному расписанию). 

Если посмотреть детальнее, то заметно, что поток представляет собой здесь набор определенных задач, которые выполняются друг за другом при успешном запуске через play: 

Или же идут по продуманному в случае ошибок потока (нет соединения, нет файлов для передачи и так далее) флоу:

Конфигурации потока в airflow задаются через импорт переменных:  

Здесь прописывается откуда берутся данные, куда передаются, сколько раз переподключается поток при ошибке, какие БД (если есть с ними взаимодействие) подключаются по каким схемам, порты серверов источника и получателя и т.д. 

Данные по подключениям (в основном это пользователь, хост, порты и информация о том, какой ключ используется при подключении – не сам ключ или пароль ни в коем случае!!!) загружаются в раздел connections:

Логирование происходит здесь же в Apache Airflow – все рядом близко и удобно.

Streamflow потоки – это все потоки, которые работают непрерывно и обеспечивают постоянный обмен данными между системами в рамках интеграций. Их конфигурации можно задавать по-разному, указывать sleep timeoutы, итерации, но суть одна – работать они будут непрерывно 24 часа.

Пишутся эти потоки также на Python, поднимаются из докера, разворачиваются в ci gitlab и отличаются тем, что после разработки и запуска в пайплайне (разработчиком или тестировщиком – бывает по-разному) больше не останавливаются (если нет критических ошибок).

Логирование здесь мы отслеживаем через OpenSearch Dashboards, который дает полноценную информацию по всем шагам потока и возможность видеть, на каком этапе происходит передача данных и куда.

Оба вида этих потоков можно разделить на степени сложности:

1)Простые – передают файлы из папки одной системы в папку другой (обмен данными между поставщиками – магазинами), забирают данные из одной БД и складывают в другую перезаписью или обновлением, без маппинга данных.

2)Среднесоставные – передают файлы в три или более систем, которые взаимодействуют между собой, где данные файлов должны проходить маппинг.

3)Сложносоставные – файлы передаются в различные системы и БД, в том числе взаимодействуют с брокерами сообщений, маппинг может происходить несколько раз или же зависеть от системы к системе, в которую данные должны подаваться. 

Для передачи файлов используются протоколы FTP и SFTP.

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

Тестирование Streamflow потоков.

Основными тестовыми артефактами для нас в тестировании потоков являются чек-листы для простых потоков, тест-кейсы для средних и сложных потоков (примеры будут приведены ниже), а также непосредственно инструменты для тестирования, такие как:

1)PuTTy – используем ее для удаленного администрирования Linux серверов через Windows, если нужно создать папки/каталоги/файлы для потоков, а также, чтобы обмениваться файлами между локальным компьютером и удалённым. Важным преимуществом является поддержка разных версий SSH-протокола, что обеспечивает передачу данных через защищённое соединение, дистанционный запуск программ, сжатие файлов для быстрой передачи, передачу шифрованного трафика между портами разных машин. Также возможно перенаправление портов через протокол SSH.

2)WinSCP — поддерживает передачу файлов между компьютером и сервером по протоколу SFTP на устройствах с ОС Windows. Утилита работает по защищённому протоколу SSH и не перегружена редко используемыми функциями, как некоторые аналоги. Это позволяет максимально быстро выполнять нужные задачи:

— редактировать, копировать, загружать, удалять файлы на сервере;

— создавать сразу несколько подключений к разным серверам;

— пользоваться командной строкой.

3)Любая СУБД – мы пользуемся Dbeaver – для селектов, инсертов, изменений данных в таблицах и проверки переданных данных в БД получателя.

4)AKHQ графический интерфейс Kafka при передаче больших потоковых данных и проверке сообщений в брокере.

Как выглядит основной флоу тестирования streamflow потоков у нас:

1)Разработчик заканчивает поток, разворачивает его из докера с помощью ci gitlab и передает на тестирование;

2)Тестировщик читает ТЗ потока, проверяет конфигурации потока в gitlab на соответствие с ТЗ – каталоги, сервера источника-получателя, установленные timeout’ы и итерации потока;

3)Тестировщик подготавливает тестовые данные: при хорошо составленном ТЗ берет данные, которые подложили аналитики, если нет – сам готовит файлы;

4)Проверяет соответствие маски файлов по ТЗ для потока;

5)Далее необходимо подложить файлы на сервер источника через инструменты выше;

6)Тестировщик отслеживает по логам действия потока и фиксирует данные;

7)Далее переходит на сервер получателя данных и проверяет, что файл передан по необходимому каталогу в нужную систему;

8)Если есть маппинг – проверяет соответствие данных ТЗ в файле источника и получателя;

9)В OpenSearch Dashboard смотрит логи – проверяет их на соответствие с ТЗ; 

10)Готовит отчет по тестированию и передает команде разработки и владельцам продукта.

Примеры чек-листов для непрерывного потока: 

Логика работы потока

1. Поток отрабатывает полный цикл;

2. Подключение к SFTP источника;

3. При неудачном подключении к источнику поток переподключается 3 раза с интервалом 30 секунд;

4. Поиск исходной папки “Путь к папке на сервере источника”;

5. Поиск входного файла по маске «Маска файлов»;

6. При некорректном имени входной файл игнорируется;

7. Выходной файл скопирован в папку на SFTP приёмника “Путь к папке на сервере получателя”;

8. При неудачной отправке входной файл перемещается в папку “Путь к каталогу при неудачной отправке»; 

9. Удаление входного файла из исходной папки после отработки;

10. Обработка нескольких входных файлов;

11. Запуск потока при отсутствии прав у рабочих папок;

12. Запуск при отсутствии доступа к рабочим серверам.

Логирование потока

1. Лог подключения к SFTP источника;

2. Лог скачивания входного файла;

3. Лог загрузки выходного файла в конечную папку;

4. Лог удаления входного файла с SFTP источника;

5. Ошибка подключения к SFTP источника;

6. Ошибка подключения к SFTP приёмника;

7. Ошибка доступа к исходной папке на SFTP источника;

8. Ошибка доступа к конечной папке на SFTP приёмника.

Примеры тест-кейсов для непрерывного потока:

1. Проверка подключения к Источнику

Тест-кейс 1.1  

Название: Повторное подключение к Источнику при неудаче  

Предусловия: Источник недоступен  

Шаги:  

1. Проверить, что поток повторяет попытки подключения каждые 5 минут.

Ожидаемый результат: Попытки подключения повторяются каждые 5 минут.

2. Проверка определения количества файлов в каталоге Источника

Тест-кейс 2.1  

Название: Определение количества файлов  

Предусловия: В каталоге Источника есть файлы с нужной маской  

Шаги:  

1. Проверить количество файлов.

Ожидаемый результат: Количество файлов определено правильно.

Тест-кейс 2.2  

Название: Обработка отсутствия файлов в каталоге Источника  

Предусловия: В каталоге Источника нет файлов с нужной маской  

Шаги:  

1. Проверить, что поток отключается от Источника.

Ожидаемый результат: Поток отключается от Источника.

При участии в тестировании БД – тестировщик проверяет БД источника. Таблицу, из которой берутся данные, и таблицы, куда данные перезаписываются. 

Тест-кейс:

Название: Проверка обработки файла, по которому нет информации в DWH

Предусловия: В каталог источника помещен файл, информации по файлу нет в DWH, нижеприведённые SELECT ничего не возвращают

Шаги:  

1. Добавить на источник файл с заказом 

Промежуточный ожидаемый результат: Поток не найдет данных по заказу в DWH, добавит информацию о заказе в файл

2. После удаления файла с источника потоком выполнить 3 запроса INSERT в DWH

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

Тестирование Airflow потоков.

При тестировании потоков, которые запускаются по триггеру основным инструментом для запуска потока и отслеживания логики, логов, всех шагов для нас является Apache Airflow. Все что касается добавления файлов, проверки таблиц – то инструментарий абсолютно такой же. 

Флоу тестирования airflow потоков:

1)Разработчик заканчивает поток, разворачивает его и загружает необходимую конфигурацию в Apache Airflow и передает на тестирование;

2)Тестировщик читает ТЗ потока, проверяет конфигурации потока в variables и connections в Apache Airflow на соответствие с ТЗ – каталоги, сервера источника-получателя, установленные timeoutы и итерации потока;

3)Тестировщик подготавливает тестовые данные: при хорошо составленном ТЗ берет данные, которые подложили аналитики, если нет – сам готовит файлы; 

4)Проверяет соответствие маски файлов по ТЗ для потока;

5)Далее необходимо подложить файлы на сервер источника через инструменты выше или же запустить поток по триггеру, если он не использует файлы, а перезаписывает данные баз данных (потоки для изменения информации витрин);

6)Тестировщик отслеживает по графике в Apache Airflow действия потока и фиксирует данные в логах здесь же; 

7)Далее переходит на сервер получателя данных и проверяет, что файл передан по необходимому каталогу в нужную систему или в БД проверяя, что данные в таблице заместились новыми и есть timestamp отметка об этом;

8)Если есть маппинг – проверяет соответствие данных ТЗ в файле источника и получателя;

9)Готовит отчет по тестированию и передает команде разработки и владельцам продукта.

Примеры чек-листов для непрерывного потока: 

Логика работы потока

1. Поток отрабатывает полный цикл;

2. Подключение к системе-источника;

3. Запись новых данных в таблицу «Название таблицы 1»;

4. Запись новых данных в таблицу «Название таблицы 2»;

5. Запись новых данных в таблицу «Название таблицы 3»;

…

10. Запуск при отсутствии доступа к БД;

11. Запуск при отсутствии доступа к рабочим серверам;

12. В случае невозможности подключения к системе-источнику поток должен сформировать лог ERROR;

13. После восстановления доступа и получения новых или измененный записей, поток должен добавить записи в соответствующие таблицы в ods-слоя.

В таком виде потоков мы практически не используем тест-кейсы, так как в основном они простые или средней сложности. 

Я не знаю, есть ли такие потоки где-то еще в бизнесе в сфере розничной торговли продуктами или иной, но это надежно. Это работает и не требует бешеных затрат на разработку, что сейчас немаловажно. Дальше я буду писать подробно про примеры, с тестированием которых я столкнулся в своей работе.

Ну и самый главный вопрос: интеграционное это тестирование или же нет? 

Я считаю, что да – все признаки этого имеются, потому что наши потоки могут взаимодействовать внутри одной системы или же с другими системами, что в конечном итоге приводит к корректной работе бизнес-юнитов. А как считаете вы?