성능테스트 시나리오 - seongneungteseuteu sinalio

complete performance testing guide with examples

성능 테스트 란 무엇입니까?

성능 테스트는 '성능 테스트'라고도하며 응답 성 및 안정성 측면에서 애플리케이션 또는 소프트웨어가 워크로드에서 어떻게 수행되는지 확인하기 위해 수행되는 테스트 유형입니다. 성능 테스트의 목표는 애플리케이션에서 성능 병목 현상을 식별하고 제거하는 것입니다.

이 테스트는 주로 소프트웨어가 애플리케이션 속도, 확장 성 및 안정성에 대한 예상 요구 사항을 충족하는지 확인하기 위해 수행됩니다.

이 튜토리얼 시리즈에서는 성능 테스트 유형, 프로세스 및 성능 테스트 전략 작성 문서와 같은 완전한 세부 사항을 처음부터 다룰 것입니다.

.torrent 파일로 수행 할 작업

이것은 북마크에 추가 할 수있는 상세한 튜토리얼 시리즈입니다!

탐험 해 봅시다!

이 시리즈의 모든 성능 테스트 자습서 목록 :

튜토리얼 # 1 : 성능 테스트 완료 가이드 (이 튜토리얼)
튜토리얼 # 2 : 성능, 부하 및 스트레스 테스트의 차이
튜토리얼 # 3 : 기능 테스트 대 성능 테스트
튜토리얼 # 4 : 성능 테스트 계획 및 테스트 전략
튜토리얼 # 5 : 성능 테스트를 강화하는 방법
튜토리얼 # 6 : 클라우드 성능 테스트 가이드
튜토리얼 # 7 : 모바일 앱 성능 테스트 가이드
튜토리얼 # 8 : 수동 성능 테스트를 수행하는 방법
튜토리얼 # 9 : 웹 사이트 성능 테스트 자습서
튜토리얼 # 10 : 성능 테스트 회사
튜토리얼 # 11 : LoadRunner를 사용한 성능 테스트 (시리즈)

도구 :

튜토리얼 # 12 : 최고의 성능 테스트 도구
튜토리얼 # 13 : Neoload 성능 테스트 튜토리얼
튜토리얼 # 14 : BlazeMeter 모바일 성능 테스트 자습서
튜토리얼 # 15 : WAPT 부하, 스트레스 및 성능 테스트 튜토리얼
튜토리얼 # 16 : SmartMeter.io 웹 사이트 성능 테스트 튜토리얼

학습 내용 :

• 성능 테스트 유형
  • 부하 테스트
  • 스트레스 테스트
  • 볼륨 테스트
  • 용량 테스트
  • 신뢰성 / 복구 테스트
• 성능 테스트 프로세스
• 성능 테스트 전략 문서를 작성하는 방법?
  • 샘플 성능 테스트 전략 템플릿
  • #1. 소개
    • 객관적인
    • 건축물
  • # 2) 범위
    • 범위 내
    • 범위 외
  • # 3) 접근
    • 성능 테스트 시나리오
    • 성능 테스트 유형
    • 성능 지표
    • 성능 테스트 활동 및 결과물
  • # 4) 테스트 데이터
  • # 5) 입장 및 퇴장 기준
  • # 6) 결함 관리
    • 결함 심각도 정의
  • # 7) 테스트 도구 및 기법
  • # 8) 일시 중지 및 재개 기준
  • # 9) 테스트 결과물
  • # 10) 역할 및 책임
  • # 11) 잠재적 위험 및 완화 계획
  • # 12) 가정
  • # 13) 종속성
  • # 14) 약어
• 현실적인 성능 테스트를위한 모범 사례
  • # 1) 계획
  • # 2) 개발
  • # 3) 실행
  • # 4) 분석
  • 결론
  • 추천 도서

성능 테스트 유형

부하 테스트

부하 테스트는 정상 및 최대 사용량에서 응용 프로그램의 성능을 테스트하는 성능 테스트 유형입니다. 응용 프로그램의 성능은 사용자 요청에 대한 응답 및 다양한 사용자로드에 대해 허용 된 허용 오차 내에서 일관되게 응답하는 기능과 관련하여 확인됩니다.

주요 고려 사항은 다음과 같습니다.

1. 애플리케이션이 예기치 않게 작동하기 전에 애플리케이션이 보유 할 수있는 최대로드는 얼마입니까?
2. 시스템이 느려지거나 충돌이 관찰되기 전에 데이터베이스가 처리 할 수있는 데이터의 양은 얼마입니까?
3. 해결해야 할 네트워크 관련 문제가 있습니까?

스트레스 테스트

스트레스 테스트는 시스템을 파괴하는 방법을 찾는 데 사용됩니다. 이 테스트는 시스템이 견딜 수있는 최대 부하 범위도 제공합니다.

일반적으로 스트레스 테스트에는 부하가 점진적으로 증가하는 점진적 접근 방식이 있습니다. 테스트는 애플리케이션이 이미 테스트 된 부하로 시작됩니다. 그런 다음 시스템에 스트레스를주기 위해 더 많은 부하가 천천히 추가됩니다. 요청에 응답하지 않는 서버를보기 시작하는 지점이 중단 점으로 간주됩니다.

다음 질문에 답해야합니다.

• 시스템이 고장 나기 전에 견딜 수있는 최대 부하는 얼마입니까?
• 시스템이 어떻게 고장 나나요?
• 시스템이 중단 된 후 복구 할 수 있습니까?
• 시스템이 몇 가지 방법으로 중단 될 수 있으며 예기치 않은로드를 처리하는 동안 약한 노드는 무엇입니까?

볼륨 테스트

볼륨 테스트는 애플리케이션의 성능이 애플리케이션에서 처리하는 데이터 볼륨의 영향을받지 않는지 확인하는 것입니다. 볼륨 테스트를 실행하기 위해 엄청난 양의 데이터가 데이터베이스에 입력됩니다. 이 테스트는 증분 또는 꾸준한 테스트 일 수 있습니다. 증분 테스트에서는 데이터 볼륨이 점진적으로 증가합니다.

일반적으로 응용 프로그램 사용에 따라 데이터베이스 크기가 커지고 무거운 데이터베이스에 대해 응용 프로그램을 테스트해야합니다. 이에 대한 좋은 예는 초기에 저장할 데이터 양이 적은 새 학교 또는 대학의 웹 사이트 일 수 있지만 5-10 년 후에는 웹 사이트 데이터베이스의 데이터 저장소가 훨씬 더 많아집니다.

용량 테스트

=> 애플리케이션이 정상 및 최대 부하 조건에서 비즈니스 볼륨을 충족 할 수 있습니까?

용량 테스트는 일반적으로 향후 전망을 위해 수행됩니다. 용량 테스트는 다음을 처리합니다.

1. 애플리케이션이 향후로드를 지원할 수 있습니까?
2. 환경이 다가오는 증가하는 부하를 감당할 수 있습니까?
3. 환경을 충분히 가능하게 만드는 데 필요한 추가 리소스는 무엇입니까?

용량 테스트는 주어진 웹 애플리케이션이 지원하고 여전히 성능을 충족시킬 사용자 및 / 또는 트랜잭션 수를 결정하는 데 사용됩니다. 이 테스트 중에 프로세서 용량, 네트워크 대역폭, 메모리 사용량, 디스크 용량 등과 같은 리소스를 고려하여 목표를 충족하도록 변경합니다.

온라인 뱅킹은 용량 테스트가 중요한 역할을 할 수있는 완벽한 예입니다.

신뢰성 / 복구 테스팅

안정성 테스트 또는 복구 테스트 – 장애 또는 비정상적인 동작 후 애플리케이션이 정상 상태로 돌아갈 수 있는지 여부와이를 수행하는 데 걸리는 시간 (즉, 시간 추정)을 확인하는 것입니다.

온라인 거래 사이트에서 사용자가 하루 중 특정 시점 (피크 시간)에 주식을 매수 / 매도 할 수 없지만 1 ~ 2 시간 후에 할 수있는 오류가 발생하는 경우 애플리케이션이 신뢰할 수 있다고 말할 수 있습니다. 비정상적인 행동에서 회복되었습니다.

성능 테스트 프로세스

이 테스트에서 수행 된 모든 활동은 다음과 같습니다.

# 1) 요구 사항 분석 / 수집

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

# 2) POC / 도구 선택

주요 기능이 식별되면 POC (개념 증명 – 실시간 활동의 일종의 시연이지만 제한된 의미에서)는 사용 가능한 도구로 수행됩니다.

사용 가능한 도구 목록은 도구 비용, 응용 프로그램이 사용하는 프로토콜, 응용 프로그램을 빌드하는 데 사용 된 기술, 테스트를 위해 시뮬레이션하는 사용자 수 등에 따라 다릅니다. POC 중에 식별 된 키에 대한 스크립트가 생성됩니다. 10-15 명의 가상 사용자로 실행됩니다.

# 3) 성능 테스트 계획 및 설계

이전 단계에서 수집 된 정보에 따라 테스트 계획 및 설계가 수행됩니다.

테스트 계획에는 테스트 환경, 워크로드, 하드웨어 등 성능 테스트가 수행되는 방법에 대한 정보가 포함됩니다.

아래의 테스트 전략 문서에 대해 자세히 알아보십시오.

# 4) 성능 테스트 개발

• 테스트 계획에서 PT 범위로 식별 된 기능에 대한 사용 사례가 생성됩니다.
• 이러한 사용 사례는 승인을 위해 클라이언트와 공유됩니다. 이는 스크립트가 올바른 단계로 기록되는지 확인하기위한 것입니다.
• 승인되면 스크립트 개발은 POC (개념 증명) 중에 선택한 성능 테스트 도구를 사용하여 사용 사례의 단계를 기록하는 것으로 시작되고 상관 관계 (동적 값 처리 용), 매개 변수화 (값 대체) 및 사용자 지정 함수를 다음과 같이 수행하여 향상됩니다. 상황이나 필요에 따라. 비디오 자습서에서 이러한 기술에 대해 자세히 알아보십시오.
• 그런 다음 스크립트는 다른 사용자에 대해 유효성을 검사합니다.
• 스크립트 생성과 병행하여 성능 팀은 테스트 환경 (소프트웨어 및 하드웨어) 설정 작업도 계속 진행합니다.
• 성능 팀은 또한 클라이언트가이 활동을 수행하지 않는 경우 스크립트를 통해 메타 데이터 (백엔드)를 처리합니다.

# 5) 성능 테스트 모델링

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

# 6) 테스트 실행

시나리오는 Controller 또는 Performance Center의 Load Model에 따라 설계되었지만 Load 모델에있는 최대 사용자로 초기 테스트가 실행되지 않습니다.

테스트 실행은 점진적으로 수행됩니다. 예를 들어, 최대 사용자 수가 100 인 경우 시나리오는 먼저 10, 25, 50 명의 사용자로 실행되고 결국 100 명의 사용자로 이동합니다.

# 7) 테스트 결과 분석

테스트 결과는 성능 테스터에게 가장 중요한 결과물입니다. 여기에서 성능 테스트 노력이 제공 할 수있는 ROI (투자 수익률)와 생산성을 증명할 수 있습니다.

결과 분석 프로세스에 도움이되는 몇 가지 모범 사례 :

1. 모든 테스트 결과에 고유하고 의미있는 이름 – 이는 테스트의 목적을 이해하는 데 도움이됩니다.
2. 테스트 결과 요약에 다음 정보를 포함하십시오.

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

# 8) 신고

결론이 더 명확하고 파생이 필요하지 않도록 테스트 결과를 단순화해야합니다. 개발 팀은 분석, 결과 비교 및 ​​결과 획득 방법에 대한 자세한 정보가 필요합니다.

테스트 보고서가 간단하고 설명 적이며 요점을 알면 좋은 것으로 간주됩니다.

성능 테스트 전략 문서를 작성하는 방법?

이 튜토리얼에서는 메시징 애플리케이션에 대한 샘플 성능 테스트 전략을 작성하는 방법을 설명합니다.

이것은 단지 예일 뿐이며 요구 사항은 클라이언트마다 다를 수 있으며이 자습서에서는 성능 테스트에 대한 모범 사례도 알게 될 것입니다.

샘플 성능 테스트 전략 템플릿

ABC 채팅 신청 정보 – 이것이 회사에서 고객 지원 에이전트가 사용하는 채팅 워크 벤치라고 가정 해 보겠습니다.이 채팅 애플리케이션은 XMPP 프로토콜 (예 : Extensible Messaging and Presence Protocol 및 Open Fire 서버를 사용하여 인스턴트 메시지를 보내고받는 데 사용)을 사용합니다.

원격 PC 제어, PC 진단, 수리 도구, 온라인 채팅 등과 같은 기존 채팅 클라이언트가 일부 개선되었으므로이 성능 테스트 전략은 이러한 응용 프로그램의 샘플입니다.

이 응용 프로그램의 경우 프로젝트 팀이 JMeter 성능 테스트 및 지라 결함 추적을 위해.

C ++ 순환 연결 목록

성능 테스트 전략 문서의 첫 페이지에는 문서 제목과 회사의 저작권이 포함되어야합니다.

두 번째 페이지에는 문서 버전 기록, 검토 자 및 승인자 목록 및 기여자 목록이 포함 된 문서 제어가 포함되어야합니다.

세 번째 페이지에는 목차와 아래 항목이 포함되어야합니다.

#1. 소개

이 문서의 목적은 현재 및 미래 상태에 대해 ABC 채팅 응용 프로그램에서 성능 테스트가 수행되는 방법을 정의 / 설명하는 것입니다.

ABC 채팅 애플리케이션은 사내 원격 지원 에이전트 워크 벤치입니다. 이 워크 벤치는 고객 요청을 이행하는 데 사용됩니다. 이 Workbench에는 온라인 채팅, 고객 식별, 원격 PC 제어, PC 진단 및 수리 도구와 같은 기능이 있습니다.

객관적인

성능 테스트의 주요 목표는 다음과 같습니다.

• 기존 채팅 응용 프로그램의 변경 사항이 정의 된 서비스 수준 계약과 일치한다는 확신을 얻기 위해.
• 새로운 개선 사항으로 인해 애플리케이션 성능, 서비스 가용성 및 애플리케이션의 안정성이 영향을받지 않도록합니다.
• 트랜잭션 응답 시간은 증가하는로드 프로필에 대해 허용 가능한 허용 범위 내로 유지됩니다.
• JVM은 증가하는로드 프로필에 대해 안정적인 메모리 사용량을 보여줍니다.

아래 그림은 성능 테스트 및 최적화 프로세스를 명확하게 설명합니다.

건축물

이 세션에서 프로젝트의 아키텍처 다이어그램을 통합해야합니다.

# 2) 범위

범위 내

다음은 ABC 채팅 워크 벤치의 성능 테스트 범위입니다.

• 주요 비즈니스 거래에 대한 지식 습득 및 시스템에 대한 자세한 연구 후 부하 분산을 구축합니다.
• 다양한 프로젝트 트랙의 도움을 받아 성능 테스트를위한 중요한 시나리오를 식별합니다.
• 이전 릴리스 결과를 향후 릴리스의 기준으로 사용합니다.
• 추가 에이전트 시스템에 대한 성능 테스트 환경과 성능 / 부하 테스트 도구 인프라를 확인하고 검증합니다.
• 확인 된 최대 부하를 모방하는 확인 된 시나리오에 대해 JMeter를 사용하여 성능 테스트 스크립트를 준비합니다.
• 테스트 실행 단계에서 병목 현상을 식별하기 위해 테스트 모니터링을 위해 서버에서 성능 모니터링을 설정합니다.
• 성능 테스트 결과를 게시합니다.
• 다양한 이해 관계자와 협력하여 식별 된 성능 문제를 해결합니다.
• 향후 릴리스의 성능 수준을 기준으로합니다.

범위 외

• 기능 테스트 , UAT, 시스템 테스트 및 보안 테스트.
• 타사 인터페이스의 성능 테스트 / 모니터링.
• 성능 조정. (대부분의 경우 튜닝은 다른 팀에서 수행합니다. 시스템을 튜닝 할 성능 엔지니어가있는 경우 Inscope에 추가 할 수 있습니다.)
• 코드 프로파일 링 / 하드웨어 크기 조정 / 용량 계획.
• 보안 / 취약성 테스트 / UAT / 화이트 박스 테스트 .
• 성능 테스트를위한 데이터 생성.
• 비 기능 테스트 ( 예를 들어,페일 오버, 재난 복구, 백업, 유용성) 성능 테스트 외
• 모든 모바일 솔루션 테스트.
• 타사 응용 프로그램 성능 테스트 및 조정.
• 성능 권장 사항, 애플리케이션 코드 변경 및 공급 업체 지원 제품 / 서버 구성 변경의 실현은 성능 팀 관점에서 범위를 벗어납니다.
• 인프라 지원 / 구축 구축 / 환경 준비 / 데이터베이스 복원 / 네트워크 지원 등

