Тестирование ETL — Введение

Данные в системе хранилища данных загружаются с помощью инструмента ETL (извлечение, преобразование, загрузка). Как следует из названия, он выполняет следующие три операции —

• Извлекает данные из вашей транзакционной системы, которая может быть Oracle, Microsoft или любой другой реляционной базой данных,

• Преобразует данные, выполняя операции очистки данных, а затем

• Загружает данные в хранилище данных OLAP.

Извлекает данные из вашей транзакционной системы, которая может быть Oracle, Microsoft или любой другой реляционной базой данных,

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

Загружает данные в хранилище данных OLAP.

Вы также можете извлечь данные из плоских файлов, таких как электронные таблицы и файлы CSV, используя инструмент ETL, и загрузить их в хранилище данных OLAP для анализа данных и составления отчетов. Давайте возьмем пример, чтобы понять это лучше.

пример

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

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

Разница между ETL и BI-инструментами

Инструмент ETL используется для извлечения данных из различных источников данных, преобразования данных и загрузки их в систему DW; однако инструмент BI используется для создания интерактивных и специальных отчетов для конечных пользователей, информационной панели для высшего руководства, визуализации данных для ежемесячных, ежеквартальных и ежегодных заседаний совета директоров.

Наиболее распространенными инструментами ETL являются — SAP BO Data Services (BODS), Informatica — Power Center, Microsoft — SSIS, Oracle Data Integrator ODI, Talend Open Studio, Clover ETL с открытым исходным кодом и т. Д.

Некоторые популярные BI-инструменты включают в себя — SAP Business Objects, SAP Lumira, IBM Cognos, JasperSoft, Microsoft BI Platform, Tableau, Oracle Business Intelligence Enterprise Edition и т. Д.

Процесс ETL

Давайте теперь немного подробнее обсудим ключевые этапы процедуры ETL —

Извлечение данных

Он включает в себя извлечение данных из разных разнородных источников данных. Извлечение данных из транзакционной системы зависит от требований и используемого ETL-инструмента. Обычно это выполняется путем выполнения запланированных заданий в нерабочее время, например, в ночное время или в выходные дни.

Преобразование данных

Это включает преобразование данных в подходящий формат, который может быть легко загружен в систему DW. Преобразование данных включает применение вычислений, объединений и определение первичных и внешних ключей данных. Например, если вы хотите% от общего дохода, которого нет в базе данных, вы примените формулу% в преобразовании и загрузите данные. Точно так же, если у вас есть имя и фамилия пользователей в разных столбцах, вы можете применить объединенную операцию перед загрузкой данных. Некоторые данные не требуют какого-либо преобразования; такие данные известны как прямое перемещение или передача данных .

Преобразование данных также включает в себя исправление и очистку данных, удаление неверных данных, формирование неполных данных и исправление ошибок данных. Он также включает в себя целостность данных и форматирование несовместимых данных перед загрузкой в ​​систему DW.

Загрузка данных в систему DW

Это включает загрузку данных в систему DW для аналитической отчетности и информации. Целевой системой может быть простой плоский файл с разделителями или хранилище данных.

Функция ETL Tool

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

• Промежуточный уровень — промежуточный слой или промежуточная база данных используются для хранения данных, извлеченных из различных систем исходных данных.

• Уровень интеграции данных — уровень интеграции преобразует данные из промежуточного уровня и перемещает данные в базу данных, где данные объединяются в иерархические группы, часто называемые измерениями , в факты и агрегируют факты . Комбинация таблиц фактов и измерений в системе DW называется схемой .

• Уровень доступа. Уровень доступа используется конечными пользователями для получения данных для аналитических отчетов и информации.

Промежуточный уровень — промежуточный слой или промежуточная база данных используются для хранения данных, извлеченных из различных систем исходных данных.

Уровень интеграции данных — уровень интеграции преобразует данные из промежуточного уровня и перемещает данные в базу данных, где данные объединяются в иерархические группы, часто называемые измерениями , в факты и агрегируют факты . Комбинация таблиц фактов и измерений в системе DW называется схемой .

Уровень доступа. Уровень доступа используется конечными пользователями для получения данных для аналитических отчетов и информации.

На следующем рисунке показано, как три слоя взаимодействуют друг с другом.

Тестирование ETL — Задачи

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

Основной целью тестирования ETL является выявление и устранение дефектов данных и общих ошибок, которые возникают до обработки данных для аналитической отчетности.

Тестирование ETL — задачи для выполнения

Вот список общих задач, связанных с тестированием ETL:

• Понять данные, которые будут использоваться для отчетности
• Просмотрите модель данных
• Сопоставление источника с целью
• Проверка данных на исходных данных
• Пакеты и проверка схемы
• Проверка данных в целевой системе
• Проверка расчетов преобразования данных и правил агрегирования
• Пример сравнения данных между исходной и целевой системами
• Проверка целостности и качества данных в целевой системе
• Тестирование производительности на данных

ETL против тестирования баз данных

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

Здесь мы выделили основные различия между тестированием ETL и тестированием базы данных.

Тестирование ETL

