성능 테스트, 부하 테스트, 스트레스 테스트에 대해 알아보자

성능 테스트 (Performance Test)

성능 테스트는 시스템 구성 요소가 특정 상황에서 어떤 성능을 보이는지 확인하기 위해 수행되는 테스트이다. 제품의 리소스 사용, 확장성 및 안정성도 이 테스트를 통해 검증할 수 있다.

 

성능 테스트는 기본적으로 매우 광범위하다. 다음 그림은 성능 테스트가 부하 및 스트레스 테스트 모두에 대한 상위 집합임을 보여준다. 그 외에도 스파이크 테스트, 볼륨 테스트, 내구성 테스트 및 확장성 테스트가 하위 집합으로 존재한다.

성능 테스트 중에 충족되어야하는 벤치 마크가 업계별로 많이 존재하는 데 해당 시스템의 벤치 마크 수준으로 시스템을 동작시키는 것이 성능 테스트의 주요 목표이다.

 

 

성공적인 성능 테스트는 데이터베이스, 네트워크, 소프트웨어, 하드웨어 등과 관련 될 수있는 대부분의 성능 문제를 예측해야 한다.

 

부하 테스트 (Load Test)

부하 테스트는 성능 테스트의 하위 집합으로, 임계치 한계에 도달 할 때까지 시스템의 부하를 지속적으로 지속적으로 증가시켜 시스템을 테스트하는 것을 의미한다. 부하 테스트의 유일한 목적은 시스템의 내구성을 테스트하고 결과를 모니터링하기 위해 처리 할 수 있는 가장 큰 작업을 시스템에 할당하는 것이다. 여기서 흥미로운 사실은 때때로 무부하 상황에서 시스템의 동작을 결정하기 위해 시스템에 빈 작업이 공급된다는 것이다.

 

부하 테스트에서 모니터링되는 속성에는 최대 성능, 서버 처리량, 다양한 부하 수준 (중단 임계 값 미만)에서의 응답 시간, H / W 환경의 적절성, 성능에 영향을주지 않고 처리 할 수있는 사용자 애플리케이션 수 등이 있습니다.

 

부하 테스트 목표

• 버퍼 오버플로, 메모리 누수 및 메모리 관리 오류와 관련된 애플리케이션의 결함 노출 로드 테스트의 결과로 결국 나올 문제에는 로드 밸런싱 문제, 대역폭 문제, 기존 시스템의 용량 등이 포함될 수 있다.
• 애플리케이션이 향후 예상되는 로드를 관리 할 수 ​​있도록 데이터베이스, 하드웨어, 네트워크 등과 같은 애플리케이션의 모든 구성 요소에 대한 상한을 결정한다.
• 애플리케이션에 대한 SLA(Service Level Agreement)를 설정한다.

 

스트레스 테스트 (Stress Test)

스트레스 테스트를 통해 기존 자원에 과잉 작업을 과부하시키는 다양한 활동을 수행하여 시스템을 무너뜨리는 시도를 한다.

• 네거티브 테스트: 시스템에서 구성 요소를 제거하는 작업도 스트레스 테스트의 일부로 수행된다.
• 피로 테스트: 이 테스트는 대역폭 용량을 넘을 정도로 테스트하여 애플리케이션의 안정성을 포착해야 한다.
• 따라서 기본적으로 스트레스 테스트는 최대 부하 및 정상 조건을 넘어서는 애플리케이션의 동작을 평가한다.

 

스트레스 테스트의 목적은 시스템의 오류를 확인하고 시스템이 어떻게 정상적으로 복구되는지 모니터링하는 것이다. 여기서 문제는 테스트를 시작하기 전에 제어 된 환경을 설정하여 가장 예측할 수없는 시나리오에서 반복적으로 시스템의 동작을 정확하게 캡처 할 수 있도록 하는 것이다.

 

스트레스 테스트의 결과로 결국 나올 문제에는 동기화 문제, 메모리 누수, 경쟁 조건 등이 포함될 수 있다.

• 스트레스 테스트가 사용자 수가 갑자기 증가하는 상황에서 시스템이 어떻게 작동하는지 확인하는 경우를 스파이크 테스트라고 한다.
• 스트레스 테스트가 사용자 수의 느린 증가를 통해 일정 기간 동안 시스템의 지속 가능성을 확인하는 것이라면 흡수 테스트라고 한다.

 

스트레스 테스트 목표 

스트레스 테스트의 목표는 충돌 후 보고서를 분석하여 실패 후 애플리케이션의 동작을 정의하는 것이다. 가장 큰 문제는 장애 발생 후 시스템이 민감한 데이터의 보안을 손상시키지 않도록하는 것입니다. 성공적인 스트레스 테스트에서 시스템은 가장 끔찍한 고장 후에도 모든 구성 요소와 함께 정상 상태로 돌아온다

 

JMeter Stepping Thread Group으로 성능 테스트 실행하기

한 번에 1000 명의 사용자가 요청을 보낼 수 있는 앱의 이메일 기능을 확인해 보자. 이제 1000 명의 사용자가 다양한 방법으로 이메일 트랜잭션 (읽기, 보내기, 삭제, 전달, 회신)을 실행할 수 있다.

 

사용자 당 시간당 하나의 트랜잭션을 수행하면 시간당 1000개의 트랜잭션이 수행된다. (10개의 트랜잭션/사용자)를 시뮬레이션하여 시간당 10000개의 트랜잭션을 차지하여 이메일 서버를 로드 테스트 할 수 있다.

 

Stepping Thread Group 설치 방법

