Es hängt wirklich davon ab, wie Ihr Test fehlschlägt. Wiederherstellungsszenarien eignen sich hervorragend für unvorhergesehene Situationen - wie das Abstürzen des Browserfensters zu unvorhersehbaren Zeitpunkten oder das Abwerfen des Netzwerks aus irgendeinem Grund oder, schlimmer noch, ein Bildschirm, der Ihnen den Wechsel auf das neueste Betriebssystem anbietet und den screen ...
Wenn Ihr Skript an einem vorhersehbaren Punkt versagt, sodass Sie IF-Anweisungen einstreuen können, die überprüfen, ob der nächste Schritt realisierbar ist (dh prüfen, ob button.exists vorhanden ist), dann nicht Sie müssen sich auf das Wiederherstellungsszenario verlassen - Sie würden den Fehlertestprozess direkt starten.
Hier ist, was ich tue - ich habe eine Funktion FailTestBecause() aufgerufen, die einen Parameter - eine Zeichenkette, die den Grund für das Scheitern (ich den Grund wissen, weil der if-Anweisung, die den Aufruf dieser Funktion hüllt)
FailTestBecause() setzt zuerst ein Flag, das einen Fehler anzeigt, protokolliert die Fehlermeldung an den Reporter, das Protokoll und an meine eigene Fehlerdatei und versucht dann, eine Aktion namens "Test beenden" auszulösen. Wenn Aktion: Test beenden nicht vorhanden ist, wird sie mit Exittest() ordnungsgemäß beendet.
FinishTest ist die letzte Aktion in meinem Test, und wenn es startet, sucht es nach dem Fehlerflag. So oder so, es ist Aufgabe, alle verbleibenden Dateien zurück zu QC/ALM zu laden. Auf diese Weise bekomme ich immer meine Testdaten gesammelt und auf QC hochgeladen, bevor das Skript stoppt.
Mein Code ist großzügig mit Fehlerprüfungen bestreut. Hier ist ein Beispiel ...
Browser("Trade").Page("Login Page").WebEdit("User ID").Set User_ID
Browser("Trade").Page("Login Page").WebEdit("Password").SetSecure User_Password
Browser("Trade").Page("Login Page").WebButton("Login").Click
Do Until Browser("Trade").Page("Main Page").Exist(0)
If Browser("Trade").Page("Login Page").WebElement("Login Failed").Exist(0) then
FailTestBecause "Login Failed, user credentials didn't work"
ElseIf Browser("Trade").Page("Challenge Questions").Exist(0) then
say "Found Challenge Questions Screen, handling it..."
RunAction "Handle Challenge Questions", OneIteration
ElseIF Browser("Trade").Page("Create Password").Exist(0) then
FailTestBecause "Detected new password, requires manual change"
ElseIf not Browser("Trade").Exist(0) then
FailTestBecause "Browser page crashed?"
Else
FailTestBecause "Something (unhandled) went wrong, please review log"
End If
Loop
Überprüfen Sie häufig auf Fehler. Wir sind immerhin Tester.
Der Trick ist, dass ich sicher sein möchte, dass der Browser, den ich zu Beginn des Tests geöffnet habe, am Ende geschlossen ist, auch wenn der Test aus irgendeinem Grund fehlschlägt. Ich könnte alles in bedingte Anweisungen schreiben, aber ich versuche, die Dinge so einfach wie möglich zu halten und die ganze Logik, oder zumindest das meiste davon, nicht in den Skripten selbst zu haben. Recovery-Szenario scheint eine gute Sache zu sein, wenn ich nur wusste, wie man sie bearbeitet ... – tom
Um klar zu sein, ich nicht normalerweise "alles in Conditionals" wickeln ... Ich habe immer nur eine .exist Check-in für bestimmte Kontrollen vor vorausgesetzt, es ist sicher, mit der Eingabe von Daten in die UAT zu beginnen. Das erlaubt mir, UAT-Fehler selbst zu kontrollieren. –
Ich vertiefte mich in die Funktionsweise von Wiederherstellungsszenarien (in der Dokumentation) und das größte Problem bei der Verwendung von Wiederherstellungsszenarien ist, dass nach Abschluss des Wiederherstellungsszenarios entweder A) mit der Ausführung in der Nähe fortgesetzt werden soll, B) fortfahren bis zur nächsten Aktion oder Iteration, C) den gesamten Test neu starten oder D) beenden.Das bedeutet, dass Sie die gesamte Verarbeitung nach dem Problem (Erfassen von Absturzdaten, Berichten usw.) innerhalb des Wiederherstellungsszenarios selbst durchführen und den Test beenden müssen, um das zu tun, was Sie tun möchten. Es scheint keine Option zu geben, "von Punkt X fortzufahren". –