Reporter.ReportEvent in UFT/QTP mit Beispiel
Thomas Hamilton
⚡ Intelligente Zusammenfassung
Reporter.ReportEvent in UFT/QTP Sendet benutzerdefinierte Meldungen über Erfolg, Misserfolg, Warnungen und Informationen direkt an den Run Results Viewer unter Verwendung der Statuskonstanten micPass, micFail, micDone und micWarning und bietet den Testern so eine lesbare, schrittweise Aufzeichnung dessen, was ein automatisiertes Skript tatsächlich getan hat.
Was ist Reporter.ReportEvent in UFT/QTP?
Reporter.ReportEvent ist eine standardmäßige Methode, die in UFT/QTP (wird jetzt verkauft als OpenText/Mikrofokus UFT Erstens) wird eine benutzerdefinierte, lesbare Meldung direkt in das Fenster mit den Testergebnissen geschrieben. Im Gegensatz zu den automatischen Ergebnissen (bestanden/nicht bestanden), die von integrierten Prüfpunkten generiert werden, ermöglicht ein ReportEvent-Aufruf dem Tester, genau festzulegen, was wann und wie protokolliert wird.
Dieser HP QTP Lernprogramm demonstriert die Verwendung der Funktion Reporter.ReportEvent und ErgebnisformatierungDas Tutorial fordert Sie auf, ein kurzes Skript zu erstellen. Die Fertigstellung dieser Skriptübung ist der schnellste Weg, um zu sehen, wie benutzerdefinierte Berichte den Ergebnisbaum in Echtzeit aktualisieren.
Klicken Sie auf werden auf dieser Seite erläutert wenn das Video nicht zugänglich ist
Reporter.ReportEvent ist besonders in der Automatisierung wichtig, da Skripte üblicherweise unbeaufsichtigt, nach einem Zeitplan oder innerhalb einer CI/CD-Pipeline ausgeführt werden. Die Ergebnisdatei ist dann die einzige Aufzeichnung des Geschehens. Ein Schritt, der stillschweigend fehlschlägt oder ohne Erklärung erfolgreich ist, erschwert die spätere Fehlersuche erheblich. Durch das Hinzufügen eines expliziten ReportEvent-Aufrufs nach einer kritischen Aktion wird die Ergebnisstruktur in einen lesbaren, schrittweisen Prüfpfad umgewandelt, den Tester, Entwickler oder Manager einsehen können, ohne das Skript selbst öffnen zu müssen.
Dies unterscheidet sich von einem Objekt-Checkpoint, der UFT Die automatische Generierung und Berichterstellung verwendet einen eigenen Standardschrittnamen. Reporter.ReportEvent hingegen ermöglicht die Verwendung aussagekräftiger Geschäftsinformationen, z. B. „Bestellbestätigung angezeigt“ anstelle der generischen Meldung „Checkpoint-Durchlauf für WebEdit-Objekt“. Dies ist für technisch nicht versierte Stakeholder im Abschlussbericht deutlich verständlicher. Die Methode funktioniert unabhängig davon, ob das Skript eine Webseite oder eine Anwendung als Ziel hat. Windows Es handelt sich um eine Desktop-Anwendung oder ein Mainframe-Terminal, da Reporter ein globales Objekt und keine Eigenschaft eines bestimmten Testobjekts ist.
Guru99'er UFT/QTP Die Serie behandelt diese Methode direkt im Anschluss. Wenn-, Sonst- und Exist-Anweisungen, weil die meisten Reporter.ReportEvent-Aufrufe innerhalb eines Bedingungsblocks stehen, der entscheidet, ob das Ergebnis als micPass oder micFail gemeldet werden soll.
Syntax und EventStatus-Werte von Reporter.ReportEvent
Sie können verwenden Reporter.ReportEvent um benutzerdefinierte Testschritte in Micro Focus zu melden UFTDer Testergebnisbaum von 's. Die Methode akzeptiert drei erforderliche und ein optionales Argument in einer festen Reihenfolge, wie unten dargestellt.
Reporter.ReportEvent EventStatus, ReportStepName, Details [, ImageFilePath]
Ereignisstatus Legt das Symbol und die Farbe für den jeweiligen Schritt fest und kann den Gesamtstatus des Laufs ändern; Berichtsschrittname ist die Kurzbezeichnung, die im Testergebnisbaum erscheint und im Allgemeinen als das erwartete Ergebnis angegeben wird; Details enthält die ausführlichere Beschreibung, typischerweise das tatsächlich beobachtete Ergebnis; und die optionale Bilddateipfad Fügt dem jeweiligen Schritt einen Screenshot hinzu, der zuvor im Skript aufgenommen wurde.
| Mehrwert | KONSTANTE | AUSWIRKUNG AUF DIE ERGEBNISSE | AUSWIRKUNG AUF DEN LAUFSTATUS |
|---|---|---|---|
| 0 | micPass | Der Schritt wird im Ergebnisbaum als „Bestanden“ angezeigt. | Keine Änderung; der Test gilt weiterhin als bestanden. |
| 1 | Mikrofonausfall | Im Ergebnisbaum wird dieser Schritt als „Fehlgeschlagen“ angezeigt. | Der Gesamtstatus des Laufs ändert sich zu „Fehlgeschlagen“. |
| 2 | micDone | Der Schritt wird als Informationsmeldung angezeigt. | Keine Änderung des Status „Bestanden/Nicht bestanden“. |
| 3 | Mikrofonwarnung | Der Schritt wird als Warnung angezeigt | Keine Änderung des Status „Bestanden/Nicht bestanden“. |
Jede Konstante kann auch als ihr numerischer Wert anstelle ihres Namens übergeben werden, also Reporter.ReportEvent 1, “Step”, “Detail” verhält sich genau wie Reporter.ReportEvent micFail, “Step”, “Detail”Die Verwendung einer benannten Konstante erleichtert das Lesen eines Skripts, das später von einem anderen Tester gewartet wird.
Ein Skript verschachtelt üblicherweise mehrere ReportEvent-Aufrufe innerhalb einer Aktion: einen micDone-Eintrag vor Beginn einer Aktion, einen micPass- oder micFail-Eintrag für die Tastenprüfung und zusätzliche micWarning-Einträge für alle Ungewöhnlichkeiten, die dabei festgestellt werden.
- Wenn Testfälle mithilfe von Automatisierungstools ausgeführt werden, kann es für manche Benutzer schwierig sein, die Rohdaten der Tests zu verstehen. Sie können verwenden results.xml, um eine XSL-Datei zu erstellen, die die Testergebnisse nach Ihren Wünschen darstellt..
- Sie können auch VBScript Bibliotheksfunktionen zu Speichern Sie die Ergebnisse in einer XLS- oder einer Textdatei. für die Berichterstattung außerhalb UFT.
Verwendung von Reporter.ReportEvent: Praktische Beispiele
Die Syntax zu kennen ist das eine; sie in einem realen Skript zu sehen, macht die vier Statuskonstanten erst richtig verständlich. Das folgende Beispiel umschließt eine Prüfung mit einer If…Then…Else-Anweisung und meldet anschließend mit Reporter.ReportEvent ein positives oder negatives Ergebnis, sodass dieses im Ergebnisbaum genau dort erscheint, wo der Prüfer es erwartet.
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
Dies spiegelt das gezeigte Muster wider in Guru99'er bedingte Anweisungen in VBScript In diesem Tutorial wählt ein If…Then…Else-Block zwischen zwei Ergebnissen; der einzige Unterschied besteht darin, dass jeder Zweig zusätzlich Reporter.ReportEvent aufruft, um das Ergebnis zu protokollieren.
Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, micDone für einen Schritt, der rein informativer Natur ist, und Mikrofonwarnung Wenn etwas ungewöhnlich aussieht, aber den Lauf nicht sofort abbrechen sollte, protokolliert der nächste Codeabschnitt einen Dateneingabeschritt als „Fertig“, kennzeichnet eine langsame Antwort als „Warnung“ und fügt mithilfe des optionalen Arguments „ImageFilePath“ einen Screenshot an.
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
Behalten Berichtsschrittname kurz und halten Details Die Aussagekraft des Ergebnisses ist entscheidend. Ein Prüfer, der nach einem fehlgeschlagenen Skriptlauf über Nacht Hunderte von protokollierten Schritten durchsieht, sollte die Ursache ermitteln können, ohne das Skript selbst öffnen zu müssen. Ein einheitliches Namensmuster für alle Aktionen beschleunigt diesen Scan erheblich.
Teams, die ReportEvent aus vielen Skripten aufrufen, verschieben diese Logik oft in eine gemeinsam genutzte VBScript-Funktion, wie z. B. LogStep(status, name, details), damit jedes Skript einen konsistenten Ergebnisbaum erzeugt, ohne denselben If…Then-Block zu wiederholen.
Eigenschaften des Reporterobjekts: Filter, Berichtspfad und Ausführungsstatus
Reporter.ReportEvent ist nicht das einzige Element des Reporter-Objekts. Drei zusätzliche Eigenschaften ermöglichen eine detailliertere Steuerung des Inhalts und des Speicherorts der Ergebnisse. UFT Sie werden gespeichert und tauchen häufig in Produktionsautomatisierungs-Frameworks auf.
| IMMOBILIEN | ZWECK | TYPISCHE ANWENDUNG |
|---|---|---|
| Filter | Steuert, welche Ereignistypen in die Ergebnisse geschrieben werden. | Reporter.Filter = rfEnableErrorsAndWarnings blendet bei einem langen Lauf die durchlaufenen Schritte aus. |
| Berichtspfad | Schreibgeschützt; gibt den Ordner zurück, in dem die Ergebnisse des aktuellen Laufs gespeichert sind. | resultsFolder = Reporter.ReportPath |
| RunStatus | Schreibgeschützt; gibt den aktuellen Status (Erfolg/Misserfolg) des bisherigen Durchlaufs zurück | Wenn Reporter.RunStatus = micFail, dann Aktion beenden |
Reporter.Filter akzeptiert vier Werte: 0 (rfEnableAll) zeigt alle Ereignisse an und ist die Standardeinstellung; 1 (rfEnableErrorsAndWarnings) blendet abgeschlossene Schritte aus; 2 (rfEnableErrorsOnly) blendet sowohl abgeschlossene Schritte als auch Warnungen aus; und 3 (rfDisableAll) deaktiviert die Ergebnisprotokollierung vollständig. Die Überprüfung von Reporter.RunStatus mitten im Skript ermöglicht es einem Test, seine eigene Logik zu verzweigen, z. B. bestimmte Schritte zu überspringen.ping die verbleibenden Schritte einer Handlung, nachdem ein vorheriger Schritt bereits fehlgeschlagen ist.
Da ReportPath und RunStatus schreibgeschützt sind, können Sie ihnen keinen Wert zuweisen. Verwenden Sie sie, um Informationen über den aktuellen Lauf auszulesen, beispielsweise um den Pfad zum Ergebnisordner zu Beginn eines Skripts in eine Protokolldatei zu schreiben oder eine langwierige Aktion nach einem schwerwiegenden Fehler abzubrechen. Das Auslesen dieser Eigenschaften verursacht nur einen vernachlässigbaren Mehraufwand. Daher können Sie Reporter.RunStatus nach jedem wichtigen Schritt in einer umfangreichen Regressionssuite bedenkenlos überprüfen, ohne den Lauf merklich zu verlangsamen.
beste Praktiken für Reporter.ReportEvent in UFT
Ein paar Gewohnheiten sorgen dafür, dass benutzerdefinierte Berichte nützlich und nicht überladen wirken.
- micFail nur für echte Fehler reservieren: Jeder micFail-Aufruf ändert Reporter.RunStatus, sodass die Verwendung von micFail bei kosmetischen Problemen echte Fehler später im selben Durchlauf verdeckt.
- Schreiben Sie ReportStepName wie ein erwartetes Ergebnis: Ein Prüfer sollte die Prüfung allein anhand des Schrittnamens verstehen, ohne die Spalte „Details“ lesen zu müssen.
- Screenshots nur im Fehlerfall aufnehmen: Die Übergabe des ImageFilePath bei jedem einzelnen Schritt führt dazu, dass der Ergebnisordner schnell voll wird und der Ablauf verlangsamt wird, ohne dass sich dadurch viel Nutzen ergibt.
- Störende Läufe filtern: Setzen Sie Reporter.Filter auf rfEnableErrorsAndWarnings für geplante oder CI-Läufe, damit abgeschlossene Schritte die wichtigen Fehler nicht unterdrücken.
- Zentralisieren Sie die Logik: Wrap Reporter.ReportEvent-Aufrufe in eine wiederverwendbare Klasse einbetten Aktion oder Funktionsbibliothek, sodass jedes Skript in der Suite die Ergebnisse auf die gleiche Weise protokolliert.
- Export für nicht-technische Leser: Kombinieren Sie results.xml mit einem benutzerdefinierten XSL-Code, wenn Stakeholder außerhalb des QA-Teams Ergebnisse überprüfen müssen, ohne die QA-Dokumentation zu öffnen. UFT.
