볼륨 테스트란 무엇입니까? 예제로 배우기

볼륨 테스트란 무엇입니까?

볼륨 테스트 소프트웨어에 엄청난 양의 데이터가 적용되는 일종의 소프트웨어 테스팅입니다. 라고도 합니다. 홍수 테스트. 볼륨 테스트는 데이터베이스의 데이터 볼륨을 늘려 시스템 성능을 분석하기 위해 수행됩니다.

볼륨 테스트를 사용하면 대량의 데이터에 노출되었을 때 응답 시간과 시스템 동작에 미치는 영향을 연구할 수 있습니다.

예를 들어, 음악 스트리밍 서비스는 50천만 곡의 음원 카탈로그로 테스트될 수 있습니다. tracks와 수십억 개의 행을 담고 있는 청취 기록 테이블을 사용하여 검색 및 추천 쿼리가 여전히 허용 가능한 시간 내에 응답하는지 확인합니다.

차이점을 유의하세요: 볼륨 테스트는 증가시킵니다. 데이터 양 시스템이 유지됩니다. 증가시키면 동시 사용자 수 부하 테스트는 목적이 다른 별도의 테스트입니다.

볼륨 테스트의 이점

• 생산 능력 문제를 조기에 파악하면 생산 중에 문제를 해결하는 데 드는 훨씬 더 높은 비용을 피할 수 있습니다.
• 확장성 계획을 더 빠르게 시작하는 데 도움이 됩니다.
• 병목 현상의 조기 식별
• 이제 귀하의 시스템이 실제 사용이 가능함을 보장합니다.

볼륨 테스트를 하는 이유는 무엇일까요?

볼륨 테스트를 수행하는 목적은 다음과 같습니다.

• 데이터베이스의 데이터 양이 증가함에 따라 시스템 성능을 확인하십시오.
• 데이터 세트의 규모가 커짐에 따라 발생할 가능성이 있는 문제점을 파악하십시오.
• 시스템의 안정성이 저하되는 지점을 파악하기 위해
• 볼륨 테스트는 시스템 또는 애플리케이션의 용량(정상 및 대용량)을 식별하는 데 도움이 됩니다.

볼륨 테스트 방법

볼륨 테스트에서는 다음과 같은 사항을 테스트해야 합니다.

• 데이터 손실이 있는지 테스트해 보세요.
• 시스템의 응답 시간을 확인하세요.
• 데이터가 올바르게 저장되었는지 확인하세요.
• 알림 없이 데이터를 덮어썼는지 확인하세요.
• 볼륨 제한에 도달했을 때 경고 및 오류 메시지가 실제로 표시되는지 확인하십시오.
• 대용량 데이터가 처리 속도에 영향을 미치는지 확인
• 시스템에 해당 볼륨에 필요한 메모리 및 저장 공간이 있는지 확인하십시오.
• 볼륨 테스트가 단일 구성 요소가 아닌 전체 시스템을 대상으로 하는지 확인하십시오.
• 데이터 볼륨이 지정된 것보다 크면 위험이 있습니까?
• 데이터 용량이 지정된 최대치를 초과하지 않을 것이라는 보장이 있는지 확인하십시오.

대용량 테스트를 위한 최고의 사례

아래의 몇 가지 방법은 부하 테스트와 공통적으로 적용되는데, 두 가지 모두 일반적으로 동일한 환경에서 실행되기 때문입니다. 볼륨 관련 방법은 데이터 세트 자체에 관한 것입니다.

• 모든 서버를 중지하고 모든 로그를 확인하세요.
• 부하 테스트 전에 애플리케이션 시나리오를 수동으로 실행합니다.
• 가장 유용한 결과를 얻으려면 사용자 수에 시차를 두십시오.
• 라이선스 제약을 극복하려면 인지 시간의 균형을 유지하세요.
• 새로운 빌드에 주의하세요
• 기준선이 설정되면 개선을 위한 사용 사례를 분석합니다.
• 성능 병목 현상이 발생할 경우 볼륨 테스트의 특정 부분 반복이 불가피합니다.

용량 테스트 vs 부하 테스트

볼륨 테스트의 과제

• 생성하기 어려운 메모리 조각화
• 동적 키 생성
• 관계형 Integrity 생성된 데이터의

이 테스트는 다른 성능 테스트와 어떻게 비교될까요?

성능 테스트는 적용되는 하중의 형태가 서로 다른 일련의 테스트이기 때문에 쉽게 혼동될 수 있습니다.

여기서 가장 중요한 차이점은 다음과 같습니다. 볼륨 테스트는 데이터 규모를 확장하고, 로드 테스트는 사용자 규모를 확장합니다. 1만 행을 처리하는 데 2초가 걸리고 1천만 행을 처리하는 데 2분이 걸리는 보고서는 부하 문제가 아니라 처리량 문제이며, 서버 용량을 아무리 늘려도 해결되지 않습니다.

대용량 테스트를 위한 테스트 데이터 생성 방법

과제 섹션에서는 현실적인 데이터를 생성하는 것이 볼륨 테스트에서 가장 어려운 부분이라고 언급합니다. 실제로는 네 가지 접근 방식이 사용되며, 각 방식에는 장단점이 있습니다.

어떤 방법을 선택하든 세 가지 조건이 충족되어야 하며, 그렇지 않으면 테스트는 아무런 유용한 결과를 측정하지 못합니다.

• 참조적 무결성. 모든 외래 키는 반드시 해결되어야 합니다. 백만 개의 고아 행은 스토리지 엔진에 부하를 주지만, 애플리케이션이 실제로 사용하는 조인 경로에는 절대 부하를 주지 않습니다.
• 현실적인 기수. 만약 운영 테이블에 200명의 고객에 걸쳐 1천만 개의 행이 있다면, 1천만 명의 고객에 걸쳐 1천만 개의 행을 생성하는 것은 완전히 다른 쿼리 실행 계획을 생성합니다.
• 현실적인 유통. 실제 데이터는 편향되어 있습니다. 균일하게 무작위로 추출된 데이터는 운영 환경 장애를 일으키는 핫 파티션과 인덱스 경합을 숨깁니다.

개인정보 보호에 대한 실질적인 경고. 운영 환경의 데이터를 테스트 환경으로 복사하는 것이 테스트 중 데이터 유출의 가장 흔한 원인입니다. 복사본이 운영 환경을 벗어나기 전에 개인 정보 필드를 가려야 하며, 복사본이 운영 환경을 벗어난 후에 가리는 것은 바람직하지 않습니다.

자주 묻는 질문