LoadRunner의 매개변수화, 함수, 트랜잭션

기록된 스크립트는 가상 사용자를 시뮬레이션할 수 있습니다. 그러나 단순한 녹음만으로는 "실제 사용자 행동"을 재현하는 데 충분하지 않을 수 있습니다.

스크립트가 기록되면 주제 응용 프로그램의 단일하고 직선적인 흐름을 다룹니다. 반면 실제 사용자는 로그아웃하기 전에 모든 프로세스를 여러 번 반복할 수 있습니다. 버튼을 클릭하는 사이의 지연 시간(생각하는 시간)은 사람마다 다릅니다. 실제 사용자 중 일부는 DSL을 통해 애플리케이션에 액세스하고 일부는 전화 접속을 통해 액세스할 가능성이 있습니다. 따라서 최종 사용자의 실제 느낌을 얻으려면 스크립트를 정확하게 일치시키거나 적어도 실제 사용자와 매우 유사하게 동작하도록 개선해야 합니다.

위의 내용은 “를 수행할 때 가장 중요한 고려사항입니다.성능 시험”하지만 VU 스크립트에는 더 많은 것이 있습니다. SUL이 성능 테스트를 진행할 때 VUser가 소요되는 정확한 시간을 어떻게 측정합니까? 특정 지점에서 VUser가 통과했는지 실패했는지 어떻게 알 수 있습니까? 일부 백엔드 프로세스가 실패했거나 서버 리소스가 제한되었는지 여부에 관계없이 실패의 원인은 무엇입니까?

위의 모든 질문에 답하는 데 도움이 되도록 스크립트를 개선해야 합니다.

거래 사용

트랜잭션은 모든 작업에 대한 서버 응답 시간을 측정하는 메커니즘입니다. 간단히 말해서, "트랜잭션"을 사용하면 특정 요청에 대해 시스템이 걸리는 시간을 측정하는 데 도움이 됩니다. 버튼을 클릭하거나 텍스트 상자에서 포커스를 잃은 후 AJAX 호출하는 것처럼 작을 수 있습니다.

트랜잭션을 적용하는 것은 간단합니다. 서버에 요청하기 전에 코드 한 줄을 작성하고 요청이 끝나면 트랜잭션을 닫습니다. LoadRunner에는 트랜잭션 이름으로 문자열만 필요합니다.

트랜잭션을 열려면 다음 코드 줄을 사용하세요.

lr_start_transaction(“Transaction Name”);

거래를 종료하려면 다음 코드 줄을 사용하세요.

lr_end_transaction(“Transaction Name”, <status>);

그만큼 LoadRunner에게 이 특정 트랜잭션이 성공했는지 실패했는지 알려줍니다. 가능한 매개변수는 다음과 같습니다.

• LR_AUTO
• LR_PASS
• LR_FAIL

예:

lr_end_transaction(“My_Login”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboard 이름”, LR_PASS);
lr_end_transaction(“Business_Workflow_트랜잭션 이름”, LR_FAIL);

참고 사항 :

• 잊지 마세요. "C"로 작업하고 있으며 대소문자를 구분하는 언어입니다.
• 거래명에는 마침표(.) 문자를 사용할 수 없으나 공백과 밑줄은 사용할 수 있습니다.
• 코드를 잘 분기하고 체크포인트를 추가하여 서버 응답을 검증했다면 LR_PASS나 LR_FAIL과 같은 사용자 정의 오류 처리를 사용할 수 있습니다. 그렇지 않으면 LR_AUTO를 사용하면 LoadRunner가 자동으로 서버 오류(HTTP 500, 400 등)를 처리합니다.
• 거래를 적용할 때 다음 사항이 없는지 확인하세요. 생각할 시간 명세서가 중간에 끼어있거나 그렇지 않은 경우 거래에는 항상 해당 기간이 포함됩니다.
• LoadRunner에서는 트랜잭션 이름으로 상수 문자열이 필요하므로 트랜잭션을 적용할 때 흔히 발생하는 문제는 문자열 불일치입니다. 거래를 열고 닫을 때 다른 이름을 지정하면 최소 2번의 오류가 발생합니다. 귀하가 연 트랜잭션이 결코 닫히지 않았기 때문에 LoadRunner는 오류를 생성합니다. 게다가 닫으려는 거래가 열리지 않아 오류가 발생했습니다.
• 당신의 지능을 활용하여 위의 오류 중 어떤 것이 먼저 보고될 것인지 스스로 답할 수 있습니까? 답변을 검증하려면 스스로 실수를 해보는 것이 어떨까요? 만약 당신이 올바르게 대답했다면, 당신은 올바른 길을 가고 있는 것입니다. 잘못 대답했다면 집중해야 합니다.
• LoadRunner가 요청과 응답의 동기화를 자동으로 처리하므로 트랜잭션을 적용할 때 응답에 대해 걱정할 필요가 없습니다.

