data migration testing tutorial
데이터 마이그레이션 테스트 개요 :
응용 프로그램이 다른 서버로 이동하거나 기술이 변경되거나 다음 버전으로 업데이트되거나 다른 데이터베이스 서버로 이동한다는 말을 자주 들었습니다.
- 이것은 실제로 무엇을 의미합니까?
- 이러한 상황에서 테스트 팀은 무엇을 기대합니까?
테스트 관점에서 보면 기존 시스템에서 새 시스템으로 성공적으로 마이그레이션하는 것과 함께 애플리케이션을 철저히 테스트해야한다는 의미입니다.
이 시리즈의 자습서 :
이 경우 시스템 테스트는 이전 응용 프로그램에서 사용되는 모든 데이터와 새 데이터로 수행되어야합니다. 기존 기능은 새로운 / 수정 된 기능과 함께 확인되어야합니다.
마이그레이션 테스트 대신 사용자의 전체 데이터가 새 시스템으로 마이그레이션되는 데이터 마이그레이션 테스트라고도합니다.
따라서 마이그레이션 테스트에는 이전 데이터, 새 데이터 또는 둘의 조합, 이전 기능 (변경되지 않은 기능) 및 새 기능을 사용한 테스트가 포함됩니다.
이전 애플리케이션은 일반적으로‘ 유산 ' 신청. 신규 / 업그레이드 된 애플리케이션과 함께, 신규 / 업그레이드 된 애플리케이션이 안정적이고 일관성이있을 때까지 레거시 애플리케이션을 계속 테스트해야합니다. 새 애플리케이션에 대한 광범위한 마이그레이션 테스트를 통해 레거시 애플리케이션에서 발견되지 않은 새로운 문제를 확인할 수 있습니다.
학습 내용 :
- 마이그레이션 테스트 란 무엇입니까?
- 마이그레이션 테스트가 필요한 이유
- 이 테스트는 언제 필요합니까?
- 데이터 마이그레이션 테스트 전략
- 마이그레이션의 여러 단계
- 역 호환성 테스트
- 롤백 테스트
- 마이그레이션 테스트 요약 보고서
- 데이터 마이그레이션 테스트의 과제
- 데이터 마이그레이션 위험을 완화하기위한 팁
- 결론
- 추천 도서
마이그레이션 테스트 란 무엇입니까?
마이그레이션 테스트는 데이터 무결성 및 데이터 손실없이 중단 / 중단 시간을 최소화하면서 기존 시스템을 새 시스템으로 마이그레이션하는 검증 프로세스이며, 애플리케이션의 지정된 모든 기능 및 비 기능적 측면이 사후 충족되는지 확인합니다. 이주.
마이그레이션 시스템의 간단한 표현 :
마이그레이션 테스트가 필요한 이유
아시다시피 새로운 시스템으로의 애플리케이션 마이그레이션은 다양한 이유로 시스템 통합, 구식 기술, 최적화 또는 기타 이유가있을 수 있습니다.
따라서 사용중인 시스템을 새 시스템으로 마이그레이션해야하지만 아래 사항을 확인하는 것이 중요합니다.
- 마이그레이션으로 인해 사용자에게 발생하는 모든 종류의 중단 / 불편 함을 방지 / 최소화해야합니다. 예 : 다운 타임, 데이터 손실
- 마이그레이션 중에 손상을 최소화하거나 전혀 발생시키지 않음으로써 사용자가 소프트웨어의 모든 기능을 계속 사용할 수 있는지 확인해야합니다. 예 : 기능 변경, 특정 기능 제거
- 라이브 시스템의 실제 마이그레이션 중에 발생할 수있는 모든 가능한 결함 / 장애를 예상하고 배제하는 것도 중요합니다.
따라서 이러한 결함을 제거하여 라이브 시스템의 원활한 마이그레이션을 보장하려면 랩에서 마이그레이션 테스트를 수행하는 것이 필수적입니다.
이 테스트는 그 자체로 중요하며 데이터가 그림에 나타날 때 중요한 역할을합니다.
기술적으로 다음과 같은 목적으로도 실행되어야합니다.
- 새로운 / 업그레이드 된 응용 프로그램과 기존 응용 프로그램이 지원하는 모든 가능한 하드웨어 및 소프트웨어와의 호환성을 보장합니다. 또한 새로운 적합성 새로운 하드웨어, 소프트웨어 플랫폼에 대해서도 테스트해야합니다.
- 모든 기존 기능이 레거시 애플리케이션에서와 같이 작동하는지 확인합니다. 기존 애플리케이션과 비교할 때 애플리케이션 작동 방식에 변화가 없어야합니다.
- 마이그레이션으로 인해 많은 수의 결함이 발생할 가능성이 매우 높습니다. 대부분의 결함은 일반적으로 데이터와 관련이 있으므로 테스트 중에 이러한 결함을 식별하고 수정해야합니다.
- 신규 / 업그레이드 된 애플리케이션의 시스템 응답 시간이 레거시 애플리케이션에 걸리는 시간과 같거나 더 짧은 지 확인합니다.
- 서버, 하드웨어, 소프트웨어 등의 연결이 모두 손상되지 않고 테스트 중에 끊어지지 않았는지 확인합니다. 다른 구성 요소 간의 데이터 흐름은 어떤 조건에서도 중단되지 않아야합니다.
이 테스트는 언제 필요합니까?
마이그레이션 전후에 테스트를 수행해야합니다.
마이그레이션 테스트의 여러 단계 Test Lab에서 수행되는 작업은 다음과 같이 분류 할 수 있습니다.
- 마이그레이션 전 테스트
- 마이그레이션 테스트
- 마이그레이션 후 테스트
위의 것 외에도 다음 테스트도 실행됩니다. 전체 마이그레이션 활동의 일부로.
- 하위 호환성 확인
- 롤백 테스트
이 테스트를 수행하기 전에 모든 테스터가 아래 사항을 명확하게 이해하는 것이 중요합니다.
- 새 시스템의 일부로 발생하는 변경 사항 (서버, 프런트 엔드, DB, 스키마, 데이터 흐름, 기능 등)
- 팀에서 제시 한 실제 마이그레이션 전략을 이해합니다. 마이그레이션이 발생하는 방식, 시스템의 백엔드에서 발생하는 단계별 변경 및 이러한 변경을 담당하는 스크립트.
따라서 이전 시스템과 새 시스템에 대한 철저한 연구를 수행 한 다음 테스트 단계 위의 일부로 다룰 테스트 사례 및 테스트 시나리오를 계획하고 설계하고 테스트 전략을 준비하는 것이 필수적입니다.
데이터 마이그레이션 테스트 전략
마이그레이션을위한 테스트 전략 설계에는 수행 할 일련의 활동과 고려할 몇 가지 측면이 포함됩니다. 이는 마이그레이션의 결과로 발생하는 오류와 위험을 최소화하고 마이그레이션 테스트를 효과적으로 수행하기위한 것입니다.
이 테스트의 활동 :
#1) 전문 팀 구성 :
필요한 지식과 경험을 가진 구성원으로 테스트 팀을 구성하고 마이그레이션중인 시스템과 관련된 교육을 제공합니다.
#두) 비즈니스 위험 분석, 가능한 오류 분석 :
마이그레이션 후 현재 비즈니스에 지장을주지 않고 ' 비즈니스 위험 분석 ' 올바른 이해 관계자 (테스트 관리자, 비즈니스 분석가, 설계자, 제품 소유자, 비즈니스 소유자 등)와 관련된 회의를 통해 위험과 구현 가능한 완화 방법을 식별합니다. 테스트에는 이러한 위험을 발견하고 적절한 완화가 구현되었는지 확인하는 시나리오가 포함되어야합니다.
실시 가능한 오류 분석 ' 적절한 사용 ‘오류 추측 접근 방식’ 그런 다음 이러한 오류를 중심으로 테스트를 설계하여 테스트 중에 발견합니다.
Windows 10 용 최고의 캡처 도구
# 3) 마이그레이션 범위 분석 및 식별 :
마이그레이션 테스트의 명확한 범위를 테스트해야하는시기와 대상을 분석합니다.
# 4) 마이그레이션을위한 적절한 도구 식별 :
이 테스트의 전략 (자동 또는 수동)을 정의하는 동안 사용할 도구를 식별하십시오. 예 : 소스 및 대상 데이터를 비교하는 자동화 된 도구입니다.
# 5) 마이그레이션을위한 적절한 테스트 환경 식별 :
사전 및 사후 마이그레이션 환경에 대한 별도의 환경을 식별하여 테스트의 일부로 필요한 확인을 수행합니다. 레거시 및 새 마이그레이션 시스템의 기술적 측면을 이해하고 문서화하여 테스트 환경이 그에 따라 설정되도록합니다.
# 6) 마이그레이션 테스트 사양 문서 및 검토 :
테스트 접근 방식, 테스트 영역, 테스트 방법 (자동, 수동), 테스트 방법 (블랙 박스, 화이트 박스 테스트 기술 ), 테스트주기 수, 테스트 일정, 데이터 생성 및 라이브 데이터 사용 방식 (민감한 정보를 마스킹해야 함), 테스트 환경 사양, 테스터 자격 등을 이해하고 이해 관계자와 검토 세션을 실행합니다.
# 7) 마이그레이션 된 시스템의 프로덕션 출시 :
프로덕션 마이그레이션을위한 할 일 목록을 분석 및 문서화하고 미리 게시합니다.
마이그레이션의 여러 단계
다음은 마이그레이션의 다양한 단계입니다.
1 단계 :마이그레이션 전 테스트
데이터를 마이그레이션하기 전에 사전 마이그레이션 테스트 단계의 일부로 일련의 테스트 활동이 수행됩니다. 이것은 무시되거나 단순한 응용 프로그램에서 고려되지 않습니다. 그러나 복잡한 애플리케이션을 마이그레이션해야하는 경우 마이그레이션 전 활동이 필수입니다.
다음은이 단계에서 수행되는 작업 목록입니다.
- 포함해야하는 데이터, 제외해야하는 데이터, 변환 / 변환이 필요한 데이터 등 데이터의 명확한 범위를 설정합니다.
- 기존 애플리케이션과 새 애플리케이션 간의 데이터 매핑을 수행합니다. 기존 애플리케이션의 각 데이터 유형에 대해 새 애플리케이션의 관련 유형을 비교 한 다음 매핑합니다.
- 새 응용 프로그램에 필수 필드가 있지만 레거시의 경우가 아닌 경우 레거시에 해당 필드가 null이 아닌지 확인합니다. – 낮은 수준의 매핑.
- 새 애플리케이션의 데이터 스키마 (필드 이름, 유형, 최소값 및 최대 값, 길이, 필수 필드, 필드 수준 유효성 검사 등)를 명확하게 연구합니다.
- 레거시 시스템의 여러 테이블을 기록해야하며 테이블이 삭제되고 추가 된 경우 마이그레이션 후 확인해야합니다.
- 각 테이블의 여러 레코드,보기는 레거시 응용 프로그램에 기록되어야합니다.
- 새 애플리케이션의 인터페이스와 연결을 연구하십시오. 인터페이스의 데이터 흐름은 보안이 강화되고 손상되지 않아야합니다.
- 새로운 애플리케이션의 새로운 조건에 대한 테스트 사례, 테스트 시나리오 및 사용 사례를 준비합니다.
- 일련의 사용자와 함께 테스트 케이스, 시나리오를 실행하고 결과, 로그를 저장합니다. 이전 데이터와 기능이 손상되지 않았는지 확인하려면 마이그레이션 후에도 동일한 사항을 확인해야합니다.
- 데이터 및 기록의 개수는 명확하게 기록해야하며 데이터 손실이 없는지 마이그레이션 후 확인해야합니다.
2 단계:마이그레이션 테스트
' 마이그레이션 가이드 '는 마이그레이션 활동을 수행하려면 마이그레이션 팀이 준비한 내용을 엄격히 따라야합니다. 이상적으로 마이그레이션 작업은 테이프에 데이터를 백업하는 것으로 시작되므로 언제든지 레거시 시스템을 복원 할 수 있습니다.
‘의 설명서 부분 확인 Migration Guide '는 데이터 마이그레이션 테스트의 일부이기도합니다. . 문서가 명확하고 따라하기 쉬운 지 확인합니다. 모든 스크립트와 단계는 모호함없이 올바르게 문서화되어야합니다. 모든 종류의 문서 오류, 단계 실행 순서의 누락 일치도보고 및 수정 될 수 있도록 중요한 것으로 간주되어야합니다.
실제 마이그레이션과 관련된 마이그레이션 스크립트, 가이드 및 기타 정보는 실행을 위해 버전 관리 저장소에서 선택해야합니다.
마이그레이션 시작 시점부터 시스템이 성공적으로 복원 될 때까지 마이그레이션에 소요 된 실제 시간을 기록하는 것은 실행해야 할 테스트 사례 중 하나이므로 ‘시스템 마이그레이션에 걸린 시간’ 마이그레이션 테스트 결과의 일부로 제공 될 최종 테스트 보고서에 기록되어야하며이 정보는 프로덕션 출시 중에 유용 할 것입니다. 테스트 환경에 기록 된 다운 타임은 실제 시스템의 대략적인 다운 타임을 계산하기 위해 추정됩니다.
마이그레이션 활동이 수행되는 레거시 시스템에 있습니다.
이 테스트 중에 환경의 모든 구성 요소는 일반적으로 마이그레이션 작업을 수행하기 위해 네트워크에서 제거되고 제거됩니다. 따라서주의 할 필요가 있습니다 '중단 시간' 마이그레이션 테스트에 필요합니다. 이상적으로는 마이그레이션 시간과 동일합니다.
일반적으로 '마이그레이션 가이드'문서에 정의 된 마이그레이션 활동에는 다음이 포함됩니다.
- 응용 프로그램의 실제 마이그레이션
- 방화벽, 포트, 호스트, 하드웨어, 소프트웨어 구성은 모두 레거시가 마이그레이션되는 새 시스템에 따라 수정됩니다.
- 데이터 유출, 보안 검사 수행
- 응용 프로그램의 모든 구성 요소 간의 연결을 확인합니다.
테스터는 시스템 백엔드에서 위의 내용을 확인하거나 화이트 박스 테스트를 수행하는 것이 좋습니다.
가이드에 지정된 마이그레이션 작업이 완료되면 모든 서버가 실행되고 마이그레이션 성공 확인과 관련된 기본 테스트가 수행되어 모든 종단 간 시스템이 적절하게 연결되고 모든 구성 요소가 각 서버와 통신하는지 확인합니다. 기타, DB가 실행 중이고 프런트 엔드가 백 엔드와 성공적으로 통신하고 있습니다. 이러한 테스트는 이전에 식별하고 마이그레이션 테스트 사양 문서에 기록해야합니다.
소프트웨어가 여러 다른 플랫폼을 지원할 가능성이 있습니다. 이 경우 마이그레이션은 이러한 각 플랫폼에서 개별적으로 확인해야합니다.
마이그레이션 스크립트 확인은 마이그레이션 테스트의 일부입니다. 때때로 개별 마이그레이션 스크립트는 독립 실행 형 테스트 환경에서 '화이트 박스 테스트'를 사용하여 확인됩니다.
따라서 마이그레이션 테스트는 '화이트 박스 및 블랙 박스 테스트'의 조합입니다.
이 마이그레이션 관련 확인이 완료되고 해당 테스트가 통과되면 팀은 마이그레이션 후 테스트 활동을 계속 진행할 수 있습니다.
3 단계 :마이그레이션 후 테스트
애플리케이션이 성공적으로 마이그레이션되면 마이그레이션 후 테스트가 필요합니다.
여기서 종단 간 시스템 테스트는 테스트 환경에서 수행됩니다. 테스터는 식별 된 테스트 케이스, 테스트 시나리오, 레거시 데이터 및 새로운 데이터 세트로 사용 사례를 실행합니다.
이외에도 아래에 나열된 마이그레이션 된 환경에서 확인할 특정 항목이 있습니다.
이들 모두는 테스트 케이스로 문서화되고 '테스트 사양'문서에 포함됩니다.
- 계획된 다운 타임 내에 레거시의 모든 데이터가 새 애플리케이션으로 마이그레이션되었는지 확인합니다. 이를 확인하려면 데이터베이스의 각 테이블과 뷰에 대해 레거시와 새 애플리케이션 간의 레코드 수를 비교하십시오. 또한 이동하는 데 걸린 시간을보고하여 10000 개의 레코드를 말합니다.
- 새 시스템에 따라 모든 스키마 변경 (추가 또는 제거 된 필드 및 테이블)이 업데이트되었는지 확인합니다.
- 레거시에서 새 응용 프로그램으로 마이그레이션 된 데이터는 지정하지 않는 한 그 값과 형식을 유지해야합니다. 이를 확인하려면 기존 및 새 응용 프로그램의 데이터베이스 간의 데이터 값을 비교하십시오.
- 새 애플리케이션에 대해 마이그레이션 된 데이터를 테스트하십시오. 여기에서는 가능한 최대 사례 수를 다룹니다. 데이터 마이그레이션 검증과 관련하여 100 % 커버리지를 보장하려면 자동화 된 테스트 도구를 사용하십시오.
- 데이터베이스 보안을 확인하십시오.
- 가능한 모든 샘플 기록에 대한 데이터 무결성을 확인하십시오.
- 기존 시스템에서 이전에 지원되었던 기능이 새 시스템에서 예상대로 작동하는지 확인하고 확인하십시오.
- 대부분의 구성 요소를 포함하는 애플리케이션 내의 데이터 흐름을 확인합니다.
- 데이터가 구성 요소를 통과 할 때 데이터가 수정, 손실 및 손상되지 않도록 구성 요소 간의 인터페이스를 광범위하게 테스트해야합니다. 통합 테스트 케이스를 사용하여이를 확인할 수 있습니다.
- 기존 데이터의 중복성을 확인합니다. 마이그레이션 중에 레거시 데이터를 복제해서는 안됩니다.
- 데이터 유형 변경, 저장 형식 변경 등 데이터 불일치 사례 확인,
- 레거시 애플리케이션의 모든 현장 수준 검사는 새 애플리케이션에서도 다루어야합니다.
- 새 응용 프로그램의 데이터 추가는 기존에 반영되지 않아야합니다.
- 새 응용 프로그램을 통한 기존 응용 프로그램의 데이터 업데이트가 지원되어야합니다. 새 애플리케이션에서 업데이트되면 레거시를 다시 반영해서는 안됩니다.
- 새 응용 프로그램에서 기존 응용 프로그램의 데이터를 삭제하는 것은 지원되어야합니다. 새 애플리케이션에서 삭제되면 레거시 데이터도 삭제해서는 안됩니다.
- 레거시 시스템에 대한 변경 사항이 새 시스템의 일부로 제공되는 새 기능을 지원하는지 확인합니다.
- 레거시 시스템의 사용자가 이전 기능과 새 기능, 특히 변경이 관련된 기능을 계속 사용할 수 있는지 확인합니다. 마이그레이션 전 테스트 중에 저장된 테스트 케이스와 테스트 결과를 실행합니다.
- 시스템에서 새 사용자를 만들고 테스트를 수행하여 새 응용 프로그램뿐만 아니라 레거시의 기능이 새로 생성 된 사용자를 지원하고 제대로 작동하는지 확인합니다.
- 다양한 데이터 샘플로 기능 관련 테스트 수행 (연령별, 지역별 사용자 등)
- 또한 새 기능에 대해 '기능 플래그'가 활성화되어 있는지 확인하고이를 켜거나 끄면 기능을 켜고 끌 수 있는지 확인해야합니다.
- 성능 테스트는 새 시스템 / 소프트웨어로의 마이그레이션으로 인해 시스템 성능이 저하되지 않았는지 확인하는 데 중요합니다.
- 또한 시스템 안정성을 보장하기 위해 부하 및 스트레스 테스트를 수행해야합니다.
- 소프트웨어 업그레이드로 인해 보안 취약점이 열리지 않았는지 확인하여 특히 마이그레이션 중에 시스템이 변경된 영역에서 보안 테스트를 수행하십시오.
- 유용성은 검증해야 할 또 다른 측면으로, GUI 레이아웃 / 프런트 엔드 시스템이 변경되었거나 기능이 변경된 경우 최종 사용자가 레거시 시스템과 비교하여 느끼는 사용 편의성은 무엇입니까?
마이그레이션 후 테스트의 범위가 매우 커지므로 마이그레이션이 성공했는지 확인하기 위해 먼저 수행해야하는 중요한 테스트를 분리 한 다음 나머지는 나중에 수행하는 것이 이상적입니다.
또한 테스트 시간을 줄이고 결과를 신속하게 사용할 수 있도록 종단 간 기능 테스트 케이스 및 기타 가능한 테스트 케이스를 자동화하는 것이 좋습니다.
마이그레이션 후 실행을위한 테스트 케이스를 작성하기위한 테스터를위한 몇 가지 팁 :
- 애플리케이션이 마이그레이션 될 때 전체 새 애플리케이션에 대해 테스트 케이스를 작성해야한다는 의미는 아닙니다. 레거시 용으로 이미 설계된 테스트 케이스는 여전히 새 애플리케이션에 적합해야합니다. 따라서 가능한 한 이전 테스트 케이스를 사용하고 필요할 때마다 기존 테스트 케이스를 새 애플리케이션 케이스로 변환하십시오.
- 새 애플리케이션에서 기능 변경이있는 경우 기능과 관련된 테스트 케이스를 수정해야합니다.
- 새 애플리케이션에 추가 된 새 기능이있는 경우 해당 특정 기능에 대해 새 테스트 케이스를 디자인해야합니다.
- 새 애플리케이션에서 기능 저하가있는 경우 관련 레거시 애플리케이션의 테스트 케이스는 마이그레이션 후 실행을 고려하지 않아야하며 유효하지 않은 것으로 표시하고 따로 보관해야합니다.
- 설계된 테스트 케이스는 사용 측면에서 항상 신뢰할 수 있고 일관성이 있어야합니다. 중요 데이터의 검증은 실행 중에 누락되지 않도록 테스트 케이스에서 다루어야합니다.
- 새 애플리케이션의 디자인이 레거시 (UI)의 디자인과 다른 경우 UI 관련 테스트 케이스를 수정하여 새 디자인을 적용해야합니다. 이 경우 변경 사항의 양에 따라 테스터가 업데이트하거나 새로 작성하는 결정을 내릴 수 있습니다.
역 호환성 테스트
시스템을 마이그레이션하려면 테스터가 '역 호환성'을 확인해야합니다. 새로 도입 된 시스템은 이전 시스템 (최소 2 개 이전 버전)과 호환되며 해당 버전과 완벽하게 작동하는지 확인합니다.
이전 버전과의 호환성은 다음을 보장하는 것입니다.
- 새 시스템이 새 버전과 함께 이전 2 버전에서 지원되는 기능을 지원하는지 여부.
- 시스템은 번거 로움없이 이전 2 개 버전에서 성공적으로 마이그레이션 할 수 있습니다.
따라서 하위 호환성 지원과 관련된 테스트를 구체적으로 수행하여 시스템의 하위 호환성을 보장하는 것이 필수적입니다. 이전 버전과의 호환성과 관련된 테스트는 실행을 위해 설계되고 테스트 사양 문서에 포함되어야합니다.
롤백 테스트
마이그레이션을 수행하는 동안 문제가 발생하거나 마이그레이션 중 어느 시점에서 마이그레이션 실패가 발생하는 경우 시스템이 기존 시스템으로 롤백하고 사용자에게 영향을주지 않고 신속하게 기능을 재개 할 수 있어야합니다. 이전에 지원 된 기능.
따라서이를 확인하려면 마이그레이션 실패 테스트 시나리오를 네거티브 테스트의 일부로 설계하고 롤백 메커니즘을 테스트해야합니다. 레거시 시스템으로 다시 재개하는 데 필요한 총 시간도 테스트 결과에 기록하고보고해야합니다.
롤백 후 주요 기능 및 회귀 테스트 (자동) 마이그레이션이 아무런 영향을 미치지 않았는지 확인하고 롤백이 기존 시스템을 제자리로 되 돌리는 데 성공했는지 확인하기 위해 실행해야합니다.
마이그레이션 테스트 요약 보고서
테스트 요약 보고서 테스트를 완료 한 후 생성되어야하며 결과 상태 (합격 / 실패) 및 테스트 로그와 함께 다양한 마이그레이션 단계의 일부로 수행 된 다양한 테스트 / 시나리오의 요약 보고서를 포함해야합니다.
다음 활동에 대해 기록 된 시간을 명확하게보고해야합니다.
- 총 마이그레이션 시간
- 응용 프로그램의 다운 타임
- 10000 개의 레코드를 마이그레이션하는 데 소요 된 시간입니다.
- 롤백에 소요 된 시간입니다.
위의 정보 외에도 관찰 / 권장 사항도보고 할 수 있습니다.
데이터 마이그레이션 테스트의 과제
이 테스트에서 직면 한 문제는 주로 데이터에 있습니다. 다음은 목록에서 몇 가지입니다.
# 1) 데이터 품질 :
레거시 응용 프로그램에서 사용 된 데이터의 품질이 새 / 업그레이드 된 응용 프로그램에서 좋지 않다는 것을 알 수 있습니다. 이러한 경우 비즈니스 표준을 충족하기 위해 데이터 품질을 개선해야합니다.
가정, 마이그레이션 후 데이터 변환, 레거시 애플리케이션 자체에 입력 된 데이터가 유효하지 않거나 데이터 분석 불량 등의 요인은 데이터 품질을 저하시킵니다. 이로 인해 운영 비용이 높아지고 데이터 통합 위험이 증가하며 비즈니스 목적에서 벗어날 수 있습니다.
# 2) 데이터 불일치 :
레거시에서 새 / 업그레이드 된 응용 프로그램으로 마이그레이션 된 데이터가 새 응용 프로그램에서 일치하지 않을 수 있습니다. 이는 데이터 유형, 데이터 저장 형식의 변경으로 인한 것일 수 있으며 데이터가 사용되는 목적이 재정의 될 수 있습니다.
이로 인해 일치하지 않는 데이터를 수정하거나이를 수용하고 그 목적에 맞게 조정하기 위해 필요한 변경 사항을 수정하는 데 엄청난 노력이 필요합니다.
# 3) 데이터 손실 :
레거시에서 새 / 업그레이드 된 애플리케이션으로 마이그레이션하는 동안 데이터가 손실 될 수 있습니다. 필수 필드 또는 필수 필드가 아닐 수 있습니다. 손실 된 데이터가 필수가 아닌 필드에 대한 것이면 해당 레코드는 여전히 유효하며 다시 업데이트 할 수 있습니다.
그러나 필수 필드의 데이터가 손실되면 레코드 자체가 무효화되고 취소 할 수 없습니다. 이로 인해 엄청난 데이터 손실이 발생하며 올바르게 캡처 된 경우 백업 데이터베이스 또는 감사 로그에서 검색해야합니다.
# 4) 데이터 볼륨 :
Windows 10 용 최고의 드라이버 소프트웨어
마이그레이션 활동의 가동 중지 기간 내에 마이그레이션하는 데 많은 시간이 필요한 방대한 데이터. 예 : 통신 산업의 스크래치 카드, 지능형 네트워크 플랫폼의 사용자 등, 여기서 문제는 시간이 지나면 레거시 데이터가 삭제되고 거대한 새 데이터가 생성되어 다시 마이그레이션해야합니다. 자동화는 대규모 데이터 마이그레이션을위한 솔루션입니다.
# 5) 실시간 환경 시뮬레이션 (실제 데이터 포함) :
테스트 랩에서 실시간 환경을 시뮬레이션하는 것은 또 다른 실제 과제입니다. 테스터는 테스트 중에 직면하지 않는 실제 데이터와 실제 시스템에 대해 다른 종류의 문제를 겪습니다.
따라서 데이터 마이그레이션 테스트를 수행하는 동안 데이터 샘플링, 실제 환경의 복제, 마이그레이션에 관련된 데이터 볼륨 식별은 매우 중요합니다.
# 6) 데이터 볼륨 시뮬레이션 :
팀은 라이브 시스템의 데이터를 매우주의 깊게 연구해야하며 데이터의 일반적인 분석 및 샘플링을 생각해 내야합니다.
예 : 10 세 미만, 10-30 세 등의 연령대를 가진 사용자, 가능한 한 라이브 데이터를 확보해야합니다. 그렇지 않은 경우 테스트 환경에서 데이터 생성을 수행해야합니다. 대량의 데이터를 생성하려면 자동화 된 도구를 사용해야합니다. 볼륨을 시뮬레이션 할 수없는 경우 적용 가능한 경우 외삽을 사용할 수 있습니다.
데이터 마이그레이션 위험을 완화하기위한 팁
다음은 데이터 마이그레이션 위험을 완화하기 위해 수행해야 할 몇 가지 팁입니다.
- 기존 시스템에서 사용되는 데이터를 표준화하여 마이그레이션시 표준 데이터를 새 시스템에서 사용할 수 있도록합니다.
- 데이터의 품질을 향상시켜 마이그레이션 할 때 최종 사용자로서 테스트하는 느낌을주는 테스트 할 정성 데이터가 있습니다.
- 마이그레이션하기 전에 데이터를 정리하여 마이그레이션 할 때 새 시스템에 중복 데이터가 존재하지 않고 전체 시스템을 깨끗하게 유지합니다.
- 정확한 결과를 산출하는 제약 조건, 저장 프로 시저, 복잡한 쿼리를 다시 확인하여 마이그레이션 할 때 새 시스템에서도 올바른 데이터가 반환되도록합니다.
- 레거시와 비교하여 새 시스템에서 데이터 검사 / 기록 검사를 수행하기위한 올바른 자동화 도구를 식별합니다.
결론
따라서 데이터 마이그레이션 테스트 수행과 관련된 복잡성을 고려할 때 테스트 중 검증의 모든 측면에서 작은 누락이 프로덕션에서 마이그레이션 실패의 위험으로 이어질 수 있다는 점을 염두에두고 신중하고 철저한 연구를 수행하는 것이 매우 중요합니다. 및 마이그레이션 전후 시스템 분석. 숙련되고 훈련 된 테스터와 함께 강력한 도구를 사용하여 효과적인 마이그레이션 전략을 계획하고 설계합니다.
마이그레이션이 애플리케이션의 품질에 큰 영향을 미친다는 것을 알고 있으므로 전체 팀이 기능, 성능, 보안, 유용성, 가용성, 안정성, 호환성과 같은 모든 측면에서 전체 시스템을 확인하기 위해 많은 노력을 기울여야합니다. 성공적인 '마이그레이션 테스트'를 보장합니다.
'다양한 마이그레이션 유형' 일반적으로 실제로 매우 자주 발생하며 테스트를 처리하는 방법은 이 시리즈의 다음 튜토리얼 .
저자 정보 : 이 안내서는 STH 작성자 Nandini가 작성했습니다. 그녀는 소프트웨어 테스트 분야에서 7 년 이상의 경험을 가지고 있습니다. 또한이 시리즈를 개선하기 위해 그녀의 valubale 제안을 검토하고 제공 한 STH Author Gayathri S.에게 감사드립니다. Gayathri는 소프트웨어 개발 및 테스트 서비스 분야에서 18 년 이상의 경력을 가지고 있습니다.
이 자습서에 대한 의견 / 제안을 알려주십시오.