In einem meiner Projekte verhielten sich Teile der Anwendung äußerst volatil.
Meistens waren die Antwortzeiten der Anwendung im erwarteten Rahmen, doch manchmal, dauerte das Liefern eines Ergebnisses statt einer halben Sekunde plötzlich 10 Sekunden.
Gründe für diese Aussetzer waren oftmals Anbindungen an externe Tools, die z.B. via Webservice ein Ergebnis liefern sollten oder Einträge in eine Datenbank schreiben bzw. aus einer Datenbank lesen mussten.
Diese Fehler waren besonders bei der Auswertung der Testergebnisse nach Ende des Testlaufes sehr nervend, weil zwar der Testfall als fehlerhaft markiert wurde, aber eine einfache Wiederholung den Testfall wieder „grün“ werden ließ.
Was sollten wir also tun, um bei der Analyse der Testergebnisse Zeit zu sparen?
Mit sleeps und Verzögerungen arbeiten?
Das wäre keine gute Idee, weil so die Tests auf den langsamsten Testlauf angepasst werden und viel Zeit mit reinem Nichtstun verschwenden.
Eine bessere Lösung ist der Einsatz von Warte- bzw. Synchronisationspunkten, die auf bestimmte Zustände von Feldern oder auf das Erscheinen eines Objekts warten.
Der Test sollte dann fortgesetzt werden, sobald die gewünschte Eigenschaft eintritt bzw. das erwartete Objekt erscheint.
Ein Beispiel hierfür ist z.B. das Warten auf einen bestimmten Maskentitel nach Klick auf einen Button, z.B. sollte nach dem Klick auf „OK“ eine Maske mit dem Titel „Menge“ erscheinen.
Nun sind mit diesem Ansatz ca. 90% der Probleme gelöst worden.
Doch es gab noch eine hartgesottene Anzahl an Tests, die immer wieder Aussetzer hatte und trotzdem an den überraschendsten Stellen den Dienst versagte.
Das lag vor allem daran, dass die abgefragten Schnittstellen, wie Webservices oder Datenbanken, selbst Aussetzer hatten.
Die Lösung dieser Herausforderung war, dass alle fehlerhaften Testfälle des aktuellen Testlaufes vom Testszenario selbstständig noch einmal wiederholt wurden und die Ergebnisse der beiden Läufe zusammengeführt wurden. In den Testergebnissen wurde nur der letzte Stand des Testfalles gezählt, der Fehler im ersten Durchlauf wurde nur auf Wunsch ausgewertet, was in unserem Fall nicht passierte.
Fehler, die nun immer noch im Testreport aufschienen, waren also wirkliche Fehler, die analysiert werden mussten.
Die sporadischen Fehler nahmen im Nachgang der Analyse nicht mehr so viel Raum ein.
In diesem Projekt ging es um das Testen einer Kassensoftware (POS) für mehrere Vertriebsformate und Sprachen.
Realisiert wurden die automatisierten Tests mit QF-Test. QF-Test verfügt über eingebaute Synchronisations- und Wartemöglichkeiten.
Die Wiederholung der fehlerhaften Testfälle wurde in einem speziellen „Rerun“ Skript mittels TestRunListener API umgesetzt.
Falls Sie mit uns über ähnliche Herausforderungen sprechen wollen, kontaktieren Sie uns unter service@die-gute-it.de.