문서요약 - 데이터 웨어하우스 테스팅과 구현 by Execution-MiH

제목: 데이터 웨어하우스 테스팅과 구현(DW Testing and Implementation)

저자: Execution-MiH

문서유형: 웹 문서

http://www.executionmih.com/data-warehouse/testing-implementation.php

 

Execution-MiH 사이트의 데이터 웨어하우스에 대한 웹 문서 중 테스팅 섹션을 정리한 자료

---

데이터 웨어하우스 테스팅의 다른점

DW 파퓰레이션(Data Warehouse population)의 대부분의 작업이 배치 런(batch runs)을 통해 이루어지므로 트랜잭션 처리 시스템에서 수행되는 테스팅과는 아래와 같은 차이가 있다.

 

사용자 유발(User-triggered) vs. 시스템 유발(System triggered)
소스 시스템/운영 시스템의 경우 사용자 입력으로부터 야기된 개별 트랜잭션의 처리를 테스팅 하는 것이 대부분이고 시스템이 유발하는 시나리오(예, 빌링)는 드물다. 반면 DW는 대부분의 테스팅이 ETL 스크립트, 뷰 리프레시 스크립트 같은 시스템이 유발하는 작업이다. 통상적으로 DW 테스팅은 백엔드 테스팅(Back-end testing)과 프론트엔드 테스팅(Front-end testing)의 두 부분으로 나뉜다. 백엔드 테스팅은 소스 시스템 데이터와 로드된 영역의 최종 결과 데이터를 비교하며, 프론트엔드 테스팅에서는 OLAP 같은 최종 사용자 도구에 의해 디스플레이 된 데이터와 경영 정보 시스템(MIS)의 데이터를 비교하여 사용자가 데이터를 체크한다.

 

배치(Batch) vs. 온라인(online gratification)

트랜잭션 시스템은 트랜잭션을 입력한 사용자에게 즉각적인(또는 하룻밤 내에) 반응을 주지만, DW의 경우 대부분의 액션이 백엔드에서 발생하고 사용자는 MIS 또는 OLAP 도구가 제공하는 뷰를 통해 개별 트랜잭션을 추적해야만 하므로 사용자의 관심을 잡아 두기가 어렵다.

 

테스트 데이터의 볼륨(Volume of Test Data)

트랜잭션 시스템에서 테스트 데이터는 전체 운영 데이터의 제한된 작은 샘플이지만, DW는 대개 디멘젼(dimensions)과 팩트(facts)의 최대 가능한 조합(combinations)과 순열(permutations)을 채우기 위한 큰 규모의 테스트 데이터를 가진다.

 

가능한 시나리오/테스트 케이스(Possible scenarios/Test Cases)

만약 트랜잭션 시스템이 수백 개의 다른 시나리오를 가진다면 이 시나리오들의 타당성 있는 가능 조합은 한정되어 있다. 반면 DW의 경우 테스트 할 수 있는 순열과 조합이 거의 무한대이다(DW의 핵심 목표가 데이터의 모든 가능한 뷰를 허용하는 것이기 때문). 따라서 신뢰도가 높은 테스트 시나리오 설계를 위해서는 창의성이 요구된다.

 

테스트 데이터 준비(Test Data Preparation)

가능한 테스트 시나리오 수 및 테스트 데이터 양과 관련된 이슈로 DW의 경우 이 두 가지를 준비하는데 훨씬 많은 노력이 소요된다.

 

테스팅을 위한 프로그래밍

트랜잭션 시스템은 대개 사용자 또는 비즈니스 분석가가 시스템 출력물을 확인하여 테스트가 이루어진다. DW의 경우 대부분의 액션이 백엔드에서 발생하며 ‘DW 데이터 품질 테스팅’과 ‘ETL 테스팅’ 대부분이 별도의 독립형 스크립트(stand-alone scripts)를 실행시켜 이루어진다. 

데이터 웨어하우스 테스팅 카테고리(Data Warehouse Testing Categories)

프로세스 단계에 따라 DW 테스팅은 아래와 같은 테스트 카테고리와 체크 사항을 가진다.

 

추출 테스팅(Extraction Testing)

• 요구된 데이터 필드를 추출할 수 있다.
• 각 소스 시스템의 추출 로직이 제대로 작동한다.
• 소스 시스템으로 추출 스크립트의 보안 접근이 허용된다.
• 추출 감사 로그 및 타임 스탬프의 업데이트가 이루어진다.
• 소스에서 추출 목적지로 완전하고 정확한 추출이 이루어진다.
• 예상 윈도우에서 추출이 완료된다.

 

변환 테스팅(Transformation Testing)

• 트랜잭션 스크립트가 예상 로직에 따라 데이터를 변환한다.
• 과거 스냅샷(historical snap-shots)의 일회성 변환이 이루어진다.
• 상세하고 종합된 데이터 집합이 생성되고 매치된다.
• 트랜잭션 감사 로그와 타임 스탬프가 이루어진다.
• 변환 프로세스 동안에 데이터 손실(pilferage of data)이 없다.
• 주어진 윈도우에서 변환이 완료된다.

 

로딩 테스팅(Loading Testing)

• 로딩 프로세스 동안에 데이터 손실이 없다.
• 로딩 프로세스 동안에 모든 변환 작업이 제대로 동작한다.
• 스테이징 단계의 데이터 셋이 로딩 목적지로 제대로 로드된다.
• 일회성 과거 스냅샷이 제대로 로드된다.
• 점진적 리프레시(incremental refresh)와 전체 리프레시(total refresh)가 둘 다 제대로 동작한다.
• 예상 윈도우에서 로딩이 발생한다.

 

최종 사용자 브라우징과 OLAP 테스팅

