부하테스트는 크게 아래 네가지의 프로세스 흐름을 가집니다.
- 부하 테스트 계획
- 부하 테스트 스크립트 작성
- 부하 테스트 실행
- 부하 테스트 결과 분석
명확성을 위해 이렇게 단계적으로 표시되어 있지만 실제로는 종종 겹치는 경우도 많습니다. 애플리케이션 릴리즈 프로세스에서 처럼, 테스팅 프로세스도 지속적이고 민첩하게(Agile) 진행되어야 하며, 이전 작업을 기반드로 작은 단계가 추가될 때마다 시간이 지남에 따라 전점 더 견고해져야 합니다.
애플리케이션 코드처럼 테스트는 느리게 시작합니다. 산의 꼭대기에서, 가장 간단한 형태로 테스트가 진행됩니다. 초기 단계 테스트는 주로 위험에 기반한 것으로 생각할 수 있습니다. 이 수준의 테스트는 실패 가능성에 대한 실패 가능성에 대한 반응입니다. 이러한 테스트는 애플리케이션의 가장 중요한 구성 요소의 오류를 방지하기 위해 특별히 작성되며. 다른 테스트에는 충분한 시간이 없을 수 있습니다.
프로젝트 내에서 테스트가 성숙해지면 회귀를 포함하기 시작할 수 있습니다. 이제 모든 고위험 영역이 다루어졌으므로 팀은 테스트를 좀 더 이전 버전과 호환되고 예방적으로 만들 시간이 생겼으며, 새로운 코드가 과거 기능을 손상시키는지 확인하기 위해 테스트를 작성합니다.
Continuous Testin Snowball은 테스트 suite와 함께 팀이 성장함에 따라 속도가 빨라지며, 반복 또는 스프린트할 때마다 테스트 프로세스의 점점 더 많은 부분을 자동화하는데 집중합니다. 반복 가능한 프레임워크가 확립됩니다. 이 단계에서 스노우볼은 가장 빠른속도로 진행됩니다.
마지막으로 지속적인 테스트는 팀이 특정 결함을 해결하는 것에서 예기치 않은 이벤트를 견딜 수 있는 애플리케이션의 전반적인 안정성과 신뢰도를 높이는 것으로 초점을 확장할 수 있을 정도로 테스트를 발전시켰습니다. 이 프레임 워크는 카오스 엔지니어링과 같은 보다탐색적인 유형의 테스트를 통해 더욱 강력해졌습니다.
지속적 테스트의 초점은 애플리케이션과 병행하여 테스트 suite를 유기적이고 반복적으로 발전시키는 것이며, 더 견고해질 때까지 충분히 점진적으로 변경하는 것을 목표로 작은 것부터 시작하여 테스트 suite를 발전시키는 것입니다.
1. Planing for load testing
부하테스트를 계획하는 것은 프로세스의 첫번째 파트입니다. 왜 테스트를 해야하는지를 인지하고, 무엇을 테스트해야 하는지를 대상을 찾고, 일반적으로 어떻게 테스트 할지 개략적으로 설명하는 작업이 포함됩니다. 이 페이즈에서, 우리는 부하 테스트에 대한 요구사항을 다음과 같이 정리합니다.
- 테스트의 범위를 명확히 하기
- SLO 정의
- 워크로드 모델 식별
- 모니터링을 포함한 테스트 환경 설정
- 테스트 빈도 및 일정에 대한 합의
- 해당되는 경우 테스트 데이터 준비
모든 테스트에 대한 계획은 팀활동이며 부하 테스트도 예외는 아닙니다. 이 단계는 모든 이해관계자가 함께 모여 테스트의 모습과 성공적인 테스트 라운드를 정의 할 수 있는 요소를 이해할 수 있는 기회입니다.
2. Scripting a load test
부하 테스트의 스크립트를 작성하는 것은 테스트 계획을 실행가능한 테스트로 변환하는 작업이 포함됩니다. 이 단계에서는 다음 중 일부를 수행할 수 있습니다.
- 요구 사항을 적절히 충족하는 테스트 시나리오 만들기
- 부하 테스트 도구글 사용하여 테스트 스크립트 작성
- 스크립트를 현실적으로 만들기
- shakeout test를 실행하여 스크립트가 예상대로 작동하는지 확인
- 개발 환경에 대한 테스트 실행
- 팀과 테스트 스크립트 공유
- 테스트 suite와 함께 성장할 수 있는 테스트 프레임워크 설정
스크립팅 중에 테스트를 실행할 수 있지만, 일반적으로 전체 부하 테스트 보다는 디버깅 또는 쉐이크 아웃을 목적으로 사용합니다. 테스트 실행 중에 발견된 문제를 해결하기 위해 기존 스크립트를 변경하거나 새 스크립트를 작성할 때 스크립팅 단계가 테스트 실행 단계로 넘어갈 수 있습니다.
3. Executing load tests
테스트 실행 중에 부하 테스트 스크립트는 의도한 대상(테스트 환경 또는 프로덕션)에 대해 실행됩니다. 다음 몇가지를 수행할 수 있습니다.
- 클라우드 또는 온프로레미스 인프라 설정
- 통합 가시성 도구를 성정하여 애플리케이션 서버 및 부하 생성기 상태를 모니터링합니다,
- Shakeout tset를 실행하여 테스트 환경이 예상대로 작동하는지 확인합니다.
- Baseline test를 실행하여 현재 시트템 동작을 이해합니다.
- 코드 또는 환경을 변경하고 테스틀르 실행하여 baseline test와 비교합니다.
- 테스트의 범위를 늘립니다.
- 부하 테스트를 늘리거나 확장해서 분산 테스트를 수행합니다.
부하 테스트를 실행하는 것은 단순히 테스트를 실행하는 것 이상의 의미를 갖습니다. 시스템의 상태와 테스트의 상태를 모니터링할 수 있는 적절한 통합 가시성 도구가 없다면 테스트 자체는 도움이 되지 않을 수 있기 때문입니다.
4. Analysis of load testing results
분석 페이즈에서는 아래 목록들 중 일부를 수행할 수 있습니다.
- 애플리케이션 서버와 부하 generator 에서 데이터 수집합니다.
- 데이터를 집계하여 테스트 중에 발생한 상황을 전체적으로 파악합니다.
- 데이터 시각화 및 분석도구를 사용해서 테스트 족너에서 시스템이 어떻게 작동했는지 확인합니다.
- 이해 관계자에게 결과를 보고합니다.
- 병목현상을 해결합니다.
- 테스트를 다시 실행하여 문제 또는 수정사항을 확인합니다.
테스트 중에 수집한 데이터를 사용해서 다양한 테스트 조건에서 시스템이 어떻게 작동하는지 이해하는 것은 부하테스트의 가치를 높이는 데큰 역할을 합니다. 데이터를 객관적으로 검토하고 그 결과를 이해하기 쉬운 방식으로 팀에 전달하는 것이 중요합니다.
5. Continuous load testing
지속적인 부하 테스트는 모튼 테스트 페이즈를 포괄하는 활동입니다. 지속적인 테스트를 할 때 다음과 같이 할 수 있습니다.
- 버전이 제어되는 레파지토리에 부하 테스트 스크립트 추가
- CI/CD 파이프라인에 부하 테스트 통합
- 보고 자동화
- 실패한 테스트에 대한 알림 설정
- 코드 변경 또는 릴리즈 주기와 연계된 부하 테스트 실행을 위한 반복 가능한 프레임워크 설정
- 테스트 결과를 데이터베이스에 캡쳐하여 과거 추세 보기
지속적인 부하테스트를 수행하지 않으면 부하 테스트가 일회성 프로세스가 될 수 있습니다. 기존 CI/CD 파이프라인에 통합하면 관련된 모든 사람이 성능을 최우선으로 고려할 수 있습니다.
테스트 스위트의 성숙도와 범위가 커짐에 따라 팀은 자연스럽게 테스트 실행, 관리, 결과 분석 및 보고를 위한 보다 효율적인 프레임워크를 만들어야합니다. 이런 방식으로 테스트는 일반적으로 애플리케이션의 가장 중요하거나 위험도가 높은 기능을 중심으로 매우 간단하게 시작한 다음 애플리케이션과 함께 유기적을 발전하고 개선할 수 있습니다.
출처: