Reporter.ReportEvent에서 UFT/QTP 예와 함께

Reporter.ReportEvent란 무엇인가요? UFT/QTP?

리포터.리포트이벤트 이는 내장된 표준 방법입니다. UFT/QTP (현재 판매 중) OpenText/마이크로 포커스 UFT 첫 번째는 테스트 결과 창에 사용자가 직접 작성한 읽기 쉬운 메시지를 출력하는 기능입니다. 내장된 체크포인트에서 자동으로 생성되는 합격 또는 불합격 판정과는 달리, ReportEvent 호출을 사용하면 테스터가 어떤 내용을 언제 어떻게 기록할지 정확하게 결정할 수 있습니다.

이 HP QTP 지도 시간 함수의 사용법을 보여줍니다. 리포터.리포트이벤트 결과 형식화이 튜토리얼에서는 간단한 스크립트를 작성하도록 요청하며, 해당 스크립트 작성 연습을 완료하는 것이 사용자 지정 보고서가 결과 트리에 실시간으로 업데이트되는 것을 가장 빠르게 확인하는 방법입니다.

여기에서 확인하세요 비디오에 접근할 수 없는 경우

Reporter.ReportEvent는 자동화 환경에서 특히 중요합니다. 스크립트는 일반적으로 무인으로, 예약된 시간에 또는 CI/CD 파이프라인 내에서 실행되기 때문입니다. 실행 결과 파일은 발생한 작업에 대한 유일한 기록이 되므로, 단계가 오류 없이 조용히 실패하거나 설명 없이 통과되면 나중에 디버깅이 훨씬 어려워집니다. 중요한 작업 후에 명시적으로 ReportEvent를 호출하면 결과 트리가 읽기 쉬운 단계별 감사 추적 기록으로 변환되어 테스터, 개발자 또는 관리자가 스크립트를 직접 열어보지 않고도 검토할 수 있습니다.

이는 객체 체크포인트와는 다릅니다. UFT 자동으로 생성되고 기본 단계 이름을 사용하여 보고되는 반면, Reporter.ReportEvent를 사용하면 "WebEdit 개체에서 체크포인트 통과"와 같은 일반적인 표현 대신 "주문 확인 표시됨"과 같이 비즈니스에 의미 있는 문구를 첨부할 수 있어 기술적인 지식이 없는 이해관계자도 최종 보고서를 훨씬 쉽게 이해할 수 있습니다. 이 방법은 스크립트가 웹 페이지를 대상으로 하든 다른 대상을 대상으로 하든 동일하게 작동합니다. Windows Reporter는 특정 테스트 객체의 속성이 아니라 전역 객체이므로 데스크톱 애플리케이션이나 메인프레임 터미널과 같은 환경에서 사용할 수 있습니다.

Guru99의의 UFT/QTP 이 시리즈는 바로 다음에 이 방법을 다룹니다. if, else, and Exists 문대부분의 Reporter.ReportEvent 호출은 결과가 micPass 또는 micFail로 보고되어야 하는지 여부를 결정하는 조건 블록 내에 있기 때문입니다.

Reporter.ReportEvent 구문 및 EventStatus 값

당신이 사용할 수 리포터.리포트이벤트 Micro Focus에서 사용자 지정 테스트 단계를 보고하려면 UFT's 테스트 결과 트리입니다. 이 메서드는 아래와 같이 고정된 순서로 세 개의 필수 인수와 하나의 선택적 인수를 받습니다.

Reporter.ReportEvent EventStatus, ReportStepName, Details [, ImageFilePath]

이벤트 상태 단계에 표시되는 아이콘과 색상을 설정하고 전체 실행 상태를 전환할 수 있습니다. 보고서 단계 이름 테스트 결과 트리에 표시되는 짧은 레이블로, 일반적으로 예상 결과로 표기됩니다. 세부 정보 더 자세한 설명(일반적으로 관찰된 실제 결과)을 담고 있으며, 선택 사항입니다. 이미지파일경로 스크립트 앞부분에서 캡처한 스크린샷을 해당 단계에 첨부합니다.