대기 시간, 랑데부 포인트 및 설명 이해

집결지

랑데뷰 포인트(Rendezvous Point)는 '만남의 장소'를 의미합니다. 이는 LoadRunner에게 동시성을 도입하도록 지시하는 한 줄의 명령문일 뿐입니다. 서버의 과도한 사용자 로드를 에뮬레이트하기 위해 VUser 스크립트에 랑데부 포인트를 삽입합니다.

랑데뷰 포인트는 VUser에게 테스트 실행 중에 여러 VUser가 특정 포인트에 도달할 때까지 기다리도록 지시하여 동시에 작업을 수행할 수 있도록 합니다. 예를 들어, 은행 서버의 최대 부하를 에뮬레이트하기 위해 100명의 VUser에게 동시에 자신의 계좌에 현금을 입금하도록 지시하는 랑데뷰 포인트를 삽입할 수 있습니다. 이는 랑데부(Rendezvous)를 사용하여 쉽게 달성할 수 있습니다.

랑데부 포인트가 올바르게 배치되지 않으면 VUser는 동일한 스크립트에 대해서도 응용 프로그램의 다른 부분에 액세스하게 됩니다. 이는 VUser마다 응답 시간이 다르기 때문에 뒤처지는 사용자가 거의 없기 때문입니다.

구문: lr_rendesvous(“논리적 이름”);

모범 사례:

• 코드 가독성을 높이려면 랑데부 지점 앞에 "rdv_"를 붙입니다. 예: “rdv_Login”
• 즉각적인 인지 시간 설명을 삭제하세요.
• 스크립트 보기에서 랑데부 포인트 적용(녹화 후)

코멘트

활동, 코드 조각 또는 코드 줄을 설명하는 주석을 추가합니다. 주석은 나중에 참조하는 모든 사람이 코드를 이해할 수 있도록 도와줍니다. 특정 작업에 대한 정보를 제공하고 두 섹션을 구분합니다.

댓글을 추가할 수 있습니다.

• 녹음 중(도구 사용)
• 녹음 후 (코드 직접 작성)

모범 사례: 각 스크립트 파일의 맨 위에 있는 모든 주석을 표시하세요.

메뉴를 통해 기능 삽입

간단한 코드 줄을 직접 쓸 수는 있지만 함수를 기억하려면 단서가 필요할 수 있습니다. Steps Toolbox(12버전 이전에는 Insert Function이라고 함)를 사용하여 모든 함수를 찾아 스크립트에 직접 삽입할 수도 있습니다.

단계 도구 모음은 보기 > 단계 도구 상자 아래에서 찾을 수 있습니다.

그러면 측면 창이 열리고 스냅샷을 살펴보세요.

매개변수화란 무엇입니까?

A 매개 변수 VUGen에서는 다양한 사용자를 위해 대체되는 기록된 값을 포함하는 컨테이너입니다.

VUGen 또는 컨트롤러에서 스크립트를 실행하는 동안 외부 소스(예: .txt, XML 또는 데이터베이스)의 값이 매개변수의 이전 값을 대체합니다.

