데이터 마이그레이션 테스팅 by softwaretestingportal.com

출처: softwaretestingportal.com의 데이터 마이그레이션 튜토리얼 동영상, 인도

https://medium.com/@theinfographix/data-migration-tutorial-learn-data-migration-basics-in-15-minutes-a-guide-to-data-migration-d8ba8321581f

유튜브 Data Migration Testing Tutorial, https://www.youtube.com/watch?v=cmiJm-_GdVA

 

---

 

데이터 마이그레이션 테스팅이란?

마이그레이션 테스팅은 레가시 또는 현 시스템의 데이터를 새로운 타겟 시스템으로 마이그레이션 하는 프로세스를 검증한다. 최소한의(또는 0의) 다운 타임과 데이터 손실 없이 마이그레이션이 수행되는지 확인하고, 마이그레이션 후 애플리케이션의 모든 명세된 기능적 및 비기능적 측면이 손상 없이 온전한지 확인한다.

 

마이그레이션 테스팅은 아래의 목적을 가진다.

1. 마이그레이션으로 인해 사용자에게 발생하는 모든 종류의 중단이나 불편을 피하거나 최소화한다. 예, 다운 타임, 데이터 손실
2. 사용자가 애플리케이션의 모든 기능을 계속 사용할 수 있도록 보장한다.
3. 레가시 애플리케이션이 지원하는 하드웨어 및 소프트웨어와 새 애플리케이션(또는 업그레이드된 애플리케이션)과의 호환성(compatibility)을 보장한다.
4. 기존 기능이 레거시 애플리케이션에서 그랬던 것처럼 원활하게 작동하도록 보장한다.
5. 테스트 동안 데이터 및 데이터 타입과 관련된 심각한 결함을 식별하고 수정한다.
6. 마이그레이션 후에 성능 저하가 없는 것을 보장한다.
7. 서버, 하드웨어, 소프트웨어 간의 커넥션(즉, 여러 다른 컴포넌트 간의 데이터 흐름)이 손상 없이 그대로 유지되는지 확인한다.

 

데이터 마이그레이션에서 테스팅 기법

데이터 마이그레이션 테스팅 기법이 두 가지 유형으로 분류된다.

데이터 유효성 테스트는 네 가지 측면을 다룬다.

• 완전성 테스트(Completeness tests): 타겟 데이터베이스에서 누락된 오브젝트를 식별한다.
• 외양 테스트(Appearance tests): 그래픽 사용자 인터페이스(GUI) 수준에서 오브젝트의 외양에 주안점을 둔다. 테스터가 소스 애플리케이션과 타겟 애플리케이션의 GUI 데이터를 보고 수동으로 오브젝트를 비교한다.
• 통합 테스트(Integration tests): 마이그레이션 후에 애플리케이션 간의 연결성(connectivity) 및 링킹(linking)이 제대로 작동하는지 확인한다.
• 처리성 테스트(Processability tests): 마이그레이션된 데이터를 처리하고, 타겟 애플리케이션과 불러온(imported) 데이터의 성공적인 연결성(connectivity)을 보장한다.

 

마이그레이션 실행 테스트는 데이터 마이그레이션 프로그램들이 원활하게 작동하고 조화롭게 통합되도록 보장한다. 마이그레이션 실행 테스트의 두 가지 서브클래스가 서로 다른 측면에 중점을 둔다.

• 전체 마이그레이션 실행 테스트(Full migration run tests): 전체 데이터 세트로 모든 마이그레이션 프로그램을 실행하는 테스트이다.
• 부분 마이그레이션 실행 테스트(Partial migration run tests): 마이그레이션 개발 동안 개발 주기의 회전 시간(round time)을 단축한다. 더 적은 비즈니스 오브젝트를 마이그레이션 하는 것은 시험 마이그레이션(trial migration) 결과를 더 빠르게 제공한다는 의미이다(예를 들어, 이틀 대신 몇 시간 내로).

 

데이터 마이그레이션에서 테스팅 단계(Testing Phases)

단계1 사전-마이그레이션 테스팅(Pre-migration testing)

마이그레이션이 수행되기 전 사전 마이그레이션 테스트 단계에서 아래 테스팅 활동이 수행되어야 한다.