Тестирование ETL включает в себя следующие операции —

• Проверка правильности перемещения данных от источника к целевой системе.

• Проверка подсчета данных в исходной и целевой системе.

• Проверка извлечения данных, преобразование согласно требованию и ожиданию.

• Проверка того, что табличные отношения — соединения и ключи — сохраняются во время преобразования.

Проверка правильности перемещения данных от источника к целевой системе.

Проверка подсчета данных в исходной и целевой системе.

Проверка извлечения данных, преобразование согласно требованию и ожиданию.

Проверка того, что табличные отношения — соединения и ключи — сохраняются во время преобразования.

Общие инструменты тестирования ETL включают QuerySurge, Informatica и т. Д.

Тестирование базы данных

Тестирование базы данных делает упор на точность данных, правильность данных и действительные значения. Он включает в себя следующие операции —

• Проверка, поддерживаются ли первичные и внешние ключи.

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

• Проверка точности данных в столбцах. Пример. Столбец Количество месяцев не должен иметь значения больше 12.

• Проверка отсутствующих данных в столбцах. Проверьте, есть ли пустые столбцы, которые на самом деле должны иметь допустимое значение.

Проверка, поддерживаются ли первичные и внешние ключи.

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

Проверка точности данных в столбцах. Пример. Столбец Количество месяцев не должен иметь значения больше 12.

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

Общие инструменты тестирования базы данных включают Selenium, QTP и т. Д.

В следующей таблице представлены ключевые функции тестирования баз данных и ETL и их сравнение.

функция	Тестирование базы данных	Тестирование ETL
Главная цель	Проверка данных и интеграция	Извлечение, преобразование и загрузка данных для отчетов BI
Применимая система	Транзакционная система, в которой происходит бизнес-поток	Система, содержащая исторические данные, а не в среде бизнес-потока
Общие инструменты	QTP, Selenium и др.	QuerySurge, Informatica и др.
Бизнес потребность	Он используется для интеграции данных из нескольких приложений, серьезного воздействия.	Используется для аналитической отчетности, информации и прогнозирования.
моделирование	ER метод	многомерный
Тип базы данных	Обычно используется в системах OLTP	Применяется для систем OLAP
Тип данных	Нормализованные данные с большим количеством объединений	Денормализованные данные с меньшим количеством объединений, большим количеством индексов и агрегаций.

Тестирование ETL — Категории

Категоризация тестирования ETL проводится на основе целей тестирования и отчетности. Категории тестирования варьируются в соответствии со стандартами организации, и это также зависит от требований клиента. Как правило, тестирование ETL классифицируется на основе следующих пунктов —

• Тестирование количества от источника к цели — включает в себя сопоставление количества записей в исходной и целевой системах.

• Тестирование данных от источника к цели — включает проверку данных между исходной и целевой системами. Он также включает в себя интеграцию данных и проверку пороговых значений, а также проверку дубликатов данных в целевой системе.

• Сопоставление данных или тестирование преобразования — подтверждает сопоставление объектов в исходной и целевой системах. Это также включает проверку функциональности данных в целевой системе.

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

• Повторное тестирование — включает исправление ошибок и дефектов в данных в целевой системе и повторный запуск отчетов для проверки данных.

• Тестирование системной интеграции — включает в себя тестирование всех отдельных систем, а затем объединение результатов, чтобы определить, есть ли какие-либо отклонения. Для этого можно использовать три подхода: нисходящий, восходящий и гибридный.

Тестирование количества от источника к цели — включает в себя сопоставление количества записей в исходной и целевой системах.

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

Сопоставление данных или тестирование преобразования — подтверждает сопоставление объектов в исходной и целевой системах. Это также включает проверку функциональности данных в целевой системе.

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

Повторное тестирование — включает исправление ошибок и дефектов в данных в целевой системе и повторный запуск отчетов для проверки данных.

Тестирование системной интеграции — включает в себя тестирование всех отдельных систем, а затем объединение результатов, чтобы определить, есть ли какие-либо отклонения. Для этого можно использовать три подхода: нисходящий, восходящий и гибридный.

На основании структуры системы хранилища данных тестирование ETL (независимо от используемого инструмента) можно разделить на следующие категории:

Тестирование новой системы DW

В этом типе тестирования создается и проверяется новая система DW. Ввод данных осуществляется от клиентов / конечных пользователей, а также из разных источников данных, и создается новое хранилище данных. Позже данные проверяются в новой системе с помощью инструментов ETL.

Миграционное тестирование

При тестировании миграции клиенты имеют существующие хранилища данных и ETL, но они ищут новый инструмент ETL для повышения эффективности. Он включает миграцию данных из существующей системы с использованием нового инструмента ETL.

Тестирование изменений

При тестировании изменений новые данные добавляются из разных источников данных в существующую систему. Клиенты также могут изменить существующие правила для ETL, или же можно добавить новое правило.

Тестирование отчетов

Тестирование отчетов включает создание отчетов для проверки данных. Отчеты являются окончательным результатом любой системы DW. Отчеты проверяются на основе их макета, данных в отчете и рассчитанных значений.

