Reporter.ReportEvent in UFT/QTP con l'esempio

Che cos'è Reporter.ReportEvent in UFT/QTP?

Reporter.ReportEvent è un metodo standard integrato UFT/QTP (ora venduto come OpenText/Micro Focus UFT Uno) che scrive un messaggio personalizzato e leggibile dall'uomo direttamente nella finestra dei risultati del test. A differenza dei verdetti automatici di superamento o fallimento generati dai checkpoint integrati, una chiamata ReportEvent consente al tester di decidere esattamente cosa viene registrato, quando e come deve essere etichettato.

Questo HP QTP lezione dimostra l'uso della funzione Reporter.ReportEvent and Formattazione dei risultatiIl tutorial richiede di creare un breve script e completare questo esercizio di scripting è il modo più rapido per vedere i report personalizzati aggiornare l'albero dei risultati in tempo reale.

Clicchi Qui. se il video non è accessibile

Il metodo `ReportEvent` è fondamentale nell'automazione perché uno script viene solitamente eseguito in modo automatico, secondo una pianificazione o all'interno di una pipeline CI/CD. Il file dei risultati dell'esecuzione diventa l'unica registrazione di quanto accaduto, quindi un passaggio che fallisce silenziosamente o che viene eseguito senza alcuna spiegazione rende il debug molto più difficile in seguito. L'aggiunta di una chiamata esplicita a `ReportEvent` dopo un'azione critica trasforma l'albero dei risultati in una traccia di controllo leggibile e dettagliata che un tester, uno sviluppatore o un responsabile possono esaminare senza dover aprire lo script stesso.

Questo è diverso da un checkpoint dell'oggetto, che UFT genera automaticamente e segnala utilizzando il proprio nome di passaggio predefinito. Reporter.ReportEvent consente invece di allegare un linguaggio significativo per il business, come "Conferma d'ordine visualizzata" invece di un generico "Check Point Pass sull'oggetto WebEdit", che è molto più facile da leggere per uno stakeholder non tecnico nel report finale. Il metodo funziona allo stesso modo sia che lo script abbia come destinazione una pagina web, un Windows applicazione desktop o terminale mainframe, poiché Reporter è un oggetto globale piuttosto che una proprietà di un singolo oggetto di test.

Guru99 di UFT/QTP la serie copre questo metodo subito dopo Istruzioni If, Else ed Exists, perché la maggior parte delle chiamate a Reporter.ReportEvent si trovano all'interno di un blocco condizionale che decide se il risultato deve essere segnalato come micPass o micFail.

Sintassi di Reporter.ReportEvent e valori di EventStatus

Puoi usare Reporter.ReportEvent per segnalare i passaggi di test personalizzati in Micro Focus UFTAlbero dei risultati del test. Il metodo accetta tre argomenti obbligatori e un argomento facoltativo, in un ordine fisso, come mostrato di seguito.

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

Stato dell'evento Imposta l'icona e il colore visualizzati per la fase e può invertire lo stato generale dell'esecuzione; ReportStepName è l'etichetta abbreviata che appare nell'albero dei risultati del test, generalmente scritta come risultato atteso; Dettagli contiene la descrizione più lunga, in genere il risultato effettivo osservato; e l'opzionale Percorso del file immagine allega uno screenshot acquisito in precedenza nello script a quello specifico passaggio.

Ogni costante può anche essere passata come valore numerico invece che come nome, quindi Reporter.ReportEvent 1, “Passo”, “Dettaglio” si comporta esattamente come Reporter.ReportEvent micFail, “Step”, “Detail”Utilizzare una costante denominata rende lo script più leggibile, soprattutto se verrà gestito in seguito da un altro tester.

Uno script in genere include diverse chiamate a ReportEvent all'interno di un'azione: una voce micDone prima dell'avvio dell'azione, una voce micPass o micFail per il controllo della chiave e ulteriori voci micWarning per qualsiasi anomalia rilevata durante il processo.

• Quando i casi di test vengono eseguiti utilizzando strumenti di automazione, può essere difficile per alcuni utenti comprendere i risultati grezzi del test. È possibile utilizzare results.xml per creare un file XSL che presenta i risultati del test nel modo che preferisci.
• È inoltre possibile utilizzare VBScript funzioni della libreria per salvare i risultati in un file xls o in un file di testo per segnalare all'esterno UFT.

Come utilizzare Reporter.ReportEvent: esempi pratici

