...Все говорят, что мы вместе, но не многие знают, в каком...

В.Цой

В ASAP методологии внедрения проектов есть такие пункты как Union-test и Regression-test: модульное и регрессионное тестировани. Очень красивые слова, но на практике мало кто себе представляет как это можно реализовать применительно к SAP BW, где нет четких функциональных блоков, где данные, как корни деревьев перетекают из одного объекта в другой, трансформируются, модифицируются, обогащаются, меппируются и т.д., одним словом, нет осязаемого предмета, который можно было бы назвать модулем или блоком и назначить ему тестирование. Что уж говорить о регрессионном тестировании, которое по идее должно решать задачу целостности системы при ее доработке... Если посмотреть на практику работы крупных BI систем, то, если выражаться одним словом - это неподконтрольный треш, вызванный постоянным риском поломки новыми доработками уже работающего функционала. Дело даже не в том, что консультант может имееть искривление рук, или они могут расти не из плеч, сама система сбора запросов SAP BW провоцирует на попадание в транспортные запросы чужих объектов, приводящих к "излому" ранее работавшего функционала.      

Как я писал в статье "Практики экстремального программирования при внедрении BW/BI проектов", одна их самых труднореализуемых задач при внедрении SAP BW/BI - это решение проблемы тестирования. По большей части данныая проблема вызвана тем, что никто, по сути, не знает, как собственно этот функционал реализовать в ландшафте BW и где взять тестовые данные. Т.е. постулаты ASAP остаются красивыми идеями, не находящими практической реализации.

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

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

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

Применительно к SAP BW выделяются три связанных, но условно независимых вида регрессионного тестирования: тестирование ETL, тестирование отчетности, тестирование форм ввода. Разделение видов тестирования связано с тем, что технологически, ETL SAP BW и отчетность являются разнесенными функциональными областями, связь между которыми осуществляется только на уровне обмена данными.

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

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

Модель регрессионного теста ETL SAP BW

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