Тестирование ETL — проблемы

Тестирование ETL отличается от тестирования базы данных или любого другого обычного тестирования. Возможно, придется столкнуться с различными типами проблем при выполнении тестирования ETL. Здесь мы перечислили несколько общих проблем —

• Потеря данных в процессе ETL.

• Неверные, неполные или дублирующие данные.

• Система DW содержит исторические данные, поэтому объем данных слишком велик и чрезвычайно сложен для проведения тестирования ETL в целевой системе.

• Тестерам ETL обычно не предоставляется доступ к просмотру графиков работы в инструменте ETL. У них практически нет доступа к инструментам отчетности BI, чтобы увидеть окончательный макет отчетов и данных внутри отчетов.

• Трудно генерировать и создавать тестовые случаи, так как объем данных слишком велик и сложен.

• Тестеры ETL обычно не имеют представления о требованиях к отчетам конечного пользователя и бизнес-потоке информации.

• ETL-тестирование включает в себя различные сложные концепции SQL для проверки данных в целевой системе.

• Иногда тестерам не предоставляется информация о сопоставлении источника и цели.

• Нестабильная среда тестирования задерживает разработку и тестирование процесса.

Потеря данных в процессе ETL.

Неверные, неполные или дублирующие данные.

Система DW содержит исторические данные, поэтому объем данных слишком велик и чрезвычайно сложен для проведения тестирования ETL в целевой системе.

Тестерам ETL обычно не предоставляется доступ к просмотру графиков работы в инструменте ETL. У них практически нет доступа к инструментам отчетности BI, чтобы увидеть окончательный макет отчетов и данных внутри отчетов.

Трудно генерировать и создавать тестовые случаи, так как объем данных слишком велик и сложен.

Тестеры ETL обычно не имеют представления о требованиях к отчетам конечного пользователя и бизнес-потоке информации.

ETL-тестирование включает в себя различные сложные концепции SQL для проверки данных в целевой системе.

Иногда тестерам не предоставляется информация о сопоставлении источника и цели.

Нестабильная среда тестирования задерживает разработку и тестирование процесса.

ETL — Роли тестера

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

Основные обязанности тестера ETL перечислены ниже.

Проверьте таблицы в исходной системе

Он включает в себя следующие операции —

• Проверка счета
• Согласовать записи с исходными данными
• Проверка типа данных
• Убедитесь, что спам-данные не загружены
• Удалить дубликаты данных
• Проверьте все ключи на месте

Применить трансформационную логику

Логика преобразования применяется перед загрузкой данных. Он включает в себя следующие операции —

• Проверка пороговых значений данных, например, возрастное значение не должно превышать 100.

• Проверка количества записей до и после применения логики преобразования.

• Проверка потока данных из промежуточной области в промежуточные таблицы.

• Проверка суррогатного ключа.

Проверка пороговых значений данных, например, возрастное значение не должно превышать 100.

Проверка количества записей до и после применения логики преобразования.

Проверка потока данных из промежуточной области в промежуточные таблицы.

Проверка суррогатного ключа.

Загрузка данных

Данные загружаются из промежуточной области в целевую систему. Он включает в себя следующие операции —

• Проверьте количество записей из промежуточной таблицы в целевой системе.

• Убедитесь, что данные ключевого поля не пропущены или пустые.

• Проверьте, загружены ли агрегированные значения и рассчитанные показатели в таблицы фактов.

• Проверьте представления моделирования на основе целевых таблиц.

• Проверьте, был ли CDC применен к таблице добавочной нагрузки.

• Проверка данных в таблице измерений и проверка истории.

• Проверьте отчеты BI на основе загруженной таблицы фактов и измерений и в соответствии с ожидаемыми результатами.

Проверьте количество записей из промежуточной таблицы в целевой системе.

Убедитесь, что данные ключевого поля не пропущены или пустые.

Проверьте, загружены ли агрегированные значения и рассчитанные показатели в таблицы фактов.

Проверьте представления моделирования на основе целевых таблиц.

Проверьте, был ли CDC применен к таблице добавочной нагрузки.

Проверка данных в таблице измерений и проверка истории.

Проверьте отчеты BI на основе загруженной таблицы фактов и измерений и в соответствии с ожидаемыми результатами.

Тестирование инструментов ETL

Тестеры ETL также обязаны тестировать инструменты и контрольные примеры. Он включает в себя следующие операции —

• Проверьте инструмент ETL и его функции
• Протестируйте систему хранилища данных ETL
• Создание, разработка и выполнение планов тестирования и тестовых случаев.
• Проверьте передачу данных плоского файла.

Тестирование ETL — Методы

Важно определить правильную технику тестирования ETL перед началом процесса тестирования. Вы должны получить согласие всех заинтересованных сторон и убедиться, что выбран правильный метод для проведения тестирования ETL. Эта методика должна быть хорошо известна группе тестирования, и они должны знать об этапах процесса тестирования.

Существуют различные типы методов тестирования, которые можно использовать. В этой главе мы кратко обсудим методы тестирования.

