부하 테스트란 무엇입니까? (예시)

⚡ 스마트 요약

부하 테스트는 예상되는 최대 부하까지 많은 사용자가 동시에 소프트웨어 애플리케이션에 접속할 때 애플리케이션의 동작 방식을 측정합니다. 이를 통해 최대 운영 용량, 용량을 제한하는 병목 현상, 그리고 현재 인프라가 충분한지 여부를 파악할 수 있습니다.

  • 👥 핵심 정의: 예상되는 최대 사용자 부하를 적용하고 응답을 측정하는 비기능 테스트입니다.
  • ⏱️ 주요 지표: 응답 시간은 정량적이고, 관련성이 있으며, 현실적이고, 달성 가능하며, 측정 가능해야 합니다.
  • 🏗️ 발견 내용: 최대 용량, 인프라 부족, 데이터베이스 제한 및 구성 문제.
  • 📉 하중 대 응력: 하중은 예상되는 최대치에서 멈추고, 응력은 의도적으로 그 지점을 지나 파괴점을 찾아낸다.
  • 🛠️ 툴링 옵션: JMeterGatling과 k6는 오픈 소스이며, LoadRunner는 이미 널리 사용되는 상용 소프트웨어입니다.
  • 📋 선수 과목 : 애플리케이션이 기능적으로 안정화된 후에만 실행하십시오. 그렇지 않으면 결함으로 인해 성능 결과가 가려질 수 있습니다.

부하 테스트란 무엇인가요?

부하 테스트란 무엇입니까?

부하 테스트 특정 예상 부하에서 소프트웨어 애플리케이션의 성능을 테스트하는 비기능적 소프트웨어 테스트 프로세스입니다. 여러 사용자가 동시에 액세스하는 동안 소프트웨어 애플리케이션이 어떻게 동작하는지 확인합니다. 부하 테스트의 목표는 성능 병목 현상을 개선하고 배포 전에 소프트웨어 애플리케이션의 안정성과 원활한 기능을 보장하는 것입니다.

이 테스트는 일반적으로 다음을 식별합니다.

  • 애플리케이션의 최대 작동 용량
  • 현재 인프라가 애플리케이션을 실행하기에 충분한지 확인
  • 최대 사용자 로드에 대한 애플리케이션의 지속 가능성
  • 애플리케이션이 지원할 수 있는 동시 사용자 수 및 더 많은 사용자가 액세스할 수 있는 확장성입니다.

비기능 테스트의 일종이다. 소프트웨어 엔지니어링에서 부하 테스트는 인트라넷과 인터넷 모두에서 웹 기반 애플리케이션인 클라이언트/서버에 일반적으로 사용됩니다.

부하 테스트

부하 테스트가 필요한 이유는 무엇입니까?

매우 인기가 높은 일부 사이트는 엄청난 양의 트래픽이 발생하면서 심각한 다운타임을 겪었습니다. 전자 상거래 웹 사이트는 광고 캠페인에 많은 투자를 하지만 해당 마케팅으로 트래픽이 발생할 때 최적의 시스템 성능을 보장하기 위한 부하 테스트에는 투자하지 않습니다.

부하 테스트 예시

  • Toysrus.com은 자체 광고 캠페인으로 발생한 트래픽을 감당하지 못해 마케팅 비용과 기대했던 매출 모두를 잃었습니다.
  • 항공사 웹사이트는 축제 기간 동안 10000명 이상의 사용자를 처리할 수 없었습니다.
  • Encyclopedia Britannica는 온라인 데이터베이스에 대한 무료 액세스를 프로모션 혜택으로 선언했습니다. 그들은 몇 주 동안 폭주하는 트래픽을 따라잡을 수 없었습니다.

많은 사이트는 트래픽이 많을 때 로드 시간이 지연되는 문제를 겪습니다. 몇 가지 사실 –

  • 페이지 로딩 시간이 약 3초를 넘어서면 이탈률이 급격히 증가하며, 모바일 연결 시에는 그 효과가 더욱 커집니다.
  • 페이지 로딩 속도가 느리면 전자상거래 사이트는 방문할 때마다 상당한 매출 손실을 입게 되므로, 성능은 기술적 지표가 아닌 비즈니스 지표로 간주됩니다.

부하 테스트를 수행하는 이유는 무엇입니까?

  • 부하 테스트는 시스템과 시스템의 신뢰성 및 성능에 대한 확신을 줍니다.
  • 부하 테스트는 프로덕션 환경에서 발생하기 전에 과도한 사용자 스트레스 시나리오에서 시스템의 병목 현상을 식별하는 데 도움이 됩니다.
  • 부하 테스트는 성능 저하에 대한 탁월한 보호 기능을 제공하고 성능 관리 및 프로덕션 환경 모니터링을 위한 보완 전략을 수용합니다.

