성능 테스트 튜토리얼

성능 테스트란 무엇입니까?

성능 시험 특정 작업 부하에서 소프트웨어 응용 프로그램의 속도, 응답 시간, 안정성, 신뢰성, 확장성 및 리소스 사용량을 테스트하는 데 사용되는 소프트웨어 테스트 프로세스입니다. 성능 테스트의 주요 목적은 소프트웨어 애플리케이션의 성능 병목 현상을 식별하고 제거하는 것입니다. 이는 성능 엔지니어링의 하위 집합이며 다음과 같이 알려져 있습니다. “성능 테스트”.

성능 테스트의 핵심은 소프트웨어 프로그램의 다음 사항들을 확인하는 것입니다.

• 속도 – 애플리케이션이 빠르게 응답하는지 여부를 결정합니다.
• 확장성 – 소프트웨어 애플리케이션이 처리할 수 있는 최대 사용자 부하를 결정합니다.
• 안정 – 다양한 부하에서 애플리케이션이 안정적인지 확인

성능 테스트가 중요한 이유는 무엇입니까?

소프트웨어 시스템이 지원하는 기능과 성능만이 고려 대상은 아닙니다. 응답 시간, 안정성, 리소스 사용량, 확장성 등 소프트웨어 애플리케이션의 성능 또한 중요합니다. 성능 테스트의 목표는 버그를 찾는 것이 아니라 성능 병목 현상을 제거하는 것입니다.

성능 테스트는 이해관계자들에게 애플리케이션의 속도, 안정성 및 확장성에 대한 정보를 제공하기 위해 수행됩니다. 더욱 중요한 것은 성능 테스트를 통해 제품 출시 전에 개선해야 할 사항을 파악할 수 있다는 점입니다. 성능 테스트를 거치지 않으면 소프트웨어는 여러 사용자가 동시에 사용할 때 속도 저하, 운영 체제 간 호환성 문제, 사용성 저하 등의 문제를 겪을 가능성이 높습니다.

성능 테스트는 예상되는 작업 부하 조건에서 소프트웨어가 속도, 확장성 및 안정성 요구 사항을 충족하는지 여부를 판단하는 데 사용됩니다. 성능 테스트가 제대로 이루어지지 않았거나 부실하여 성능 지표가 좋지 않은 상태로 출시된 애플리케이션은 평판이 나빠지고 예상 판매 목표를 달성하지 못할 가능성이 높습니다.

또한, 미션 크리티컬 애플리케이션 우주 발사 프로그램이나 생명을 구하는 의료 장비와 같은 제품은 성능 테스트를 통해 장기간 편차 없이 작동하는지 확인해야 합니다.

Dunn & Bradstreet에 따르면, Fortune 59 기업의 500%가 매주 약 1.6시간의 다운타임을 경험한다고 합니다. 최소 500명의 직원을 둔 Fortune 10,000 기업의 평균이 시간당 56달러를 지불한다는 점을 고려하면, 그러한 조직의 다운타임 비용 중 노동 비용은 주당 896,000달러로, 연간 46만 달러가 넘습니다.

오직 5분의 가동 중지 시간 of Google.com 인수(2013년 8월 19일)는 검색 대기업에게 상당한 비용이 들 것으로 추정됩니다. $ 545,000.

기업들이 입은 매출 손실액은 상당할 것으로 추산된다. 초당 $1100 최근 일로 인해 Amazon 웹 서비스 중단.

따라서 성능 테스트가 중요합니다. 이 프로세스에 도움을 받으려면 다음 목록을 확인하세요. 성능 테스트 도구.

성능 테스트 유형

소프트웨어 테스팅에는 기본적으로 6가지 유형의 성능 테스트가 있으며, 아래에서 설명합니다.

