Компании все больше внимания уделяют сбору и организации данных для принятия стратегических решений. Способность анализировать исторические тенденции и отслеживать оперативные данные в режиме, близком к реальному времени, стало одним из ключевых конкурентных преимуществ.
В этой статье даны практические рекомендации по проведению ETL-тестирований (ETL - извлечение, преобразование и загрузка), основанные на многолетнем опыте тестирования хранилищ данных, используемых в финансовых институтах и предприятиях розничной торговли.
Несмотря на то, что эксперты в течение многих лет обращают внимание на проблему обеспечения качества данных, этот вопрос по-прежнему не теряет актуальности в наше время. В поддержку этого мнения говорят результаты последних исследований Tower Group, Bank Administration Institute, Gartner Group, FDIC, USPS:
Продуманность и проработанность самого ETL-процесса имеет огромное значение, так как от него зависит качество данных в хранилище. Своим видением и опытом, как нужно проводить тестирования ETL-процесса делится сотрудник финансового учреждения (Capital One), Джефф Теобальд. Его мнение особенно интересно, поскольку он представляет точку зрения заказчика.
Как известно, чем позже в ходе разработки программного обеспечения обнаруживаются ошибки, тем к большим затратам они приводят. В случае хранилища данных ситуация усугубляется в связи с дополнительными издержками при использовании недостоверных данных в процессе принятия управленческих решений. Учитывая важность раннего обнаружения ошибок в программном обеспечении, вначале стоит рассмотреть некоторые общие цели тестирования ETL-приложений:
Одним из самых основных тестов полноты данных является проверка того, чтобы все данные загружены в хранилище. Это включает в себя проверку того, что все записи, все поля и содержимое каждого поля полностью загружены. Подходы к осуществлению этого процесса включают:
Проверка того, корректно ли преобразуются данные в соответствии с бизнес-правилами, может быть самой сложной частью тестирования ETL-приложений. Один из типичных методов - это выбрать несколько записей и "смотреть их и сравнивать", т.е. вручную проверять правильность преобразования. Это может быть полезно, но требует наличия тестировщиков, которые понимают логику ETL-процесса. Сочетание автоматизированного профилирования данных и автоматизированного переноса данных является более долгосрочной стратегией. Вот несколько простых методов автоматизированного переноса данных:
По мнению Джеффа Теобальда, качество данных определяется тем «как ETL-системе удается исправлять данные, производить их замену, отклонять некорректные данные и генерировать уведомления без изменения данных». Для обеспечения успеха в тестировании качества данных следует включать максимально возможное количество сценариев данных. Обычно, правила для обеспечения качества данных определяются на стадии проектирования, например:
В зависимости от правил обеспечения качества данных тестируемого приложения сценарии для проверки могут включать нулевые значения ключей, дублирование записей в исходных данных и неправильные типы данных в полях (например, символы в десятичном поле). Нужно просмотреть подробные сценарии тестирования с бизнес-пользователями и проектировщиками, чтобы убедиться, что они понимают их одинаково. Правила качества данных, применяемые к данным, обычно невидимы для пользователей, когда приложение запущено в работу. Пользователи будут видеть только то, что загружается в базу данных. По этой причине важно, чтобы то, что делается с некорректными данными, сообщалось пользователям. Такие отчеты о качестве данных представляют ценную информацию, которая иногда раскрывает систематические проблемы с исходными данными. В некоторых случаях имеет смысл дополнить исходные данные и показать пользователям.
Поскольку объем данных в хранилище растет, можно ожидать увеличения времени загрузки и выполнения запросов. Этот процесс может быть ускорен при наличии надежной технической архитектуры и модели ETL-процесса. Целью тестирования является выявление любых потенциальных недостатков в ETL-архитектуре, таких как чтение файла несколько раз или создания ненужных временных файлов. Следующие стратегии помогут обнаружить проблемы с производительностью:
Как правило, тестирование системы включает в себя только тестирование в пределах ETL-приложения. Конечными точками для тестирования системы являются вход и выход тестируемого ETL-кода. Интеграционное тестирование показывает, как приложение вписывается в инфраструктуру, состоящую из всех предшествующих и следующих приложений. При создании сценария теста интеграции, необходимо решить, какой процесс может привести к поломке, и сосредоточится на точках взаимодействия между приложениями, а не в пределах одного приложения. Затем рассмотреть, как ошибки процесса на каждом этапе могут быть решены и как данные будут восстановлены или удалены при необходимости.
Большинство проблем, найденных во время интеграционного тестирования, связано с неверным восприятием архитектуры другого приложения. Поэтому важно проводить тестирование на данных, приближенных к реальным. Реальные данные являются идеальным материалом, но здесь могут возникать вопросы, связанные с защитой частной информации и безопасностью, поэтому значения в некоторых полях стоит сгенерировать случайным образом, прежде чем использовать в тестировании. Как всегда, не нужно забывать о важности хороших связей между тестировщиками и разработчиками, которые задействованы для создания системы. Чтобы наладить работу, необходимо собрать членов команды из всех подразделений, а также сформулировать тестовые сценарии и обсудить, что может пойти не так при промышленной эксплуатации системы. Выполнять весь процесс от начала до конца нужно в том же порядке и с теми же зависимостями, как и в режиме промышленной эксплуатации. Интеграционное тестирование должно быть результатом объединения усилий всех специалистов, а не находиться исключительно в зоне ответственности сотрудников, занимающихся тестированием ETL-приложения.
Основная причина создания приложений на основе хранилища данных - сделать данные доступными для бизнес-пользователей. Пользователи знают данные лучше других, и их участие в тестировании является залогом успешного внедрения хранилища данных. Для получения оценки степени принятия приложения пользователем обычно используют аналитические выборки, полученные из данных, загруженных в хранилище, а тонкости работы ETL-приложения для пользователей не интересны. Практика показала ценность следующих подходов:
Регрессивное тестирование выполняется для перепроверки существующей функциональности при выходе каждой новой версии кода. При создании тестов, нужно помнить, что они, вероятно, будут выполняться несколько раз, так как новые версии создаются в связи с исправлением ошибок, улучшениями и изменениями. Автоматизация системного тестирования сделает процесс регрессионного тестирования более гладким. Контрольные примеры должны быть распределены по приоритетности в зависимости от степени риска, чтобы помочь определить, какие должны быть выполнены повторно для каждой новой версии кода. Простая, но эффективная и действенная стратегия проверки базовой функциональности - это хранение исходных данных и результатов успешного исполнения кода и их сравнение с новыми результатами тестов. При выполнении регрессионного тестирования гораздо быстрее сравнивать с предыдущими результатами, чем делать всю проверку еще раз.
Применение этих рекомендаций в процессе разработки и тестирования хранилищ данных гарантирует качество продукта на выходе и поможет предотвратить дорогостоящие ошибки, которые могут возникнуть в режиме промышленной эксплуатации системы.
Джефф Теобальд. Стратегии для тестирования хранилищ данных. (Jeff Theobald. Strategies for Testing Data Warehouse Applications).