Валидационные испытания продукции

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

Тестирование количества от источника к цели

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

Тестирование данных от источника к цели

В этом типе тестирования тестер проверяет значения данных из источника в целевую систему. Он проверяет значения данных в исходной системе и соответствующие значения в целевой системе после преобразования. Этот тип тестирования занимает много времени и обычно выполняется в финансовых и банковских проектах.

Тестирование интеграции данных / пороговых значений

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

Пример — атрибут возраста не должен иметь значение больше 100. В столбце даты ДД / ММ / ГГ поле месяца не должно иметь значение больше 12.

Тестирование миграции приложений

Тестирование миграции приложений обычно выполняется автоматически при переходе от старого приложения к новой системе приложений. Это тестирование экономит много времени. Он проверяет, совпадают ли данные, извлеченные из старого приложения, с данными в новой системе приложений.

Проверка данных и тестирование ограничений

Он включает в себя выполнение различных проверок, таких как проверка типа данных, проверка длины данных и проверка индекса. Здесь инженер по тестированию выполняет следующие сценарии — первичный ключ, внешний ключ, NOT NULL, NULL и UNIQUE.

Проверка на наличие дубликатов данных

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

Дублирующиеся значения можно проверить с помощью оператора SQL, например:

Select Cust_Id, Cust_NAME, Quantity, COUNT (*) 
FROM Customer
GROUP BY Cust_Id, Cust_NAME, Quantity HAVING COUNT (*) >1;

Дублирующиеся данные появляются в целевой системе по следующим причинам:

• Если первичный ключ не определен, могут появиться повторяющиеся значения.
• Из-за неправильного картирования или экологических проблем.
• Ручные ошибки при передаче данных из источника в целевую систему.

Тестирование преобразования данных

Тестирование преобразования данных не выполняется с помощью одного оператора SQL. Это отнимает много времени и включает в себя выполнение нескольких SQL-запросов для каждой строки для проверки правил преобразования. Тестер должен выполнить SQL-запросы для каждой строки, а затем сравнить выходные данные с целевыми данными.

Тестирование качества данных

Тестирование качества данных включает в себя проверку чисел, проверку даты, проверку на ноль, проверку точности и т. Д. Тестер выполняет синтаксическую проверку, чтобы сообщить о недопустимых символах, неправильном верхнем / нижнем регистре и т. Д., И контрольные проверки, чтобы проверить, соответствуют ли данные данным. модель данных.

Инкрементальное тестирование

Инкрементное тестирование выполняется для проверки выполнения операторов вставки и обновления в соответствии с ожидаемым результатом. Это тестирование выполняется пошагово со старыми и новыми данными.

Регрессионное тестирование

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

проведение испытания

Когда вы запускаете тесты после исправления кодов, это называется повторным тестированием.

Тестирование системной интеграции

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

Навигационное тестирование

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

ETL Тестирование — Процесс

Тестирование ETL охватывает все этапы жизненного цикла ETL. Он начинается с понимания бизнес-требований до составления сводного отчета.

Общие этапы жизненного цикла тестирования ETL перечислены ниже —

• Понимание бизнес-требований.

• Проверка бизнес-требований.

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

• Планирование тестирования включает в себя поиск метода тестирования на основе входных данных в соответствии с требованиями бизнеса.

• Создание тестовых сценариев и тестовых случаев.

• Как только контрольные примеры готовы и утверждены, следующим шагом является проверка перед выполнением.

• Выполните все тесты.

• Последний шаг заключается в создании полного сводного отчета и регистрации процесса закрытия.

Понимание бизнес-требований.

Проверка бизнес-требований.

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

Планирование тестирования включает в себя поиск метода тестирования на основе входных данных в соответствии с требованиями бизнеса.

Создание тестовых сценариев и тестовых случаев.

Как только контрольные примеры готовы и утверждены, следующим шагом является проверка перед выполнением.

Выполните все тесты.

Последний шаг заключается в создании полного сводного отчета и регистрации процесса закрытия.

Тестирование ETL — Сценарии

Сценарии тестирования ETL используются для проверки процесса тестирования ETL. В следующей таблице описаны некоторые из наиболее распространенных сценариев и тестовых случаев, которые используются тестерами ETL.