부하 테스트의 목표

로딩 테스트는 애플리케이션을 시장이나 프로덕션에 출시하기 전에 다음과 같은 문제를 식별합니다.

  • 각 트랜잭션의 응답 시간
  • 다양한 부하에서 시스템 구성 요소의 성능
  • 다양한 로드 하에서 데이터베이스 구성요소의 성능
  • 클라이언트와 서버 간의 네트워크 지연
  • 소프트웨어 설계 문제
  • 웹 서버, 애플리케이션 서버, 데이터베이스 서버 등과 같은 서버 구성 문제
  • CPU 최대화, 메모리 제한, 네트워크 병목 현상 등과 같은 하드웨어 제한 문제

부하 테스트는 성능을 향상시키기 위해 시스템을 미세 조정해야 하는지 또는 하드웨어 및 소프트웨어를 수정해야 하는지 여부를 결정합니다. 부하 테스트를 효과적으로 수행하기 위해 다양한 활용 방법을 활용할 수 있습니다. 성능 테스트 도구 개선이 필요한 영역을 식별하는 데 도움이 되는 정보입니다.

부하 테스트의 필수 조건

부하 테스트의 주요 지표는 응답 시간입니다. 부하 테스트를 시작하기 전에 다음을 결정해야 합니다.

  • 응답 시간이 이미 측정 및 비교되었는지 여부 – 정량적
  • 응답 시간이 비즈니스 프로세스에 적용 가능한지 여부 – 관련
  • 응답시간의 정당성 여부 – 현실적
  • 응답 시간 달성 가능 여부 - 달성 가능
  • 도구나 스톱워치를 사용하여 응답 시간을 측정할 수 있는지 여부 – 측정 가능

부하 테스트 전 환경 설정

하드웨어 플랫폼 소프트웨어 구성
  • 서버 머신
  • 프로세서
  • 메모리
  • 디스크 저장소
  • 머신 구성 로드
  • 네트워크 구성
  • Opera팅 시스템
  • 서버 소프트웨어

부하 테스트 전략

부하 테스트를 수행하는 방법은 여러 가지가 있습니다. 다음은 몇 가지 부하 테스트 전략입니다.

부하 테스트 전략

  • 수동 부하 테스트: 이는 부하 테스트를 실행하는 전략 중 하나이지만 반복 가능한 결과를 생성하지 못하고 애플리케이션에 측정 가능한 수준의 스트레스를 제공할 수 없으며 조정이 불가능한 프로세스입니다.
  • 자체 개발된 부하 테스트 도구: 부하 테스트의 중요성을 인식한 조직에서는 부하 테스트를 실행하기 위한 자체 도구를 구축할 수 있습니다.
  • 오픈 소스 부하 테스트 도구: 무료로 오픈 소스로 제공되는 여러 가지 부하 테스트 도구가 있습니다. 유료 제품만큼 정교하지는 않지만 예산이 충분하다면 최선의 선택입니다.
  • 엔터프라이즈급 부하 테스트 도구: 일반적으로 캡처/재생 기능이 함께 제공됩니다. 그들은 많은 수의 프로토콜을 지원합니다. 매우 많은 수의 사용자를 시뮬레이션할 수 있습니다.

부하 테스트를 수행하는 방법

부하 테스트 프로세스는 다음과 같이 간략하게 설명할 수 있습니다.

  1. 전용 만들기 테스트 환경 부하 테스트를 위해
  2. 부하 테스트 시나리오를 정의하십시오.
  3. 애플리케이션에 대한 부하 테스트 트랜잭션 결정
    • 각 거래에 대한 데이터 준비
    • 시스템에 액세스하는 사용자 수를 예측해야 합니다.
    • 연결 속도를 결정합니다. 일부 사용자는 임대 회선을 통해 연결되고 다른 사용자는 전화 접속을 사용할 수 있습니다.
    • 사용자가 사용하는 다양한 브라우저와 운영 체제를 확인하세요. 
    • 웹, 애플리케이션, DB 서버 등 모든 서버 구성
  4. 테스트 시나리오 실행 및 모니터링. 다양한 지표 수집
  5. 결과를 분석하십시오. 추천하기
  6. 시스템 미세 조정
  7. 재시험

부하 시험 지침