매개변수화는 동적(또는 고유) 값을 서버에 보내는 데 유용합니다. 비즈니스 프로세스는 10번의 반복을 실행하기를 원하지만 매번 고유한 사용자 이름을 선택합니다.

또한 대상 시스템에 실제와 유사한 동작을 자극하는 데 도움이 됩니다. 아래 예를 살펴보십시오.

문제 예:

비즈니스 프로세스는 서버에서 제공되는 현재 날짜에 대해서만 작동하므로 하드코딩된 요청으로 전달할 수 없습니다.

경우에 따라 클라이언트 애플리케이션은 프로세스를 계속하기 위해 서버에 고유 ID(예: session_id)를 전달합니다(단일 사용자의 경우에도). 이러한 경우 매개변수화가 도움이 됩니다.

종종 클라이언트 응용 프로그램은 서버와 주고받는 데이터의 캐시를 유지 관리합니다. 결과적으로 서버는 실제 사용자 동작을 수신하지 못합니다(서버가 검색 기준에 따라 다른 알고리즘을 실행하는 경우). VUser 스크립트가 성공적으로 실행되는 동안 작성된 성능 통계는 의미가 없습니다. 매개변수화를 통해 다양한 데이터를 사용하면 서버측 활동(프로시저 등)을 에뮬레이션하고 시스템을 시험하는 데 도움이 됩니다.

녹화 중 VUser에 하드 코딩된 날짜는 해당 날짜가 지나면 더 이상 유효하지 않을 수 있습니다. 날짜를 매개변수화하면 하드 코딩된 날짜를 대체하여 VUser 실행이 성공할 수 있습니다. 이러한 필드나 요청은 매개변수화에 적합한 후보입니다.

LINK 비디오에 접근할 수 없는 경우

런타임 설정 및 VU 시뮬레이션에 미치는 영향

런타임 설정은 VUGen 스크립트만큼 중요합니다. 다양한 구성을 통해 다양한 테스트 설계를 얻을 수 있습니다. 따라서 런타임 설정이 일관되지 않으면 반복할 수 없는 결과가 발생할 수 있습니다. 각 속성을 하나씩 논의해 보겠습니다.

로직 실행

Run Logic은 vuser_init 및 vuser_end를 제외한 모든 작업이 실행되는 횟수를 정의합니다.

아마도 이는 LoadRunner가 모든 로그인 코드를 vuser_init 내에 유지하고 로그아웃 부분을 vuser_end 내에 단독으로 유지하도록 제안하는 이유를 더욱 명확하게 합니다.

로그인, 화면 열기, 임대 계산, 자금 제출, 잔액 확인 및 로그아웃과 같은 여러 작업을 생성한 경우 각 VUser에 대해 아래 시나리오가 발생합니다.

모든 VUser는 로그인하고 화면 열기, 임대 계산, 자금 제출, 잔액 확인을 실행한 다음 다시 화면 열기, 임대 계산… 등을 10회 반복한 후 로그아웃(XNUMX회)합니다.

이는 실제 사용자처럼 행동할 수 있게 해주는 강력한 설정입니다. 실제 사용자는 매번 로그인하고 로그아웃하는 것이 아니라 일반적으로 동일한 단계를 반복한다는 점을 기억하십시오.

로그아웃하기 전에 이메일을 확인할 때 "받은 편지함"을 몇 번이나 클릭하시나요?

간격

이건 중요하다. 대부분의 사람들은 속도와 생각 시간의 차이를 이해하지 못합니다. 유일한 차이점은, “페이싱(pacing)은 반복 사이의 지연을 의미하는 반면, 인지 시간은 두 단계 사이의 지연을 의미합니다.

권장 설정은 테스트 설계에 따라 다릅니다. 그러나 공격적인 로드를 원하는 경우 "이전 반복이 종료되자마자"를 선택하는 것이 좋습니다.

로그