# 3) 접근

ABC 채팅에 대한 성능 테스트는 XMPP 연결에 smack 라이브러리를 사용하는 사용자 지정 XMPP 플러그인을 작성하여 Jmeter를 사용하여 수행됩니다. 이러한 라이브러리는 연결을 설정하고 로그인하고 XMPP 서버에 채팅 메시지를 보내는 데 사용됩니다.

이러한 라이브러리는 Jmeter에 배포되고 테스트 할 시나리오를 기반으로 설계된 jar 파일에 번들로 제공됩니다. Jmeter Work Bench는 시스템 동작을 모니터링하기 위해 Chat 서버 시스템에 필요한 부하를 생성하기 위해 Load Generators가있는 JMeter 서버에 연결되는 로컬 시스템에 설치됩니다.

테스트 시나리오는 JMeter 도구를 사용하여 스크립팅됩니다. 스크립트는 필요에 따라 사용자 정의됩니다. 실제 시나리오를 시뮬레이션하는 데 필요한 램프 업으로 일정이 생성됩니다.

테스트 시나리오는 아래 측면에서 분류되고 측정됩니다.

a) 기준 테스트 : 애플리케이션 성능이 비즈니스 서비스 수준 계약을 충족하는지 여부를 식별하기 위해 1 개의 Vuser 및 여러 반복으로 각 시나리오를 실행합니다.

제품을 사용해보기 위해 비용을 지불하는 회사

b) 기본 부하 테스트 : 부하 테스트에서 비즈니스 벤치 마크를 충족하기 위해 성능 테스트 팀은 부하 증가에 따른 시스템 성능 문제를 식별하는 데 도움이되는 기본 부하 테스트를 수행하고 다음 수준의 성능 테스트를위한 기준을 만듭니다.

c) 최대 부하 / 확장 성 테스트 : 성능 테스트 팀은 증가하는 Vusers와 함께 여러 테스트를 수행하여 예상 부하를 충족하고 애플리케이션 성능을 측정하여 성능 곡선을 설정하고 배포가 최대 사용자 부하에서 서비스 수준 계약을 지원할 수 있는지 여부를 식별합니다.

개별 JVM (Java Virtual Machine), 필요한 총 JVM 수 및 프로세서의 조정 또는 용량 계획에 도움이됩니다. 이는 Vuser 수를 최대 용량의 50 %, 75 %, 100 % 및 125 %로 늘림으로써 달성됩니다.

디) 내구성 시험: 성능 테스트 팀은 메모리 누수, 시간 경과에 따른 성능 문제 및 전반적인 시스템 안정성을 식별하기 위해이 테스트를 8 시간 / 16 시간 / 24 시간 동안 실행합니다. 내구성 테스트 중에 성능 테스트 팀은 트랜잭션 응답 시간 및 메모리 사용 안정성과 같은 핵심 성능 지표를 모니터링합니다.

CPU, 메모리 및 IO와 같은 시스템 리소스는 프로젝트 팀의 도움을 받아 모니터링해야합니다.

성능 테스트 환경은 프로덕션 환경의 복제본으로 간주됩니다. 테스트는 애플리케이션이 실패한 위치를 식별하기 위해 증분로드로 실행됩니다.

성능 테스트 시나리오

일련의 시나리오에 Excel을 포함하십시오.

예를 들어,

시나리오 1 : X 번호에 대한 상담원 및 고객 채팅을 확인하려면 동시 세션의.

성능 테스트 유형

아래 표는 다양한 유형의 성능 테스트와 목표를 설명합니다.

성능 지표

• 클라이언트 측 메트릭

• 시스템 및 네트워크 성능 메트릭

성능 테스트 활동 및 결과물

# 4) 테스트 데이터

