LoadRunner 테스트 도구 - 구성 요소 및 Archi강의

LoadRunner란 무엇입니까?

LoadRunner 에 의해 개척된 성능 테스트 도구입니다. Mercury 1999년에 LoadRunner가 인수되었습니다. 이후 2006년에 HPE가 LoadRunner를 인수했습니다. 2016년에 LoadRunner가 MicroFocus에 인수되었습니다.

LoadRunner는 다양한 개발 도구, 기술 및 통신 프로토콜을 지원합니다. 실제로 이것은 수행할 수 있는 수많은 프로토콜을 지원하는 시장에서 유일한 도구입니다. 성능 시험. LoadRunner 소프트웨어에서 생성된 성능 테스트 결과는 다른 도구에 대한 벤치마크로 사용됩니다.

LoadRunner 비디오

왜 LoadRunner인가?

LoadRunner 성능 테스트의 선구자 도구일 뿐만 아니라 여전히 성능 테스트 패러다임의 시장 리더입니다. 최근 평가에 따르면 LoadRunner는 성능 테스트 업계에서 약 85%의 시장 점유율을 차지하고 있습니다.

광범위하게 LoadRunner 도구는 RIA(Rich Internet Application), Web 2.0(HTTP/HTML, Ajax, Flex 및 Silverlight 등), 모바일, SAP, Oracle, MS SQL 서버, 시트릭스, RTE, Mail 그리고 무엇보다도, Windows 소켓. 단일 도구에 이렇게 다양한 프로토콜을 제공할 수 있는 경쟁 도구는 시장에 없습니다.

소프트웨어 테스트에서 LoadRunner를 선택하는 데 더 설득력 있는 것은 이 도구의 신뢰성입니다. LoadRunner 도구는 자주 볼 수 있듯이 오랫동안 명성을 쌓아 왔습니다. 클라이언트는 LoadRunner를 사용하여 성능 벤치마크를 교차 검증합니다. 성능 테스트 요구 사항에 대해 이미 LoadRunner를 사용하고 있다면 안심할 수 있습니다.

LoadRunner 소프트웨어는 QTP(Unified Functional Test) 및 ALM(Application Lifecycle Management)과 같은 다른 HP 도구와 긴밀하게 통합되어 엔드투엔드 테스트 프로세스를 수행할 수 있도록 해줍니다.

LoadRunner는 대상 응용 프로그램에서 가상 사용자를 시뮬레이션하는 원칙에 따라 작동합니다. VUser라고도 하는 이러한 가상 사용자는 클라이언트의 요청을 복제하고 트랜잭션 전달에 대한 해당 응답을 기대합니다.

성능 테스트가 필요한 이유는 무엇입니까?

추정 매출 4.4억 손실 웹 성능 저하로 인해 매년 기록됩니다.

오늘날의 웹 2.0 시대에 사용자는 웹사이트가 8초 이내에 응답하지 않으면 클릭을 멈춥니다. Google에서 검색하거나 Facebook에서 친구 요청을 할 때 5초를 기다려야 한다고 상상해 보세요. 성능 저하의 여파는 상상 이상으로 파괴적입니다. 최근 Bank of America 온라인 뱅킹에 영향을 준 사례가 있습니다. Amazon 웹 서비스, Intuit 또는 Blackberry.

Dunn & Bradstreet에 따르면, Fortune 59 기업의 500%가 매주 약 1.6시간의 다운타임을 경험한다고 합니다. 최소 500명의 직원을 둔 Fortune 10,000 기업의 평균이 시간당 56달러를 지불한다는 점을 고려하면, 그러한 조직의 다운타임 비용 중 노동 비용은 주당 896,000달러로, 연간 46만 달러가 넘습니다.

Google.com의 단 5분 다운타임(19년 13월 545,000일)으로 인해 검색 대기업에 XNUMX달러의 손실이 발생한 것으로 추산됩니다.

최근 발생한 문제로 인해 기업들은 초당 1100달러 상당의 매출 손실을 입은 것으로 추산됩니다. Amazon 웹 서비스 중단.

소프트웨어 시스템이 조직에 의해 배포될 때 성능 지연을 초래할 수 있는 많은 시나리오에 직면할 수 있습니다. 여러 요인이 성능 저하를 일으키며, 몇 가지 예는 다음과 같습니다.