Тестовые сценарии	Тест-случаи
Проверка структуры	Это включает проверку исходной и целевой таблиц структуры в соответствии с документом сопоставления. Тип данных должен быть проверен в исходной и целевой системах. Длина типов данных в исходной и целевой системах должна быть одинаковой. Типы полей данных и их формат должны быть одинаковыми в исходной и целевой системах. Проверка имен столбцов в целевой системе.
Проверка соответствия документа	Это включает в себя проверку документа сопоставления, чтобы убедиться, что вся информация была предоставлена. Документ сопоставления должен иметь журнал изменений, вести типы данных, длину, правила преобразования и т. Д.
Проверить ограничения	Это включает проверку ограничений и обеспечение их применения к ожидаемым таблицам.
Проверка целостности данных	Это включает проверку неправильного использования ограничений целостности, таких как внешний ключ. Длина и тип данных атрибута могут различаться в разных таблицах, хотя их определение остается неизменным на семантическом уровне.
Проверка полноты данных	Он включает в себя проверку, все ли данные загружены в целевую систему из исходной системы. Подсчет количества записей в исходной и целевой системах. Анализ граничных значений. Проверка уникальных значений первичных ключей.
Проверка правильности данных	Это включает проверку значений данных в целевой системе. Ошибочные или неточные данные приведены в табл. Нулевые, не уникальные данные сохраняются при отключении ограничения целостности во время импорта.
Проверка преобразования данных	Это включает в себя создание электронной таблицы сценариев для входных значений и ожидаемых результатов, а затем проверку с конечными пользователями. Проверка родительско-дочерних отношений в данных путем создания сценариев. Использование профилирования данных для сравнения диапазона значений в каждом поле. Проверка правильности типов данных в хранилище, упомянутых в модели данных.
Проверка качества данных	Он включает в себя проверку номера, проверку даты, проверку точности, проверку данных, проверку нуля и т. Д. Пример. Формат даты должен быть одинаковым для всех значений.
Нулевая проверка	Он включает в себя проверку значений Null, где Not Null упоминается для этого поля.
Повторная проверка	Это включает проверку дублированных значений в целевой системе, когда данные поступают из нескольких столбцов из исходной системы. Проверка первичных ключей и других столбцов, если есть дублирующиеся значения в соответствии с бизнес-требованиями.
Проверка даты проверки	Проверка поля даты для различных действий, выполняемых в процессе ETL. Общие тесты для проверки даты — From_Date не должно превышать To_Date Формат значений даты должен быть правильным. Значения даты не должны иметь никаких нежелательных значений или нулевых значений.
Полная проверка данных минус запрос	Он включает проверку полного набора данных в исходной и целевой таблицах с использованием минус-запроса. Вы должны выполнить и источник минус цель и цель минус источник . Если минус-запрос возвращает значение, это следует рассматривать как несовпадающие строки. Вам необходимо сопоставить строки в источнике и цели, используя инструкцию Intersect . Число, возвращаемое Intersect, должно совпадать с индивидуальным количеством исходных и целевых таблиц. Если минус-запрос не возвращает строк и пересечение счетчиков меньше, чем исходное или целевое количество таблиц, то в таблице содержатся повторяющиеся строки.
Другие тестовые сценарии	Другие тестовые сценарии могут заключаться в проверке того, что процесс извлечения не извлек дублирующиеся данные из исходной системы. Команда тестирования будет вести список операторов SQL, которые выполняются для проверки того, что из исходных систем не было извлечено дублированных данных.
Очистка данных	Нежелательные данные должны быть удалены перед загрузкой данных в область подготовки.

Проверка структуры

Это включает проверку исходной и целевой таблиц структуры в соответствии с документом сопоставления.

Тип данных должен быть проверен в исходной и целевой системах.

Длина типов данных в исходной и целевой системах должна быть одинаковой.

Типы полей данных и их формат должны быть одинаковыми в исходной и целевой системах.

Проверка имен столбцов в целевой системе.

Проверка соответствия документа

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

Проверить ограничения

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

Проверка целостности данных

Это включает проверку неправильного использования ограничений целостности, таких как внешний ключ.

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

Проверка полноты данных

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

Подсчет количества записей в исходной и целевой системах.

Анализ граничных значений.

Проверка уникальных значений первичных ключей.

Проверка правильности данных

Это включает проверку значений данных в целевой системе.

Ошибочные или неточные данные приведены в табл.

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

Проверка преобразования данных

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

Проверка родительско-дочерних отношений в данных путем создания сценариев.

Использование профилирования данных для сравнения диапазона значений в каждом поле.

Проверка правильности типов данных в хранилище, упомянутых в модели данных.

Проверка качества данных

Он включает в себя проверку номера, проверку даты, проверку точности, проверку данных, проверку нуля и т. Д.

Пример. Формат даты должен быть одинаковым для всех значений.

Нулевая проверка

Он включает в себя проверку значений Null, где Not Null упоминается для этого поля.

Повторная проверка

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

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

Проверка даты проверки

Проверка поля даты для различных действий, выполняемых в процессе ETL.

Общие тесты для проверки даты —

From_Date не должно превышать To_Date

Формат значений даты должен быть правильным.

Значения даты не должны иметь никаких нежелательных значений или нулевых значений.

Полная проверка данных минус запрос

Он включает проверку полного набора данных в исходной и целевой таблицах с использованием минус-запроса.

Вы должны выполнить и источник минус цель и цель минус источник .

Если минус-запрос возвращает значение, это следует рассматривать как несовпадающие строки.

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

Число, возвращаемое Intersect, должно совпадать с индивидуальным количеством исходных и целевых таблиц.

Если минус-запрос не возвращает строк и пересечение счетчиков меньше, чем исходное или целевое количество таблиц, то в таблице содержатся повторяющиеся строки.

Другие тестовые сценарии

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

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

Очистка данных

Нежелательные данные должны быть удалены перед загрузкой данных в область подготовки.

