Неинтеграционное тестирование интеграционных потоков. Или интеграционное?
Я работаю в тестировании 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-слоя.
В таком виде потоков мы практически не используем тест-кейсы, так как в основном они простые или средней сложности.
Я не знаю, есть ли такие потоки где-то еще в бизнесе в сфере розничной торговли продуктами или иной, но это надежно. Это работает и не требует бешеных затрат на разработку, что сейчас немаловажно. Дальше я буду писать подробно про примеры, с тестированием которых я столкнулся в своей работе.
Ну и самый главный вопрос: интеграционное это тестирование или же нет?
Я считаю, что да — все признаки этого имеются, потому что наши потоки могут взаимодействовать внутри одной системы или же с другими системами, что в конечном итоге приводит к корректной работе бизнес-юнитов. А как считаете вы?
