comprehensive hadoop testing tutorial big data testing guide
이 자습서에서는 Hadoop 및 BigData 테스트를위한 기본 사항, 테스트 유형, 계획, 필수 환경, 테스트 프로세스, 유효성 검사 및 확인에 대해 설명합니다.
이 튜토리얼에서는 테스트가 언제 어디에서 나올지, Hadoop 테스트의 일부로 테스트해야하는 항목과 같은 Hadoop 및 BigData 테스트에 대한 기본 소개를 볼 수 있습니다.
또한 다음 주제에 대해서도 자세히 설명합니다.
- Hadoop 테스트의 역할 및 책임
- Hadoop / BigData 테스트를위한 테스트 접근 방식
=> 여기에서 BigData 교육 자습서의 A-Z를 보려면 여기를 확인하십시오.
학습 내용 :
- Hadoop에서 데이터 저장 및 처리
- BigData 및 Hadoop 테스트
- 빅 데이터 테스트를위한 전략 또는 계획은 무엇입니까?
- BigData 테스트를위한 테스트 유형
- BigData Hadoop 테스트 도구
- 테스트 환경 및 설정
- Hadoop 테스트의 역할 및 책임
- Hadoop 테스트 / 빅 데이터 테스트를위한 테스트 접근 방식
- 결론
- 추천 도서
Hadoop에서 데이터 저장 및 처리
Hadoop 시스템에서 이러한 프로세스를 수행하기 위해 우리는 4 개 섹션으로 분류 된 인력을 보유하고 있습니다.
- Hadoop 관리자 환경 설정을 담당하고 Hadoop 시스템에 액세스 할 수있는 관리 권한이 있습니다.
- Hadoop 개발자 다른 위치에서 중앙 위치로 데이터를 가져오고 저장하고 처리하는 것과 관련된 프로그램을 개발합니다.
- Hadoop 테스터 데이터를 다른 위치에서 가져 오기 전과 중앙 위치에서 가져온 후 데이터의 유효성을 검사하고 확인하는 것은 물론 데이터를 클라이언트 환경에로드하는 동안 유효성 검사 및 검증이 수행됩니다.
- Hadoop 분석가 데이터로드가 완료되고 데이터가 클라이언트 위치의웨어 하우스에 도달 할 때 작동합니다. 보고서 및 대시 보드 생성에이 데이터를 사용합니다. 분석가는 성장 및 비즈니스 개발을위한 데이터 분석을 수행합니다.
우리는 Hadoop이 단일 시스템이 아니라는 것을 알고 있습니다. 여기에는 여러 시스템과 기계가 포함됩니다. 데이터는 분할되어 여러 시스템에 저장되며 다시 액세스하려면 데이터를 결합하여 보고서로 가져와야합니다.
개발자는 데이터를 추출하고 저장하기 위해 JAVA 및 Python으로 프로그램을 작성해야합니다.
개발자의 다른 일은 데이터를 처리하는 것입니다. Hadoop에는 두 개의 계층이 있는데, 하나는 저장 (예 : Hadoop HDFS)을위한 것이고 다른 하나는 처리 (예 : Hadoop MapReduce)를위한 것입니다.
저장이란 소스에있는 모든 데이터가 시스템에 저장 / 삽입되는 것을 의미합니다. 처리는 여러 머신으로 분할 한 다음 다시 결합하여 클라이언트로 전송해야 함을 의미합니다.
따라서 저장 및 처리는 프로그래밍 스크립트에 의해 수행되며 개발자는 스크립트 작성을 담당합니다.
프로그래밍 외에도 Hadoop에서 데이터를 저장하고 처리하는 다른 방법은 Hive, Impala, HBase 등과 같은 데이터베이스 애플리케이션을 사용하는 것입니다. 이러한 도구에는 프로그래밍 지식이 필요하지 않습니다.
BigData 및 Hadoop 테스트
개발자가 저장 및 처리를 완료하면 데이터가 보고서 생성에 사용됩니다. 그 전에 처리 된 데이터의 정확성을 확인하고 데이터가 정확하게로드되고 올바르게 처리되었는지 확인해야합니다.
따라서 개발자가 만든 프로그램 및 / 또는 스크립트는 Hadoop 또는 BigData Tester에서 확인해야합니다. 테스터는 스크립트를 확인하고 명령을 실행하기 위해 Mapper, Hive, Pig Scripts 등과 같은 기본 프로그래밍을 알아야합니다.
따라서 테스트하기 전에 테스터는 모든 프로그램과 스크립트가 작동하는지, 코드를 작성하는 방법을 파악한 다음 테스트하는 방법에 대해 생각해야합니다. 테스트는 수동으로 또는 자동화 도구를 사용하여 수행 할 수 있습니다.
Hadoop에는 단위 테스트, 회귀 테스트, 시스템 테스트 및 성능 테스트 등과 같은 다양한 종류의 테스트가 있습니다. 따라서 이들은 Hadoop 및 BigData 테스트뿐만 아니라 일반 테스트에서 사용하는 일반적인 테스트 유형입니다.
Hadoop 및 BigData Testing에는 테스트 전략, 테스트 시나리오, 테스트 케이스 등과 같은 동일한 종류의 테스트 용어가 있습니다. 환경 만 다르며 BigData 및 Hadoop 시스템을 테스트하는 데 사용하는 다양한 기술이 있습니다. 여기에서는 애플리케이션이 아닌 데이터를 테스트해야하기 때문입니다.
BigData를 테스트하는 방법과 BigData에서 테스트가 필요한 모든 것은 무엇입니까?
빅 데이터 테스트를 위해서는 몇 가지 계획과 전략이 필요합니다.
따라서 다음 사항을 고려해야합니다.
- BigData에 대한 테스트 전략 또는 계획은 무엇입니까?
- BigData에는 어떤 종류의 테스트 접근 방식이 적용됩니까?
- 필요한 환경은 무엇입니까?
- BigData를 검증하고 확인하는 방법은 무엇입니까?
- BigData Testing에서 사용되는 도구는 무엇입니까?
위의 모든 질문에 대한 답을 얻으려고 노력합시다.
빅 데이터 테스트를위한 전략 또는 계획은 무엇입니까?
빅 데이터 테스트는 데이터를 데이터웨어 하우스에 저장하고 처리하는 동안 데이터의 확인 및 유효성 검사를 의미합니다.
BigData를 테스트하는 동안 서로 다른 데이터베이스에서 추출되고 데이터웨어 하우스 또는 Hadoop 시스템에서로드 및 처리되는 데이터의 볼륨과 다양한 데이터를 테스트해야합니다.이 테스트는 기능 테스트를받습니다.
다양한 데이터베이스에서 다운로드하여 성능 테스트의 일부인 Hadoop 시스템에 업로드 한 데이터의 속도를 테스트해야합니다.
따라서 계획이나 전략으로 빅 데이터 테스팅의 기능 및 성능 테스팅에 집중해야합니다.
BigData Testing에서 테스터는 Commodity Hardware 및 관련 구성 요소를 사용하여 방대한 양의 데이터 처리를 확인해야합니다. 따라서 데이터의 품질은 빅 데이터 테스트에서 중요한 역할을합니다. 데이터의 품질을 확인하고 검증하는 것이 중요합니다.
BigData 테스트를위한 테스트 유형
이전 섹션에서 기능 테스트 및 성능 테스트가 BigData 테스트에서 중요한 역할을한다는 것을 확인했습니다. BigData Tester와는 별개로 데이터베이스 테스트 및 아키텍처 테스트와 같은 몇 가지 유형의 테스트를 더 수행해야합니다.
이러한 테스트 유형은 기능 및 성능 테스트만큼 중요합니다.
# 1) 아키텍처 테스트
이 테스트는 데이터 처리가 적절하고 요구 사항을 충족하는지 확인하기 위해 수행됩니다. 실제로 Hadoop 시스템은 방대한 양의 데이터를 처리하고 리소스가 매우 포괄적입니다.
아키텍처가 부적절하면 성능이 저하되어 데이터 처리가 중단되고 데이터 손실이 발생할 수 있습니다.
# 2) 데이터베이스 테스트
여기에서 프로세스 유효성 검사가 그림에 나타나고 다양한 데이터베이스의 데이터를 유효성 검사해야합니다. 즉, 소스 데이터베이스 또는 로컬 데이터베이스에서 가져온 데이터가 정확하고 적절해야합니다.
또한 소스 데이터베이스에서 사용 가능한 데이터가 하둡 시스템에 입력 된 데이터와 일치하는지 확인해야합니다.
마찬가지로 처리 후 Hadoop System의 데이터가 정확하고 적절한 지 확인하거나 변환 후 적절한 확인 및 확인을 통해 클라이언트 환경에로드해야합니다.
데이터베이스 테스트의 일환으로 잔인한 작업, 즉 창조하다 로컬 데이터베이스의 데이터 검색 데이터를 검색해야하며 데이터웨어 하우스로로드하기 전후 및 데이터웨어 하우스에서 클라이언트 환경으로로드하기 전과 후에 데이터베이스에서 사용할 수 있어야합니다.
모든 확인 업데이트 됨 데이터 저장,로드 및 처리의 모든 단계에 대한 데이터. 손상된 데이터 또는 중복 및 null 데이터 삭제.
# 3) 성능 테스트
성능 테스트의 일환으로 IOPS (초당 입력 출력)와 같은 데이터의로드 및 처리 속도를 확인해야합니다.
다양한 데이터베이스에서 데이터웨어 하우스 또는 하둡 시스템으로, 하둡 시스템 또는 데이터웨어 하우스에서 고객 환경으로의 입력으로 데이터 또는 데이터를 입력하는 속도를 확인해야합니다.
또한 다양한 데이터베이스 및 데이터웨어 하우스에서 나오는 데이터의 속도를 출력으로 확인해야합니다. 이를 초당 입력 출력 또는 IOPS라고합니다.
그 외에도 데이터 흡수 및 데이터 배포의 성능을 확인하고 다양한 데이터베이스의 데이터웨어 하우스와 Hadoop 시스템의 클라이언트 시스템에서 데이터를 얼마나 빠르게 소비하는지 확인합니다.
또한 테스터로서 Hadoop 시스템 또는 데이터웨어 하우스에서 사용 가능한 다양한 파일에 데이터가 배포되는 속도와 같은 데이터 배포의 성능을 확인해야합니다. 마찬가지로 클라이언트 시스템에 데이터를 배포하는 동안에도 동일한 프로세스가 발생합니다.
Hadoop 시스템 또는 데이터웨어 하우스는 여러 구성 요소로 구성되어 있으므로 테스터는 MapReduce 작업, 데이터 삽입 및 소비, 쿼리 응답 시간 및 성능, 검색 성능과 같은 모든 구성 요소의 성능을 확인해야합니다. 작업. 이 모든 것이 성능 테스트에 포함되어 있습니다.
# 4) 기능 테스트
기능 테스트에는 모든 하위 구성 요소, 프로그램 및 스크립트, 저장 또는로드 및 처리 작업을 수행하는 데 사용되는 도구 등에 대한 테스트가 포함됩니다.
테스터의 경우 클라이언트가 완벽하고 오류없는 데이터를 얻을 수 있도록 데이터를 필터링해야하는 네 가지 중요한 유형 및 단계입니다.
BigData Hadoop 테스트 도구
BigData를 테스트하는 데 사용되는 다양한 도구가 있습니다.
- BigData 저장을위한 HDFS Hadoop 배포 파일 시스템.
- BigData 처리를위한 HDFS Map Reduce.
- NoSQL 또는 HQL Cassandra DB, ZooKeeper 및 HBase 등
- EC2와 같은 클라우드 기반 서버 도구.
테스트 환경 및 설정
모든 유형의 테스트에서 테스터는 적절한 설정과 환경이 필요합니다.
다음은 요구 사항 목록입니다.
- 테스트 할 데이터 및 애플리케이션의 유형입니다.
- 저장 및 처리에는 방대한 양의 데이터를위한 큰 공간이 필요합니다.
- 클러스터 전체의 모든 데이터 노드에 파일을 적절히 배포합니다.
- 데이터를 처리하는 동안 하드웨어 사용률은 최소한이어야합니다.
- 응용 프로그램의 요구 사항에 따라 실행 가능한 프로그램 및 스크립트.
Hadoop 테스트의 역할 및 책임
Hadoop 테스터로서 우리는 요구 사항을 이해하고, 테스트 예측을 준비하고, 테스트 케이스를 계획하고, 테스트 데이터를 가져와 일부 테스트 케이스를 테스트하고, 테스트 베드 생성에 참여하고, 테스트 계획을 실행하고, 결함을보고 및 재 테스트합니다.
또한 우리는 일일 상태보고 및 테스트 완료를 책임 져야합니다.
가장 먼저 논의 할 것은 테스트 전략 . 문제에 대한 제안 된 해결책이 있으면 테스트 계획을 계획하거나 전략화해야합니다. 여기서 사용할 수있는 자동화 전략, 배송 날짜에 따라 달라지는 테스트 일정에 대한 계획, 자원 계획을 논의 할 수 있습니다.
자동화 전략은 제품 테스트에 필요한 수작업을 줄이는 데 도움이 될 것입니다. 테스트 일정은 제품의 적시 배송을 보장하기 때문에 중요합니다.
리소스 계획은 테스트에 필요한 인력과 테스트 계획을 실행하는 데 필요한 Hadoop 리소스의 양을 계획해야하므로 매우 중요합니다.
테스트를 전략화 한 후에는 테스트를 자동화하고 테스트 계획에 사용될 일부 테스트 데이터를 식별하는 데 도움이되는 테스트 계획 작성, 테스트 스크립트 작성을 포함하는 테스트 개발 계획을 작성해야합니다. 이러한 테스트 계획을 실행하는 데 도움이됩니다.
테스트 계획, 테스트 스크립트 및 테스트 데이터 만들기를 포함하는 테스트 개발이 완료되면 해당 테스트 계획을 실행하기 시작합니다.
테스트 계획을 실행할 때 실제 출력이 예상과 다른 특정 시나리오가있을 수 있으며이를 결함이라고합니다. 결함이있을 때마다 해당 결함도 테스트해야하며 이에 대한 행렬을 만들고 유지 관리해야합니다.
이 모든 것들은 다음 범주에 속합니다. 결함 관리 .
결함 관리 란?
결함 관리는 버그 추적, 버그 수정 및 버그 확인으로 구성됩니다. 우리가 보유한 제품에 대해 테스트 계획이 실행될 때마다 특정 버그가 식별되거나 결함이 식별되는 즉시 해당 결함을 개발자에게보고하거나 개발자에게 할당해야합니다.
따라서 개발자는이를 조사하고 작업을 시작할 수 있습니다. 테스터로서 우리는 버그의 진행 상황을 추적하고 버그가 수정되었는지 추적해야합니다. 보고 된대로 버그가 수정 된 경우 계속해서 다시 테스트하고 해결되었는지 확인해야합니다.
모든 버그가 수정되고 닫히고 확인되면 OKAY 테스트를 거친 제품을 제공해야합니다. 그러나 제품을 배송하기 전에 UAT (User Acceptance Testing)가 성공적으로 완료되었는지 확인해야합니다.
설치 테스트 및 요구 사항 확인이 올바르게 수행되었는지 확인합니다. 즉, 클라이언트 또는 최종 사용자에게 제공되는 제품이 소프트웨어 요구 사항 문서에 언급 된 요구 사항에 부합하는지 확인합니다.
우리가 논의한 단계는 상상력을 기반으로합니다. 테스트 시나리오 또는 해당 단계에 사용할 테스트 접근 방식 중 하나이거나 제품을 테스트하고 최종 결과를 제공하기 위해 이러한 문구를 말합니다. OKAY 테스트를 거친 제품.
계속해서 이에 대해 자세히 논의하고 Hadoop 테스트와 연관시켜 보겠습니다.
우리는 Hadoop이 일괄 처리에 사용되는 것임을 알고 있으며 ETL이 Hadoop이 많이 사용되는 분야 중 하나라는 것을 알고 있습니다. ETL은 Extraction Transformation and Loading을 의미합니다. . 테스트 계획 및 테스트 전략을 Hadoop 테스트 관점으로 논의 할 때 이러한 프로세스에 대해 자세히 설명합니다.
아래에 언급 된 다이어그램에 따라 우리는 4 개의 서로 다른 데이터 소스가 있다고 가정합니다. 운영 시스템, CRM ( 고객 관계 관리 ) 및 ERP ( 기업 자원 계획 )는 RDBMS 또는 우리가 가지고있는 관계형 데이터베이스 관리 시스템이라고 말하며, 데이터 소스에 관한 로그, 파일, 기록 또는 기타 정보가 될 수있는 플랫 파일도 있습니다.
우리는 Sqoop, Flume 또는 특정 제품을 사용하여 데이터, 레코드 또는 데이터 소스를 가져올 수 있습니다. 이러한 도구를 사용하여 데이터 소스에서 내 스테이징 디렉토리로 데이터를 가져올 수 있습니다. 이는 프로세스의 첫 번째 단계입니다. 추출.
실제로 HDFS (Hadoop Distribution File System) 인 Staging Directory의 데이터가 있으면 특히 PIG와 같은 스크립팅 언어를 사용하여 변환 그 데이터. 그 변환 우리가 가지고있는 데이터에 따를 것입니다.
우리가 보유한 스크립팅 기술을 사용하여 데이터가 그에 따라 변환되면 로딩 중 해당 데이터를 데이터웨어 하우스로 가져옵니다. 데이터웨어 하우스에서 해당 데이터는 OLAP 분석,보고 및 데이터 마이닝 또는 분석에 사용됩니다.
계속해서 Hadoop 테스트에 사용할 수있는 모든 단계를 논의하겠습니다.
첫 번째 단계는 추출 단계입니다. 여기서는 소스 데이터베이스 또는 플랫 파일에서 데이터를 가져올 것이며,이 경우 모든 데이터가 소스에서 스테이징 디렉토리로 성공적이고 올바르게 복사되었는지 확인할 수 있습니다.
여기에는 기록 수, 기록 유형 및 필드 유형 등의 확인이 포함될 수 있습니다.
이 데이터가 스테이징 디렉토리에 복사되면 두 번째 단계 인 변환을 트리거합니다. 여기에는 소스 시스템에서 복사 된 데이터에 대해 작동하고 실제로 데이터를 필요한 비즈니스 로직으로 생성하거나 변환하는 비즈니스 로직이 있습니다.
변환에는 데이터 정렬, 데이터 필터링, 서로 다른 두 데이터 소스의 데이터 결합 및 기타 특정 작업이 포함될 수 있습니다.
데이터가 변환되면 계속해서 테스트 계획을 준비하고 예상대로 출력을 얻고 있는지, 그리고 우리가 얻는 모든 출력이 예상 결과와 데이터 유형, 필드 값 및 데이터 유형을 충족하는지 확인합니다. 범위 등은 제자리에있는 것입니다.
정확하면 데이터웨어 하우스에 데이터를로드 할 수 있습니다.
로드 단계에서는 실제로 스테이지의 레코드 수와 데이터웨어 하우스의 레코드 수가 동기화되어 있는지 확인하고 있습니다. 서로 비슷하지 않을 수도 있지만 동기화되어야합니다. 또한 변환 된 데이터 유형이 동기화되어 있는지 확인합니다.
이 데이터를 제품의 마지막 계층 인 OLAP 분석,보고 및 데이터 마이닝에 사용할 것이라고 게시하고이 경우 후속 작업을 수행하거나 이러한 모든 계층에 대해 테스트 계획을 사용할 수 있다고 말할 수 있습니다.
소스에서 대상으로 데이터를 가져올 때마다 항상 인증 된 사람 만 데이터에 대한 액세스 권한이 있는지 확인해야합니다.
입증
권한 부여
이 두 용어는 무엇을 의미합니까?
이를 이해하기 위해 ETL 다이어그램에서 관점을 살펴 보겠습니다.
위의 다이어그램에 따라 소스 RDBMS 엔진 및 플랫 파일에서 HDFS로 데이터를 가져오고 있으며이 단계를 추출이라고합니다.
특정 방식으로 인증에 대해 설명하겠습니다. 특성상 제한된 데이터가있는 특정 비즈니스가 있습니다. 이러한 유형의 데이터를 미국 표준에 따라 PII 데이터라고합니다.
PII 약자 개인 식별 정보, 생년월일, SSN, 휴대폰 번호, 이메일 주소 및 집 주소 등과 같은 모든 정보는 모두 PII에 속합니다. 이것은 제한적이며 모든 사람과 공유 할 수 없습니다.
데이터는 데이터가 가장 필요한 사람과 실제 처리를 위해 데이터가 필요한 사람에게만 공유되어야합니다. 이 검사와 첫 번째 방어선을 마련하는 것을 인증이라고합니다.
예를 들어 우리는 랩톱을 사용하고 있고 거기에 Windows가 설치되어 있으며 Windows 운영 체제에서 일부 사용자 계정을 만들 수 있으며 거기에서 암호를 적용했습니다.
이렇게하면이 특정 사용자 계정에 대한 자격 증명을 가진 사람 만 시스템에 로그인 할 수 있으며, 이것이 우리가 데이터를 도난 또는 불필요한 액세스로부터 보호하는 방법입니다. 다른 계층은 인증입니다.
예, Windows 운영 체제에 두 개의 서로 다른 사용자 계정이 있습니다. 한 사용자 계정은 우리 계정이고 다른 하나는 게스트 사용자 계정 일 수 있습니다. 관리자 (WE)는 소프트웨어 설치 및 제거, 새 파일 생성 및 기존 파일 삭제 등과 같은 모든 종류의 작업을 수행 할 권한이 있습니다.
반면 게스트 사용자는 이러한 종류의 모든 액세스 권한을 갖지 못할 수 있습니다. 게스트는 시스템에 로그인 할 수있는 인증이 있지만 파일 및 설치를 삭제하거나 만들 수있는 권한과 시스템 및 시스템에서 각각 소프트웨어를 제거 할 권한이 없습니다.
그러나 인증 된 게스트 사용자 계정은 생성 된 파일을 읽고 이미 설치된 소프트웨어를 사용할 수있는 권한이 있습니다.
이것이 HDFS 또는 데이터의 인증 및 권한 부여를 확인하는 데 필요한 파일 시스템에서 사용할 수있는 모든 데이터에 대해 인증 및 권한 부여를 테스트하는 방법입니다.
Hadoop 테스트 / 빅 데이터 테스트를위한 테스트 접근 방식
테스트 접근 방식은 일반 수동 테스트 또는 자동화 테스트 또는 보안 테스트, 성능 테스트로 이동할 때 BigData 또는 Hadoop 테스트이기 때문에 모든 종류의 테스트에 일반적으로 사용되므로 모든 종류의 테스트는 동일한 접근 방식을 따릅니다.
요구 사항
테스트 접근 방식의 일환으로 요구 사항 , 요구 사항은 기본적인 것입니다. 요즘 애자일 프로세스에서는이를 스토리 및 에픽이라고합니다. Epic은 더 큰 요구 사항에 지나지 않지만 Stories는 더 작은 요구 사항입니다.
요구 사항에는 기본적으로 모든 데이터 모델, 대상, 소스는 물론 적용해야하는 변환 유형, 사용해야하는 도구 종류가 포함됩니다. 이러한 모든 종류의 세부 정보는 요구 사항에서 사용할 수 있습니다.
이것은 기본적으로 고객 요구 사항 또는 고객 요구 사항입니다. 이 요구 사항에 따라 테스트 프로세스를 시작합니다.
견적
접근 방식의 또 다른 부분은 견적 , 전체 활동을 테스트의 일부로 수행하는 데 걸리는 시간. 우리는 테스트 계획, 테스트 시나리오 준비, 테스트 케이스 준비 및 동일한 실행을 수행하고 결함을 찾아보고보고하고 테스트 보고서도 준비합니다.
이러한 모든 활동은 시간이 걸리므로 이러한 모든 활동을 완료하는 데 필요한 시간을 기본적으로 추정이라고합니다. 경영진에 대한 대략적인 평가가 필요합니다.
테스트 계획
테스트 계획 프로세스, 테스트 대상, 테스트하지 않을 항목, 테스트 범위, 일정, 필요한 리소스 수, 하드웨어 및 소프트웨어 요구 사항, 타임 라인 및 테스트주기에 대한 설명 일뿐입니다. 우리가 요구 한 테스트 수준 등이 사용됩니다.
테스트 계획 중에 그들은 프로젝트에 대한 특정 리소스 할당을 수행하고 우리가 가지고있는 다른 모델이 무엇인지, 필요한 리소스의 수와 필요한 기술 세트의 종류 등을 수행합니다. 이러한 모든 사항과 측면이 테스트에 포함됩니다. 계획 단계.
대부분의 경우 리드 수준 또는 관리 수준의 사람들이 테스트 계획을 수행합니다.
테스트 시나리오 및 테스트 케이스
테스트 계획이 완료되면 준비해야합니다. 테스트 시나리오 및 테스트 케이스 , 특히 빅 데이터 테스트의 경우 요구 사항 문서와 함께 몇 가지 문서가 필요합니다. 이 요구 사항 문서와 함께 우리에게 필요한 것은 무엇입니까?
우리는 요구 사항 문서 여기에는 클라이언트의 요구 사항이 포함되어 있으며 입력 문서 즉 데이터 모델. 데이터 모델은 데이터베이스 스키마가 무엇인지, 테이블이 무엇이며,이 모든 데이터가 데이터 모델에서 사용할 수있는 관계는 무엇입니까?
또한, 우리는 문서 매핑 , 문서 매핑 예 : 관계형 데이터베이스에는 테이블이 몇 개 있고 HDFS의 데이터웨어 하우스에서 ETL을 통해 데이터를로드 한 후 수행해야하는 모든 매핑은 무엇입니까? 즉, 매핑 데이터 유형.
Windows 10 용 최고의 무료 파일 변환기
예를 들어 HDFS에 고객 테이블이있는 경우 HDFS에 CUSTOMER_TARGET 테이블이 있거나 동일한 테이블이 HIVE에도있을 수 있습니다.
이 고객 테이블에는 특정 열이 있고 CUSTOMER TARGET 테이블에는 다이어그램에 표시된 특정 열이 있습니다. 고객 테이블의 데이터를 CUSTOMER TARGET 테이블, 즉 소스에서 대상으로 덤프했습니다.
그런 다음 Customer Table의 Column 1과 Row 1 인 Source Table에있는 Data와 같은 정확한 매핑을 확인하고이를 C1R1로 간주하고 CUSTOMER TARGET Table의 C1R1에 동일한 Data를 매핑해야합니다. 이를 기본적으로 매핑이라고합니다.
확인해야하는 모든 매핑이 무엇인지 어떻게 알 수 있습니까? 따라서 이러한 매핑은 매핑 문서에 표시됩니다. 매핑 문서에서 고객은 모든 종류의 매핑을 제공합니다.
또한 우리는 디자인 문서 , 디자인 문서는 고객이 제공 할 디자인 문서에서 어떤 종류의 Map Reduce 작업을 구현할 것이며 어떤 유형의 MapReduce 작업이 입력을 받고 어떤 유형의 MapReduce를 제공하기 때문에 개발 팀과 QA 팀 모두에 필요합니다. Jobs는 출력을 제공합니다.
마찬가지로 HIVE 또는 PIG가있는 경우 고객이 생성 한 모든 UDF는 무엇이며 어떤 입력을 받고 어떤 종류의 출력을 생성 할 것인지 등이 있습니다.
테스트 시나리오 및 테스트 케이스를 준비하려면 다음 문서를 모두 손으로 준비해야합니다.
- 요구 사항 문서
- 데이터 모델
- 매핑 문서
- 디자인 문서
이는 조직마다 다를 수 있으며 이러한 모든 문서를 가져야한다는 필수 규칙은 없습니다. 때로는 모든 문서가 있고 때로는 2 ~ 3 개의 문서 만 있거나 때로는 하나의 문서에 의존해야하는 경우도 있습니다. 이는 프로젝트 복잡성, 회사 일정 및 모든 것에 달려 있습니다.
테스트 시나리오 및 테스트 사례에 대한 검토
테스트 시나리오 및 테스트 케이스에 대한 검토를 수행해야합니다. 어떻게 든 또는 어떤 경우에는 일부 테스트 케이스를 잊어 버리거나 놓치기 때문입니다. 모든 사람이 요구 사항으로 수행 할 수있는 모든 가능한 일을 생각할 수 없기 때문입니다. 타사 도구 또는 다른 사람의 도움.
따라서 문서를 준비하거나 무언가를 수행 할 때마다 개발자, 테스터와 같은 동일한 팀의 내용을 검토 할 누군가가 필요합니다. 그들은 더 많은 것을 포함하도록 적절한 제안을 제공하거나 테스트 시나리오 및 테스트 케이스를 업데이트하거나 수정하도록 제안합니다.
그들은 모든 주석을 제공하고이를 기반으로 우리는 테스트 시나리오와 테스트 케이스, 그리고 요구 사항에 따라 문서가 완전히 업데이트 될 때까지 팀 전체에서 릴리스해야하는 여러 버전의 문서를 업데이트 할 것입니다.
테스트 실행
문서가 준비되면 상위 팀의 승인을 받아 기본적으로 테스트 케이스 실행이라고하는 실행 프로세스를 시작합니다.
실행 중에 테스트 케이스를 실행하려면 개발자가 정보를 보내야하는지 확인해야합니다. 정상적인 기능 테스트이거나 다른 테스트 또는 자동화 테스트 인 경우 빌드가 필요합니다. 그러나 여기서 Hadoop 또는 BigData 테스팅 관점에서 개발자는 MapReduce 작업을 제공합니다.
HDFS 파일 – HDFS에 복사 된 파일 정보는 권한을 확인하는 데 필요한 파일 정보, HIVE 테이블의 데이터를 확인하기 위해 개발자가 만든 HIVE 스크립트 및 개발자가 개발 한 HIVE UDF, PIG가 필요합니다. 스크립트 및 PIG UDF.
이것들은 우리가 개발자로부터 얻는 데 필요한 모든 것입니다. 처형하기 전에 우리는이 모든 것을 가지고 있어야합니다.
MapReduce 작업의 경우 일부 JAR 파일을 제공하고 HDFS의 일부로 이미 HDFS에 데이터를로드했으며 파일이 준비되어 있어야하며 HIVE 테이블의 데이터를 검증하기위한 HIVE 스크립트가 있어야합니다. 구현 한 UDF가 무엇이든 HIVE UDF에서 사용할 수 있습니다. PIG 스크립트와 UDF에도 동일한 것이 필요합니다.
결함보고 및 추적
테스트 케이스를 실행하면 일부 결함을 발견하고 일부는 예상 된 결과와 일부는 예상 된 결과와 동일하지 않으므로 동일한 항목을 나열하고 해결을 위해 개발 팀에 제공해야합니다.이를 기본적으로 결함보고라고합니다.
MapReduce 작업에서 결함을 발견하면 개발자에게보고하고 다시 MapReduce 작업을 다시 생성하고 코드 수준을 수정 한 다음 다시 테스트해야하는 최신 MapReduce 작업을 제공한다고 가정합니다. .
이것은 지속적인 프로세스입니다. 일단 작업이 테스트되고 통과되면 다시 테스트하고 개발자에게보고 한 다음 테스트를 위해 다음 작업을 가져와야합니다. 이것이 결함보고 및 추적 활동이 수행되는 방법입니다.
테스트 보고서
모든 테스트 프로세스를 완료하고 결함이 종료되면 테스트 보고서를 작성해야합니다. 테스트 보고서는 지금까지 테스트 프로세스를 완료하기 위해 수행 한 작업입니다. 모든 계획, 테스트 사례 작성 및 실행, 우리가 얻은 결과 등 모든 것이 테스트 보고서의 형태로 함께 문서화됩니다.
이러한 보고서는 매일 또는 매주 또는 고객의 요구에 따라 보내야합니다. 오늘날 조직은 AGILE 모델을 사용하고 있으므로 모든 상태 보고서는 일일 스크럼 중에 업데이트해야합니다.
결론
이 자습서에서는 다음을 살펴 보았습니다.
- 빅 데이터 테스트 전략 또는 계획.
- BigData 테스팅에 필요한 환경.
- 빅 데이터 검증 및 검증.
- BigData를 테스트하는 데 사용되는 도구.
우리는 또한 다음에 대해 배웠습니다.
- 테스트 전략, 테스트 개발, 테스트 실행, 결함 관리 및 제공이 Hadoop 테스트의 일부인 역할 및 책임에서 작동하는 방식.
- 요구 사항 수집, 추정, 테스트 계획, 테스트 시나리오 생성 및 테스트 사례를 검토와 함께 포함하는 Hadoop / BigData 테스트를위한 테스트 접근 방식.
- 또한 테스트 실행, 결함보고 및 추적 및 테스트보고에 대해서도 알게되었습니다.
이 BigData Testing Tutorial이 도움이 되었기를 바랍니다.
=> 여기에서 모든 BigData 자습서를 확인하십시오.