• 비즈니스 뷰와 데시보드가 의도한 대로 데이터를 디스플레이 한다.
• 예정된 보고서가 정확하고 완전하다.
• 예정된 보고서와 뷰 리프레시 같은 기타 배치 오퍼레이션이 예상 윈도우에서 발생한다.
• ‘분석 기능(Analysis Functions)’과 ‘데이터 분석’이 제대로 동작한다.
• 소스 시스템과 뷰 사이의 데이터 손실이 없다.

 

애드 혹 쿼리 테스팅(Ad-hoc Query Testing)

• 애드 혹 쿼리 생성이 의도된 기능대로 이루어진다.
• 애드 혹 쿼리 출력 응답 시간이 의도한 대로이다.

 

다운 스트림 플로우 테스팅(Down Stream Flow Testing)

• DW로부터 데이터가 추출되고, 다운 스트림 시스템/데이터 마트에서 업데이트 된다.
• 데이터 손실이 발생하지 않는다.

 

일회성 파퓰레이션 테스팅(One Time Population testing)

• 운영 데이터(the production data)에 대한 일회성 ETL이 제대로 동작한다.  
• 운영 보고서(The production reports)와 DW 보고서가 매치된다.
• 일회 프로세싱에 걸리는 시간이 전환을 위해 할당된 주말 시간 동안 가능하다.

 

엔드 투 엔드 통합 테스팅(End-to-End Integrated Testing)

• 소스 시스템으로부터 다운 스트림 시스템까지 엔드 투 엔드 데이터 플로우가 완전하고 정확하다.

 

스트레스 테스팅과 볼륨 테스팅(Stress and volume Testing)

시스템의 견고성(robustness)과 용량(capacity)을 체크하기 위해 최대 볼륨 또는 실패가 발생할 정도의 볼륨을 주어 수행하는 테스트로 아래의 예를 들 수 있다.

• 배치 프로세스 동안 서버 중단(shutdown)
• 계획된 최대 용량 보다 2~3배 많은 데이터로 추출, 변형, 로딩 수행
• 정상 보다 2~3배 많은 사용자를 통해 많은 수의 애드혹 쿼리를 발생시킴
• 많은 수의 예정 보고서(scheduled reports)를 런 시킴

 

병행 테스팅(Parallel Testing)

실제와 같은 운영 데이터로 DW를 런 시키고 그 결과를 기존 보고서 집합과 비교하여 양쪽이 매치가 되는지(또는 납득 가능한 불일치가 있는지) 확인한다.

 

보안 프레임워크 테스팅(Security Framework testing)

보안 프레임워크(Security Framework)의 가능한 모든 측면을 체크한다.

데이터 웨어하우스 테스트 시나리오(Data Warehouse Test Scenarios)

현실적인 단순 시나리오(Real Life Simple Scenarios)

단순 시나리오는 비교적 간단하고 시스템의 상태를 이해하는 가장 첫 단계의 확인사항들로 예를 들면 아래와 같은 것들이 있다.

• 추출: 견고한 DBMS로 핵심 시스템으로부터 테이블 완전 추출
• 변환: 간단한 도출 애트리뷰트 생성(예, 개별 빌링 항목으로부터 빌링 총계 생성)이나 종합 데이터(aggregates) 생성
• 로딩: 더 적은 애트리뷰트로 로딩 동안에 어떤 변환도 없이 디멘젼 셋 로딩
• OLAP: ‘기본 기능(Basic Functions)’을 이용한 테스팅

 

현실적인 복합 시나리오(Real Life complex scenarios)

• 추출: 표준 고객 코드에 매치되지 않는 고객을 걸러낸(필러링) 액셀 시트로부터 데이터 추출
• 변환: 'De-Dup', 'Integration' 수행
• 로딩: 큰 애트리뷰트 셋을 가진 디멘젼 로딩
• OLAP: OLAP 파퓰레이션을 테스팅

 

경계 테스팅(Boundary Testing) 시나리오

DW가 직면할 수 있는 극한의 상황을 테스트하는 것으로 예를 들면 아래와 같다.

• 추출: 소스 시스템에 데이터가 없음
• 변환: 매우 큰 또는 매우 작은 입력으로 도출 애트리뷰트(derived attribute) 생성

 

네가티브 테스팅(Negative Testing) 시나리오

시스템이 부정 조건(negative conditions)을 어떻게 처리하는지 체크하는 것으로 예를 들면 아래와 같다.

• 추출: 테이블에 잘못된 또는 예상치 않은 데이터 존재(예, 잘못된 고객 ID 형식, 수치 필드인 곳에 캐릭터 필드를 사용 등)
• 변환: 변환 로직이 마이너스 판매 수치나 나이가 200살 같은 정상적이지 않은 상황을 만나는 경우
• 로딩: 특정 디멘젼 데이터 셋의 컬럼 수가 부족하거나 null 값을 가지는 등의 잘못된 데이터 셋을 로딩해야 하는 경우. 대용량 로딩(bulk Loading)을 시작하기 전에 로딩 시스템이 몇몇 기본적인 체크를 수행할 필요가 있다.
• OLAP: 사용자가 잘못된 식(formulae)을 입력하는 경우

 

완전 운영 시뮬레이션(Full Production Simulation)

• 전체 스케일 병행 테스팅(a full scale parallel testing)과 유사하지만 약간 다른 테스트
• 이전 시점에 수행된 소스 시스템의 백업을 가지고 완전한 ETL을 수행하며 그 결과를 보기 위해 최종 사용자 도구 오퍼레이션을 런 시킨다.
• 운영 시뮬레이션은 사용자 관점의 병행 테스팅 수행을 위해 시스템을 릴리즈 하기 전 단계에 수행되는 실험실 테스트(a lab test)이다.