• 데이터베이스에 존재하는 레코드 수 증가
• 시스템에 동시에 요청되는 수 증가
• 과거에 비해 한 번에 시스템에 액세스하는 사용자 수가 더 많아졌습니다.

LoadRunner 란 무엇입니까? Archi강의?

대체로 HP LoadRunner의 아키텍처는 복잡하지만 이해하기 쉽습니다.

당신이 성과를 점검하도록 배정되었다고 가정해보자. Amazon5000명의 사용자를 위한 .com

실제 상황에서 이 5000명의 사용자는 모두 홈페이지가 아닌 웹사이트의 다른 섹션에 있을 것입니다. 어떻게 다르게 시뮬레이션할 수 있습니까?

VUGen

VUGen 또는 가상 사용자 Generator IDE(통합 개발 환경) 또는 풍부한 코딩 편집기입니다. VUGen은 SUL(System Under Load) 동작을 복제하는 데 사용됩니다. VUGen은 VUser 스크립트라고도 하는 코딩된 스크립트 형식으로 클라이언트와 서버 간의 통신을 기록하는 "녹화" 기능을 제공합니다.

따라서 위의 예를 고려할 때 VUGen은 다음과 같은 비즈니스 프로세스를 시뮬레이션하기 위해 기록할 수 있습니다.

1. 제품 페이지 서핑 Amazon.COM
2. Checkout
3. 지불 처리
4. 내 계정 페이지 확인 중

제어 장치

VUser 스크립트가 완료되면 Controller는 다음과 같은 관리를 통해 로드 시뮬레이션을 제어하는 ​​주요 LoadRunner 구성 요소 중 하나입니다.

• 각 비즈니스 프로세스 또는 VUser 그룹에 대해 시뮬레이션할 VUser 수
• VUser의 동작(램프 업, 램프 다운, 동시 또는 동시적 특성 등)
• 부하 시나리오의 성격(예: 실제 생활 또는 목표 지향 또는 SLA 확인)
• 사용할 인젝터, 각 인젝터에 대한 VUser 수
• 결과를 주기적으로 대조
• IP 스푸핑
• 오류보고
• 거래보고 등

예제 컨트롤러에서 유추를 사용하면 VUGen 스크립트에 다음 매개변수가 추가됩니다.

1) 사용자는 3500명입니다. 제품 페이지 서핑 Amazon.COM

2) 750명의 사용자가 있습니다. Checkout

3) 사용자는 500명입니다. 결제 처리 수행

4) 사용자는 250명입니다. 500명의 사용자가 결제 처리를 완료한 후에만 내 계정 페이지 확인

훨씬 더 복잡한 시나리오도 가능합니다.

1. 5명의 VUser가 로드될 때까지 2초마다 3500명의 VUser를 시작합니다(서핑 Amazon 제품 페이지)가 달성되었습니다.
2. 30분 동안 반복
3. 25명의 VUser에 대한 반복 일시 중지
4. VUSer 20명 다시 시작
5. 매초 2명의 사용자(결제, 결제 처리, 내 계정 페이지)를 시작합니다.
6. 2500명의 VUser가 시스템 A에 생성됩니다.
7. 2500명의 VUser가 시스템 B에서 생성됩니다.

에이전트 머신/로드 Generators/인젝터

HP LoadRunner 컨트롤러는 수천 명의 VUser를 시뮬레이션하는 역할을 담당합니다. 이러한 VUser는 프로세서 및 메모리와 같은 하드웨어 리소스를 소비하므로 이를 시뮬레이션하는 시스템에 제한이 적용됩니다. 게다가 Controller는 동일한 시스템(Controller가 있는 곳)에서 이러한 VUser를 시뮬레이션하므로 결과가 정확하지 않을 수 있습니다. 이 문제를 해결하기 위해 모든 VUser는 하중 Generators 또는 로드 인젝터.

일반적으로 Controller는 다른 시스템에 상주하며 다른 시스템에서 로드가 시뮬레이션됩니다. VUser 스크립트의 프로토콜과 기계 사양에 따라 전체 시뮬레이션에 여러 개의 로드 인젝터가 필요할 수 있습니다. 예를 들어, HTTP 스크립트의 VUser에는 시뮬레이션을 위해 VUser당 2-4MB가 필요하므로 4 VUser의 로드를 시뮬레이션하려면 각각 4GB RAM이 있는 10,000대의 시스템이 필요합니다.