부하 테스트 지침

  1. 애플리케이션이 기능적으로 안정되면 부하 테스트를 계획해야 합니다.
  2. 데이터 풀에는 고유한 대량의 데이터가 준비되어 있어야 합니다.
  3. 시나리오나 스크립트별로 사용자 수를 결정해야 합니다.
  4. 디스크 IO 공간을 절약하기 위해 자세한 로그 생성을 피하세요.
  5. 사이트에서 이미지 다운로드를 피하십시오
  6. 부하 테스트 테스트 케이스를 실행하는 과정에서 경과 시간에 따른 응답 시간의 일관성을 기록하고 이를 다양한 테스트 실행과 비교해야 합니다.

부하 테스트와 스트레스 테스트의 차이점

부하 테스트 스트레스 테스트
부하 테스트는 다양한 작업 부하 하에서 시스템의 병목 현상을 식별하고 부하가 점차 증가할 때 시스템이 어떻게 반응하는지 확인합니다. 스트레스 테스트 시스템의 중단점을 결정하여 중단 후 최대 지점을 나타냅니다.
시스템의 상한을 인식하려면 앱의 SLA를 설정하고 시스템이 과부하를 어떻게 처리할 수 있는지 확인합니다. 극심한 부하에서 시스템이 어떻게 작동하는지, 장애로부터 어떻게 복구하는지 확인합니다.
웹 애플리케이션에서 증가된 로드를 생성하는 것이 로드 테스트의 주요 목표입니다. 스트레스 테스트는 상당한 기간 동안 갑자기 높은 부하가 발생하는 경우 서버가 충돌하지 않도록 하는 것을 목표로 합니다.
부하 테스트에서 확인하는 속성은 최대 성능, 서버 수량, 응답 시간입니다. 이러한 종류의 테스트는 안정성 응답 시간 등을 확인합니다.
부하 테스트에서 부하 제한은 중단의 임계값입니다. 스트레스 테스트에서 로드 제한은 중단 임계값보다 높습니다.

기능 테스트와 부하 테스트의 차이점

기능 테스트 부하 테스트
적절한 단계와 사전 조건이 정의되어 있으므로 기능 테스트 결과를 쉽게 예측할 수 있습니다. 부하 테스트 결과를 예측할 수 없습니다.
기능 테스트 결과는 약간씩 다릅니다. 부하 테스트 결과는 매우 다양합니다.
실행 빈도 기능 테스트 높을 것이다 부하 테스트 실행 빈도가 낮습니다.
기능 테스트 결과는 테스트 데이터에 따라 다릅니다. 부하 테스트는 사용자 수에 따라 다릅니다.

부하 테스트 도구

LoadRunner

LoadRunner는 원래 HP에서 개발했으며 현재는 다른 회사 제품입니다. OpenText Micro Focus 인수 이후, 이 플랫폼은 정상 부하 및 최대 부하 조건에서 애플리케이션을 테스트합니다. 실제 네트워크 트래픽을 모방하는 가상 사용자를 통해 부하를 생성하고 결과를 그래프로 보고합니다.

더 많은 것을 읽으십시오 LoadRunner 튜토리얼.

Apache JMeter

오픈 소스 Java 이 도구는 가장 널리 사용되는 무료 옵션입니다. HTTP, JDBC, JMS, FTP 등을 지원하고, 테스트 계획을 XML로 저장하며, CI 파이프라인과 통합됩니다. 자세한 내용은 다음을 참조하세요. JMeter 지도 시간 자세한 설명은 여기를 참조하세요.

개틀링

테스트 코드가 Scala 또는 다른 언어로 작성된 오픈 소스 도구 Java이 소프트웨어는 사양이 낮은 하드웨어에서도 높은 동시 접속률을 처리하며, 버전 관리가 가능한 테스트 스크립트를 선호하는 팀에게 적합한 상세한 HTML 보고서를 생성합니다.

k6

테스트가 작성된 오픈 소스 도구 Java이 스크립트는 별도의 QA 활동이 아닌 CI 파이프라인 내에서 개발자가 직접 성능 테스트를 수행하도록 설계되었습니다.

도구 선택

Pick JMeter 가장 광범위한 프로토콜을 무료로 지원하려면 Gatling 또는 k6를, 테스트 코드를 애플리케이션과 함께 소스 코드 관리 시스템에 보관하려면 LoadRunner와 같은 상용 도구를 사용하는 것이 좋습니다. 특히 엔터프라이즈급 프로토콜 지원과 벤더 지원이 라이선스 비용을 정당화할 만큼 중요한 경우에는 더욱 그렇습니다.

부하 시험의 장점과 단점

부하 테스트의 장점은 다음과 같습니다.

  • 생산 전 성능 병목 현상 식별
  • 시스템의 확장성을 향상시킵니다.
  • 시스템 다운타임과 관련된 위험 최소화
  • 실패 비용 감소
  • 고객 만족도 향상

