2016-07-14 39 views
1

Tor

I „normale“ Prüfschritte will den SoapUI Testfall zu brechen, während eine deutliche Teilmenge von Test Schritte scheitern erlaubt sein soll.Wie ignoriert man bestimmte Testschrittfehler im SoapUI-Testfall?

Rationale

Ich habe einen Fall SoapUI Test, der einen ziemlich komplizierten Funktionstest durchführt, wo einige optionalen Informationen durch zusätzliche JDBC Prüfschritten geprüft werden. Da diese Details "optional" sind, sollte der Testfall nicht fehlschlagen (d. H. Er sollte grün werden), selbst wenn einer oder mehrere dieser JDBC-Tests fehlschlagen.

Fast dort

Wenn die Anforderung würde aller Prüfschritte im Testfall erlauben zu scheitern, könnte ich einfach den Testfall Verhalten umschalten:

öffnen Sie den Testcase Optionen-Dialog (von der Testcase-Symbolleiste) und deaktivieren Sie die Option Abbruch bei Fehler. Wenn Sie den Testfall ausführen, die nach wie vor Schritt scheitert aber SoapUI wird weiterhin durch die anderen Testschritte laufen Functional Tests | Data-Driven Tests (SoapUI.org)

Frage

  • Kann dieses Ziel durch eine Einstellung oder Eigenschaft auf Prüfschritt Ebene erreicht werden (vor allem: ohne Pro-Version)?
  • Gibt es eine Groovy-Lösung ähnlich setFailOnError/setFailTestCaseOnErrors Methoden auf WsdlTestCase aber auf Test Schritt Ebene?

Antwort

1

Ich habe es gelöst, indem zwei Groovy Prüfschritte Einsetzen dass

  1. speichern die aktuellen Testfall-Einstellungen auf (temporäre) Testfall benutzerdefinierte Eigenschaftsfelder;
  2. Wende des Fehlerverhaltens vor den optionalen Schritten;
  3. das vorherige Fehlerverhalten nach den optionalen Schritten aus den (temporären) Eigenschaften wiederherstellen.

Vorher: disableFailOnErrorBehavior.groovy:

testRunner.testCase.with { 
    // Store current TestCase options in (temporary) TestCase properties. 
    setPropertyValue('_failOnError', failOnError.toString()) 
    setPropertyValue('_failTestCaseOnErrors', failTestCaseOnErrors.toString()) 
    log.debug "Saved FailOnError behavior: ${failOnError}, ${failTestCaseOnErrors}." 

    // Allow following TestSteps to fail without aborting the TestCase immediately. 
    setFailOnError(false) 
    setFailTestCaseOnErrors(true) 
    log.info "Set FailOnError behavior: ${failOnError}, ${failTestCaseOnErrors}." 
} 

Nach: restoreFailOnErrorBehavior.groovy:

testRunner.testCase.with{ 
    // Use (temporary) TestCase properties to restore initial TestCase options. 
    setFailOnError(getPropertyValue('_failOnError').toBoolean()) 
    setFailTestCaseOnErrors(getPropertyValue('_failTestCaseOnErrors').toBoolean()) 
    log.info "Restored FailOnError behavior: ${failOnError}, ${failTestCaseOnErrors}." 

    // Remove (temporary) TestCase properties. 
    removeProperty('_failOnError') 
    removeProperty('_failTestCaseOnErrors') 
    log.debug "Clean up temporary properties: done." 
} 

Diese Skripte auf zwei Methoden verlassen, um den Testfall Verhalten zu ändern:

+0

Ich habe das versucht, aber es hat nicht für mich gearbeitet. Ich habe den ersten Code im groovigen Skript hinzugefügt. Ich kann sehen, dass die 2 Eigenschaften auf Testfallebene gesetzt wurden.Wenn ich den Testfall ausführe, schlägt dieser Schritt aufgrund eines funktionalen Problems wie erwartet fehl und die Ausführung wird beendet, obwohl beide Eigenschaften festgelegt sind. Der nächste Schritt sollte ausgeführt werden, da die Eigenschaften bereits auf der Testfallebene –

+1

@Gauravkhurana gesetzt sind. Die Eigenschaften '_failOnError' und' _failTestCaseOnErrors' werden nur verwendet, um den aktuellen Zustand des Testfalls zu speichern, damit wir das ursprüngliche Verhalten später wiederherstellen können. Die Kernfunktionalität dieser Skripts besteht darin, 'setFailOnError()' und 'setFailTestCaseOnErrors()' für das TestCase-Objekt aufzurufen. h., verlassen sich nicht auf die Eigenschaften, weil sie z.B. wenn Sie das TestCase-Verhalten manuell ändern (Dialogfeld Optionen). – fheub