• 데이터의 범위가 명확하게 이해되었는지 확인한다. 예, 어떤 데이터가 포함되어야 하는지, 어떤 데이터가 제외되어야 하는지
• 목적지(destination)와 로드(load) 프로세스를 이해하고 있는지 확인한다.
• 레거시 애플리케이션과 새 애플리케이션 간에 데이터 매핑을 수행한다.
• 데이터 스키마를 알고 있는지 확인한다. 예, 오리지널 데이터 소스와 타겟 시스템 양쪽에 대한 필수 필드, 필드 이름, 필드 타입, 데이터 타입 등등
• 데이터 정제 요구사항(data cleansing requirements)을 이해하고 있는지 확인한다.
• 타 시스템과의 인터페이스 또는 시스템에 데이터를 제공하는 2차 공급자(secondary suppliers)와의 모든 인터페이스를 이해하고 있는지 확인한다.
• 레거시 시스템에 있는 테이블을 기록해 둔다. 만약 테이블이 삭제되거나 추가되는 경우 마이그레이션 후에 이를 확인한다.
• 레거시 애플리케이션의 각 테이블 레코드와 뷰를 기록해 둔다.
• 새 애플리케이션의 새로운 조건에 대한 테스트케이스, 테스트 시나리오, 유스케이스를 준비한다.
• 테스트케이스와 시나리오를 실행하고 결과 로그를 저장한다. 마이그레이션 후에 이 동일한 테스트를 수행하여 레거시의 데이터와 기능이 손상 없이 온전한 것을 확인한다.
• 데이터 및 레코드의 개수를 명확하게 기록해야 한다. 마이그레이션 후 이를 체크하여 데이터 손실이 없는지 확인한다.
• 사용자 인터페이스에 대한 매핑이 올바른지 확인한다.
• 비즈니스 프로세스에 대한 매핑이 올바른지 확인한다.
• 필드 세부 정보를 사용하여 테스트 도구 구성 및 스크립트 생성을 한다.
• 테스트를 위한 데이터 서브셋 세부 정보를 식별한다.
• 모든 비즈니스 케이스, 유저스토리, 유스케이스를 이해하고 있는지 확인한다.

 

단계2 데이터 정제(data cleansing)

데이터가 올라가 있고 유지/관리되는 시스템 상에서 데이터 정제를 수행하는 것이 매우 중요하다. 다음의 데이터 정제 태스크들을 계획해야 한다.

• 에러 타입을 이해한다. 예, 빈 필드(blank field), 너무 긴 데이터 길이, 잘못된 문자(bad characters)
• 데이터를 체킹하는 방법을 식별한다. 예, SQL을 사용하여 데이터베이스를 통해 조회하거나 또는 데이터 마이그레이션 도구를 사용하여 확인
• 데이터 종속성(data dependencies)을 이해한다. 즉, 한 테이블의 데이터를 변경하면 다른 링크 테이블의 데이터에 영향을 준다.
• 데이터 이슈를 해결한다.
• 데이터의 개수를 확인한다.

 

단계3 사후-마이그레이션 테스팅(post-migration testing)

성공적으로 마이그레이션이 이루어지고 나면 마이그레이션 후 테스트가 시작된다. 알려진 비즈니스 흐름을 테스트하는 것 외에도 테스터가 다음 테스트 활동을 수행해야 한다.

• 계획된 다운 타임 내에 레가시의 모든 데이터가 새로운 애플리케이션으로 마이그레이션되었는지 확인한다. 예를 들어, 레거시와 새 애플리케이션 간의 레코드 수를 비교한다.
• 새 시스템에 따른 모든 스키마 변경 사항이 업데이트되었는지 확인한다. 레거시에서 새 애플리케이션으로 마이그레이션된 데이터는 그 값과 포맷을 유지해야 한다.
• 비즈니스 데이터 타입과 기술적 데이터 타입을 포함하여 마이그레이션된 데이터 타입을 테스트한다.
• 애플리케이션 내에서의 데이터 흐름을 확인한다.
• 가장 먼저 지원되는(사용자가 가장 처음 접하게 되는) 기능을 체크하고 검증한다.
• 레거시 데이터의 중복성을 확인한다.
• 경계 값 분석, 동등 분할, 오류 추측 등을 사용하여 유효성 규칙(validation rules) 위반을 시도한다.
• 필수 데이터를 우회한다. 필수 데이터 필드를 채우지 않고 계속 진행을 시도한다.
• 데이터 쓰기가 진행되는 중에 데이터 락(lock)을 확인한다. 다수의 사용자가 데이터베이스 내의 동일한 레코드에 액세스하는 것이 불가능해야 한다.
• 데이터베이스 보안 및 데이터 무결성을 확인한다.
• 새로운 사용자를 시스템 상에서 생성하고 새로 생성된 사용자가 기능에 액세스할 수 있는지 확인하는 테스트를 한다.
• 데이터 분리(data segregation): 새 애플리케이션에서 데이터를 삭제하는 것이 레거시의 데이터도 삭제하는 결과를 낳으면 안된다. 마찬가지로 새 애플리케이션에서 데이터 추가가 레거시 시스템에 다시 반영되어서는 안 된다.
• 성능 시험: 마이그레이션으로 인해 시스템 성능이 저하되지 않았고, 요구 성능에 따라 데이터에 액세스할 수 있는지 확인한다.
• 보안 테스트: 데이터에 대한 액세스는 적절하게 제한되어야 한다.
• 사용성: 최종 사용자를 위해 마이그레이션된 기능의 사용 용이성을 확인한다.
• 이전 버전과의 호환성 테스트(Backward compatibility testing): 도입된 새로운 시스템이 구 시스템과 호환되는지 테스터가 호환성을 확인해야 한다.
• 롤백 테스트(Rollback testing): 부정적 테스트(negative testing)의 일환으로 마이그레이션 실패 테스트 시나리오가 설계되어야 한다. 마이그레이션을 수행하는 동안 이슈가 있거나 마이그레이션 중 어느 시점에서 마이그레이션 실패가 발생하는 경우를 대비하여 롤백 메커니즘을 테스트할 필요가 있다.

 