성능 환경 데이터는 프로덕션 데이터의 사본이고 필요한 테스트 데이터는 프로젝트 팀에서 제공하는 것으로 가정합니다.

# 5) 입장 및 퇴장 기준

• 환경의 모든 애플리케이션에 대한 액세스.
• 환경 준비 완료.
• 성능 테스트 데이터 준비.

# 6) 결함 관리

• JIRA의 Defect Management 모듈은 프로젝트에서 결함 로깅과 종료 추적을 위해 사용됩니다.
• 테스트 실행 단계에서 발견 된 결함 식별은 JIRA에서 캡처되며 이러한 결함은 아래 심각도에 따라 개발 팀에서 해결됩니다.
• 테스트, 개발, 품질 분석가 및 비즈니스 팀의 참여로 결함 검토 회의가 매일 개최됩니다.
• 프로젝트가 Go Live 날짜에 가까워지면 결함을 수정하는 기준이 엄격 해집니다. 결함 검토 회의에 게시 할 결함 수정 기준에 대한 지침입니다.

결함 심각도 정의

심각도 코드의 정의는 다음과 같습니다.

# 7) 테스트 도구 및 기법

# 8) 일시 중지 및 재개 기준

다음은 테스트 활동에 영향을 미칠 중요한 일시 중지 및 재개 기준입니다.

# 9) 테스트 결과물

성능 테스트 결과물에는 다음이 포함됩니다.

• 성능 테스트 전략
• 성능 요구 사항 문서
• 성능 테스트 시나리오 문서
• 성능 테스트 스크립트
• 성능 테스트 결과

# 10) 역할 및 책임

역할 및 책임은 아래 표에 명확하게 설명되어 있습니다.

# 11) 잠재적 위험 및 완화 계획

# 12) 가정

• 성능 테스트 환경은 제품 아키텍처 환경의 복제본이 될 것입니다. (예 : 올바른 하드웨어, 소프트웨어, 인터페이스, 통합 레이어 등).
• 성능 스크립트는 사용량이 높은 중요 흐름을 기반으로 설계됩니다.
• 성능 테스트를 시작하기 전에 모든 인프라 문제를 해결해야합니다. 나중에 시스템 구성을 변경하면 테스트 결과가 무효화됩니다.
• 애플리케이션이 안정적이고 성능 테스트 환경에서 사용할 준비가되었습니다.
• 필요한 하드웨어 및 소프트웨어 리소스 (예 :로드 생성기 시스템 / 소프트웨어, 컨트롤러 / 에이전트 시스템)를 사용할 수 있습니다.
• 범위에 대한 모든 변경은 변경 제어 프로세스를 거치고 성능 테스트 팀은 일정과 리소스의 영향을 평가합니다.
• 각 서버가 부하를 처리 할 것으로 예상됩니다.
• 모니터링을 위해 지원 시스템에 대해 애플리케이션 추적 로그를 사용하도록 설정해야합니다.

# 13) 종속성

• 제품 아키텍처 환경을 복제 한 성능 테스트 환경의 가용성.
• 테스트 준비 및 실행 단계에서 다양한 기능, 개발, 데이터베이스 및 인프라 팀의 지원이 필요합니다.
• 시간이 매우 제한되어 있으므로 전체 성능 테스트 단계에서는 코드 변경이 구현되지 않습니다.
• 타임 라인 내에서 제한으로 이어지는 예기치 않은 문제가 발생한 경우, 타임 라인에서 원래 마일스톤 날짜 내에 모든 테스트 범위를 충족 할 수없는 경우 범위 지정 및 우선 순위 결정을 제공하기 위해 릴리스 관리자가 지원을받을 수 있습니다.
• 애플리케이션 비즈니스 사용자 / 주제 전문가는 기능 설명 및 비즈니스 트랜잭션 승인을 위해 제공됩니다.
• ABC 채팅 프로그램 관리자가 검토하고 승인합니다.

# 14) 약어

이제 메시징 애플리케이션에 대한 효과적인 성능 테스트 전략을 작성하는 방법을 명확하게 이해 했어야합니다.

현실적인 성능 테스트를위한 모범 사례

성능 테스트 프로젝트를 성공적으로 완료하려면 계획 단계, 즉 계획, 개발, 실행 및 분석에서 올바른 방법으로 수행하고 있는지 확인해야합니다.

