performance efficiency test

반응형

성능 효율성 테스트 (Performance Efficiency Test)

소프트웨어 성능 효율성 테스트는 소프트웨어의 응답 시간, 처리량, 자원 사용량, 안정성 등을 평가하여 소프트웨어가 주어진 조건 하에서 얼마나 효율적으로 동작하는지를 확인하는 과정입니다. 성능 테스트는 주로 다음과 같은 목적을 가지고 수행됩니다.

1. 응답 시간 (Response Time) : 요청에 대한 응답이 얼마나 빠르게 이루어지는지를 측정합니다.
2. 처리량 (Throughput) : 주어진 시간 동안 얼마나 많은 작업을 처리할 수 있는지를 평가합니다.
3. 자원 사용량 (Resource Utilization) : CPU, 메모리, 네트워크 대역폭 등 시스템 자원을 얼마나 효율적으로 사용하는지를 측정합니다.
4. 확장성 (Scalability) : 시스템이 증가하는 부하를 얼마나 잘 처리할 수 있는지를 평가합니다.
5. 안정성 (Stability) : 장시간 동작 시에도 시스템이 안정적으로 동작하는지를 확인합니다.

성능 테스트의 종류

1. 부하 테스트 (Load Testing) : 시스템이 정상적인 부하 상태에서 어떻게 동작하는지를 평가합니다. 예를 들어, 동시 사용자 수를 증가시키면서 응답 시간과 자원 사용량을 측정합니다.
2. 스트레스 테스트 (Stress Testing) : 시스템의 한계를 테스트하기 위해 비정상적으로 높은 부하를 가하여 시스템이 어떻게 반응하는지를 평가합니다. 목표는 시스템이 언제, 어디서 실패하는지를 확인하는 것입니다.
3. 내구성 테스트 (Endurance Testing) : 장기간 동안 시스템을 테스트하여 시간이 지남에 따라 성능이 어떻게 변하는지를 평가합니다. 메모리 누수와 같은 문제를 발견하기 위해 수행됩니다.
4. 스파이크 테스트 (Spike Testing) :  짧은 시간 동안 급격히 증가하는 부하를 시스템에 가하여 시스템이 이를 어떻게 처리하는지를 평가합니다.
5. 볼륨 테스트 (Volume Testing) : 대량의 데이터를 시스템에 입력하여 데이터베이스와 같은 컴포넌트가 이를 얼마나 잘 처리할 수 있는지를 평가합니다.
6. 컨커런시 테스트 (Concurrency Testing) : 동시에 여러 사용자가 접근하는 상황에서 시스템이 어떻게 동작하는지를 평가합니다.

출처 : TTA

성능 테스트 사례와 예시

1. 웹 애플리케이션 성능 테스트
   • 예시 : 전자상거래 웹사이트에서 부하 테스트를 수행하여 1000명의 동시 사용자가 로그인하고 제품을 검색할 때 응답 시간이 어떻게 변하는지 측정합니다.
   • 결과 : 서버 응답 시간이 2초 이내로 유지된다면 성능이 양호하다고 평가할 수 있습니다.
2. 모바일 애플리케이션 스트레스 테스트
   • 예시 : 모바일 게임 애플리케이션에 대해 10,000명의 동시 사용자가 게임에 접속하여 플레이할 때 서버가 다운되지 않고 안정적으로 동작하는지를 확인합니다.
   • 결과 : 특정 지점에서 서버 과부하로 인해 게임이 느려지거나 중단된다면 서버 확장 또는 최적화가 필요합니다.
3. 데이터베이스 내구성 테스트
   • 예시 : 금융 시스템의 데이터베이스에 대해 24시간 동안 지속적으로 거래 데이터를 입력하여 메모리 누수나 성능 저하가 발생하는지를 평가합니다.
   • 결과 : 24시간 동안 메모리 사용량이 일정하게 유지되고 성능 저하가 발생하지 않으면 안정성이 입증됩니다.
