data validation tests
이 자습서에서는 ETL 및 데이터 마이그레이션 프로젝트에 대해 설명하고 데이터 품질 향상을위한 ETL / 데이터 마이그레이션 프로젝트에 대한 데이터 유효성 검사 또는 테스트를 다룹니다.
이 문서는 ETL 또는 데이터 마이그레이션 프로젝트에서 작업하고 있으며 데이터 품질 측면에만 테스트를 집중하려는 소프트웨어 테스터를위한 것입니다. 이러한 유형의 프로젝트에는 소스 스토리지에 저장된 후 소프트웨어에있는 일부 로직에 의해 작동되고 대상 스토리지로 이동되는 엄청난 양의 데이터가 있습니다.
데이터 유효성 검사 테스트는 최종 대상 시스템에있는 데이터가 비즈니스 요구 사항에 따라 유효하고 정확하며 라이브 프로덕션 시스템에서 사용하기에 적합한 지 확인합니다.
mp3 변환기에 최고의 유튜브 비디오
테스트 할 수있는 데이터 품질 측면의 수는 방대하며 아래 목록은이 주제에 대한 소개를 제공합니다.
학습 내용 :
데이터 검증이란?
간단히 말해서 데이터 유효성 검사는 ETL 또는 데이터 마이그레이션 작업의 일부로 이동 된 데이터가 비즈니스 요구 사항을 충족하기 위해 대상 프로덕션 라이브 시스템에서 일관되고 정확하며 완전하다는 사실을 확인하는 행위입니다.
예: Student 테이블의 학생 주소는 소스 시스템에서 2000 자였습니다. 데이터 유효성 검사는 대상 시스템에 정확히 동일한 값이 있는지 확인합니다. 데이터가 잘 렸는지 또는 특정 특수 문자가 제거되었는지 확인합니다.
이 기사에서는 이러한 많은 데이터 유효성 검사에 대해 설명합니다. ETL 또는 데이터 마이그레이션 프로젝트의 테스터로서 대상 시스템으로 전파되고 전체 비즈니스 프로세스를 방해 할 수있는 데이터 품질 문제를 발견하면 엄청난 가치를 더합니다.
ETL 프로젝트의 데이터를 검증하는 이유는 무엇입니까?
ETL 프로젝트에서 데이터는 소스에서 추출되고 소프트웨어에 일부 로직을 적용하여 작업 한 다음 변환 된 다음 대상 스토리지에로드됩니다. 대부분의 경우 변환은 비즈니스 요구 사항에 대해보다 유용한 형식으로 소스 데이터를 변경하기 위해 수행됩니다.
여기서 대상 시스템에로드되는 데이터가 완전하고 정확하며 데이터 손실이나 불일치가 없는지 확인하기 위해 데이터 유효성 검사가 필요합니다.
예: 전자 상거래 애플리케이션에는 고객의 TotalDollarsSpend를 합산 한 Orders 테이블에서 각 CustomerID에 대한 모든 OrdersId를 선택하는 ETL 작업이 있으며이를 새 CustomerValue 테이블에로드하여 각 CustomerRating을 고 / 중 / 저 가치 고객 기반으로 표시합니다. 복잡한 알고리즘에서.
간단한 데이터 유효성 검사 테스트는 CustomerRating이 올바르게 계산되었는지 확인하는 것입니다.
또 다른 테스트는 TotalDollarSpend가 값을 반올림하거나 최대 값 오버플로에 결함없이 올바르게 계산되었는지 확인하는 것입니다.
데이터 마이그레이션 프로젝트를 위해 데이터를 검증하는 이유는 무엇입니까?
데이터 마이그레이션 프로젝트에서 소스 스토리지에 저장된 방대한 양의 데이터는 인프라 업그레이드, 구식 기술, 최적화 등과 같은 여러 이유로 다른 대상 스토리지로 마이그레이션됩니다. 예를 들면 기업은 대규모 데이터웨어 하우스를 레거시 시스템에서 AWS 또는 Azure의 새롭고 강력한 솔루션으로 마이그레이션 할 수 있습니다.
이러한 프로젝트의 주된 동기는 데이터를 소스 시스템에서 타겟 시스템으로 이동하여 비즈니스를 중단하거나 부정적인 영향을주지 않으면 서 타겟의 데이터를 매우 유용하게 사용하는 것입니다.
여기서도 소스의 데이터가 이동 후 대상에서 동일한 지 확인하기 위해 데이터 유효성 검사가 필요합니다.
예: 전자 상거래 애플리케이션의 경우 2 억 개의 행이있는 Orders 테이블이 Azure의 대상 시스템으로 마이그레이션되었다고 가정합니다. 간단한 데이터 유효성 검사 테스트는 대상 시스템에서 모든 2 억 행의 데이터를 사용할 수 있는지 확인하는 것입니다.
또 다른 테스트는 날짜 형식이 소스 시스템과 대상 시스템간에 일치하는지 확인하는 것입니다.
기능 테스트, 성능 테스트, 보안 테스트, 인프라 테스트, E2E 테스트, 회귀 테스트 등과 같은 프로젝트에서 테스터가 테스트 할 수있는 다양한 측면이 있습니다.
추천 자료 => 데이터 마이그레이션 테스트 , ETL 테스트 데이터웨어 하우스 테스트 자습서
이 기사에서는 ETL 및 마이그레이션 프로젝트 테스트의 데이터 측면 만 살펴볼 것입니다.
데이터 매핑 시트
먼저 데이터 프로젝트에 대한 데이터 매핑 시트를 만듭니다. 데이터 매핑은 원본 테이블과 대상 테이블간에 엔터티를 일치시키는 프로세스입니다. 스프레드 시트의 소스 시스템에있는 모든 테이블과 해당 엔티티를 문서화하는 것으로 시작합니다. 이제 대상 테이블에서 일치 할 것으로 예상되는 각 행에 해당하는 값을 문서화하십시오. 변환 규칙이있는 경우 별도의 열에 기록하십시오.
데이터 매핑 시트에는 Data Architects에서 제공하는 데이터 모델에서 선택한 많은 정보가 포함되어 있습니다. 처음에 테스터는 단순화 된 버전을 만들고 진행하면서 더 많은 정보를 추가 할 수 있습니다. 아래 데이터 매핑 시트의 예를 참조하십시오. 
에서 템플릿 다운로드 단순화 된 데이터 매핑 시트
데이터 검증 테스트
# 1) 데이터 균일 성
데이터 균일 성 테스트는 엔티티의 실제 값이 다른 위치에서 정확히 일치하는지 확인하기 위해 수행됩니다. 여기서 가능한 두 가지 유형의 테스트가 있습니다.
(i) 동일한 스키마 내에서 확인 :
- 데이터 엔티티는 동일한 스키마 (소스 시스템 또는 대상 시스템) 내의 두 테이블에 존재할 수 있습니다.
- 예: 아래 이미지에서 볼 수 있듯이 ProductID는 OrderDetails 및 Products 테이블에 있습니다. OrderDetails vs Products 테이블에있는 ProductId에 대해 정확히 일치하는지 확인합니다.
(ii) 스키마 간 확인 :
- 데이터 엔티티는있는 그대로 대상 스키마로 마이그레이션 될 수 있습니다. 즉, 소스 시스템과 대상 시스템에 존재합니다.
- 예: 위 이미지에서 볼 수 있듯이 ProductID는 소스 시스템의 Products 테이블과 대상 시스템의 Products 테이블에 있습니다. 소스 시스템의 Products 테이블에있는 ProductId를 대상 시스템의 Products 테이블에있는 ProductId와 정확히 일치시키는 확인을 수행합니다.
노트 : 빠른 참조를 위해 데이터 매핑 시트에서 일치하는 데이터 엔티티를 강조 표시 (색상 코드)하는 것이 가장 좋습니다.
# 2) 엔티티 존재
이 유형의 테스트에서는 모든 엔터티 (테이블 및 필드)가 원본과 대상간에 일치하는지 확인해야합니다. 두 가지 가능성이 있습니다. 데이터 모델 디자인에 따라 엔터티가 있거나 없을 수 있습니다.
(나는) 소스와 대상 모두에 해당하는 존재가있는 모든 테이블 (및 열)이 일치하는지 확인합니다. 모든 테이블 (및 열) 목록을 가져와 텍스트 비교를 수행합니다. 이 온 전성 테스트는 동일한 엔티티 이름이 전체적으로 사용되는 경우에만 작동합니다.
때로는 다른 테이블 이름이 사용되므로 직접 비교가 작동하지 않을 수 있습니다. 데이터 매핑 시트에이 정보를 매핑하고 실패 여부를 확인해야 할 수 있습니다.
또 다른 가능성은 데이터가 없다는 것입니다. 데이터 모델에서 소스 시스템 (또는 열)의 테이블이 대상 시스템에 해당하는 존재가 없거나 그 반대의 경우가 필요한 경우가 있습니다. 이를 검증하기위한 테스트를하십시오.
- 예: 아래 이미지에서 볼 수 있듯이 CustDemographic Table은 소스 시스템이 아닌 타겟 시스템에 있습니다.
- Customers 테이블의 CustomerType 필드에는 대상 시스템이 아닌 소스 시스템에만 데이터가 있습니다.
# 3) 데이터 정확성
이름에서 알 수 있듯이 데이터가 논리적으로 정확한지 확인합니다. 이 유형의 테스트에는 두 가지 범주가 있습니다. 이를 통해 테스터는 소스 시스템에서도 데이터 품질 문제를 포착 할 수 있습니다.
(영상 출처 )
노트 : 대상 시스템에서이 테스트를 실행하고 결함이 있는지 소스 시스템에서 백 체크하십시오.
(i) 숫자가 아닌 유형 : 이 분류에 따라 숫자가 아닌 콘텐츠의 정확성을 확인합니다. 예 유효한 형식의 이메일, 핀 코드, 전화입니다.
(ii) 도메인 분석 : 이 유형의 테스트에서는 데이터 도메인을 선택하고 오류를 확인합니다. 이를위한 세 가지 그룹이 있습니다.
- 가치 기준 : 여기에서 필드 (테이블의 열)에 대해 발생할 수있는 값 목록을 만듭니다. 그런 다음 열 값이 목록의 하위 집합인지 확인합니다.
- 예: 성별 열에 M 또는 F가 포함되어 있는지 확인합니다.
- 범위 기준 : 여기서는 논리 또는 비즈니스 추론을 기반으로 열의 유효한 데이터 값에 대한 최소 및 최대 범위를 설정합니다. 그런 다음 열 값이이 범위 내에 있는지 확인합니다.
- 예: 연령은 0 ~ 120입니다.
- 참조 파일 : 여기서 시스템은 외부 유효성 파일을 사용합니다.
- 예: 국가 코드는 유효하고 참조 파일에서 올바른 값을 선택합니까? 국가 코드는 QA와 프로덕션 환경간에 동일합니까? 참조 파일에 국가 코드가 업데이트 된 경우 DB에서 올바르게 업데이트됩니까?
# 4) 메타 데이터 유효성 검사
메타 데이터 유효성 검사에서 대상에 대한 테이블 및 열 데이터 형식 정의가 올바르게 설계되었는지 확인하고 일단 설계되면 데이터 모델 설계 사양에 따라 실행됩니다.
여기에는 두 가지 그룹이 있습니다.
(i) 메타 데이터 디자인 : 첫 번째 검사는 데이터 모델이 대상 테이블의 비즈니스 요구 사항에 따라 올바르게 설계되었는지 확인하는 것입니다. 데이터 아키텍트는 스키마 엔터티를 마이그레이션하거나 대상 시스템을 설계 할 때 수정할 수 있습니다.
다음 검사는 데이터 모델을 사용하여 올바른 스크립트가 생성되었는지 확인하는 것입니다.
아래의 각 범주에 대해 먼저 대상 시스템에 대해 정의 된 메타 데이터가 비즈니스 요구 사항을 충족하는지, 두 번째로 테이블 및 필드 정의가 정확하게 생성되었는지 확인합니다.
다음은 몇 가지 메타 데이터 검사입니다.
Windows 10 용 프리웨어 레지스트리 클리너
- 데이터 유형 검사 : 예: Total Sales는 Decimal (8, 16 또는 20 바이트) 또는 Double 유형에서 올바르게 작동합니까?
- 데이터 길이 확인 : 예: 주소 필드의 데이터 길이가 500 자로 충분합니까? 새로운 지역이 회사에 추가됨에 따라 데이터 마이그레이션이 수행되는 경우 일 수 있습니다. 새로운 지역의 주소는 매우 긴 형식을 가질 수 있으며 원래 길이를 고수하면 사용 사례에 오류가 발생할 수 있습니다.
- 색인 확인 : 예 : 대상 시스템의 OrderId 열에 대해 인덱싱이 수행 되었습니까? 기업 합병이 발생하여 데이터 마이그레이션이 필요하고 대상 시스템에서 Orders 테이블의 크기가 100 배 증가하면 어떻게됩니까?
- 환경 전반의 메타 데이터 확인 : 이 검사에서 메타 데이터가 QA 테스트와 프로덕션 환경간에 일치하는지 확인합니다. 테스트는 QA 환경에서는 통과하지만 다른 환경에서는 실패 할 수 있습니다.
(ii) 델타 변경 : 이 테스트는 프로젝트가 진행 중일 때 발생하는 결함을 발견하고 중간에 소스 시스템의 메타 데이터가 변경되어 타겟 시스템에 구현되지 않았습니다.
예: 새 필드 CSI (Customer Satisfaction Index)가 소스의 Customer 테이블에 추가되었지만 대상 시스템에 만들지 못했습니다.
# 5) 데이터 무결성
여기서는 주로 외래 키, 기본 키 참조, 고유, 기본값 등과 같은 무결성 제약 조건을 확인합니다.
(영상 출처 )
외래 키의 경우 사용 된 외래 키가 부모 테이블에없는 자식 테이블에 고아 레코드가 있는지 확인해야합니다.
예: Customers 테이블에는 기본 키인 CustomerID가 있습니다. Orders 테이블에는 외래 키로 CustomerID가 있습니다. Orders 테이블에 Customers 테이블에없는 CustomerID가있을 수 있습니다. 그러한 무결성 제약 위반을 발견하기위한 테스트가 필요합니다. 데이터 매핑 테이블은 이러한 제약 조건이있는 테이블에 대한 명확성을 제공합니다.
노트 : 대상 시스템에서이 테스트를 실행하고 결함이있는 경우 소스 시스템에서 백 체크하십시오.
# 6) 데이터 완전성
이들은 원본과 대상 테이블 사이의 누락 된 레코드 또는 행 수를 발견하는 온 전성 테스트이며 자동화 된 후에 자주 실행할 수 있습니다.
두 가지 유형의 테스트가 있습니다.
(i) 기록 수 : 여기서는 소스 시스템과 대상 시스템 간의 일치 테이블에 대한 총 레코드 수를 비교합니다. 이것은 ETL 또는 마이그레이션 작업의 실행 후를 확인하기위한 빠른 온 전성 검사입니다. 개수가 일치하지 않으면 결함이 있습니다.
작업 실행 중에 때때로 거부 된 레코드가 있습니다. 이들 중 일부는 유효 할 수 있습니다. 그러나 테스터로서 우리는 이에 대한 사례를 제시합니다.
(ii) 열 데이터 프로파일 링 : 이러한 유형의 온 전성 테스트는 레코드 수가 많을 때 유용합니다. 여기서는 레코드 수를 줄이는 논리적 데이터 집합을 만든 다음 소스와 대상을 비교합니다.
- 가능한 경우 열의 모든 고유 값을 필터링하고 예를 들면 ProductID는 OrderDetails 테이블에서 여러 번 발생할 수 있습니다. 대상 및 소스 테이블 모두에서 ProductID에 대한 고유 목록을 선택하고 유효성을 검증하십시오. 이렇게하면 레코드 수를 크게 줄이고 온 전성 테스트 속도를 높일 수 있습니다.
- 위의 테스트와 마찬가지로 모든 주요 열을 선택하고 KPI (최소, 최대, 평균, 최대 또는 최소 길이 등)가 대상 테이블과 소스 테이블간에 일치하는지 확인할 수도 있습니다. 예: OrderDetails의 Price 열에서 평균, 최소 및 최대 값을 가져 와서 대상 테이블과 소스 테이블간에 이러한 값을 비교하여 불일치를 찾습니다.
- Null 값에 대해 또 다른 검사를 수행 할 수 있습니다. 중요한 열을 선택하고 열에 Null 값이 포함 된 행 목록을 필터링합니다. 대상 시스템과 소스 시스템간에 이러한 행을 비교하여 불일치를 확인하십시오.
# 7) 데이터 변환
이러한 테스트는 프로젝트의 핵심 테스트를 구성합니다. 변환 요구 사항을 이해하려면 요구 사항 문서를 검토하십시오. 다양한 변환 시나리오를 반영하기 위해 소스 시스템에서 테스트 데이터를 준비합니다. 여기에는 다양한 테스트가 있으며 ETL 테스트 주제에서 자세히 다루어야합니다.
다음은 이에 대해 다루는 간결한 테스트 목록입니다.
(i) 변환 :
- 예: ETL 코드에는 유효하지 않은 데이터를 거부하는 논리가있을 수 있습니다. 요구 사항과 비교하여 확인하십시오.
- ETL 코드에는 대리 키와 같은 특정 키를 자동 생성하는 논리도 포함될 수 있습니다. 이들의 정확성 (기술적 및 논리적)을 확인하기위한 테스트가 필요합니다.
- ETL 또는 마이그레이션 작업이 완료된 후 필드 값의 결합 또는 분할의 정확성을 검증하십시오.
- 참조 무결성 검사를 확인하기위한 테스트가 있습니다. 예를 들면 결함 유형은 Orders 테이블에 사용 된 ProductId가 상위 테이블 Products에 없습니다. ETL 작업 중에 고아 레코드가 어떻게 작동하는지 확인하는 테스트를 수행하십시오.
- 때때로 누락 된 데이터는 ETL 코드를 사용하여 삽입됩니다. 이들의 정확성을 확인하십시오.
- ETL 또는 마이그레이션 스크립트에는 때때로 데이터를 수정하는 논리가 있습니다. 데이터 수정이 작동하는지 확인합니다.
- 무효 / 거부 / 오류 데이터가 사용자에게보고되었는지 확인합니다.
- 입력 데이터 및 예상 결과의 시나리오 스프레드 시트를 만들고 비즈니스 고객과 함께이를 검증합니다.
(ii) 에지 케이스 : 변환 논리가 경계에서 잘 유지되는지 확인합니다.
- 예: 값이 1 조인 TotalSales가 ETL 작업을 통해 실행되면 어떻게됩니까? 종단 간 케이스가 작동합니까? 잠재적으로 큰 값을 가질 수있는 필드를 식별하고 이러한 큰 값으로 테스트를 실행합니다. 숫자 값과 숫자가 아닌 값을 포함해야합니다.
- 예상되는 전체 날짜 범위를 포함한 날짜 필드의 경우 윤년, 2 월은 28/29 일입니다. 다른 달의 경우 30 일, 31 일.
# 8) 데이터 고유성 또는 중복
이 유형의 테스트에서는 데이터 모델에 따라 고유 한 값을 가져야하는 열을 식별합니다. 또한 비즈니스 논리를 고려하여 이러한 데이터를 제거하십시오. 테스트를 실행하여 시스템에서 고유한지 확인합니다. 다음으로 테스트를 실행하여 실제 중복을 식별합니다.
- 예: 중복 데이터를 필터링하고 인증 여부를 확인합니다. 예를 들면 직원 종속 레코드에 동일한 형제 데이터가 두 번 포함됩니다.
- 사용자 전화 번호는 시스템에서 고유해야합니다 (비즈니스 요구 사항).
- 비즈니스 요구 사항에 따르면 ProductName은 중복 될 수 있으므로 Products 테이블의 ProductID와 ProductName 조합은 고유해야합니다.
# 9) 필수
이 유형의 테스트에서는 필수로 표시된 모든 필드를 식별하고 필수 필드에 값이 있는지 확인합니다. DB의 필드와 관련된 기본값이있는 경우 데이터가 없을 때 올바르게 채워 졌는지 확인합니다.
- 예: BillDate가 입력되지 않은 경우 CurrentDate는 BillDate입니다.
# 10) 적시성
항상 합의 된 타임 라인의 데이터로 작업하고 있는지 확인하는 테스트를 문서화하십시오.
- 예: ProductDiscount는 15 일 전에 업데이트되었으며 비즈니스 도메인에 ProductDiscount가 7 일마다 변경됩니다. 이는 테스트가 올바른 할인 값으로 수행되고 있지 않음을 의미합니다.
- 고객 만족도 지수에 대한 예측 분석 보고서는 월마트에서 판매 촉진 주간이었던 지난 1 주 데이터로 작업해야했습니다. 그러나 ETL 작업은 15 일의 빈도로 실행되도록 설계되었습니다. 이것은 테스터가 발견 할 수있는 주요 결함입니다.
# 11) 널 데이터
이 유형의 테스트에서는 null 데이터의 유효성과 중요한 열이 null 일 수 없음을 확인하는 데 중점을 둡니다.
- 예: 모든 null 데이터를 필터링하고 null이 허용되는지 확인합니다.
- 비즈니스 결정을위한 중요한 열이있는 경우 null이 없는지 확인하십시오.
# 12) 범위 확인
범위가 비즈니스에 적합한 데이터 엔터티를 테스트해야합니다.
- 예: 송장 당 주문 수량은 소프트웨어 범주에서 5K를 초과 할 수 없습니다.
- 나이는 120 세를 넘지 않아야합니다.
# 13) 비즈니스 규칙
필드에 대한 비즈니스 요구 사항을 문서화하고 동일한 테스트를 실행합니다.
- 예: 연령이 20 세 미만인 리소스는 자격이 없습니다. 이 규칙이 데이터에 적용되는 경우 데이터 유효성 검사가 필요합니다.
- Employee Active 상태가 True / Deceased 인 경우 종료 날짜는 null이어야합니다.
- FROM 데이터는 TO 날짜보다 작아야합니다.
- 품목 수준 구매 금액을 주문 수준 금액으로 합산하십시오.
# 14) 집계 함수
집계 함수는 데이터베이스의 기능에 내장되어 있습니다. 소스 시스템의 모든 집계를 문서화하고 집계 사용량이 대상 시스템에서 동일한 값을 제공하는지 확인합니다 (sum, max, min, count).
종종 소스 시스템의 도구는 대상 시스템과 다릅니다. 두 도구가 동일한 방식으로 집계 함수를 실행하는지 확인합니다.
# 15) 데이터 잘림 및 반올림
이러한 유형의 테스트에서 비즈니스와 관련된 잘림 및 반올림 논리가있는 필드를 식별합니다. 그런 다음 제품 소유자와 함께 자르기 및 반올림 논리를 문서화하고 승인하고 생산 대표 데이터로 테스트합니다.
# 16) 인코딩 테스트
소스 시스템에 인코딩 된 값이 있는지 확인하고 ETL 또는 데이터 마이그레이션 작업을 대상 시스템에 게시 한 후 데이터가 올바르게 채워 졌는지 확인합니다.
- 예: 중국어로 된 FirstName의 2 바이트 문자가 인코딩 된 소스 시스템에서 허용되었습니다. 대상 시스템으로 이동할 때이 필드의 동작을 확인하십시오.
- 암호 필드가 인코딩되고 마이그레이션되었습니다. 마이그레이션 후 제대로 작동하는지 확인하십시오.
# 17) 회귀 테스트
이는 테스터가 소스 또는 대상 시스템에 대한 변경 사항을 게시 한 후 위의 체크리스트를 사용하여 생성 된 모든 중요 테스트 케이스 스위트를 실행하는 기본 테스트 개념입니다.
결론
따라서 데이터 유효성 검사가 데이터 집약적 인 프로젝트를 탐색하기에 흥미로운 영역이며 가장 중요한 테스트를 형성한다는 것을 확인했습니다. 데이터 매핑 시트는 테스터가 이러한 테스트를 성공적으로 수행하기 위해 유지해야하는 중요한 아티팩트입니다. 그들은 위의 테스트에 대한 입력을 형성하기 위해 색상 강조 표시가있는 여러 버전을 유지할 수 있습니다.
버전간에 델타 변경 사항을 유지하려면주의해야합니다.
우리는 독자들에게 테스터 커뮤니티에 도움이되도록 작업 중에 발견 한 테스트의 다른 영역을 공유하도록 요청합니다.
추천 도서
- 데이터웨어 하우스에서 ETL (추출, 변환,로드) 프로세스 란 무엇입니까?
- 2021 년 최고의 ETL 도구 15 개 (전체 업데이트 목록)
- Informatica PowerCenter 도구를 사용하여 ETL 테스트를 수행하는 방법
- ETL 프로세스에 유용한 10 가지 최고의 데이터 매핑 도구 (2021 목록)
- 2021 년 상위 10 개 ETL 테스트 도구
- 데이터 마이그레이션 테스트 자습서 : 완전한 가이드
- 완벽한 데이터 무결성을위한 13 가지 최고의 데이터 마이그레이션 도구 (2021 목록)
- ETL 테스트 데이터웨어 하우스 테스트 자습서 (전체 가이드)