페이퍼요약 - 포괄적인 데이터 웨어하우스 테스팅 방법 by Golfarelli

제목: 포괄적인 데이터 웨어하우스 테스팅 방법(A Comprehensive Approach to Data Warehouse Testing)

저자: Matteo Golfarelli 외 1인, 이탈리아

문서유형: 학계 컨퍼런스 페이퍼(총 8페이지), 2009년

 

데이터 웨어하우스 시스템 테스팅을 위한 총괄적인 방법론적 프레임워크를 제안한 자료

---

DW 시스템 테스팅과 일반 소프트웨어 시스템 테스팅의 차이점

• 소프트웨어 테스팅이 주로 프로그램 코드에 집중하는 반면 DW 테스팅은 데이터와 정보에 중점을 둔다. 실제 DW 테스팅의 핵심은 데이터를 이해하고 사용자 쿼리에 대한 응답이 무엇인지를 아는데 있다.
• 일반 소프트웨어 시스템 테스팅과 달리 DW 테스팅은 아주 많은 데이터 양을 다루어야 할 필요가 있으며 결과적으로 성능과 생산성에 크게 영향을 받는다.
• DW 테스팅은 사용자에게 전달되는 정보의 정확성(correctness) 및 유용성(usefulness)에 중점을 두므로 일반 소프트웨어 테스팅 보다 더 넒은 범위를 가진다. 실제 DW 테스팅의 주요 목표 중 하나가 데이터 검증(data validation)이다.
• 일반 소프트웨어 시스템이 많은 수의 다양한 사용자 시나리오를 가지기는 하지만 이들의 타당성 있는 조합은 한정되어 있다. 반면 DW 시스템은 데이터의 모든 뷰를 지원하는 것을 목표로 하므로 가능한 조합의 거의 무한대여서 모두를 테스트 할 수가 없다.
• 일반 소프트웨어 시스템에서는 대부분의 테스팅 활동이 시스템 전개(deployment) 이전에 수행되지만 DW 테스팅 활동은 시스템 릴리즈 후에도 계속된다. 즉, DW 프로젝트는 특정 시점에 종료되는 개념이 아니고 지속적으로의사 결정 프로세스 관련 요구사항 및 운영 데이터 에러를 반영해야 하므로 회귀 테스팅이 본질적으로 불가피하다.

DW 테스팅의 구분

• DW 프로젝트에서 대부분의 최종 사용자 요구사항(end-users requirements)이 데이터 분석과 데이터 품질에 관한 것이므로 DW 테스팅은 1) ETL 프로세스(백엔드 테스팅)와 2) 리포팅 및 OLAP(프론트엔드 테스팅)에 중점을 둔다.
• 백엔드 테스팅은 데이터 웨어하우스로 로드된 데이터가 소스 데이터와 일관성을 가지는지를 확인하는데 중점을 두며 프론트엔드 테스팅은 가용 보고서에서 데이터가 정확하게 보여지며 제대로 취합되어(aggregated) 나타나는지를 검증하는데 목표가 있다.

테스팅 관련 조직 구성원의 역할

• 분석가(Analysts): 테스팅의 참고 자료(a reference)가 되는 사용자 요구사항을 표현한 개념 스키마(conceptual schemata) 작성을 책임진다.
• 설계가(Designers): 데이터 저장소의 논리 스키마(logical schemata)와 효율성 및 견고성 측면에서 테스트가 필요한 데이터 스테이징플로우 작성을 책임진다.
• 테스터(Testers): 테스트 계획과 테스트 스크립트를 개발하고 실행한다.
• 개발자(Developers): 화이트 박스 단위 테스트를 수행한다.
• 데이터베이스 관리자(Database administrators): 성능 및 스트레스 테스트를 수행하고 테스트 환경을 셋업한다.
• 최종 사용자(end-users): 리포팅과 OLAP 프론트엔드에 대한 기능 테스트를 수행한다.

 

데이터마트개발 단계