ETL Тестирование — Производительность

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

Как выполнить настройку производительности тестирования ETL?

Для настройки производительности тестирования ETL выполните следующие шаги:

• Шаг 1 — Найти груз, который трансформируется в производство.

• Шаг 2. Создайте новые данные с той же загрузкой или переместите из производственных данных на локальный сервер производительности.

• Шаг 3 — Отключите ETL, пока вы не создадите требуемую нагрузку.

• Шаг 4 — Возьмите подсчет необходимых данных из таблиц базы данных.

• Шаг 5 — Запишите последний запуск ETL и включите ETL, чтобы он получал достаточное напряжение для преобразования всей создаваемой нагрузки. Запустить его

• Шаг 6 — После того, как ETL завершит свою работу, возьмите подсчет созданных данных.

Шаг 1 — Найти груз, который трансформируется в производство.

Шаг 2. Создайте новые данные с той же загрузкой или переместите из производственных данных на локальный сервер производительности.

Шаг 3 — Отключите ETL, пока вы не создадите требуемую нагрузку.

Шаг 4 — Возьмите подсчет необходимых данных из таблиц базы данных.

Шаг 5 — Запишите последний запуск ETL и включите ETL, чтобы он получал достаточное напряжение для преобразования всей создаваемой нагрузки. Запустить его

Шаг 6 — После того, как ETL завершит свою работу, возьмите подсчет созданных данных.

Ключевые показатели эффективности

• Узнайте общее время, необходимое для преобразования нагрузки.
• Узнайте, улучшилось ли время выполнения или упало.
• Проверьте, что вся ожидаемая нагрузка была извлечена и передана.

Тестирование ETL — Масштабируемость

Целью тестирования ETL является получение достоверных данных. Достоверность данных может быть достигнута путем повышения эффективности цикла тестирования.

Комплексная стратегия тестирования — это установка эффективного цикла тестирования. Стратегия тестирования должна охватывать планирование тестирования для каждого этапа процесса ETL, каждый раз, когда данные перемещаются, и указывать обязанности каждого заинтересованного лица, например, бизнес-аналитиков, команды инфраструктуры, команды QA, администраторов баз данных, разработчиков и бизнес-пользователей.

Чтобы обеспечить готовность к тестированию во всех аспектах, ключевые области, на которых должна сосредоточиться стратегия тестирования, — это

• Объем тестирования — Опишите методы и типы тестирования, которые будут использоваться.

• Настройка тестовой среды.

• Проверка доступности данных. Рекомендуется, чтобы данные производились в соответствии со всеми / критическими требованиями бизнеса.

• Качество данных и критерии приемлемости производительности.

Объем тестирования — Опишите методы и типы тестирования, которые будут использоваться.

Настройка тестовой среды.

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

Качество данных и критерии приемлемости производительности.

ETL-тестирование — точность данных

В тестировании ETL точность данных используется для гарантии того, что данные точно загружены в целевую систему в соответствии с ожиданиями. Ключевые шаги в выполнении точности данных следующие:

Сравнение значений

Сравнение значений включает сравнение данных в исходной и целевой системах с минимальным преобразованием или без него. Это можно сделать с помощью различных инструментов тестирования ETL, например, Преобразование квалификатора источника в Informatica.

Некоторые преобразования выражений также могут выполняться при проверке точности данных. В операторах SQL можно использовать различные операторы множеств для проверки точности данных в исходной и целевой системах. Обычными операторами являются операторы минус и пересечение. Результаты этих операторов можно рассматривать как отклонение в значении в целевой и исходной системах.

Проверьте критические столбцы данных

Столбцы критических данных можно проверить, сравнив отдельные значения в исходной и целевой системах. Вот пример запроса, который можно использовать для проверки столбцов критических данных:

SELECT cust_name, Order_Id, city, count(*) FROM customer 
GROUP BY cust_name, Order_Id, city;

Тестирование ETL — Метаданные

Проверка метаданных включает в себя проверку исходной и целевой структуры таблицы в документе сопоставления. Документ сопоставления содержит сведения об исходных и целевых столбцах, правилах преобразования данных и типах данных, всех полях, которые определяют структуру таблиц в исходной и целевой системах.

Проверка длины данных

Длина типа данных целевого столбца должна быть равна или больше типа данных исходного столбца. Давайте возьмем пример. Предположим, у вас есть имена и фамилии в исходной таблице, а длина данных для каждого определяется как 50 символов. Тогда целевая длина данных для столбца с полным именем в целевой системе должна составлять не менее 100 или более.

Проверка типа данных

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

Ограничение / проверка индекса

Проверка ограничений включает в себя проверку значений индекса и ограничений согласно документу спецификации проекта. Все столбцы, которые не могут иметь значения Null, должны иметь ограничение Not Null. Столбцы первичных ключей индексируются в соответствии с проектным документом.

Тестирование ETL — Преобразование данных

Выполнение преобразований данных немного сложнее, поскольку этого нельзя достичь, написав один SQL-запрос, а затем сравнив выходные данные с целью. Для преобразования данных тестирования ETL вам может потребоваться написать несколько SQL-запросов для каждой строки, чтобы проверить правила преобразования.

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