Conoscere la sintassi è una cosa; vederla all'interno di uno script reale è ciò che permette di comprendere appieno le quattro costanti di stato. L'esempio seguente racchiude un controllo all'interno di un'istruzione If…Then…Else, quindi segnala un esito positivo o negativo con Reporter.ReportEvent, in modo che il risultato appaia nell'albero dei risultati esattamente dove un revisore si aspetta di trovarlo.

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

Ciò rispecchia il modello mostrato in Guru99 di Istruzioni condizionali VBScript tutorial, in cui un blocco If…Then…Else sceglie tra due risultati; l'unica differenza qui è che ogni ramo chiama anche Reporter.ReportEvent per registrare il risultato.

Usa il micDone per un passo che è puramente informativo e micWarning quando qualcosa sembra insolito ma non dovrebbe interrompere l'esecuzione immediatamente. Il frammento successivo registra un passaggio di immissione dati come completato, quindi segnala una risposta lenta come avviso e allega uno screenshot utilizzando l'argomento opzionale 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

mantenere ReportStepName corto e mantieni Dettagli Specificare il risultato effettivo. Un revisore che analizza centinaia di passaggi registrati dopo un'esecuzione notturna fallita dovrebbe essere in grado di capire cosa è successo senza dover aprire lo script stesso, e un modello di denominazione coerente per ogni azione rende questa analisi molto più rapida.

I team che richiamano ReportEvent da molti script spesso spostano questa logica in una funzione VBScript condivisa, come LogStep(status, name, details), in modo che ogni script produca un albero dei risultati coerente senza ripetere lo stesso blocco If…Then.

Proprietà dell'oggetto Reporter: Filtro, Percorso del report e Stato di esecuzione

Reporter.ReportEvent non è l'unico membro dell'oggetto Reporter. Tre proprietà aggiuntive offrono un controllo extra su cosa contengono i risultati e dove UFT li memorizzano e compaiono frequentemente nei framework di automazione della produzione.

Reporter.Filter accetta quattro valori: 0 o rfEnableAll mostra ogni evento ed è l'impostazione predefinita; 1 o rfEnableErrorsAndWarnings nasconde i passaggi superati; 2 o rfEnableErrorsOnly nasconde sia i passaggi superati che gli avvisi; e 3 o rfDisableAll disattiva completamente la registrazione dei risultati. Il controllo di Reporter.RunStatus a metà script consente a un test di diramare la propria logica, ad esempio saltareping i passaggi rimanenti di un'azione quando un passaggio precedente è già fallito.

Poiché ReportPath e RunStatus sono di sola lettura, non è possibile assegnare loro un valore; utilizzateli per leggere informazioni sull'esecuzione corrente, ad esempio per scrivere il percorso della cartella dei risultati in un file di log all'inizio di uno script o per interrompere un'azione lunga dopo un errore irreversibile. La lettura di queste proprietà aggiunge un overhead trascurabile, quindi è possibile controllare Reporter.RunStatus dopo ogni passaggio importante in una suite di regressione lunga senza rallentare l'esecuzione in modo percettibile.

migliori pratiche per Reporter.ReportEvent in UFT

Alcune abitudini contribuiscono a rendere i report personalizzati utili anziché fonte di confusione.

• Riserva micFail ai guasti reali: Ogni chiamata a micFail modifica Reporter.RunStatus, quindi utilizzarla per problemi estetici nasconde difetti reali che si verificano successivamente nella stessa esecuzione.
• Scrivi ReportStepName come risultato atteso: Un revisore dovrebbe essere in grado di comprendere il controllo dal solo nome del passaggio, senza dover leggere la colonna Dettagli.
• Acquisisci schermate solo in caso di errore: Passare ImageFilePath a ogni singolo passaggio riempie rapidamente la cartella dei risultati e rallenta l'esecuzione senza apportare grandi benefici.
• Filtra le sequenze rumorose: Imposta Reporter.Filter su rfEnableErrorsAndWarnings per le esecuzioni pianificate o CI, in modo che i passaggi superati non nascondano gli errori importanti.
• centralizzare la logica: Avvolgere le chiamate Reporter.ReportEvent all'interno di un riutilizzabile azione o una libreria di funzioni in modo che ogni script della suite registri i risultati nello stesso modo.
• Esporta per lettori non tecnici: Combina results.xml con un XSL personalizzato quando le parti interessate esterne al team QA devono rivedere i risultati senza aprire UFT.

DOMANDE FREQUENTI