각 상수는 이름 대신 숫자 값으로 전달할 수도 있습니다. Reporter.ReportEvent 1, “단계”, “세부 정보” 정확히 다음과 같이 작동합니다 Reporter.ReportEvent micFail, “단계”, “세부 정보”명명된 상수를 사용하면 나중에 다른 테스터가 유지 관리할 스크립트에서 읽기가 더 쉽습니다.

스크립트에서는 일반적으로 하나의 액션 내에 여러 개의 ReportEvent 호출을 중첩합니다. 예를 들어 액션 시작 전에 micDone 항목을 추가하고, 키 확인을 위해 micPass 또는 micFail 항목을 추가하며, 진행 과정에서 발견된 특이 사항에 대해서는 추가적인 micWarning 항목을 추가합니다.

• 자동화 도구를 사용하여 테스트 케이스를 실행할 때, 일부 사용자는 테스트 결과 원본을 이해하기 어려울 수 있습니다. 이럴 때 다음 방법을 사용할 수 있습니다. results.xml 파일을 사용하여 원하는 방식으로 테스트 결과를 표시하는 XSL 파일을 생성할 수 있습니다..
• VOUS pouvez의 aussi 사용 Vbscript 라이브러리 함수 결과를 XLS 파일이나 텍스트 파일에 저장하세요. 외부 보도용 UFT.

Reporter.ReportEvent 사용 방법: 실제 예제

구문을 아는 것과 실제 스크립트에서 이를 확인하는 것은 별개의 문제입니다. 네 가지 상태 상수를 제대로 이해하려면 실제 스크립트에서 이를 살펴보는 것이 중요합니다. 아래 예제는 조건문을 If…Then…Else 문으로 감싸고, Reporter.ReportEvent를 사용하여 통과 또는 실패 여부를 보고합니다. 따라서 검토자가 예상하는 위치인 결과 트리에서 결과를 확인할 수 있습니다.

If Browser("Guru99 Demo").Page("Guru99 Demo").WebButton("Login").Exist(5) Then
    Reporter.ReportEvent micPass, "Login button check", "Login button was found on the page"
Else
    Reporter.ReportEvent micFail, "Login button check", "Login button was not found on the page"
End If

이는 다음과 같은 패턴을 반영합니다. Guru99의의 VBScript 조건문 이 튜토리얼에서는 If…Then…Else 블록이 두 가지 결과 중 하나를 선택합니다. 여기서 유일한 차이점은 각 분기에서 Reporter.ReportEvent를 호출하여 결과를 로그에 기록한다는 것입니다.

마이크돈 순전히 정보 제공을 위한 단계이므로, 마이크경고 뭔가 비정상적으로 보이지만 실행이 완전히 실패해서는 안 될 때 사용합니다. 다음 코드 조각은 데이터 입력 단계를 완료로 기록한 다음, 응답이 느리면 경고로 표시하고 선택적 ImageFilePath 인수를 사용하여 스크린샷을 첨부합니다.

Reporter.ReportEvent micDone, "Enter search text", "Typed 'UFT tutorial' into the search box"
errorImage = "C:\Results\SearchDelay.png"
Browser("Guru99 Demo").CaptureBitmap errorImage, True
Reporter.ReportEvent micWarning, "Search response time", "Results took longer than 5 seconds to load", errorImage

유지 보고서 단계 이름 짧게 유지하고 세부 정보 실제 결과에 대해 구체적으로 설명해야 합니다. 실패한 야간 실행 후 수백 개의 로그 단계를 검토하는 검토자는 스크립트 자체를 열어보지 않고도 무슨 일이 일어났는지 파악할 수 있어야 하며, 모든 작업에 걸쳐 일관된 명명 패턴을 사용하면 이러한 검토 속도가 훨씬 빨라집니다.