Ключевые шаги для преобразования данных тестирования ETL перечислены ниже —

• Первым шагом является создание списка сценариев входных данных и ожидаемых результатов и проверка их с бизнес-клиентом. Это хороший подход для сбора требований во время проектирования и может также использоваться как часть тестирования.

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

• Затем используйте результаты профилирования данных для сравнения диапазона и представления значений в каждом поле между целевыми и исходными данными.

• Проверка правильности обработки сгенерированных ETL полей, например суррогатных ключей.

• Проверка типов данных в хранилище те же, что были указаны в модели данных или дизайне.

• Создайте сценарии данных между таблицами, которые проверяют ссылочную целостность.

• Проверьте родитель-дочерние отношения в данных.

• Последний шаг — выполнить преобразование поиска . Ваш поисковый запрос должен быть прямым без какой-либо агрегации и должен возвращать только одно значение на исходную таблицу. Вы можете напрямую присоединиться к таблице поиска в исходном квалификаторе, как и в предыдущем тесте. Если это не так, напишите запрос, соединив таблицу поиска с основной таблицей в источнике, и сравните данные в соответствующих столбцах цели.

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

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

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

Проверка правильности обработки сгенерированных ETL полей, например суррогатных ключей.

Проверка типов данных в хранилище те же, что были указаны в модели данных или дизайне.

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

Проверьте родитель-дочерние отношения в данных.

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

ETL-тестирование — качество данных

Проверка качества данных во время тестирования ETL включает в себя проверку качества данных, загружаемых в целевую систему. Включает в себя следующие тесты —

Проверка номера

Числовой формат должен быть одинаковым во всей целевой системе. Например, в исходной системе формат нумерации столбцов равен x.30 , но если целевым значением является только 30 , он должен загружаться без префикса x. в целевом столбце номер.

Проверка даты

Формат даты должен быть согласованным как в исходной, так и в целевой системах. Например, оно должно быть одинаковым для всех записей. Стандартный формат: гггг-мм-дд.

Проверка точности

Значение точности должно отображаться, как ожидается, в целевой таблице. Например, в исходной таблице значение равно 15.2323422, но в целевой таблице оно должно отображаться как 15.23 или раунд 15.

Проверка данных

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

Пример — в целевую таблицу должны загружаться только те записи, у которых date_id> = 2015 и Account_Id! = ‘001’.

Null Check

Некоторые столбцы должны иметь значение Null в соответствии с требованиями и возможными значениями для этого поля.

Пример. В столбце «Дата завершения» должно отображаться значение «Ноль», если и до тех пор, пока в столбце «Активное состояние» не будет указано «T» или «Умерший».

Другие проверки

Обычные проверки, такие как From_Date, не должны превышать To_Date.

Тестирование ETL — Полнота данных

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

Общие тесты, которые могут быть выполнены для этого, следующие:

• Проверка Агрегатных функций (сумма, максимум, минимум, количество),

• Проверка и проверка количества и фактических данных между источником и целью для столбцов без преобразований или с простыми преобразованиями.

Проверка Агрегатных функций (сумма, максимум, минимум, количество),

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

Проверка достоверности

Сравните количество записей в исходной и целевой таблицах. Это можно сделать, написав следующие запросы —

SELECT count (1) FROM employee; 
SELECT count (1) FROM emp_dim; 

Проверка профиля данных

Он включает проверку агрегатных функций, таких как count, sum и max, в исходной и целевой таблицах (факт или измерение).

Проверка профиля данных столбца

Это включает в себя сравнение различных значений и количества строк для каждого отдельного значения.

SELECT city, count(*) FROM employee GROUP BY city; 
SELECT city_id, count(*) FROM emp_dim GROUP BY city_id;

Проверка дубликатов данных

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

SELECT first_name, last_name, date_of_joining, count (1) FROM employee
GROUP BY first_name, last_name HAVING count(1)>1;

Тестирование ETL — Резервное копирование

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

Тестирование восстановления ETL Backup используется для того, чтобы убедиться, что система хранилища данных успешно восстанавливается после аппаратного, программного или сетевого сбоя с потерей любых данных.

Надлежащий план резервного копирования должен быть подготовлен для обеспечения максимальной доступности системы. Системы резервного копирования должны иметь возможность легко восстанавливаться и принимать отказавшую систему без потери данных.

Тестирование ETL Восстановление резервной копии включает в себя воздействие приложения или системы DW на экстремальные условия для любого аппаратного компонента, сбой программного обеспечения и т. Д. Следующим шагом является обеспечение запуска процесса восстановления, проверки системы и восстановления данных.

ETL Тестирование — Автоматизация

ETL-тестирование в основном выполняется с использованием сценариев SQL и сбора данных в электронных таблицах. Этот подход к выполнению тестирования ETL очень медленный и занимает много времени, подвержен ошибкам и выполняется на данных выборки.

Техническая проблема в ручном тестировании ETL