• 부하 테스트 - 예상되는 사용자 로드 하에서 애플리케이션의 성능을 확인합니다. 목표는 소프트웨어 애플리케이션이 활성화되기 전에 성능 병목 현상을 식별하는 것입니다.
• 스트레스 테스트 - 극한의 워크로드에서 애플리케이션을 테스트하여 높은 트래픽이나 데이터 처리를 어떻게 처리하는지 확인하는 작업이 포함됩니다. 목표는 애플리케이션의 중단점을 식별하는 것입니다.
• 내구성 테스트 – 이는 소프트웨어가 장기간에 걸쳐 예상되는 부하를 처리할 수 있는지 확인하기 위해 수행됩니다. 이를 통해 지속적인 작동 중에만 발생하는 메모리 누수 및 리소스 고갈과 같은 문제를 감지할 수 있습니다.
• 스파이크 테스트 – 스파이크 테스트는 사용자로 인해 발생하는 갑작스럽고 큰 부하 급증에 대한 소프트웨어의 반응을 테스트합니다. 스트레스 테스트와 달리 스파이크 테스트는 시스템이 급격하고 단기간에 발생하는 트래픽 급증을 어떻게 처리하고 복구하는지에 초점을 맞춥니다.
• 볼륨 테스트 – 이 프로젝트는 대량의 데이터를 데이터베이스에 입력하고 소프트웨어 시스템의 전반적인 동작을 모니터링하는 것을 포함합니다. 목표는 다양한 데이터베이스 용량 조건에서 소프트웨어 애플리케이션의 성능을 확인하는 것입니다.
• 확장성 테스트 – 소프트웨어 애플리케이션이 사용자 부하 증가를 지원하기 위해 "확장"하는 데 얼마나 효과적인지 판단합니다. 이를 통해 소프트웨어 시스템의 용량 추가 계획을 수립하는 데 도움이 됩니다.

일반적인 성능 문제

대부분의 성능 문제는 속도, 응답 시간, 로딩 시간 및 확장성 부족과 관련이 있습니다. 속도는 애플리케이션에서 가장 중요한 속성 중 하나입니다. 느리게 실행되는 애플리케이션은 잠재적 사용자를 잃게 됩니다. 성능 테스트는 애플리케이션이 사용자의 관심과 흥미를 유지할 수 있을 만큼 충분히 빠르게 실행되는지 확인합니다. 다음은 속도가 주요 원인으로 작용하는 일반적인 성능 문제입니다.

• 로딩 시간이 오래 걸림 – 로딩 시간은 일반적으로 애플리케이션이 처음 시작될 때까지 걸리는 시간입니다. 이 시간은 최소한으로 유지해야 합니다. 일부 애플리케이션은 1분 이내에 로딩이 완료되는 것이 불가능할 수 있지만, 가능하면 몇 초 이내로 유지하는 것이 좋습니다.
• 응답 시간이 좋지 않음 – 응답 시간은 사용자가 애플리케이션에 데이터를 입력한 시점부터 애플리케이션이 해당 입력에 대한 응답을 출력하는 시점까지 걸리는 시간입니다. 일반적으로 응답 시간은 매우 빨라야 합니다. 사용자가 너무 오래 기다려야 한다면 흥미를 잃게 됩니다.
• 확장성이 좋지 않음 – 소프트웨어 제품은 예상되는 사용자 수를 처리할 수 없거나 충분히 넓은 범위의 사용자를 수용하지 못하는 경우 확장성이 좋지 않습니다. 부하 테스트 애플리케이션이 예상되는 사용자 수를 처리할 수 있는지 확인해야 합니다.
• 병목 현상 – 병목 현상은 시스템 성능을 저하시키는 장애물입니다. 코딩 오류나 하드웨어 문제로 인해 특정 부하에서 처리량이 감소하는 현상이 병목 현상으로 나타납니다. 병목 현상은 대개 코드의 특정 부분에서 오류가 발생하여 생깁니다. 병목 현상 문제를 해결하는 핵심은 속도 저하를 유발하는 코드 부분을 찾아 수정하는 것입니다. 일반적으로 병목 현상은 성능이 저하된 프로세스를 개선하거나 추가 하드웨어를 설치하여 해결할 수 있습니다. 일반적인 성능 병목 현상 위치 :
  • CPU 사용률
  • 메모리 활용도
  • 네트워크 활용
  • Opera시스템 제한 사항
  • 디스크 사용량