우리의 비유를 들어보자 Amazon 예를 들어, 이 구성요소의 출력은 다음과 같습니다.

분석

로드 시나리오가 실행되면 '분석” LoadRunner의 구성요소가 들어옵니다.

실행 중에 컨트롤러는 원시 형식으로 결과 덤프를 생성하고 이 결과 덤프를 생성한 LoadRunner 버전 및 구성과 같은 정보를 포함합니다.

모든 오류와 예외는 Microsoft output.mdb라는 이름의 데이터베이스에 액세스합니다. "분석" 구성 요소는 이 데이터베이스 파일을 읽어 다양한 유형의 분석을 수행하고 그래프를 생성합니다.

이 그래프는 부하 시 오류 및 실패의 원인을 이해하기 위한 다양한 추세를 보여줍니다. 따라서 SUL, 서버(예: JBoss, Oracle) 또는 인프라.

다음은 대역폭으로 인해 병목 현상이 발생할 수 있는 예입니다. 웹 서버의 용량이 1GBps인데 데이터 트래픽이 이 용량을 초과하여 후속 사용자에게 피해를 준다고 가정해 보겠습니다. 시스템이 이러한 요구 사항을 충족하는지 확인하려면 성능 엔지니어가 비정상적인 로드가 있는 애플리케이션 동작을 분석해야 합니다. 다음은 LoadRunner가 대역폭을 유도하기 위해 생성하는 그래프입니다.

성능 테스트를 수행하는 방법

성능 테스트 로드맵은 크게 5단계로 나눌 수 있습니다.

• 부하 테스트 계획
• VUGen 스크립트 만들기
• 시나리오 생성
• 시나리오 실행
• 결과 분석(이후 시스템 조정)

이제 LoadRunner를 설치했으므로 프로세스와 관련된 단계를 하나씩 이해해 보겠습니다.

성능 테스트 프로세스와 관련된 단계

1단계) 부하 테스트 계획

성능 테스트 계획은 성능 테스트 계획과 다릅니다. SIT(시스템 통합 테스트) or UAT(사용자 승인 테스트). 계획은 아래와 같이 작은 단계로 더 나눌 수 있습니다.

팀을 구성하세요

LoadRunner 테스트를 시작할 때 프로세스 중에 관련된 각 팀의 활동에 참여할 사람을 문서화하는 것이 가장 좋습니다.

프로젝트 매니저 :

이 활동을 담당하고 에스컬레이션 담당자 역할을 할 프로젝트 관리자를 지정합니다.

직무 전문가/비즈니스 분석가:

SUL의 사용 분석 제공 및 웹사이트/SUL의 비즈니스 기능에 대한 전문 지식 제공

성능 테스트 전문가:

자동화된 성능 테스트 생성 및 로드 시나리오 실행

시스템 Archi감지하다:

SUL의 청사진 제공

웹 개발자 및 SME:

• 웹 사이트 유지 관리 및 모니터링 측면 제공
• 웹사이트 개발 및 버그 수정

시스템 관리자:

• 테스트 프로젝트 전반에 걸쳐 관련 서버를 유지 관리합니다.

관련된 애플리케이션 및 비즈니스 프로세스 개요:

성공한 부하 테스트 특정 비즈니스 프로세스를 수행할 계획이 필요합니다. 비즈니스 프로세스는 부하 테스트 목표를 달성하기 위해 원하는 비즈니스 트랜잭션을 준수하는 명확하게 정의된 단계로 구성됩니다.

시스템에서 사용자 로드를 유도하기 위해 요구 사항 측정 기준을 준비할 수 있습니다. 다음은 회사의 출석 시스템의 예입니다.

위의 예에서 수치는 특정 시간에 애플리케이션(SUL)에 연결된 사용자 수를 나타냅니다. 가장 오른쪽 열에서 계산된 하루 중 언제든지 비즈니스 프로세스에 연결된 최대 사용자 수를 추출할 수 있습니다.

마찬가지로 하루 중 언제든지 애플리케이션(SUL)에 연결된 총 사용자 수를 결론 내릴 수 있습니다. 이는 마지막 행에서 계산됩니다.