로그(일반적으로 이해됨)는 LoadRunner를 실행하는 동안 모든 이벤트를 기록하는 것입니다. 로그를 활성화하면 애플리케이션과 서버 사이에 무슨 일이 일어나고 있는지 알 수 있습니다.

LoadRunner는 자체적으로 강력하고 확장 가능한 강력한 로깅 메커니즘을 제공합니다. 이를 통해 "표준 로그" 또는 상세하고 구성 가능한 확장 로그만 유지하거나 모두 비활성화할 수 있습니다.

표준 로그는 유익하고 쉽게 이해할 수 있습니다. 여기에는 일반적으로 VUser 스크립트 문제 해결에 필요한 적절한 양의 지식이 포함되어 있습니다.

확장 로그의 경우 모든 표준 로그 정보가 하위 집합입니다. 또한 매개변수 대체가 가능합니다. 이는 LoadRunner 구성 요소에 응답 데이터뿐만 아니라 요청을 포함한 모든 매개 변수(매개 변수화의)에 대한 전체 정보를 포함하도록 지시합니다.

"서버에서 반환된 데이터"를 포함하면 로그 길이가 길어집니다. 여기에는 로그 내에 바로 포함된 모든 HTML, 태그, 리소스, 리소스 이외의 정보가 포함됩니다. 이 옵션은 심각한 문제 해결이 필요한 경우에만 유용합니다. 일반적으로 이로 인해 로그 파일의 크기가 매우 커지고 쉽게 이해할 수 없게 됩니다.

지금까지 짐작하셨겠지만 "Advance Trace"를 선택하면 로그 파일이 방대해질 것입니다. 꼭 시도해 보세요. VUGen에서 걸리는 시간도 상당히 증가했지만 VUGen에서 보고하는 트랜잭션 응답 시간에는 영향을 미치지 않습니다. 그러나 이는 매우 진보된 정보이며 해당 애플리케이션, 애플리케이션과 하드웨어 간의 클라이언트-서버 통신, 프로토콜 수준 세부 정보를 이해한다면 유용할 수 있습니다. 일반적으로 이 정보는 이해하고 문제를 해결하는 데 극도의 노력이 필요하기 때문에 본질적으로 쓸모가 없습니다.

팁 :

• 로그가 활성화될 때 VUGen이 걸리는 시간에 관계없이 트랜잭션 응답 시간에는 영향을 미치지 않습니다. HP는 이러한 현상을 "최첨단 기술"이라고 부릅니다.
• 필요하지 않은 경우 로그를 비활성화합니다.
• 스크립트 작업이 끝나면 로그를 비활성화하십시오. 로깅이 활성화된 스크립트를 포함하면 컨트롤러가 느리게 실행되고 잔소리 메시지가 보고됩니다.
• 로그를 비활성화하면 LoadRunner에서 시뮬레이션할 수 있는 최대 사용자 수의 용량이 늘어납니다.
• "오류가 발생한 경우에만 메시지 보내기"를 사용해 보십시오. 이렇게 하면 불필요한 정보 메시지가 음소거되고 오류 관련 메시지만 보고됩니다.

생각할 시간

사고 시간은 단순히 두 단계 사이의 지연입니다.

실제 사용자는 기계(VUGen)와 같은 애플리케이션을 사용할 수 없으므로 Think Time은 사용자 행동을 복제하는 데 도움이 됩니다. VUGen은 자동으로 인지 시간을 생성합니다. 인지 시간의 지속 시간을 제거, 증가 또는 변동시키는 완전한 제어 권한은 여전히 ​​있습니다.

예를 들어 더 자세히 이해하기 위해 사용자는 화면을 열고(요청이 뒤따르는 응답) Enter 키를 누르기 전에 사용자 이름과 비밀번호를 제공할 수 있습니다. 서버에 대한 애플리케이션의 다음 상호작용은 "로그인"을 클릭할 때 발생합니다. 사용자가 자신의 사용자 이름과 암호를 입력하는 데 걸린 시간은 LoadRunner의 인지 시간입니다.