성능 테스트를 수행하는 방법

성능 테스트에 채택된 방법론은 매우 다양할 수 있지만 성능 테스트의 목적은 동일합니다. 이는 소프트웨어 시스템이 사전 정의된 특정 성능 기준을 충족하는지 입증하는 데 도움이 될 수 있습니다. 또는 두 소프트웨어 시스템의 성능을 비교하는 데 도움이 될 수 있습니다. 또한 성능을 저하시키는 소프트웨어 시스템의 일부를 식별하는 데도 도움이 될 수 있습니다.

다음은 성능 테스트를 수행하는 일반적인 절차입니다.

1단계) 테스트 환경 식별

물리적 테스트 환경, 운영 환경, 그리고 사용 가능한 테스트 도구를 파악하십시오. 테스트를 시작하기 전에 테스트에 사용되는 하드웨어, 소프트웨어 및 네트워크 구성에 대한 세부 정보를 이해해야 합니다. 이는 테스터가 보다 효율적인 테스트를 설계하는 데 도움이 될 뿐만 아니라 성능 테스트 절차 중에 발생할 수 있는 잠재적인 문제점을 파악하는 데에도 도움이 됩니다.

2단계) 성과 수용 기준 식별

여기에는 처리량, 응답 시간 및 리소스 할당에 대한 목표와 제약 조건이 포함됩니다. 또한 이러한 목표와 제약 조건 외에도 프로젝트 성공 기준을 파악해야 합니다. 테스터는 성능 기준과 목표를 설정할 수 있는 권한을 가져야 합니다. 프로젝트 사양에 다양한 성능 벤치마크가 충분히 포함되어 있지 않거나 아예 없는 경우가 많기 때문입니다. 가능한 경우, 비교할 만한 유사한 애플리케이션을 찾는 것이 성능 목표를 설정하는 좋은 방법입니다.

3단계) ​​계획 및 설계 성능 테스트

최종 사용자 간 사용 패턴이 어떻게 다를지 예측하고, 가능한 모든 사용 사례에 대해 테스트할 주요 시나리오를 파악해야 합니다. 다양한 최종 사용자를 시뮬레이션하고, 성능 테스트 데이터를 계획하며, 수집할 지표를 명확히 정의해야 합니다.

4단계) 테스트 환경 구성

실행 전에 테스트 환경을 준비하십시오. 필요한 도구와 기타 리소스도 준비해야 합니다. 테스트 결과가 현실적이고 실행 가능한지 확인하기 위해 실제 운영 환경과 최대한 유사하게 환경을 구성하십시오.

5단계) 테스트 설계 구현

테스트 설계에 따라 성능 테스트를 만듭니다.

6단계) 테스트 실행

테스트를 실행하고 모니터링합니다.

7단계) 분석, 조정 및 재테스트

테스트 결과를 취합, 분석 및 공유합니다. 그런 다음 미세 조정을 하고 다시 테스트하여 성능이 향상되었는지 또는 저하되었는지 확인합니다. 일반적으로 재테스트를 거듭할수록 개선 효과가 줄어들기 때문에 CPU로 인해 병목 현상이 발생하면 작업을 중단하십시오. 그 후에는 CPU 성능을 향상시키는 방안을 고려해야 할 수도 있습니다.

성능 테스트 지표: 모니터링되는 매개변수

성능 테스트 중에 모니터링되는 기본 매개변수는 다음과 같습니다.