부하 테스트의 단점:

  • 대부분의 도구는 현실적인 시나리오를 작성하기 위해 프로그래밍 지식을 필요로 합니다.
  • 가격은 지원되는 가상 사용자 수에 따라 달라지므로 도구 비용이 많이 들 수 있습니다.

부하 테스트 중 수집해야 할 주요 지표

필수 조건 섹션에서는 응답 시간을 주요 측정 기준으로 설정합니다. 실제로 부하 테스트 보고서에는 응답 시간만으로는 시스템 속도 저하의 원인을 파악할 수 없기 때문에 수십만 단위의 데이터가 필요합니다.

메트릭 그것이 당신에게 말하는 것 경고 표시
평균 응답 시간 일반적인 사용자 경험 부하가 증가함에 따라 상승함
95번째 백분위수 응답 시간 가장 느린 사용자의 경험 평균을 훨씬 웃도는
맞춤형 설비 초당 성공적으로 처리된 요청 수 하중이 증가하는 동안 평평해지거나 아래로 처짐
오류율 실패 또는 시간 초과된 요청 비율 합의된 기준치를 초과하는 모든 상승
동시 사용자 실제 동시 접속 세션 수 달성 의도했던 시나리오보다 낮음
서버 리소스 사용량 CPU, 메모리, 디스크 및 네트워크 여유 공간 대략 80% 이상인 모든 자원

읽기 처리량과 응답 시간을 함께 나타낸 그래프입니다. 처리량이 증가함에 따라 응답 시간이 증가하는 것은 시스템이 더 바빠졌다는 것을 의미합니다. 전도 처리량이란 시스템이 용량을 초과하여 작업 손실이 발생하고 있음을 의미하며, 테스트는 바로 이 지점을 찾아내기 위해 존재합니다.

평균값만 발표해서는 안 됩니다. 평균 900ms, 95번째 백분위수 1.1초는 안정적인 시스템을 나타냅니다. 하지만 동일한 평균값에서 95번째 백분위수가 11초라는 것은 20명 중 1명의 사용자가 평균값에 가려진 불만족스러운 경험을 하고 있음을 의미합니다.

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

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

테스트 유형 증가된 것은 무엇입니까? 질문에 대한 답변
부하 테스트 동시 접속 사용자 수, 예상 최고치까지 일반적인 최대 트래픽 상황에서 목표치를 충족합니까?
볼륨 테스트 데이터베이스에 저장된 데이터 데이터 세트가 커짐에 따라 제대로 작동합니까?
스트레스 테스트 용량 초과 부하, 고장 발생 시 어디서, 그리고 어떻게 고장나는가?
스파이크 테스트 즉시 그리고 매우 빠르게 로드됩니다. 충격에서 살아남고 회복할 수 있을까요?
내구성 테스트 정상 부하에서의 지속 시간 시간이 지남에 따라 성능이 저하됩니까?
침수 테스트 시청 시간, 시청 자료 메모리 누수나 핸들 누수가 있습니까?
안정성 테스트 다양한 조건 환경 변화에도 신뢰성을 유지합니까?

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

자주 묻는 질문

부하 테스트는 예상되는 최대 부하를 적용하여 목표가 충족되는지 확인합니다. 스트레스 테스트는 의도적으로 시스템 용량을 초과하여 한계점을 찾아내고 시스템이 실패하더라도 정상적으로 복구되는지 확인합니다.

애플리케이션이 기능적으로 안정화되고, 발견된 병목 현상을 수정할 수 있을 만큼 충분히 초기 단계에 실행해야 합니다. 마지막 주에 실행하면 발견된 문제점을 해결할 시간이 없습니다.

JMeter무료이고, 가장 광범위한 프로토콜을 지원하며, 가장 방대한 문서 자료를 보유하고 있기 때문입니다. 팀에서 버전 관리되는 코드로 작성된 테스트를 선호한다면 Gatling이나 k6로 전환하세요.

AI는 실제 운영 환경의 트래픽 로그에서 현실적인 부하 프로파일을 도출하고, 결과의 이상 징후를 자동으로 감지하며, 실행 예약 전에 성능 저하를 유발할 가능성이 있는 코드 변경 사항을 예측합니다.

예. AI 도구는 기록된 사용자 여정이나 API 사양을 실행 가능한 스크립트로 변환합니다. 생성된 사고 시간과 데이터 매개변수 설정을 검증해야 합니다. 비현실적인 값은 잘못된 결과를 초래할 수 있습니다.

이 게시물을 요약하면 다음과 같습니다.