여러 스크립트에서 ReportEvent를 호출하는 팀은 종종 이 로직을 LogStep(status, name, details)와 같은 공유 VBScript 함수로 옮겨서 모든 스크립트가 동일한 If…Then 블록을 반복하지 않고 일관된 결과 트리를 생성하도록 합니다.

리포터 객체 속성: 필터, 보고서 경로 및 실행 상태

Reporter.ReportEvent는 Reporter 객체의 유일한 멤버가 아닙니다. 세 가지 추가 속성을 통해 결과의 내용과 위치를 더욱 세밀하게 제어할 수 있습니다. UFT 이러한 정보는 저장되며, 프로덕션 자동화 프레임워크에서 자주 나타납니다.

Reporter.Filter는 네 가지 값을 허용합니다. 0(rfEnableAll)은 모든 이벤트를 표시하며 기본값입니다. 1(rfEnableErrorsAndWarnings)은 통과한 단계를 숨깁니다. 2(rfEnableErrorsOnly)는 통과한 단계와 경고를 모두 숨깁니다. 3(rfDisableAll)은 결과 로깅을 완전히 비활성화합니다. 스크립트 중간에 Reporter.RunStatus를 확인하면 테스트가 자체 로직을 분기할 수 있습니다(예: 건너뛰기).ping 이전 단계가 실패했을 때 남은 단계들.

ReportPath와 RunStatus는 읽기 전용이므로 값을 할당할 수 없습니다. 이러한 속성은 현재 실행에 대한 정보를 읽는 데 사용할 수 있습니다. 예를 들어 스크립트 시작 부분에 결과 폴더 경로를 로그 파일에 기록하거나, 치명적인 오류 발생 후 시간이 오래 걸리는 작업을 단축하는 데 사용할 수 있습니다. 이러한 속성을 읽는 데 추가되는 오버헤드는 미미하므로, 긴 회귀 테스트 스위트에서 주요 단계마다 Reporter.RunStatus를 확인해도 실행 속도가 눈에 띄게 느려지지 않습니다.

Reporter.ReportEvent에 대한 최고의 사례 UFT

몇 가지 습관을 들이면 사용자 지정 보고서를 시끄러운 소음이 아닌 유용한 정보로 유지할 수 있습니다.

• micFail은 실제 오류가 발생한 경우에만 사용하세요. micFail 호출이 발생할 때마다 Reporter.RunStatus가 변경되므로, 이를 외관상의 문제 해결에 사용하면 동일한 실행에서 나중에 발생하는 실제 결함을 숨길 수 있습니다.
• ReportStepName을 예상 결과와 같이 작성하세요: 검토자는 세부 정보 열을 읽지 않고도 단계 이름만으로 검토 내용을 이해할 수 있어야 합니다.
• 오류 발생 시에만 스크린샷을 캡처하세요. 모든 단계에서 ImageFilePath를 전달하면 결과 폴더가 빠르게 가득 차고 실행 속도가 느려지지만 얻는 이점은 미미합니다.
• 잡음이 심한 실행 결과를 필터링합니다. 예약 실행 또는 CI 실행 시 Reporter.Filter를 rfEnableErrorsAndWarnings로 설정하여 통과된 단계에 중요한 오류가 묻히지 않도록 하십시오.
• 논리를 중앙 집중화하세요: Reporter.ReportEvent 호출을 재사용 가능한 태그 안에 감싸세요. 동작 또는 함수 라이브러리를 사용하여 제품군 내 모든 스크립트가 동일한 방식으로 결과를 기록하도록 합니다.
• 기술 지식이 없는 독자를 위한 내보내기: QA 팀 외부의 이해관계자가 파일을 열지 않고 결과를 검토해야 하는 경우 results.xml 파일과 사용자 지정 XSL을 결합하세요. UFT.

자주 묻는 질문