Ваша группа тестирования ETL пишет запросы SQL для проверки данных в системе хранилища, и им необходимо выполнить их вручную с помощью редактора SQL, а затем поместить данные в электронную таблицу Excel и сравнить их вручную. Этот процесс трудоемкий, ресурсоемкий и неэффективный.

На рынке доступны различные инструменты для автоматизации этого процесса. Наиболее распространенными инструментами тестирования ETL являются QuerySurge и Informatica Data Validation.

QuerySurge

QuerySurge — это решение для тестирования данных, предназначенное для тестирования больших данных, хранилищ данных и процесса ETL. Он может автоматизировать весь процесс для вас и хорошо вписаться в вашу стратегию DevOps.

Ключевые особенности QuerySurge следующие:

• В нем есть Query Wizards, позволяющие быстро и легко создавать тестовые QueryPairs без необходимости написания SQL-кода.

• Имеется библиотека дизайна с многоразовыми фрагментами запросов. Вы также можете создавать собственные QueryPairs.

• Он может сравнивать данные из исходных файлов и хранилищ данных с целевым хранилищем данных или хранилищем больших данных.

• Он может сравнивать миллионы строк и столбцов данных в считанные минуты.

• Это позволяет пользователю планировать выполнение тестов (1) немедленно, (2) в любую дату / время или (3) автоматически после окончания события.

• Он может создавать информативные отчеты, просматривать обновления и автоматически отправлять результаты по электронной почте вашей команде.

В нем есть Query Wizards, позволяющие быстро и легко создавать тестовые QueryPairs без необходимости написания SQL-кода.

Имеется библиотека дизайна с многоразовыми фрагментами запросов. Вы также можете создавать собственные QueryPairs.

Он может сравнивать данные из исходных файлов и хранилищ данных с целевым хранилищем данных или хранилищем больших данных.

Он может сравнивать миллионы строк и столбцов данных в считанные минуты.

Это позволяет пользователю планировать выполнение тестов (1) немедленно, (2) в любую дату / время или (3) автоматически после окончания события.

Он может создавать информативные отчеты, просматривать обновления и автоматически отправлять результаты по электронной почте вашей команде.

Чтобы автоматизировать весь процесс, инструмент ETL должен запустить QuerySurge через API командной строки после того, как программное обеспечение ETL завершит процесс загрузки.

QuerySurge будет запускаться автоматически и без присмотра, выполняя все тесты, а затем отправляя результаты всем членам команды по электронной почте.

Как и QuerySurge, Informatica Data Validation предоставляет инструмент тестирования ETL, который помогает вам ускорить и автоматизировать процесс тестирования ETL в среде разработки и производства. Это позволяет вам предоставлять полное, повторяемое и проверяемое тестовое покрытие за меньшее время. Не требует навыков программирования!

Тестирование ETL — лучшие практики

Чтобы протестировать систему хранилища данных или приложение BI, необходимо использовать ориентированный на данные подход. Лучшие практики тестирования ETL помогают минимизировать затраты и время на проведение тестирования. Это улучшает качество данных, загружаемых в целевую систему, которая генерирует высококачественные информационные панели и отчеты для конечных пользователей.

Мы перечислили здесь несколько лучших практик, которые можно использовать для тестирования ETL —

Анализировать данные

Чрезвычайно важно проанализировать данные, чтобы понять требования, чтобы установить правильную модель данных. Потратив время на понимание требований и наличие правильной модели данных для целевой системы, можно уменьшить количество проблем ETL. Также важно изучить исходные системы, качество данных и создать правильные правила проверки данных для модулей ETL. Стратегия ETL должна быть сформулирована на основе структуры данных исходной и целевой систем.

Исправить неверные данные в исходной системе

Конечные пользователи обычно знают о проблемах с данными, но они не знают, как их исправить. Важно найти эти ошибки и исправить их, прежде чем они достигнут системы ETL. Распространенным способом решения этой проблемы является время выполнения ETL, но лучше всего находить ошибки в исходной системе и предпринимать шаги для их исправления на уровне исходной системы.

Найти совместимый инструмент ETL

Одной из распространенных рекомендаций ETL является выбор инструмента, наиболее совместимого с исходной и целевой системами. Возможность инструмента ETL генерировать сценарии SQL для исходной и целевой систем может сократить время обработки и ресурсы. Это позволяет обрабатывать преобразования в любом месте в среде, которая является наиболее подходящей.

Мониторинг рабочих мест ETL

Еще одна лучшая практика при внедрении ETL — планирование, аудит и мониторинг заданий ETL, чтобы гарантировать, что нагрузки выполняются в соответствии с ожиданиями.

Интегрировать инкрементные данные

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

Обычно исходные системы не имеют временных меток или первичного ключа для легкой идентификации изменений. Такие проблемы могут быть очень дорогостоящими, если они будут выявлены на более поздних этапах проекта. Одна из лучших практик ETL — охватить такие аспекты при изучении системы исходного кода. Эти знания помогают команде ETL выявлять измененные проблемы сбора данных и определять наиболее подходящую стратегию.

Масштабируемость

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