다수의 데이터 마트로 구성된 DW 시스템은 대개 한번에 하나의 단일 데이터 마트를 설계 및 구현하는 일을 반복하는 방식으로 구축된다. 단일 데이터 마트는 아래와 같은 8 단계로 개발된다.

• 요구사항 분석(Requirement analysis): 사용자로부터 요구사항을 추출하여 비정형적으로 또는 정형적으로 표현한다.
• 분석 및 통합(Analysis and reconciliation): 데이터 소스를 검사하고, 정규화하고, 통합하여 통합 스키마(a reconciled schema)를 획득한다.
• 개념적 설계(Conceptual design): 사용자 요구사항과 통합 스키마의 데이터를 고려하여 데이터 마트의 개념 스키마를 설계한다(예, fact schemata 형태로 설계).
• 워크로드 정제(Workload refinement):사용자가 표현한 일차적인 워크로드를 정제하고 UML 유스케이스 다이어그램 등을 이용하여 사용자 프로파일을 추려낸다.
• 논리적 설계(Logical design): 개념적 스키마를 적절히 변환하여 데이터 마트의 논리 스키마를 획득한다(예, star schemata 형태로 설계).
• 데이터 스테이징 설계(Data staging design): 소스 스키마, 통합 스키마, 데이터 마트의 논리 스키마를 고려하여 ETL 절차를 설계한다.
• 물리적 설계(Physical design): 인덱스 선정, 스키마 단편화(schema fragmentation), 기타 물리적 할당(Physical allocation)과 관련된 모든 이슈를 다룬다.
• 구현(Implementation): ETL 절차를 구현하고 프론트엔드 리포트를 생성한다.

DW 시스템의 테스트 대상 항목

• 개념 스키마(Conceptual schema):구현에 독립적인 관점에서 데이터 마트를 기술. 모니터할 팩트(facts), 팩트 측정치, 취합(aggregation)에 사용되는 계층구조(hierarchies)를 명세
• 논리스키마(Logical schema): 데이터 마트의 코어에 있는 데이터 저장소의 구조를 기술. 만약 구현 타겟이 ROLAP 플랫폼이라면 논리 스키마는 관계형 스키마가 된다(대개 스타 스키마 또는 그 변형 중 하나).
• ETL 절차(ETL procedures): 데이터 소스로부터 나온 데이터로 데이터 저장소를 채우는 일을 하는 복잡한 절차
• 데이터베이스(Database): 데이터를 저장하는 저장소(repository)
• 프론트엔드(Front-end): 데이터를 분석하기 위해 최종 사용자가 접근하는 애플리케이션으로 대개 정적 리포팅 도구나 또는 좀더 유연한 OLAP 도구

DW 시스템의 테스트 타입

• 기능 테스트(Functional test): 테스트 대상 항목이 명세된 비즈니스 요구사항에 부합하는지 검증
• 사용성 테스트(Usability test): 테스트 대상 항목의 사용 및 이해가 쉬운지 검증하기 위해 해당 항목을 사용자와 직접 상호작용하도록 하여 평가
• 성능 테스트(Performance test): 일상적인 워크로드 조건에서 테스트 대상 항목의 성능이 만족스러운지를 체크
• 스트레스 테스트(Stress test): 데이터 부하 및 매우 높은 워크로드가 주어졌을 때 테스트 대상 항목이 얼마나 잘 작동하는지를 확인
• 복구 테스트(Recovery test): 시스템 충돌(crashes), 하드웨어 실패, 기타 유사한 문제로부터 테스트 대상 항목이 얼마나 잘 복구할 수 있는지를 체크
• 보안 테스트(Security test): 테스트 대상 항목이 데이터를 보호하고 의도한대로 기능을 유지할 수 있는지 체크
• 회귀 테스트(Regression test): 테스트 대상 항목이 변경 발생 후에도 여전히 정상 작동하는지 체크 

	개념 스키마	논리 스키마	ETL 절차	데이터베이스	프론트엔드