위의 두 가지 사실을 결합하면 시스템 성능을 테스트하는 데 필요한 총 사용자 수를 알 수 있습니다.

테스트 데이터 관리 절차 정의

성능 테스트를 통해 얻은 통계 및 관찰 내용은 앞서 설명한 대로 다양한 요인에 의해 크게 영향을 받습니다. 성능 테스트를 위한 테스트 데이터를 준비하는 것은 매우 중요합니다. 때로는 특정 비즈니스 프로세스가 데이터 세트를 사용하고 다른 데이터 세트를 생성합니다. 아래 예를 들어보세요:

• 사용자 'A'는 금융 계약을 생성하고 검토를 위해 제출합니다.
• 또 다른 사용자 'B'는 사용자 'A'가 생성한 하루 200개의 계약을 승인합니다.
• 또 다른 사용자 'C'는 사용자 'B'가 승인한 하루 약 150개의 계약을 지불합니다.

이 상황에서 사용자 B는 시스템에서 200개의 계약을 '생성'해야 합니다. 게다가 사용자 C는 150명의 사용자 로드를 시뮬레이션하려면 "승인"된 150개의 계약이 필요합니다.

이는 최소한 200+150= 350개의 계약을 생성해야 함을 의미합니다.

그 후 사용자 C의 테스트 데이터로 사용할 150개의 계약을 승인하고 나머지 200개의 계약은 사용자 B의 테스트 데이터로 사용됩니다.

아웃라인 모니터

시스템 성능에 영향을 미칠 수 있는 모든 요소를 ​​추측해 보세요. 예를 들어, 하드웨어 수가 줄어들면 SUL(System Under Load) 성능에 잠재적인 영향을 미칠 수 있습니다.

모든 요인을 수집하고 이를 측정할 수 있도록 모니터를 설정합니다. 다음은 몇 가지 예입니다.

• 프로세서(웹 서버, 애플리케이션 서버, 데이터베이스 서버 및 인젝터용)
• RAM(웹 서버, 애플리케이션 서버, 데이터베이스 서버 및 인젝터용)
• 웹/앱 서버(예: IIS, JBoss, Jaguar Server, Tomcat 등)
• DB 서버(PGA 및 SGA 크기의 경우 Oracle 및 MSSQL 서버, SP 등)
• 네트워크 대역폭 활용도
• 클러스터링의 경우 내부 및 외부 NIC
• 로드 밸런서(그리고 클러스터의 모든 노드에 로드를 균등하게 분산하고 있음)
• 데이터 흐름(클라이언트와 서버 간에 이동하는 데이터의 양을 계산한 다음 NIC 용량이 X명의 사용자를 시뮬레이션하기에 충분한지 계산)

2단계) VUGen 스크립트 생성

계획 후 다음 단계는 생성하는 것입니다. VUser 스크립트.

3단계) ​​시나리오 생성

다음 단계는 로드 시나리오를 생성하는 것입니다.

4단계) 시나리오 실행

시나리오 실행은 여러 VUser에게 동시에 작업을 수행하도록 지시하여 서버의 사용자 부하를 에뮬레이트하는 것입니다.

동시에 작업을 수행하는 VUser 수를 늘리거나 줄여 부하 수준을 설정할 수 있습니다.

이 실행으로 인해 서버가 스트레스를 받아 비정상적으로 동작할 수 있습니다. 이것이 바로 성능 테스트의 목적입니다. 도출된 결과는 자세한 분석 및 근본 원인 식별에 사용됩니다.

5단계) 결과 분석(시스템 조정 후)

시나리오 실행 중에 LoadRunner는 다양한 부하에서 애플리케이션의 성능을 기록합니다. 테스트 실행에서 추출한 통계가 저장되고 세부 분석이 수행됩니다. 'HP 분석' 도구는 시스템 성능 지연의 근본 원인과 시스템 장애를 식별하는 데 도움이 되는 다양한 그래프를 생성합니다.

얻은 그래프 중 일부는 다음과 같습니다.

• 첫 번째 버퍼까지의 시간
• 트랜잭션 응답 시간
• 평균 트랜잭션 응답 시간
• 초당 조회수
• Windows 자료
• 오류 통계
• 거래 요약

자주 묻는 질문