• 프로세서 사용량 – 프로세서가 유휴 상태가 아닌 스레드를 실행하는 데 소요하는 시간.
• 메모리 사용 – 컴퓨터에서 프로세스가 사용할 수 있는 물리적 메모리의 양.
• 디스크 시간 – 디스크가 읽기 또는 쓰기 요청을 실행하는 데 소요되는 시간.
• 대역폭 – 네트워크 인터페이스에서 사용되는 초당 비트 수를 보여줍니다.
• 개인 바이트 – 프로세스가 할당했지만 다른 프로세스와 공유할 수 없는 바이트 수입니다. 이는 메모리 누수 및 사용량을 측정하는 데 사용됩니다.
• 커밋된 메모리 – 사용된 가상 메모리의 양.
• 메모리 페이지/초 - 하드 페이지 폴트를 해결하기 위해 디스크에 쓰거나 읽은 페이지 수입니다. 하드 페이지 폴트는 현재 작업 세트에 속하지 않은 코드가 다른 곳에서 호출되어 디스크에서 검색될 때 발생합니다.
• 페이지 폴트/초 – 프로세서가 오류 페이지를 처리하는 전체 속도입니다. 이는 프로세스가 작업 세트 외부의 코드를 필요로 할 때 발생합니다.
• 초당 CPU 인터럽트 - 프로세서가 매초 수신하고 처리하는 하드웨어 인터럽트의 평균 횟수.
• 디스크 대기열 길이 – 샘플링 간격 동안 선택된 디스크에 대해 대기 중인 읽기 및 쓰기 요청의 평균 수입니다.
• 네트워크 출력 대기열 길이 – 출력 패킷 큐의 길이를 패킷 단위로 나타낸 값입니다. 2보다 크면 지연이 발생하므로 병목 현상을 해결해야 합니다.
• 초당 총 네트워크 바이트 – 프레임 문자를 포함하여 인터페이스에서 바이트가 송수신되는 속도.
• 응답 시간 - 사용자가 요청을 입력한 시점부터 응답의 첫 번째 문자가 수신될 때까지의 시간.
• 처리량 - 컴퓨터 또는 네트워크가 초당 요청을 수신하는 속도.
• 연결 풀링 양 – 풀링된 연결에 의해 충족되는 사용자 요청 수입니다. 풀의 연결에서 충족되는 요청이 많을수록 성능이 향상됩니다.
• 최대 활성 세션 – 동시에 활성화될 수 있는 최대 세션 수입니다.
• 적중률 – 이것은 숫자와 관련이 있습니다. SQL 비싼 I/O 작업 대신 캐시된 데이터로 처리되는 명령문. 이는 병목 문제를 해결하기 위한 좋은 시작점입니다.
• 초당 조회수 – 부하 테스트 중 매초 웹 서버에 대한 접속 횟수.
• 롤백 세그먼트 – 언제든지 롤백할 수 있는 데이터의 양.
• 데이터베이스 잠금 – 테이블과 데이터베이스의 잠금을 모니터링하고 주의 깊게 조정해야 합니다.
• 최고 대기자 – 메모리에서 데이터를 검색하는 속도와 관련하여 대기 시간을 줄일 수 있는 부분을 파악하기 위해 모니터링합니다.
• 스레드 수 - 애플리케이션의 상태는 현재 실행 중이거나 활성화된 스레드 수로 측정할 수 있습니다.
• 쓰레기 수거 – 가비지 컬렉션은 사용되지 않는 메모리를 시스템으로 반환하는 작업입니다. 효율성을 위해 가비지 컬렉션의 작동 상태를 지속적으로 모니터링해야 합니다.

성능 테스트 테스트 사례 예

다음은 성능 테스트 샘플 사례입니다.

• 테스트 케이스 01: 1000명의 사용자가 동시에 웹사이트에 접속할 때 응답 시간이 4초를 넘지 않는지 확인하십시오.
• 테스트 케이스 02: 네트워크 연결 속도가 느릴 때 부하가 걸린 애플리케이션의 응답 시간이 허용 가능한 범위 내에 있는지 확인하십시오.
• 테스트 케이스 03: 애플리케이션이 충돌하기 전에 처리할 수 있는 최대 사용자 수를 확인하십시오.
• 테스트 케이스 04: 500개 레코드를 동시에 읽거나 쓸 때 데이터베이스 실행 시간을 확인하세요.
• 테스트 케이스 05: 최대 부하 조건에서 애플리케이션과 데이터베이스 서버의 CPU 및 메모리 사용량을 확인하십시오.
• 테스트 케이스 06: 저부하, 보통, 보통, 고부하 조건에서 애플리케이션의 응답 시간을 확인합니다.