기능테스트	ü	ü	ü		ü
사용성테스트	ü	ü			ü
성능테스트		ü	ü	ü	ü
스트레스테스트			ü	ü	ü
복구테스트			ü	ü
보안테스트			ü	ü	ü
회귀테스트	ü	ü	ü	ü	ü

[테스트 대상 항목과 테스트 타입의 관계 - ü는 해당 테스트 적용이 필요함을 표시]

DW 시스템 테스팅의 방법론적 프레임워크

개념 스키마 테스팅(Testing the Conceptual Schema)

• 데이터 마트 개념 스키마의 기능 테스트로 크게 두 가지 테스트 타입을 제안(팩트 테스트, 부합성 테스트)
• 팩트 테스트(fact test): 요구사항 분석에서 사용자가 일차적으로 표명한 워크로드가 개념 스키마에 의해 지원되는지를 검증. 즉, 각 워크로드 쿼리에 대하여 요구 측정치(the required measures)가 팩트 스키마(the fact schema)에 포함되어 있는지, 요구 취합 수준(the required aggregation level)이 팩트 스키마에서 유효한 그룹핑 셋트로 표현될 수 있는지를 체크
• 부합성 테스트(conformity test): 계층구조(hierarchies)가 얼마나 잘 설계되었는지 평가. 이 테스트는 각 팩트를 디멘젼과 연계함으로써 계층 구조를 보여주는 버스 매트릭스(bus matrix)의 희박도(sparseness)를 측정하여 수행할 수 있다. 버스 매트릭스가 매우 희박하다면 설계자는 명백하게 다른 계층간의 의미적 유사성과 구조적 유사성을 인지하는데 실패했을 가능성이 높다. 반대로 버스 매트릭스가 매우 조밀하다면 설계자는 명백하게 다른 팩트간의 의미적 유사성과 구조적 유사성을 인지하는데 실패했을 가능성이 높다.
• 사용성 테스팅에서는 계층별 평균 레벨 수, 팩트별 측정치 수 같은 메트릭을 사용하여 이해성(understandability) 측면에서 개념 스키마의 품질을 정량적으로 측정한다.

논리 스키마 테스팅(Testing the Logical Schema)

• 기능 테스트 방법으로 일차 워크로드의 쿼리 샘플이 논리 스키마 상에서 올바르게 SQL로 표현될 수 있는지를 검증하는 스타 테스트(star test)가 있다. 샘플 구성 시 계층(hierarchies)의 불규칙한 부분에 관여된 쿼리(예, 다대다 연계, 크로스 디멘젼 애트리뷰트), 복잡한 취합 방법(aggregation schemes)에 기반한 쿼리, 비표준 시간적 시나리오(non-standard temporal scenarios)에 의존하는 쿼리에 우선순위를 준다.
• 사용성 테스팅에서는 논리 스키마의 팩트 테이블 수나 디멘젼 테이블 수에 기반한 간단한 메트릭으로 스키마의 이해하기 쉬운 정도(understandability)를 측정한다.
• 논리 스키마에 대한 성능 테스트에서는 논리 스키마가 어느 정도 다차원 정규형(the multidimensional normal forms)에 부합하는지를 체크한다.
• 데이터 마트의 논리 스키마가 진화 프로세스 동안의 변경을 감당해 내는 능력을 평가하는데 목표를 둔 유지보수성(maintainability) 측면의 매트릭도 제안됨

ETL 절차 테스팅(Testing the ETL Procedures)

ETL 테스팅은 데이터 품질에 직접적인 영향을 미치므로 가장 복잡하고 중요한 테스트 단계이다. ETL은 많은 부분이 코드 기반이므로 일반 소프트웨어 시스템 테스팅의 표준 기법들을 여기서 적용할 수 있다.