데이터 마이그레이션 테스팅에서의 리스크

마이그레이션 테스트에서는 주로 데이터에 관한 어려움과 리스크가 있다.

• 데이터 품질(Data Quality): 레가시 애플리케이션에서 사용해 온 데이터가 업그레이드된 애플리케이션에서는 품질이 낮은 경우를 발견할 수 있다. 이 경우 데이터 품질이 비즈니스 표준을 충족하도록 개선되어야 한다. 이를 해결하는 방법 중 일부는 최종 마이그레이션 전에 모의 마이그레이션(mock migrations) 및 파일럿 마이그레이션(pilot migrations)을 실행하는 것인데, 이를 통해 이전 단계들에서는 보이지 않던 에러가 모습을 드러낼 수 있다.
• 데이터 손실(Data Loss): 레거시에서 업그레이드된 애플리케이션으로 마이그레이션하는 동안 데이터가 손실될 수도 있다. 이런 일이 필수 필드(mandatory fields) 또는 비필수 필드(non-mandatory fields)에서 있을 수 있는데, 비필수 필드에서 데이터 손실이 있다면 다시 업데이트될 수 있으므로 리스크가 더 낮다. 반면 필수 필드 데이터가 손실되면 레코드 자체가 무효화(void) 되어 이로 인해 데이터가 손실이 발생할 수 있다.
• 널 데이터 해석(Null Data Translation): Null 데이터는 타겟에서 공백(space)이나 기본값(default values)이 아니라 null 자체로 변환되어야 한다. 애플리케이션이 null 유효성에 대한 검사를 수행하기도 한다.
• 데이터 타입과 데이터 불일치(Data Type and Data Mismatch): 레거시에서 업그레이드된 애플리케이션으로 마이그레이션된 데이터 및 데이터 타입이 새 애플리케이션에서 일치하지 않을 수 있다. 이는 데이터 타입이나 데이터 스토리지 형식에 변경이 있기 때문이거나, 데이터 사용 목적이 재정의 되었기 때문일 수 있다. 따라서 데이터 타입이 반드시 올바르게 매핑되어야 한다.
• 데이터의 잘림 및 정밀도(Truncation and Precision of Data): 마이그레이션할 데이터가 일부만 타겟 시스템으로 이동할 수도 있다. 예, 소스 데이터에 추가적인 패딩 공간이 있거나 바이트 수가 더 적은 경우
• 잉여 레코드(Extra Records): 여러 다른 데이터 소스로부터 중복 레코드가 올 수 있다. 따라서 타겟 시스템에 데이터를 로드하기 전에 데이터 필터링 및 변환을 수행할 필요가 있다.
• 데이터 볼륨(Data Volume): 거대한 양의 데이터를 다운 타임 윈도우 이내에 마이그레이션하는 작업은 많은 시간을 필요로 한다.
• 테스팅 랩에서 실시간 환경 시뮬레이션: 테스터가 실제 데이터와 실제 시스템으로 애플리케이션을 테스트할 때 전혀 다른 종류의 이슈에 직면할 수 있다. 따라서 데이터 샘플링, 실제 환경 복제, 마이그레이션에 관련된 데이터 볼륨 식별 등이 데이터 마이그레이션 테스트를 수행하는 동안 상당히 중요하다.