1. https://jmeter-plugins.org/?search=jpgc-casutg에 접속하여 신버전을 다운받는다.
2. 압축 해제 후 /apache-jmeter-5.4.3/lib 에 복사한다.
3. Jmeter를 재실행하면 Stepping Thread Group이 추가된 것을 확인할 수 있다.

 

 

설정 값은 다음과 같다.

• [ this group will start ] 해당 그룹에서 최대 생성되는 Thread 개수
• [ Next, add ] 추가되는 Thread의 수 몇 개씩 더해질 것인가
• [ threads every ] Thread 추가되는 시간 간격(s)
• [ using ramp-up ] Thread가 추가되는데 걸리는 시간(s)
• [ Then hold load for ] 최대 쓰레드가 유지되는 시간(s)
• [ Finally, stop ] Thread가 몇 개씩 줄어들 것인가
• [ threads every ] Thread가 줄어드는데 걸리는 시간(s)

 

부하 테스트 예시

이 테스트는 시스템에서 처리 할 수있는 사용자 수를 식별하기 위해 수행된다.

• 이 테스트에서는 부하가 1,000명의 사용자에 도달 할 때까지 매 30초마다 100명의 사용자가 추가된다. 100명이 추가되는 데 걸리는 시간은 10초이다. (1초당 10개의 쓰레드씩 추가)
• JMeter는 다음 단계를 시작하기 전에 30초 동안 대기한다
• 쓰레드 로드가 1000개의 스레드에 도달하면 모든 스레드가 300초(5분)동안 계속 실행된다.
• 이후 3초마다 10개씩 스레드를 중지시킨다.

 

부하 테스트

 

 

스파이크 테스트 예시

예를 들어 OpenOffice.org의 Writer1.1.0과 같은 워드 프로세서는 편지, 프리젠 테이션, 스프레드 시트 등의 개발에 사용된다. 스트레스 테스트의 목적은 초과 문자로 로드하는 것이다. 이를 위해 많은 양의 텍스트를 처리하는 임계치 한계에 도달 할 때까지 데이터 줄을 반복해서 붙여 넣는다. 문자 크기가 65,535 자에 도달하면 더 이상 데이터를 입력받지 않게 된다.

 

Writer 1.1.0에 대한 스트레스 테스트 결과 스트레스로 인해 충돌이 발생하지 않는 결과를 생성하고 상황을 우아하게 처리하여 엄격한 스트레스 조건에서도 응용 프로그램이 올바르게 작동하는지 확인한다.

 

Jmeter로 7000 명의 갑작스러운 사용자 증가를 통한 스파이크 테스트를 묘사하는 부하 테스트의 또 다른 예이다.

• 이 테스트에서는 스파이크 테스트로 실행되고나서 5초 후 7,000명이 사용자가 추가된다.
• 이후 매 30초마다 100명이 사용자가 추가된다. 100명이 추가되는 데 걸리는 시간은 10초이다. (1초당 10개의 쓰레드씩 추가)
• JMeter는 다음 단계를 시작하기 전에 30초 동안 대기한다.
• 쓰레드 로드가 10,000개의 스레드에 도달하면 모든 스레드가 300초(5분)동안 계속 실행된다.
• 이후 1초마다 10개씩 스레드를 중지시킨다.

 

스파이크 테스트

 

 

성능, 부하, 스트레스 테스트 비교

 

	성능 테스트	부하 테스트	스트레스 테스트
도메인	부하 및 스트레스 테스트의 상위 집합	성능 테스트의 하위 집합	성능 테스트의 하위 집합
범위	매우 넓은 범위 하위 집합 - {부하 테스트, 스트레스 테스트, 용량 테스트, 볼륨 테스트, 내구성 테스트, 스파이크 테스트, 확장 성 테스트 및 안정성 테스트 등}	성능 테스트에 비해 범위가 좁다. 볼륨 테스트 및 내구성 테스트를 포함한다.	성능 테스트에 비해 범위가 좁다. soak 테스트 및 스파이크 테스트를 포함한다.
주요 목표	애플리케이션 성능을 벤치 마크 및 표준에 맞춘다.	시스템의 상한선을 식별하려면 앱의 SLA를 설정하고 시스템이 과부하 볼륨을 처리하는 방법을 확인한다.	과부하에서 시스템이 작동하는 방식과 장애로부터 복구하는 방식을 테스트하면서 알아낸다. 앱이 기본적으로 예기치 않은 트래픽 급증에 다운되지 않도록 대비한다.
부하 제한	임계치 이전과 초과된 경우 모두 검사	임계치 이전까지 검사	임계치를 초과한 경우 검사
학습된 속성	리소스 사용량, 안정성, 확장성, 리소스 사용량, 응답 시간, 처리량, 속도 등	과부하 수준에서 최대 성능, 서버 처리량, 응답 시간 (임계치 값 미만), H/W 환경의 적절성, 처리 할 수 있는 사용자 앱 수, 부하 분산 요구 사항 등	대역폭 용량, 응답 시간 이상의 안정성 (임계치 값 초과)
얻은 결과	런타임 팽창, 최적화 범위, 속도, 지연 시간, 처리량 등과 관련된 문제를 포함한 모든 성능 버그. 기본적으로 – 성능과 관련된 모든 것!	부하 분산 문제, 대역폭 문제, 시스템 용량 문제, 응답 시간 부족, 처리량 문제 등	과부하, 과부하 상황에서의 데이터 손상 문제, 속도 저하, 메모리 누수 등의 보안 허점

 

---

참고

https://techblog.woowahan.com/2572/

https://www.softwaretestinghelp.com/what-is-performance-testing-load-testing-stress-testing/