성능 테스트 유형 알아보기
Updated:
우리가 성능 테스트에 대한 이해를 넓혀보기 위해 인터넷에서 자료를 찾아가다보면, 생각보다 많은 유형의 성능테스트에 대한 정의들이 나열되어 있는 것을 보게 됩니다.
그나마 익숙한 Performance Testing과 Load Testing 외에도, Endurance Testing, Stress Testing, Spike Testing, Scalability Testing, Volume Testing, Soak Testing, Capacity Testing, Configuration Testing, Availability & Resilience Testing 등 정말 많은 테스트 유형을 정의하는 용어들이 검색을 통해 한꺼번에 쏟아듯이 등장합니니다.
Source: www.opencodez.com
한편, 성능 테스트 유형에 대한 정의를 정확히 이해해 보고자, 여러 자료들을 비교해가며 하나씩 짚어서 읽어가다 보면, 예상과 달리 그 정의하고 있는 용어와 매핑되는 내용들이 조금씩 다른 것을 보게 됩니다. 예를 들어, 성능 테스트 유형에 대해서도 아래의 경우와 같이 ‘Baseline Testing’이라는 용어를 시작으로, 그 ‘부하량’과 ‘기간’ 등의 정도에 따라 성능 테스트 유형을 정의하는 경우도 있습니다.
Source: researchgate
이번 글에서는 ‘성능 테스트 유형’에 대한 기본적인 이해를 가질 수 있도록, 일반적으로 성능 테스트에는 어떠한 종류들이 있는지, 그리고 각각은 대략적으로 어떤 차이점을 가지고 성능 업무에 적용되고 있는지에 대해 몇가지 자료들을 중심으로 살펴봄으로써, 성능테스트가 수행되는 다양한 형태들에 대한 기본적인 이해를 돕고자 합니다.
첫번째로 살펴볼 자료는, 성능 테스트 유형에 대해 사용자의 부하발생 패턴별로 시각화하여 차이점을 비교하고 있는 DCube’s Practices 자료입니다.
1. 성능 테스트의 다섯가지 일반적인 유형들
Source: DCube
그래프의 Y축은 가상사용자(Virtual Users), X축은 지속 시간(Test Time)을 각각 나타내고 있으며, 사용자의 증가, 유지, 감소 등 부하패턴 변화에 따라 각각의 테스트 유형을 구분지어 비교하고 있습니다. 참고로, 성능 테스트 Tool에서는 이러한 그래프와 유사하게 Workload를 설계하여 사용하고 있습니다. 예를 들어, 500명의 가상사용자(Virtual Users)를 이용한다면, 5분간 500명 증가(Ramp Up), 10분간 부하지속(Steady State), 1분간 부하 감소(Ramp Down) 등과 같은 형태로 설계하여 실제 부하를 발생시키고 있습니다.
Source: guides.blazemeter.com
그러면, 위의 그래프에서 보여주고 있는 다섯가지 성능테스트 유형들은 각각 어떤 의미를 가지고 있는지에 대해 DCube’s Practices에서 설명하고 있는 정의를 통해 살펴보겠습니다.
1. Load Test (most common out of the five)
사전에 결정된 Peak시점의 부하 상황에서 시스템의 성능을 검증하는 것으로, Peak Load는 일반적으로 1시간동안 유지됩니다. 이 테스트는 적정한 성능으로 Peak Hour Traffic을 감당할 수 있는지 확인합니다.
2. Stress Test
Peak Load보다 훨씬 높은 부하 상황에서 시스템의 성능을 검증합니다.(일반적으로는 Peak Load의 2배를 사용합니다.) 이러한 상황에서 시스템이 장애가 발생하는지 또는 사용 가능한 상태로 유지되는지, 그리고 부하가 정상 수준으로 돌아갈 때 우아하게(gracefully) 복구되는지 체크합니다.
3. Endurance Test
장기간에 걸쳐 나타나는 메모리 누수와 같은 이슈들을 감지하기 위해, 8시간 이상의 기간에 걸쳐 시스템의 안정성을 확인하는 장기적인 테스트입니다.
4. Spike Test
시스템의 갑작스러운 사용량 급증에 대한 독특한 시나리오에 대해 시뮬레이션합니다. 이것은 인기있는 제품 출시(e.g. iPhone) 또는 Big Sales(e.g. Singles’ Day)와 같은 상황과 관련이 있습니다.
5. Breakpoint Test
동시단말 사용자(concurrent users)의 수를 점진적으로 증가시켜서, 시스템의 장애 지점을 결정합니다. 테스트 이후, 시스템을 사용할 수 없게 되는 지점, 즉 시스템의 중단점(the breakpoint of the system)을 관찰하기 위해 그래프를 그릴 수 있습니다.
정리해 보면, DCube’s Practices에서 단순하게 구분짓고 있는 다섯가지 성능테스트 유형은 다음과 같이 요약할 수 있습니다.
- ‘적정 부하’(=Peak 시점의 부하)를 유지하는 것을 Load Testing
- ‘적정 부하의 2배’를 유지하는 것을 Stress Testing
- ‘장시간 부하’를 유지하는 것을 Endurance Testing
- ‘순간적인 대량 부하’를 발생하는 것을 Spike Testing
- ‘부하를 점차 증가’시켜 임계점을 확인하는 것을 Breakpoint Testing
여기서는, Stress Testing의 정의가 ‘적정 부하의 2배’ 등의 예시로 단순화하여 설명되었지만, 원래의 의미는 좀 더 넓은 개념으로 사용되고 있습니다. 예를 들어, 아래 그림에서 부하 유형의 그래프들 중 사선으로 표시한 부분을 보면, Stress Testing에 대한 설명이 ‘Find the Performance Limits of the System’으로 되어 있어서, 앞서 언급된 Breakpoint Testing과 비슷한 의미로 사용되기도 합니다. 좀더 자세한 설명은 두번째 예시에서 참조하시기 바랍니다.
Source: www.netsolutions.com
net solutions의 그림에서 표현하고 있는 성능테스트 유형 그래프들 중, ‘Soak Test - 24hr Duration’라는 추가적인 용어가 나왔는데, ‘Soak’이란 단어가 평소에 익숙하지 않을 수 있는 용어라서(저만 그런가요? ^^) 잠깐 살펴보고 넘어가겠습니다.
우선, 사전에서 찾아보면 ‘Soak’은 1. (액체 속에 푹) 담그다 2. 흠뻑 적시다 등으로 정의하고 있습니다. 평소에 익숙하게 쓰는 단어는 아니지만, Universal Studio의 ‘Water World Show’라든지, SeaWorld의 ‘Shamu show’ 등을 관람하는 야외 좌석 앞쪽에는 ‘Soak Zone’이라는 표시가 되어 있는 경우가 있습니다.
Source: jardinluxembourg.wordpress.com
이 곳은 말 그대로 공연을 관람하다가, 수상보트나 범고래 등이 관람석에 접근하면서 갑자기 물벼락을 맞아 흠뻑 젖을 수 있는 좌석입니다.
Source: briebrieblooms.com
이제 ‘Soak’이라는 용어가 조금 익숙해 지셨다면, GURU99 에서 설명하고 있는 Soak Testing에 대한 설명을 살펴보겠습니다.
Soak Testing은 오랜 시간동안 대량 부하(huge volume of load) 상황에서, 애플리케이션의 성능을 측정하는데 사용되는 비기능 테스트의 한 유형입니다. 이 유형의 테스트에서 기본적으로 모니터링 되는 것은 시스템의 애플리케이션에 의한 메모리의 사용율입니다.
Why do Soak Testing?
시스템이 2시간 동안 사용될 때는 정상적으로 동작할 수 있지만, 동일한 시스템을 10시간 이상 사용하면 장애가 발생하거나 비정상적인 상황이 발생할 수 있습니다. 이러한 상황을 예측하기 위해 Soak Testing이 수행됩니다.
When to do Soak Testing?
빌드가 고객에게 배포되기 전에, 즉 특정 플랫폼에서 애플리케이션이 출시되기 전에 일련의 Load Tests가 수행된 이후, Soak Tesitng이 수행됩니다. 메모리 누수/ 메모리 손상 등과 같은 이슈가 발견되면 즉시 보고해야 합니다.
Source: guru99.com
이제 그래프 패턴 차이에 따른 성능 테스트 유형이 눈에 조금 익숙해 지셨다면, 이번에는 조금 다른 시각으로 용어 정의에 접근하고 있는, Software Testing Class의 정의에 대해 살펴보겠습니다.
2. 성능 테스트의 6가지 유형
Source: softwaretestingclass
Software Testing Class에서는 성능테스트(Performance Testing)의 주요 유형을 6가지로 정의하고 있습니다. 위에서 언급되었던 ‘Breakpoint Testing’이 빠지고, 여기서는 ‘Volume Testing’과 ‘Scalability Testing’이 추가되어 있습니다. 우선 각각의 정의에 대해 살펴보겠습니다.
1. Load Testing
Load Testing은 부하가 임계치(Threshold Value)에 도달할 때까지 시스템의 부하를 지속적으로 증가시키면서 시스템을 확인하는, Performance Testing의 한 유형입니다. 여기서 부하를 증가시킨다는 것은, 동시단말사용자(concurrent users)와 트랜잭션을 증가시키면서 테스트 중인 애플리케이션의 동작을 확인하는 것을 의미합니다. ‘Endurance testing’ 또는 ‘Volume testing’이라고 불리기도 합니다.
Load Testing의 주요 목적은 과부하 상태(under heavy load)에서 시스템이 잘 작동될 때, 응답시간과 애플리케이션의 지구력(staying power)을 모니터링하는 것입니다. Load Testing과 아래에 기술된 테스트들은 모두 비기능 테스트(NFT/ Non Functional Testing)에 속하며, 소프트웨어 애플리케이션의 비기능 요구사항을 테스트하기 위해 설계되었습니다.
Load Testing은 테스트중인 애플리케이션이 견딜 수 있는 부하의 양을 확인하기 위해 수행됩니다. ‘성공적으로 수행된 Load Testing’은 지정된 테스트 케이스가 할당된 시간동안 오류없이 수행된 경우에만 가능합니다.
2. Stress Testing
Stress Testing은 CPU, Memory, Disk Space 등과 같은 하드웨어 자원이 충분하지 않을 때, 소프트웨어의 안정성을 확인하는 Performance Testing의 한 유형입니다. Stress Testing의 기본 개념은 시스템의 오류를 확인하고, 어떻게 시스템이 정상적으로 복구되는지를 살펴보는 것입니다.
“To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions.”
Stress Testing은 시스템 하드웨어 자원에서 처리할 수 없는 많은 수의 동시단말사용자(concurrent users)/프로세스로 소프트웨어에 부하를 주는 Negative Testing입니다. 이 Testing은 피로시험(Fatigue testing)으로도 알려져 있습니다.
Stress Testing의 기본 개념은 시스템의 장애를 확인하고 시스템이 어떻게 정상적으로 복구되는지를 주시하는 것입니다. 이러한 품질 특성을 회복성(recoverability)이라고 합니다.
3. Spike testing
Spike testing은 Stress Testing의 Subset입니다. 테스트 대상 시스템에 대해, 상용 운영환경에서 예상되는 부하 이상의 Workload를 짧은 기간동안 반복적으로 증가시킬 때 나타나는 성능 특성을 검증하기 위해 수행합니다.
4. Endurance testing
Endurance testing은 시스템의 동작을 확인하기 위해, 장기간에 걸쳐 예상되는 부하량에 기반하여 시스템을 테스트 하는 것을 포함합니다. 예를 들어, 시스템이 3시간동안 작업을 수행하도록 설계되었다면, 동일 시스템이 6시간동안 지속되어도 시스템이 지구력을 유지하는지를 확인하는 것입니다. 가장 일반적인 테스트 케이스는 메모리 누수, 시스템 장애 또는 무작위적인 동작(random behavior)과 같은 시스템의 동작을 확인하기 위해 수행됩니다. 때때로, Endurance testing은 ‘Soak testing’이라고도 합니다.
5. Scalability Testing
Scalability Testing은 사용자 부하, 트랜잭션 수, 데이터 볼륨 등과 같은 비기능 측면에서 확장할 수 있는 역량을 판단하기 위한 소프트웨어 애플리케이션 테스트입니다. 이 테스트의 주요 목적은 더이상 확장(Scaling)하지 못하도록 막는 ‘시스템의 Peak’가 무엇인지 확인하는 것입니다.
6. Volume testing
Volume testing은 처리해야 할 많은 양의 데이터를 가진 애플리케이션의 효율성을 확인하기 위한 테스트입니다. 이 테스트의 주요 목표는 다양한 Database Volumes 하에서 애플리케이션의 성능을 모니터링 하는 것입니다.
Source: softwaretestingclass
첫번째 살펴보았던 DCube’s Practices의 성능테스트 유형 정의와, 두번째 softwaretestingclass의 정의는 각각 설명하고 있는 내용과 범위에서 약간의 뉘앙스 차이가 있는 것을 발견할 수 있습니다. 그러면서도, 대략적으로는 각각의 테스트 유형이 자신만의 특성을 가지면서 서로 구분되는 것을 알 수 있습니다.
이렇게 정의의 차이가 발생하는 이유는, 아래 다이어그램에서 표현하고 있는 것과 같이, 각각의 테스트가 명확하게 완전히 분리된 성질을 가지기 보다는, 어느 정도는 서로간에 공통점을 공유하는 특성 때문에 발생되는 상황 때문이라고 이해할 수 있을 것 같습니다.
Source: A Survey on Load Testing of Large-Scale Software Systems
참고로, 위에서 언급된 ‘Volume Testing’과 ‘Scalability Testing’을 포함한 성능 테스트 유형에 대한 추가적인 설명은, 여기 Tech Blog의 Performance 관련 글 중 “Introduce to Performance test(4/5)”에서도 ‘테스트 시나리오’ 부분에 잘 정리되어 있으니 참고하시기 바랍니다.
이상으로, 성능테스트 유형의 정의에 대한 내용들을 개략적인 수준에서 살펴보았습니다. 이번 글에서는 ‘생각보다 많은 성능테스트의 종류’와, ‘용어를 정의하는 자료마다 다른 뉘앙스의 차이’가 주는 약간의 당황스러움을 경험해볼 수 있었습니다. 하지만, 실제 업무 수행시에는 우리가 성능테스트 계획을 수립하면서 성능 테스트 용어와 그 정의를 앞부분에서 명확히 기술한 이후에 테스트를 수행해 나가기 때문에, 진행하고자 하는 성능테스트의 개념에 큰 혼동없이 나아갈 수 있는 부분이라고 생각합니다.
또한, 이후 인터넷 검색을 통해 조금 다른 뉘앙스의 정의가 나오더라도, ‘이건 틀렸어’, ‘저건 맞아’라는 식으로 접근하기 보다는, ‘여기서는 어떤 목적으로 이렇게 유형을 나누고 정의했을까?’를 가만히 생각해 본다면, 유형 구분에 숨겨진 각 회사들의 테스트 접근 방법 및 실제 적용 케이스를 이해하는데 있어 어느정도는 도움을 얻게 되지 않을까 싶습니다.
[끝]