zurück
Avatar of Martina Schmid
Autor: Martina Schmid
29. April 2021

Seminararbeit | Testautomatisierung von KeePass mit QF-Test

"Warum zerbrechen meine automatisierten GUI-Tests?" das war die Seminarfrage eines Studenten. Damit hat er die zentrale Frage für die Testautomatisierung gestellt. Denn der Erfolg dieser, ebenso wie die tägliche Arbeit der QA, steht und fällt mit der Wiedererkennung der Objekte - oder eben deren Scheitern/Zerbrechen der Tests.

Sein Forschungsobjekt war KeePass für Windows in den Versionen 2.0 bis 2.18 (=SUT, System under test). Mit QF-Test Version erstellte er für KeePass2.00 GUI-Tests, die er in den folgenden 17 Versionen abspielte.

Zum Exzerpt der Seminararbeit

Komplette Seminararbeit als PDF

Wenn Tests fehlschlugen, woran lag das? Er hat drei Hauptgründe (neben Einzelgründen wie Verschwinden einer Komponente) gefunden und von all denen die Kategorie "Triviale Umbenennungen" als Hauptursache ausgemacht.

Wie repräsentativ ist sein Ergebnis für die Erfahrungen des Support-Teams von QFS?

Dort wurde mir bestätigt, dass - wenn Tests fertig sind und laufen - ebenso triviale Umbenennungen bei der Weiterentwicklung des SUT den Schwerpunkt der Anfragen im Support-Team ausmachen. Heißt, GUI Tests zerbrechen ganz oft, weil sich die Erkennungsmerkmale der Komponente geändert haben.

⇒ Also liebe Entwickler:

Bitte eineindeutige Namen oder IDs setzen und diese nie mehr anfassen.

Wie in der Seminararbeit geschrieben, "Lock Windows" zu "Lock Window" zu ändern ist für einen Entwickler und Menschen klar als "identisch" erkennbar, aber ein Testautomat stolpert darüber.

QF-Test entwickelt seine Konzepte zur Komponentenerkennung stetig weiter und optimiert den Algorithmus, um die erstellten Tests möglich robust gegen Änderungen zu machen. Es bietet verschiedene Möglichkeiten auf die Erkennung der GUI-Komponenten Einfluss zu nehmen um diese so stabil wie nur möglich zu gestalten.

Aktuell wird ein neuer Ansatz entwickelt, der es erlauben wird, den Suchbereich für eine Komponente noch dedizierter einzugrenzen, um so neben einer stabileren Erkennung durch Ausschluss von multiplen möglichen Komponenten die Test noch stabiler und darüber hinaus auch schneller zu machen. Außerdem wird die Wartbarkeit erhöht, da man keine komplexen Komponentenbäume mehr pflegen muss.

Neuer Kommentar
( wird auf der Seite/Blog erscheinen )
( wird nicht auf der Seite/Blog erscheinen )

1 Kommentare

Christian P

29. April 2021

Sehr interessante Arbeit, die Ergebnisse kann ich aus eigener Erfahrung bestätigen!

 

Zu "Eigenschaften des GUI-Test Frameworks kennen":

Neben der Bedeutung des Namens einer Komponente wird bei QFTest auch die Struktur sehr hoch gewichtet.

Das ist bei uns eine etwa ebenso grosse Fehlerquelle wie der Name der Komponente.

Grund ist, dass bei Webanwendungen häufig enorme Schachtelungstiefen an z.B. div Elementen erreicht wird.

Selbst kleinste Änderungen am Code ohne sichtbaren optischen Effekt können zu einer geänderten Komponentenhierarchie und damit zu fallenden Tests führen.

 

Ein häufiger Fehler speziell bei JSF UIs sind bei uns vom Framework automatisch generierte IDs => bei der nächsten Anpassung des UIs ändern sich potentiall alle automatisch genierten IDs und die Tests schlagen entsprechend fehl obwohl keine relevante Änderung am Code gemacht wurde.

 

Bezüglich Fehlertoleranz:

Leider können zu laxe Kriterien auch eine zusätzliche Fehlerquelle sein.

z.B. wenn ein Button nur über den Namen gematched wird. Das funktioniert oft anfangs gut bis jemand einen zweiten Button mit demselben Namen auf der Seite unterbringt. Mit etwas Pech wird einfach zufällig einer der Buttons geklickt was dann zu wackelnden Tests und einer zeitaufwändigen Fehleranalyse führt.

Oder einfach den ersten Button klicken und später sortiert jemand die Buttons um - dann wird der falsche Button geklickt und oft tritt erst ein paar Schritte später ein Fehler auf was wiederum zu erhöhtem Zeitaufwand bei der Fehleranalyse führt.

 

Ich bin zufrieden mit der Komponentenerkennung in QFTest, diese war mit Abstand die Beste in unserer Evaluation einer UI Test Lösung und ausschlaggebend für die Auswahl von QFTest.

Ich bin schon gespannt auf den im Artikel erwähnten neuen Ansatz.