성능 테스트 튜토리얼

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

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

성능 테스트의 초점은 소프트웨어 프로그램의 성능을 확인하는 것입니다.

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

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

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

성능 테스트는 이해 관계자에게 속도, 안정성 및 확장성과 관련된 애플리케이션에 대한 정보를 제공하기 위해 수행됩니다. 더 중요한 것은 성능 테스트가 제품을 출시하기 전에 개선해야 할 사항을 밝혀낸다는 것입니다. 성능 테스트가 없으면 소프트웨어는 다음과 같은 문제로 어려움을 겪을 가능성이 높습니다. 여러 사용자가 동시에 사용하는 동안 느리게 실행, 다양한 운영 체제에서 불일치, 사용성 저하.

성능 테스트를 통해 해당 소프트웨어가 예상 워크로드에서 속도, 확장성 및 안정성 요구 사항을 충족하는지 확인합니다. 존재하지 않거나 열악한 성능 테스트로 인해 성능 지표가 좋지 않은 상태로 시장에 출시된 애플리케이션은 나쁜 평판을 얻고 예상 판매 목표를 달성하지 못할 가능성이 높습니다.

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

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

오직 5분의 가동 중지 시간 Google.com(19년 13월 XNUMX일)의 비용은 검색 대기업에 $ 545,000.

기업의 매출 가치가 손실된 것으로 추정됩니다. 초당 $1100 최근 일로 인해 Amazon 웹 서비스 중단.

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

성능 테스트 유형

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

• 부하 테스트 - 예상되는 사용자 로드 하에서 애플리케이션의 성능을 확인합니다. 목표는 소프트웨어 애플리케이션이 활성화되기 전에 성능 병목 현상을 식별하는 것입니다.
• 스트레스 테스트 - 극한의 워크로드에서 애플리케이션을 테스트하여 높은 트래픽이나 데이터 처리를 어떻게 처리하는지 확인하는 작업이 포함됩니다. 목표는 애플리케이션의 중단점을 식별하는 것입니다.
• 내구성 테스트 – 이는 소프트웨어가 장기간에 걸쳐 예상되는 로드를 처리할 수 있는지 확인하기 위해 수행됩니다.
• 스파이크 테스트 – 사용자가 생성한 로드의 갑작스러운 큰 급증에 대한 소프트웨어의 반응을 테스트합니다.
• 볼륨 테스트 – 볼륨 테스트 중 대형 no. 의. 데이터는 데이터베이스에 채워지고 전체 소프트웨어 시스템의 동작이 모니터링됩니다. 목표는 다양한 데이터베이스 볼륨에서 소프트웨어 애플리케이션의 성능을 확인하는 것입니다.
• 확장 성 테스트 – 확장성 테스트의 목적은 사용자 로드 증가를 지원하기 위해 "확장"하는 데 있어 소프트웨어 응용 프로그램의 효율성을 확인하는 것입니다. 이는 소프트웨어 시스템에 용량 추가를 계획하는 데 도움이 됩니다.

일반적인 성능 문제

대부분의 성능 문제는 속도, 응답 시간, 로드 시간, 낮은 확장성에서 비롯됩니다. 속도는 종종 애플리케이션의 가장 중요한 속성 중 하나입니다. 느리게 실행되는 애플리케이션은 잠재적 사용자를 잃게 됩니다. 성능 테스트를 통해 앱이 사용자의 주의와 흥미를 유지할 만큼 충분히 빠르게 실행되는지 확인합니다. 일반적인 성능 문제 목록을 살펴보고 속도가 많은 문제에서 공통적인 요소인 것을 확인하세요.

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

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

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

다음은 성능 테스트를 수행하는 방법에 대한 일반적인 프로세스입니다.

1단계) 테스트 환경 식별

물리적 테스트 환경, 프로덕션 환경 및 사용 가능한 테스트 도구를 파악합니다. 테스트 프로세스를 시작하기 전에 테스트 중에 사용된 하드웨어, 소프트웨어 및 네트워크 구성의 세부 정보를 이해합니다. 테스터가 보다 효율적인 테스트를 만드는 데 도움이 됩니다. 또한 테스터가 성능 테스트 절차 중에 마주칠 수 있는 잠재적인 과제를 식별하는 데 도움이 됩니다.

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

여기에는 처리량, 응답 시간 및 리소스 할당에 대한 목표와 제약 조건이 포함됩니다. 또한 이러한 목표와 제약 사항 외에 프로젝트 성공 기준을 식별하는 것도 필요합니다. 프로젝트 사양에 충분히 다양한 성능 벤치마크가 포함되지 않는 경우가 많기 때문에 테스터는 성능 기준과 목표를 설정할 수 있는 권한을 받아야 합니다. 때로는 전혀 없을 수도 있습니다. 가능하다면 비교할 유사한 응용 프로그램을 찾는 것이 성능 목표를 설정하는 좋은 방법입니다.

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

최종 사용자 간에 사용량이 어떻게 달라질지 파악하고 가능한 모든 사용 사례를 테스트하기 위한 주요 시나리오를 식별합니다. 다양한 최종 사용자를 시뮬레이션하고, 성능 테스트 데이터를 계획하고, 어떤 지표를 수집할지 개략적으로 설명해야 합니다.

4단계) 테스트 환경 구성

실행 전 테스트 환경을 준비합니다. 또한 도구 및 기타 리소스를 준비하십시오.

5단계) 테스트 설계 구현

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

6단계) 테스트 실행

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

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

테스트 결과를 통합, 분석 및 공유합니다. 그런 다음 미세 조정하고 다시 테스트하여 성능이 향상되거나 저하되는지 확인합니다. 일반적으로 다시 테스트할 때마다 개선 사항이 작아지므로 CPU로 인해 병목 현상이 발생하는 경우 중지하십시오. 그런 다음 CPU 성능을 높이는 옵션을 고려할 수 있습니다.

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

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

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

성능 테스트 테스트 사례 예

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

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

성능 테스트 도구

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

• HP 로드러너 - 오늘날 시장에서 가장 인기 있는 성능 테스트 도구입니다. 이 도구는 수십만 명의 사용자를 시뮬레이션하고 실제 부하에 애플리케이션을 배치하여 예상 부하에서 해당 동작을 확인할 수 있습니다. 로드러너 실제 인간 사용자의 행동을 시뮬레이션하는 가상 사용자 생성기를 제공합니다.
• 제이미터 – 웹 및 애플리케이션 서버의 로드 테스트에 사용되는 주요 도구 중 하나입니다.

자주 묻는 질문

결론

In 소프트웨어 공학, 소프트웨어 제품을 마케팅하기 전에 성능 테스트가 필요합니다. 이는 고객 만족을 보장하고 제품 실패로부터 투자자의 투자를 보호합니다. 성능 테스트 비용은 일반적으로 향상된 고객 만족도, 충성도 및 유지율로 인해 상쇄되는 것보다 더 많습니다.