- БАЗЫ ДАННЫХ -
УДК 681.3.06
НАЦЕЛЕННАЯ ГЕНЕРАЦИЯ ДАННЫХ ДЛЯ ТЕСТИРОВАНИЯ ПРИЛОЖЕНИЙ НАД БАЗАМИ ДАННЫХ
© 2012 г. Е.А. Костычев, В.А. Омельченко, С.В. Зеленов
Институт Системного Программирования РАН 109004 Москва, ул. А. Солженицына, 25 E-mail: {kostychev, vitaly, zelenov}@ispras.ru Поступила в редакцию 14.07.2012
Приложения, обрабатывающие большие массивы данных, являются широко распространенным типом программного обеспечения. В частности, такие приложения решают задачи интеграции данных в области интеграции корпоративных приложений. При решении таких задач используются специальные инструментальные среды, поддерживающие разработку, выполнение и мониторинг приложений, реализующих шаблон извлечения, трансформации и загрузки данных (Extract, Transform and Load-ETL). Специфика функционального тестирования таких приложений заключается в большом количестве возможных комбинаций входных данных. Подходы, реализованные в инструментах генерации данных для функциональной проверки приложений над базами данных, в лучших случаях основываются на схемах баз данных и запросах на SQL, используемых в тестируемых приложениях. Гарантированное покрытие функциональности тестируемого приложения при таких подходах может быть достигнуто только полным перебором возможных комбинаций исходных данных. При помощи предложенного в статье подхода к генерации данных возможно достижение покрытия функциональности приложения с близким к оптимальному объему данных (один набор данных для одной функциональной ветви приложения).
1. ВВЕДЕНИЕ
Постоянно растущая доступность все больших объемов для хранения информации в электронном виде и все больших вычислительных ресурсов для их обработки приводит к все большей распространенности приложений над все большими объемами данных в различных областях. Так в начале 90-х годов прошлого века появился британский национальный корпус - специальным образом размеченный и обработанный большой массив, содержащий 100 миллионов слов в виде коллекции письменных и устных текстов за более чем двадцатилетний промежуток [1]. С тех пор такие национальные корпуса появились и продолжают появляться и пополняться для многих языков. Такие корпуса языков не только делают более тривиальными многие традиционные задачи лингвистики,
но и позволяют ставить и решать ранее невыполнимые задачи, прежде всего связанные с обработкой больших объемов данных [2]. С обработкой больших объемов данных так же связаны задачи в таких областях как статистика, социология, георазведка, некоторые разделы физики, молекулярная генетика, климатология, метеорология.
Хранение и обработка больших объемов данных является критической задачей и для современного корпоративного бизнеса. Корпоративные системы содержат огромные объемы взаимосвязанных данных о потребителях и заказчиках, поставщиках, партнерах, различных бизнес-транзакциях, об оборудовании и персонале, финансовых потоках. Большие объемы корпоративных данных, как правило, хранятся в структурированном виде в одной или нескольких базах данных под управлением одной или нескольких
СУБД. Для обеспечения поддержки решений различных задач бизнеса зачастую требуется функциональность, которая может быть реализована только путем интеграции нескольких подсистем корпоративной системы, а иногда и интеграции с подсистемами внешних корпоративных систем. Часто в таких случаях возникает проблема доступа к большим массивам данных из разных хранилищ и имеющих разные форматы. Поэтому приложения репликации, обновления и синхронизации больших объемов данных являются широко распространенным частным случаем интеграционных корпоративных приложений.
Задачи таких приложений могут быть элементарными, но не всегда простыми в реализации, как, например, выборка полных или частичных данных, касающихся физического или юридического лица. Они могут быть и достаточно сложными, как по условиям выборки и агрегации входных данных, так и по формированию конечного результата, как, например, выставление счетов пользователям в соответствии с объемом реально потребленных услуг, тарифными планами и с учетом предоставляемых скидок. Высокая частота возникновения таких задач при решении проблемы интеграции корпоративных приложений привела к появлению специализированных платформ, предоставляющих универсальную, относительно платформ хранения данных, среду выполнения и инструменты для разработки приложений, эффективно решающих задачи извлечения, трансформации и загрузки больших массивов данных [3]. Далее такие приложения будем называть ETL-приложениями (от англ. Extract, Transform and Loading).
2. ПОСТАНОВКА ЗАДАЧИ
После разработки любого нового приложения или доработки уже существующего требуется проверка корректности его поведения на соответствие функциональным требованиям, реализующим необходимую бизнес-логику. Бизнес-логику приложений над большими объемами данных, в том числе и ETL-приложений, можно детализировать следующим образом:
• извлечение из источника тех и только тех данных, которые удовлетворяют соответствующим условиям, определенным в требованиях;
• изменение в источнике значений тех и только тех данных, которые удовлетворяют соответствующим условиям, определенным в требованиях;
• трансформация (изменение значений, формата представления) входных данных в соответствии с требованиями;
• загрузка в приемник тех и только тех данных, которые должны быть загружены в соответствии с требованиями;
• изменение в приемнике значений тех и только тех данных, которые удовлетворяют соответствующим условиям, определенным в требованиях.
Проверка корректности поведения реализации осуществляется, как правило, при помощи функционального тестирования, которое состоит из выполнения приложения на специально подготовленных входных данных и сравнения полученных выходных данных с ожидаемыми результатами. В данной статье рассматривается задача генерации входных данных для функционального тестирования приложений над большими объемами данных (далее тестовые данные). В качестве примеров таких приложений рассматриваются БХЬ-при-ложения, содержащие все этапы, которые могут встречаться в приложениях над большими объемами данных: извлечение данных, их преобразование и загрузка.
Критерием качества функционального тестирования является полнота покрытия функциональных требований. Чем больше функциональных ветвей алгоритма, реализующего функциональные требования к тестируемому приложению, покрыто при выполнении тестов, тем качественнее тестирование. Из сформулированных выше подзадач функциональности БХЬ-приложений следует, что для покрытия функциональности таких
приложений в массиве тестовых данных должны присутствовать такие данные, что при выполнении приложения:
• выборка данных из источника и их фильтрация происходит по всем возможным комбинациям условий, определенных в требованиях;
• при трансформации данных покрываются все возможные функциональные ветви алгоритма трансформации, соответствующего требованиям.
• обеспечивается проверка отсутствия лишних изменений данных в приемнике и источнике;
• обеспечивается проверка обработки специальных данных (пустые поля, строки ограниченной длины и т.д.).
Множество всех возможных комбинаций значений входных данных заведомо содержит комбинации, необходимые для покрытия функциональности тестируемого приложения. Однако такой подход в реальных ситуациях очень быстро вызывает комбинаторный взрыв и приводит к неприемлемым затратам по времени генерации и по суммарному объему полученных тестов. Кроме того, в подавляющем большинстве случаев при проведении функционального тестирования полученное таким способом множество тестов заведомо является чрезмерным: очень многие тесты отличаются лишь такими значениями полей, которые не различимы с точки зрения функциональности. Это создает проблемы при анализе результатов тестирования: одна и та же ошибка будет проявляться на тысячах подобных "неразличимых" тестов, и все эти ситуации потребуют трудоемкого анализа.
Оптимальными с точки зрения покрытия функциональных требований являются такие данные, которые обеспечивают на каждое ветвление функциональности по одной возможной комбинации булевских выражений. В статье рассматривается метод получения тестовых данных, по объемам близких к оптимальному набору.
3. ОБЗОР СУЩЕСТВУЮЩИХ ИНСТРУМЕНТОВ
Большинство существующих инструментов генерации тестовых данных (DTM Data Generator [4], Turbo Data [5], DBMonster [6]) обеспечивают поддержку заполнения таблиц БД большим количеством синтаксически корректных данных и предоставляют следующие возможности:
• генерация случайных данных с возможностью задать интервал для числовых типов, длину для строк и формат генерируемых данных;
• генерация данных из списка, с возможностью указать процентное соотношение каждой строки из списка ко всем сгенерированным строкам;
• генерация данных путем их выбора из другой таблицы;
• генерация данных путем их выбора из файла;
• генерация автоувеличивающихся данных, с указанием начального значения и шага;
• генерация данных из существующих библиотек;
• генерация случайных данных по маске;
• генерация данных на основе возвращаемого результата SQL-выражений;
• генерация данных для зависимых таблиц;
• генерация данных на основе внешних процедур генерации, пользователь имеет возможность создавать свои процедуры.
Некоторые инструменты (AGENDA [7], HTDGen [8]) поддерживают генерацию данных не только на основе ограничений, заданных пользователем или схемой, но и на основе SQL-запросов тестируемого приложения. В этом случае гарантируется, как минимум, что SQL-запросы, используемые в реализации приложения, будут возвращать не пустой результат. Однако при генерации данных на
Рис. 1.
Пример зависимости значений полей.
основе реализации нет гарантии покрытия всех требуемых функциональных ветвей, так как реализация может содержать ошибочные ветви или не содержать требуемые. Так же такой подход не обеспечивает покрытия всех требуемых функциональных ветвей трансформации и фильтрации данных.
В общем случае, используя доступные инструменты, гарантировать полное покр
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.