성능 테스트를 효과적으로 수행하기 위해 각 단계를 자세히 살펴 보겠습니다.

# 1) 계획

• 가장 일반적인 워크 플로우, 즉 테스트해야하는 비즈니스 시나리오를 식별하십시오. 애플리케이션이 기존 애플리케이션 인 경우 서버 로그를 확인하여 가장 자주 액세스하는 시나리오를 이해하십시오. 응용 프로그램이 새로운 것보다 프로젝트 관리 팀에 문의하여 주요 비즈니스 흐름을 이해하십시오.
• 가벼운 사용량, 중간 사용량 및 최대 부하와 같은 광범위한 워크 플로를 포괄하는 방식으로 부하 테스트를 계획합니다.
• 부하 테스트의 여러주기를 수행해야하므로 동일한 스크립트를 반복해서 사용할 수 있도록 프레임 워크를 만들어보십시오. 또한 스크립트를 백업하십시오.
• 테스트를 실행해야하는 시간을 분석해보십시오. 1 시간입니까? 8 시간? 하루 또는 일주일? 일반적으로 장기간 테스트는 OS 버그, 메모리 누수 등과 같은 많은 주요 결함을 발견합니다.
• 조직에서 APM (Application Monitoring Tool)을 사용하는 경우 테스트 실행 중에이를 포함하여 성능 문제를 쉽게 식별하고 근본 원인을보다 쉽게 ​​식별 할 수 있습니다.

# 2) 개발

• 스크립트, 즉 기록을 개발하는 동안 계획에 언급 된 비즈니스 흐름 이름을 기반으로보다 의미있는 트랜잭션 이름을 지정하십시오.
• 타사 응용 프로그램을 기록하지 말고 기록 된 경우 스크립트를 향상시키면서 필터링 해보십시오.
• 도구의 자동 상관 기능을 사용하여 모든 동적 값을 상관시킬 수있는 것은 아니므로 오류를 방지하려면 수동 상관을 수행하십시오.
• 캐시 서버뿐만 아니라 애플리케이션의 백엔드에 도달하는 방식으로 성능 테스트를 설계하십시오.

# 3) 실행

• SSL,로드 밸런서 및 방화벽과 같은 요소를 포함하여 프로덕션과 유사한 환경에서 테스트를 실행해야합니다. 이는 시스템의 실제 부하를 시뮬레이션하는 데 필요합니다.
• 매우 현실적인 워크로드를 생성 해보십시오. 기존 애플리케이션 인 경우 서버 로그를 확인하여이를 얻을 수 있으며 새로운 애플리케이션 인 경우 비즈니스 팀으로부터이 정보를 얻어야합니다. 성공적인 성능 테스트를 수행하려면 워크로드가 매우 중요합니다.
• 프로덕션 환경의 절반으로 테스트를 실행하여 결론을 내리지 마십시오. 항상 프로덕션 환경과 동일한 환경에서 테스트를 수행하는 것이 좋습니다.
• 장기 테스트를 실행하는 동안 테스트가 원활하게 실행되는지 확인하기 위해 자주 실행되는 간격을 확인하십시오.

# 4) 분석

• 먼저 몇 가지 중요한 카운터를 추가하여 응용 프로그램을 분석하고 병목 현상이 발견되면 병목 현상과 관련하여 추가 카운터를 추가하십시오. 그러면 문제를 더 쉽게 찾는 데 도움이됩니다.
• 애플리케이션은 요청에 응답하지 못하거나 오류 코드로 응답하거나 유효성 검사 논리에 실패하거나 너무 느리게 응답하는 등 여러 가지 이유로 실패 할 수 있습니다. 따라서 결론을 내리기 전에이 모든 것을 살펴보십시오.

결론

이 튜토리얼을 통해 성능 테스트 및 자세한 예제와 함께 성능 테스트 전략 문서를 작성하는 방법에 대한 엄청난 지식을 얻을 수 있었을 것입니다.

다음 자습서에서는 성능, 부하 및 스트레스 테스트의 차이점에 대해 자세히 알아 봅니다.

또한 확인 => 무료 LoadRunner 심층 교육 시리즈

NEXT 튜토리얼

추천 도서