Я знаю, что несколько небольших компаний не тестируют процесс ETL, но это кажется субоптимальным с точки зрения разработки программного обеспечения.Как проверить (единичный тест) на процесс ETL?
Как обычно люди проводят тестирование/единичный тест/функциональный тест на процесс ETL?
Большое спасибо
Проверка ETL обычно является проблемой. Точнее, тестирование не является проблемой, проблема в том, как получить разумные тестовые данные. ETL обычно тестируется на производственных данных. Помимо проблемы безопасности проблема с производственными данными заключается в том, что она недостаточно покрывает функциональность ETL (обычно около 40% бизнес-правил не покрывается образцом производственных данных), и для обработки требуется слишком много времени.
Недавно мы разработали генератор тестовых данных (для получения более подробной информации ознакомьтесь с GTL QAceGen: Генератор данных на основе бизнес-логики на рынке Informatica), которые генерируют тестовые данные на основе исходных таблиц/файлов по спецификации бизнес-правил. Инструмент учитывает применение любого внешнего ключа и работает для любых основных ETL и/баз данных.
Этот инструмент помогает ускорить цикл тестирования не менее чем на 50% (по сравнению с ручным тестированием), покрывает 100% всех бизнес-правил. Он также генерирует довольно подробные отчеты и, что более важно, эти тесты могут быть повторены в любое время (например, регрессионные тесты).
Недавно мы работали над проектом, где плата управления требовали «Вы должны быть тесты Unit», и поэтому мы старались изо всех сил.
Что сработало для нас, каждое решение ETL начиналось и заканчивалось пакетом QA/Test.
Все, что было обнаружено этими пакетами, было зарегистрировано в таблице аудита, а затем было отменено событие «Неудачный пакет», чтобы остановить всю работу. Мы полагали, что лучше работать с хорошими данными вчера, чем представлять отчетность о возможных неудачах «сегодня», данные.
В стартовом пакете будут выполняться процедуры db и проверки работоспособности данных. Data Sanity включала проверку дублирования или отсутствия данных, вызванных отсутствием ссылочной целостности в исходных системах. Проверка схемы гарантировала, что любые изменения схемы, которые не были применены во время непрерывной интеграции, были обнаружены.
В конце пакета будут проверяться результаты любых преобразований. К ним относятся:
Большинство из этих тестов были операторами SQL, которые использовали встроенные объекты схемы в нашей базе данных, поэтому они не были обременительными для создания.
Кроме того, в рамках нашего процесса разработки мы создадим представления, которые имели бы конечный результат любых преобразований, которые мы делали. Мы использовали эти взгляды для подтверждения наших преобразований пакетов.
Каждая из этих проверок создала запись в нашей специальной таблице аудита. Таким образом, мы могли бы предоставить исчерпывающий список всех проверок и проверок, которые мы проводили каждый процесс, чтобы удовлетворить потребности людей в управлении.
(У нас также был отдельный набор пакетов, которые будут тестировать каждый тест QA путем создания фиктивных таблиц, заполнения их, выполнения теста, а затем подтверждения записи соответствующего аудита. Как сказал Ник, это было много работы и небольшой реальной стоимости)
Мы создали систему, в которой для каждой процедуры ETL мы определили входной набор данных и ожидаемый набор данных результатов. Затем мы создали систему, которая, используя Robot Framework, запускает трехчастные тесты для каждой процедуры ETL, где первая часть вставляет входной набор данных в таблицы данных источника, вторая часть выполняет ETL, а третья часть сравнивает фактические результаты с наши ожидаемые результаты.
Это работает очень хорошо для нас, но есть несколько недостатков: прежде всего, мы создаем тестовые наборы данных вручную для каждой процедуры ETL, которая требует некоторой работы, а во-вторых, это означает, что тестирование «неожиданных» входов не сделан.
Для автоматизированного модульного тестирования у нас есть отдельная среда, в которой мы можем автоматически устанавливать сборки всего нашего DW.
Вам необходимо создать пустую тестовую базу данных, тестовые примеры (в источниках данных), запустить ваш ETL, а затем проверить полученные данные в целевой тестовой базе данных. Гораздо более запутанный, чем тест на единицу приложения, поэтому он не делается много. –
@ Nick.McDermaid благодарит за информацию –