Стратегии для тестирования ETL-процессов

В статье рассказывается о том, как оптимально выстроить тестирование
ETL-решения при создании инфраструктуры хранилища данных.

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

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

Несмотря на то, что эксперты в течение многих лет обращают внимание на проблему обеспечения качества данных, этот вопрос по-прежнему не теряет актуальности в наше время. В поддержку этого мнения говорят результаты последних исследований Tower Group, Bank Administration Institute, Gartner Group, FDIC, USPS:

• Средний банк с активами в 1 млрд. долл. имеет около 500 миллионов записей данных.
• От 2,5 до 3,4 % банковских данных теряются каждый месяц.
• 40% данных о клиентах содержат ошибки.
• Ежегодно каждый шестой клиент, или около 43 миллионов человек, меняют место жительства и не сообщают свой новый адрес.
• Ежегодно появляется информация об около полутора миллионов новых адресов.
• До 25% данных, вносимых в банковские базы данных о клиентах, имеют ошибки.
• Более половины CRM-проектов заканчиваются неудачей из-за проблем с качеством данных.

Продуманность и проработанность самого ETL-процесса имеет огромное значение, так как от него зависит качество данных в хранилище. Своим видением и опытом, как нужно проводить тестирования ETL-процесса делится сотрудник финансового учреждения (Capital One), Джефф Теобальд. Его мнение особенно интересно, поскольку он представляет точку зрения заказчика.

Цели тестирования

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

• Полнота данных. Гарантируется, что все ожидаемые данные загружены.
• Преобразование данных. Гарантируется, что все данные преобразуются правильно в соответствии с бизнес-правилами и / или проектной спецификацией.
• Качество данных. Гарантируется, что ETL-приложение корректно отклоняет, исправляет неверные данные, заменяет их на значения по умолчанию, или игнорирует и выводит соответствующий отчет.
• Производительность и масштабируемость. Гарантируется, что загрузка данных и выполнение запросов осуществляется в пределах ожидаемых сроков, техническая архитектура является масштабируемой.
• Тестирование интеграции. Гарантируется, что ETL-процесс работает с предыдущими и последующими процессами.
• Оценка степени принятия приложения пользователями (User-Acceptance Testing (UAT)). Позволяет убедиться в том, что решение соответствует текущим ожиданиям пользователей и учитывает их будущие ожидания.
• Регрессионное тестирование. Гарантируется, существующую функциональность не меняется при выходе каждой новой версии кода.

Полнота данных

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

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

Трансформация данных

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

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

Качество данных

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

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

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

Производительность и масштабируемость

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

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

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

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

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

Оценка степени принятия приложения пользователем

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

• Использование либо «промышленных» данных, либо максимально приближенных к ним. Пользователи обычно обнаруживают проблемы, как только они видят "реальные" данные, что иногда приводит к изменениям в проекте.
• Тестирование аналитических выборок из базы данных и сравнение их содержимого с тем, что планировалось. Важно, чтобы пользователи четко понимали, каким образом эти представления создаются.
• Планирование работы команды системного тестирования с целью поддержки пользователей во время проведения бета-тестирования. У пользователей, скорее всего, возникнут вопросы о том, как формируются данные, и они потребуют детальную информацию о том, как работает ETL-процесс.
• Определение того, как часто пользователи будут требовать загруженные во время бета-тестирования данные, и когда эти данные будут обновляться.

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

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

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

Публикации

Джефф Теобальд. Стратегии для тестирования хранилищ данных. (Jeff Theobald. Strategies for Testing Data Warehouse Applications).

Автор: По материалам зарубежных сайтов