Performance Test Process

#1. Requirement Analysis/Gathering

성능 팀은 고객과 상호 작용하여 기술 및 비즈니스 요구 사항을 파악하고 수집합니다. 여기에는 응용 프로그램의 아키텍처, 사용된 기술 및 데이터베이스, 의도된 사용자, 기능, 응용 프로그램 사용법, 테스트 요구 사항, 하드웨어 및 소프트웨어 요구 사항 등에 대한 정보가 포함됩니다.

 

#2. POC/Tool selection

핵심 기능이 확인되면 POC (실시간 활동에 대한 일종의 시연이지만 제한된 의미에서의 사용)은 사용 가능한 도구로 수행됩니다. 사용 가능한 도구 목록은 도구 비용, 응용 프로그램이 사용하는 프로토콜, 응용 프로그램을 작성하는데 사용된 기술, 테스트를 위해 시뮬레이트하는 사용자 수 등에 따라 다릅니다. POC 중에 식별된 키에 대한 기능과 10-15 명의 가상 사용자와 함께 실행되도록 스크립트가 작성됩니다

 

#3. Performance Test Plan & Design

이전 단계에서 수집된 정보에 따라 테스트 계획 및 설계가 수행됩니다.
테스트 계획에는 테스트 환경, 작업 부하, 하드웨어 등 성능 테스트의 수행 방법에 대한 정보가 포함됩니다.
아래의 테스트 전략 문서에 대해 자세히 설명합니다.

 

#4. Performance Test Development

- 테스트 계획에서 식별된 기능에 대한 사용 사례가 PT 범위로 작성됩니다.
- 이러한 사용 사례는 승인을 위해 클라이언트와 공유됩니다. 이것은 스크립트가 올바른 단계로 기록되는지 확인하는 것입니다.
- 일단 승인되면 스크립트 개발은 POC (Proof of Concepts) 중에 선택된 성능 테스트 도구로 유스 케이스의 단계를 기록을 시작하여 상관 관계 분석 (동적값 처리), 매개 변수화(값 대체) 및 사용자 지정 함수를 수행하게 됩니다. 
- 스크립트는 다른 사용자에 대해 유효성이 검사됩니다.
- 스크립트 작성과 병행하여 성능 팀은 테스트 환경 (소프트웨어 및 하드웨어)의 설정 작업을 계속 수행합니다.
- 성능 팀은 클라이언트에 의해 채택되지 않으면 스크립트를 통해 메타 데이터 (백엔드)를 관리합니다.

 

#5. Performance Test Modeling

성능 실행 모델은 테스트 실행을 위해 생성됩니다. 이 단계의 주된 목표는 테스트 중에 클라이언트가 제공한 성능 메트릭이 달성되었는지 여부를 확인하는 것입니다. 실행 모델을 작성하는 데는 여러 가지 방법이 있습니다. "리틀의 법칙(“Little's Law”)"은 대부분의 경우에 사용됩니다.

 

#6. Test Execution

이 시나리오는 컨트롤러 또는 성능 센터의 모델 로드에 따라 설계되었지만 초기 테스트는 로드 모델에 있는 최대 사용자와 함께 실행되지 않습니다.
테스트 실행은 점진적으로 수행됩니다. 예 : 최대 사용자 수가 100 명인 경우 시나리오는 처음에 10 명, 25 명, 50 명 등으로 실행되어 결국 100 명의 사용자로 이동합니다.

 

#7. Test Results Analysis

테스트 결과는 성능 테스터에게 가장 중요한 결과물입니다. 이것이 우리가 ROI (Return on Investment) 및 성능 테스트 노력이 제공 할 수 있는 생산성을 증명할 수 있는 곳입니다.

결과 분석 프로세스를 돕는 몇 가지 모범 사례 :
a) 모든 시험 결과에 대해 의미있는 이름 - 시험 목적을 이해하는 데 도움이됩니다.
b) 테스트 결과 요약에 다음 정보를 포함시킵니다.

- 실패 이유 
- 이전 테스트 실행과 비교하여 응용 프로그램의 성능이 변경되었습니다.
- 응용 프로그램 빌드 또는 테스트 환경에서 테스트의 변경 사항.
- 각 테스트 실행 후에 결과 요약을 작성하여 테스트 결과를 참조 할 때마다 분석 결과가 컴파일되지 않도록 하는 것이 좋습니다.
- PT는 일반적으로 올바른 결론에 도달하기 위해 많은 테스트가 필요합니다.
- 결과 요약에 다음 사항을 포함하는 것이 좋습니다.
  - 시험 목적
  - 가상 사용자 수
  - 시나리오 요약
  - 시험 기간
  - 처리량
  - 그래프
  - 그래프 비교
  - 응답 시간
  - 오류 
  - 권장 사항

 

#8. Report

테스트 결과는 단순화 되어야 결론이 명확해지며 파생이 필요하지 않습니다. 개발 팀은 분석, 결과 비교 및 결과 획득 방법에 대한 자세한 정보가 필요합니다.
시험 보고서는 간략하고 설명 적이며 요점이 맞다면 좋은 것으로 간주됩니다.