• 기능 테스트는 ETL 절차가 정확하게 데이터를 추출하고(extract), 정제하고(clean), 변환하고(transform), 데이터 마트로 로드하는지(load)를 체크하는데 목표가 있다.단위 테스트와 통합 테스트에서 기능 테스트 수행
• 단위 테스트: 각 개발자가 개발된 단위에 대해 화이트 박스 테스트를 수행. ETL의 수직적 단위(예, 디멘젼, 상호연관된 팩트의 그룹) 또는 수평적 단위(예, 정적 추출물, 점증적 추출물)를 테스트 단위로 선정. 데이터 마트의 팩트수, 정제 및 변환의 복잡도, 구현 계획이 개발자에게 어떻게 분배되었는지를 고려하여 적절한 테스트 단위를선정한다.
• 통합 테스트: ETL 절차에서 데이터 플로우의 정확성을 체크. 데이터 응집도, 완전도, 신선도(데이터의 나이) 등의 여러 품질 차원을 고려한다.
• ETL 기능 테스팅은 적어도 3개 유형의 데이터베이스로 수행되어야 한다(1완전하고 정확한 데이터, 2 흔히 발생하는 잘못된 데이터를 흉내 낸 더티 시뮬레이션 데이터, 3실 데이터). 특히 더티 시뮬레이션 데이터를 사용하는 테스트는 ‘의도된 에러 테스트(forced-error tests)’라고도 불리는데, 시스템이 잘못된 데이터를 계획대로 처리할 수 있는지를 검증하기 위해 ETL 절차가 에러 조건에 직면하도록 설계한 테스트이다.
• 성능 테스트:일상적인 워크로드(즉, 도메인의 통상적인 데이터 양이 추출되고 로드됨)에 대한 ETL의 동작을 평가한다. 특히 프로세싱 시간이 데이터 스테이징 프로세스에서 의도하는 시간대(the time frames)에 맞는지를 체크한다.
• 스트레스 테스팅:정상 보다 훨씬 많은 데이터 양을 가진 워크로드를 시뮬레이션 하여 테스트한다.
• 복구 테스트: 하나 또는 여러 컴포넌트에 결함이 존재할 때의 시스템 반응을 평가하여 견고성(robustness)을 체크한다(예, ETL 프로세스 진행 중에 파워 공급을 차단, 복구 정책의 효과성 체크를 위해 OLAP 세션이 진행중인 동안 데이터베이스를 오프라인화)
• 보안 테스트: 데이터 스테이징 영역에서 처리될 데이터를 임시로 저장하기 위해 사용하는 데이터베이스의 침범이 불가능함을 검증할 필요가 있으며, 또한 데이터 소스와 데이터 마트를 연결하는 데이터 플로우를 호스팅하는 네트워크 인프라구조가 안전한지도 확인해야 한다.

데이터베이스 테스팅(Testing the Database)

논리 스키마 테스트에서 논리 스키마의 품질이 이미 검증되었고 ETL 테스트가 데이터 품질 관련 모든 이슈를 다루었다고 가정했을 때 데이터베이스 테스팅은 표준 워크로드나 과부하 워크로드에서 데이터베이스 성능을 체크하는데 주 목적이 있다. ETL에서와 마찬가지로 테스트 되는 데이터베이스의 크기와 데이터 분포는 반드시 설계자 및 데이터베이스 관리자와 의논해야 한다.

• 성능 테스트: 실 데이터를 포함한 데이터베이스 또는 모의 데이터베이스(mock database)를 가지고 수행하며, 테스트되는 데이터베이스의 크기는 실제 시스템의 예상 평균 데이터 양에 부합해야 한다.
• 스트레스 테스트: 대개 모의 데이터베이스(mock databases)로 수행하며, 데이터베이스 크기가 정상 보다 훨씬 크다.
• 최대 쿼리 반응 시간(maximum query response time) 같은 표준 DB 메트릭을 테스트 결과를 정량화하는데 사용 가능하며, 성능/스트레스 테스팅 활동을 최대한 진전시키고 프론트엔드 애플리케이션에 독립적인 테스트 결과를 얻기 위해 워크로드 코딩에 SQL을사용하는 것이 좋다.
• 복구 테스트:심각한 에러(예, 업데이트 중 파워 중단, 네트워크 에러, 하드 디스크 에러)가 발생한 후 DBMS 동작을 검증
• 보안 테스트: 데이터 보호를 위한 암호 기법(cryptography technique) 사용과 사용자 프로파일 및 데이터 액세스 권한(database access grants)의 정확한 정의가 주 관심사