실제 성능 테스트 실행 중에 허용 범위, 무거운 하중 등과 같은 모호한 용어는 구체적인 숫자로 대체됩니다. 성능 엔지니어는 비즈니스 요구 사항과 애플리케이션의 기술적 환경에 따라 이러한 숫자를 설정합니다.

성능 테스트 최고의 사례

정립된 모범 사례를 따르면 성능 테스트에서 신뢰할 수 있는 결과를 얻을 수 있습니다. 이러한 지침은 팀이 흔히 발생하는 문제점을 피하는 데 도움이 됩니다.

• 생산 환경을 그대로 반영하세요. 테스트 환경은 실제 운영 환경과 최대한 유사하게 구성해야 합니다. 하드웨어 또는 소프트웨어 버전의 차이로 인해 잘못된 결과가 나올 수 있습니다.
• 현실적인 테스트 시나리오를 설계하세요 – 사용자의 실제 행동(생각 시간 및 동시 트랜잭션 구성 포함)을 시뮬레이션하는 테스트 케이스를 만드세요.
• 백분위 기반 지표를 사용하세요. 평균값만 사용하는 대신 90번째 및 95번째 백분위수 응답 시간을 활용하세요. 백분위수는 평균값으로는 드러날 수 있는 후반부 지연 시간을 보여줍니다.
• 초기에 그리고 지속적으로 테스트하십시오. 성능 테스트를 최종 단계 활동으로 취급하는 대신 CI/CD 파이프라인에 통합하십시오.
• 문서 및 기준선 결과 – 모든 테스트 실행 결과를 기록하세요. 새로운 결과를 기준선과 비교하면 릴리스 간의 성능 저하를 쉽게 감지할 수 있습니다.

AI가 성능 테스트를 어떻게 혁신하고 있는가

인공지능은 레샤입니다ping 복잡한 분석 작업을 자동화하고 예측 기능을 활성화하여 성능 테스트를 수행합니다. AI 기반 도구는 과거 데이터를 분석하고 패턴을 감지하며, 모든 단계에서 사람의 개입 없이 실행 가능한 권장 사항을 제공합니다.

• 예측적 이상 탐지 – AI 알고리즘은 부하 테스트 중에 성능 지표를 실시간으로 분석하고 심각한 오류로 이어지기 전에 이상 징후를 감지합니다.
• 자동화된 근본 원인 분석 – AI 기반 도구는 분산 시스템 전반의 데이터를 상호 연관시켜 성능 저하를 일으키는 정확한 구성 요소를 찾아냅니다.
• 지능형 테스트 최적화 – 머신러닝 모델은 중복되는 테스트 시나리오를 식별하고 최적의 구성을 제안하여 테스트 범위는 유지하면서 실행 시간을 단축합니다.
• 자가 복구 테스트 스크립트 – AI는 애플리케이션 인터페이스가 변경될 때 테스트 스크립트를 조정하여 성능 테스트 스위트의 유지 관리 부담을 줄입니다.

성능 테스트 도구

시중에는 다양한 성능 테스트 도구가 있습니다. 테스트에 사용할 도구는 지원되는 프로토콜 유형, 라이선스 비용, 하드웨어 요구 사항 및 플랫폼 지원과 같은 여러 요소에 따라 달라집니다. 아래는 널리 사용되는 테스트 도구 목록입니다.

• HP 로드러너 - 시중에서 가장 인기 있는 성능 테스트 도구 중 하나입니다. 이 도구는 수십만 명의 사용자를 시뮬레이션하여 애플리케이션을 실제 부하 상태에 노출시켜 예상 부하 조건에서의 동작을 파악할 수 있습니다. LoadRunner 실제 인간 사용자의 행동을 시뮬레이션하는 가상 사용자 생성기를 제공합니다.
• JMeter - 웹 및 애플리케이션 서버 부하 테스트에 사용되는 대표적인 오픈 소스 도구 중 하나입니다. 다양한 프로토콜을 지원하며 광범위한 보고 기능을 제공합니다.

자주 묻는 질문