애플리케이션의 공격적인 로드를 시뮬레이션하려는 경우 인지 시간을 완전히 비활성화하는 것이 좋습니다.

그러나 실제와 유사한 동작을 시뮬레이션하려면 "사용자 임의 인지 시간"을 선택하고 백분율을 원하는 대로 설정할 수 있습니다.

적법한 기간으로 Think Time 제한을 사용하는 것을 고려하십시오. 일반적으로 30초면 충분합니다.

속도 시뮬레이션

속도 시뮬레이션은 단순히 각 클라이언트 시스템의 대역폭 용량을 나타냅니다.

LoadRunner를 통해 수천 명의 VUser를 시뮬레이션하고 있으므로 LoadRunner가 대역폭/네트워크 속도 시뮬레이션을 제어하는 ​​방법이 얼마나 간단했는지는 놀랍습니다.

고객이 128Kbps를 통해 애플리케이션에 액세스하는 경우 여기에서 이를 제어할 수 있습니다. 올바른 성능 통계를 얻는 데 도움이 되는 "실제 유사 동작"을 시뮬레이션하게 됩니다.

가장 좋은 권장 사항은 최대 대역폭 사용으로 설정하는 것입니다. 이렇게 하면 네트워크 관련 성능 병목 현상을 무시하고 애플리케이션의 잠재적인 문제에 먼저 집중하는 데 도움이 됩니다. 언제든지 테스트를 여러 번 실행하여 다양한 상황에서 다양한 동작을 확인할 수 있습니다.

브라우저 에뮬레이션

사용자 경험은 최종 사용자가 사용하는 브라우저에 따라 달라지지 않습니다. 분명히 이는 성과 측정의 범위를 벗어납니다. 그러나 에뮬레이션하려는 브라우저를 선택할 수 있습니다.

이 구성에서 올바른 브라우저를 선택하는 것이 정확히 언제 중요한지 스스로에게 답할 수 있습니까?

대상 애플리케이션이 웹 애플리케이션인 경우 이 구성을 사용하여 브라우저마다 다른 응답을 반환합니다. 예를 들어, IE와 Firefox 등

또 다른 중요한 설정은 브라우저 캐시 시뮬레이션입니다. 캐시가 활성화되었을 때 응답 시간을 측정하려면 이 상자를 체크하세요. 최악의 상황을 찾고 있다면 이것은 분명히 고려 사항이 아닙니다.

HTML이 아닌 리소스를 다운로드하면 LoadRunner가 CSS, JS 및 기타 리치 미디어를 다운로드할 수 있습니다. 이 부분은 계속 확인해야 합니다. 그러나 성능 테스트 설계에서 이를 제거하려면 이 항목을 선택 취소할 수 있습니다.

대리

귀하의 사이트에서 프록시를 완전히 제거하는 것이 가장 좋습니다. 테스트 환경 – 이로 인해 테스트 결과를 신뢰할 수 없게 됩니다. 그러나 불가피한 상황에 직면할 수도 있습니다. 이러한 상황에서는 LoadRunner가 프록시 설정을 도와줍니다.

프록시 없음 설정으로 작업하게 됩니다(또는 작업해야 합니다). 기본 브라우저에서 얻을 수 있습니다. 그러나 어떤 브라우저가 기본값으로 설정되어 있는지, 기본 브라우저에 대한 프록시 구성이 무엇인지 확인하는 것을 잊지 마십시오.

프록시를 사용하고 인증(또는 스크립트)이 필요한 경우 인증 버튼을 클릭하면 새 창이 열립니다. 아래 스크린샷을 참고하세요.

이 화면을 사용하여 프록시 서버에서 인증을 받기 위한 사용자 이름과 비밀번호를 입력하세요. 확인을 클릭하여 화면을 닫습니다.

축하해요. VUGen 스크립트 구성이 완료되었습니다. 모든 VUser 스크립트에 대해 이를 구성하는 것을 잊지 마십시오.