Reporter.ReportEvent dans UFT/QTP avec exemple

Qu'est-ce que Reporter.ReportEvent dans UFT/QTP?

Reporter.ReportEvent est une méthode standard intégrée à UFT/QTP (maintenant vendu sous le nom de OpenText/Micro Focus UFT Premièrement, cette fonction permet d'afficher un message personnalisé et lisible directement dans la fenêtre des résultats de test. Contrairement aux verdicts automatiques de réussite ou d'échec générés par les points de contrôle intégrés, un appel à ReportEvent permet au testeur de choisir précisément les informations à consigner, le moment de leur consignation et la manière dont elles doivent être étiquetées.

Ce HP QTP tutoriel démontre l'utilisation de la fonction Reporter.ReportEvent et Formatage des résultatsLe tutoriel vous invite à créer un court script ; réaliser cet exercice de script est le moyen le plus rapide de voir les rapports personnalisés mettre à jour l’arborescence des résultats en temps réel.

Cliquez à nouveau ici si la vidéo n'est pas accessible

L'objet Reporter.ReportEvent est crucial en automatisation, car un script s'exécute généralement sans surveillance, selon une planification ou au sein d'un pipeline CI/CD. Le fichier de résultats d'exécution constitue l'unique trace des opérations effectuées ; par conséquent, une étape qui échoue silencieusement ou qui réussit sans explication complique considérablement le débogage ultérieur. L'ajout d'un appel explicite à ReportEvent après une action critique transforme l'arborescence des résultats en un journal d'audit détaillé et lisible, consultable étape par étape par un testeur, un développeur ou un responsable, sans avoir à ouvrir le script lui-même.

Cela diffère d'un point de contrôle d'objet, qui UFT Génère automatiquement des rapports en utilisant son propre nom d'étape par défaut. Reporter.ReportEvent vous permet quant à lui d'associer un langage métier, tel que « Confirmation de commande affichée », plutôt qu'un terme générique comme « Validation du point de contrôle sur l'objet WebEdit », ce qui est beaucoup plus facile à comprendre pour un interlocuteur non technique dans le rapport final. La méthode fonctionne de la même manière, que le script cible une page web ou un Windows application de bureau ou terminal mainframe, car Reporter est un objet global plutôt qu'une propriété d'un objet de test particulier.

Guru99's UFT/QTP La série aborde cette méthode juste après Instructions If, Else et Existe, car la plupart des appels Reporter.ReportEvent se trouvent à l'intérieur d'un bloc conditionnel qui décide si le résultat doit être signalé comme micPass ou micFail.

Syntaxe et valeurs de l'événement Reporter.ReportEvent

Vous pouvez utiliser Reporter.ReportEvent pour signaler les étapes de test personnalisées dans Micro Focus UFTL'arbre des résultats de test de la méthode accepte trois arguments obligatoires et un argument facultatif, dans un ordre fixe, comme indiqué ci-dessous.

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

Statut de l'événement définit l'icône et la couleur affichées pour l'étape et peut inverser l'état d'exécution global ; Nom de l'étape du rapport est l'étiquette courte qui apparaît dans l'arbre des résultats de test, généralement écrite comme le résultat attendu ; DÉTAILS contient la description plus longue, généralement le résultat observé ; et l'optionnel Chemin du fichier image joint une capture d'écran effectuée plus tôt dans le script à cette étape spécifique.

Chaque constante peut également être transmise sous forme de valeur numérique au lieu de son nom. Reporter.ReportEvent 1, « Étape », « Détail » se comporte exactement comme Reporter.ReportEvent micFail, « Étape », « Détail »L'utilisation d'une constante nommée facilite la lecture d'un script qu'un autre testeur sera amené à maintenir ultérieurement.

Un script imbrique généralement plusieurs appels ReportEvent au sein d'une même action : une entrée micDone avant le démarrage de l'action, une entrée micPass ou micFail pour la vérification des touches, et des entrées micWarning supplémentaires pour tout élément inhabituel détecté en cours de route.

• Lorsque des cas de test sont exécutés à l'aide d'outils d'automatisation, certains utilisateurs peuvent avoir du mal à comprendre les résultats bruts. Vous pouvez utiliser Le fichier results.xml permet de créer un fichier XSL qui présente les résultats des tests selon vos préférences..
• Vous pouvez également utiliser VBScript fonctions de bibliothèque à Enregistrez les résultats dans un fichier xls ou un fichier texte. pour signaler l'extérieur UFT.

Comment utiliser Reporter.ReportEvent : exemples pratiques

Connaître la syntaxe est une chose ; la voir dans un script réel permet de comprendre les quatre constantes d'état. L'exemple ci-dessous intègre une vérification dans une instruction If…Then…Else, puis signale la réussite ou l'échec avec Reporter.ReportEvent afin que le résultat apparaisse dans l'arborescence des résultats, exactement là où le réviseur l'attend.

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

Cela reflète le modèle présenté dans Guru99's Instructions conditionnelles VBScript Dans ce tutoriel, un bloc If…Then…Else choisit entre deux résultats ; la seule différence ici est que chaque branche appelle également Reporter.ReportEvent pour consigner le résultat.

Utilisez le microTerminé pour une étape purement informative, et Avertissement micro Lorsqu'un comportement inhabituel est détecté, mais ne devrait pas entraîner l'arrêt immédiat de l'exécution, l'extrait de code suivant consigne une étape de saisie de données comme terminée, puis signale une réponse lente comme un avertissement et joint une capture d'écran à l'aide de l'argument optionnel 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

Rester Nom de l'étape du rapport court et gardez DÉTAILS Il est essentiel de fournir des informations précises sur le résultat obtenu. Un examinateur analysant des centaines d'étapes consignées après un échec d'exécution nocturne devrait pouvoir déterminer la cause du problème sans ouvrir le script lui-même. De plus, une convention de nommage cohérente pour chaque action accélère considérablement cette analyse.

Les équipes qui appellent ReportEvent depuis de nombreux scripts déplacent souvent cette logique dans une fonction VBScript partagée, telle que LogStep(status, name, details), afin que chaque script produise un arbre de résultats cohérent sans répéter le même bloc If…Then.

Propriétés de l'objet Reporter : Filtre, Chemin du rapport et État d'exécution

L'objet Reporter.ReportEvent n'est pas le seul membre de l'objet Reporter. Trois propriétés supplémentaires permettent de contrôler plus finement le contenu et l'emplacement des résultats. UFT Ils les stockent et apparaissent fréquemment dans les frameworks d'automatisation de la production.

Reporter.Filter accepte quatre valeurs : 0 (rfEnableAll) affiche tous les événements et est la valeur par défaut ; 1 (rfEnableErrorsAndWarnings) masque les étapes passées ; 2 (rfEnableErrorsOnly) masque à la fois les étapes passées et les avertissements ; et 3 (rfDisableAll) désactive complètement la journalisation des résultats. La vérification de Reporter.RunStatus en cours de script permet à un test d'exécuter sa propre logique, par exemple en ignorant une étape.ping les étapes restantes d'une action une fois qu'une étape précédente a déjà échoué.

Les propriétés ReportPath et RunStatus étant en lecture seule, vous ne pouvez pas leur attribuer de valeur. Utilisez-les pour consulter des informations sur l'exécution en cours, par exemple pour consigner le chemin du dossier de résultats dans un fichier journal au début d'un script, ou pour interrompre une action longue après une erreur fatale. La lecture de ces propriétés n'entraîne qu'une surcharge négligeable ; il est donc possible de vérifier Reporter.RunStatus après chaque étape importante d'une longue suite de tests de régression sans ralentir sensiblement l'exécution.

Meilleures pratiques pour Reporter.ReportEvent dans UFT

Quelques habitudes permettent de conserver des rapports personnalisés utiles plutôt que de générer du bruit.

• Réservez micFail aux véritables pannes : Chaque appel micFail inverse Reporter.RunStatus, son utilisation pour des problèmes cosmétiques masque donc de véritables défauts survenant plus tard dans la même exécution.
• Rédigez ReportStepName comme un résultat attendu : Un réviseur doit comprendre le contrôle à partir du seul nom de l'étape, sans avoir à lire la colonne Détails.
• Capture d'écran uniquement en cas d'échec : Le fait de transmettre ImageFilePath à chaque étape remplit rapidement le dossier de résultats et ralentit l'exécution pour un bénéfice minime.
• Filtrer les séquences bruyantes : Configurez Reporter.Filter sur rfEnableErrorsAndWarnings pour les exécutions planifiées ou CI afin que les étapes passées n'enfouissent pas les échecs importants.
• Centraliser la logique : Enveloppez les appels à Reporter.ReportEvent dans un conteneur réutilisable. action ou une bibliothèque de fonctions afin que chaque script de la suite enregistre les résultats de la même manière.
• Version exportée pour les lecteurs non spécialistes : Combinez le fichier results.xml avec une feuille XSL personnalisée lorsque des parties prenantes extérieures à l'équipe d'assurance qualité doivent consulter les résultats sans ouvrir le fichier. UFT.

FAQ