프론트엔드테스팅(Testing the Front-End)

• 프론트엔드의 기능 테스팅에서는 애플리케이션 도메인에 익숙하여 데이터의 사소한 비정상(abnormality)도 발견할 수 있는 많은 수의 최종사용자 참여가 필수적이다.
• OLAP 분석의 잘못된 결과는 잘못된 ETL 절차 때문만이 아니라 프론트엔드 도구의 부정확한 데이터 취합(aggregations)이나 데이터 선택에 의해서도 발생될 수 있으며, 또한 일부 에러는 데이터 마트 때문이 아니라 소스 데이터베이스의 지나치게 낮은 데이터 품질의 결과이기도 하다. 따라서 OLAP 분석의 결과를 소스 데이터베이스를 직접 쿼리하여 얻은 결과와 비교하는 방법이 프론트엔드 기능 테스팅에서 주로 사용된다.
• 프론트엔드의 단위 테스트는 단일 팩트와 관련된 리포트의 정확성 체크에 목표를 두며, 통합 테스트는 다수의 팩트를 상호 연결시키거나(즉, drill-across 쿼리) 또는 다른 애플리케이션 컴포넌트를 이용에 대한 분석 세션을 수반 한다.
• 사용성 테스트: OLAP 리포트가 적절하게 표현되었고 데이터의 실제 의미에 대한 오해를 피하기 위한 주석이 달렸는지를 체크한다.
• 성능 테스트: 프로트엔드에 한 무리의 쿼리를 동시에 제출하여(즉, concurrent queries)이 쿼리들을 처리하는데 걸리는 시간을 확인한다. 동시 사용자 수, 쿼리 타입, 데이터 양 측면에서 명세된 표준 워크로드를 적용
• 스트레스 테스트: 시스템 안전성(stability)을 평가하기 위해 표준 워크로드보다 훨씬 높은 워크로드를 적용한다.
• 성능 테스트와 스트레스 테스트는 클라이언트 인터페이스를 포함하는 프론트엔드를 중시하지만 리포팅과 OLAP 서버 엔진에도 역시 관심을 둔다. 즉 DBMS로 인한 접근 시간(access time)은 측정된 전체 응답 시간에서 차감해야 한다.
• 보안 테스트: 사용자 프로파일이 제대로 셋업되었는지를 체크하는 것이 특히 중요하다. 또한 서로 다른 분석 애플리케이션 간의 전환이 발생한 후에 single-sign-on 정책이 제대로 셋업되는지도 체크해야 한다.

회귀 테스트(Regression Tests)

• 데이터 마트처럼 자주 업데이트 되는 시스템에 관련된 문제로 신규 컴포넌트 또는 새롭게 추가된 기능(new add-on features)이 전체 시스템 오퍼레이션에 부합하는지를 확인한다. 즉, 시스템에 가해진 변동이 기존 품질과 이미 테스트된 기능을 해치지 않고 또한 시스템 성능을 저하하지 않음을 보장하기 위해 수행되는 테스팅 활동이다.
• 전체 시스템을 여러 차례 반복 테스트 하는 것은 높은 비용이 들므로 이를 줄이기 위한 3가지 접근방법이 아래와 같다.
  i) 테스팅에서 비용이 많은 드는 활동인 테스트 결과 확인(the validation of the test results)을 생략한다(즉, 회귀 테스팅에서는 테스트 결과가 이전 테스팅에서 얻어진 결과와 일관적인지만을 확인)
  ii) 테스트 자동화를 통해 이전 테스트를 재생하는데 드는 비용을 줄이고 테스팅 활동의 효율성을 증가시킨다.
  iii) 특정 애플리케이션 오브젝트의 변경에 의해 영향을 받는 타 애플리케이션 오브젝트를 식별하는 영향 분석 기법(Impact analysis)을 적용하여 테스트 범위를 크게 줄인다.