4. 스파이크 테스트
   • 예시 : 티켓 예매 시스템에서 특정 이벤트가 시작될 때 짧은 시간 내에 수천 명의 사용자가 동시에 티켓을 예매하려고 할 때 시스템이 이를 잘 처리하는지 평가합니다.
   • 결과 : 예매 시작 시점에 잠깐 동안 응답 시간이 길어지지만 전체적으로 시스템이 정상 동작하면 긍정적인 결과로 볼 수 있습니다.

 소프트웨어 성능 효율성 테스트는 이러한 다양한 테스트 방법과 사례를 통해 시스템의 약점을 발견하고 보완하여 최적의 성능을 유지할 수 있도록 돕습니다.

리틀의 법칙과 성능 테스트 (Little's Law and Performance Testing)

리틀의 법칙은 성능 테스트에서 반드시 알아야 하는 중요한 법칙입니다. 이 법칙은 발명자인 존 리틀 박사의 이름을 따서 명명되었으며, 매우 간단하고 직관적입니다. 리틀의 법칙은 시스템에 오랜 시간 머물러 있는 고객의 평균 수가 오랜 시간 동안의 평균 도착률과 시스템에서 고객이 머문 평균 시간을 곱한 값과 동일하다는 것을 나타냅니다. 성능 테스트 관점에서 이 법칙을 설명하기 위해 필요한 용어는 다음과 같습니다.

1. 동시 사용자 (concurrent user) : active user와 inactive user의 합
2. active user : 요청 후 응답을 기다리는 사용자.
3. inactive user : 세션 정보를 가지고 있지만, 요청을 보내지 않는 사용자
   (예: 앞선 요청에 대한 결과를 보고 있는 사용자).
4. 처리량 (throughput) : 단위 시간 동안 시스템(서버)에서 처리되는 요청 수로, 보통 TPS(transactions per second)로 나타냅니다.
5. 응답 시간 (response time) : 요청을 보낸 후 응답이 처리되어 결과가 사용자에게 전달될 때까지 걸리는 시간.
6. 씽크 타임 (think time) : 요청을 보낸 후 응답 결과를 수신하고 다음 요청을 보낼 때까지 걸리는 시간.
7. 요청 간격 (request interval) : 요청을 보낸 후 다음 요청을 보낼 때까지 걸리는 시간으로, request interval = response time + think time 입니다.

이러한 정의를 바탕으로 리틀의 법칙을 성능 테스트 관점에서 기술하면 아래와 같은 공식으로 표현됩니다.

• concurrent user = 처리량(TPS) * 요청 간격(request interval)
• concurrent user = 처리량(TPS) * (response time + think time)
• active user = 처리량(TPS) * response time
• inactive user = 처리량(TPS) * think time

리틀의 법칙은 성능 테스트에서 목표 처리량에 요구되는 동시 사용자 수를 산정할 때 사용됩니다. 동시 사용자 수를 너무 적게 산정하면 실제 시스템에서 발생할 수 있는 상황과는 거리가 먼 테스트 결과가 나올 수 있으며, 너무 많이 산정하면 테스트에 필요 이상으로 비용이 들게 됩니다. 

예를 들어, 목표 처리량이 50TPS이고 시스템의 평균 응답 시간(think time은 0이라고 가정)이 2초라면, 성능 테스트에 필요한 가상 사용자 수는 100명입니다. 따라서 100명의 가상 사용자를 대신하는 쓰레드를 생성하여 성능 테스트를 수행할 필요가 있습니다.

리틀의 법칙과는 직접적인 관계는 없지만, 성능 테스트에서 자주 사용되는 용어로 ramp up과 ramp down이 있습니다. ramp up은 가상 사용자를 이용하여 부하를 주는 패턴을 말하며, 가상 사용자를 동시에 유입할지 또는 일정 시간 간격을 두고 유입할지를 정의합니다. 예를 들어, ramp up 기간이 100초이고 10명의 가상 사용자가 있다면, 100/10 = 10초 주기로 가상 사용자가 한 명씩 유입됩니다. 반면, ramp down은 성능 테스트가 종료된 후 가상 사용자 수를 줄이는 패턴입니다.

 

 

ISO/IEC 25010