Gui Testautomatisierung

Gui-Test-Automatisierung

Eine neue Art der GUI-Testautomatisierung. GUI Testautomatisierung in Theorie und Praxis. Was ist der richtige Umgang mit der Testautomatisierung? GUI-Testautomatisierung mit Abbot Framework. Die GUI-Prüfung ist ein wichtiges Werkzeug zur Qualitätssicherung von Webanwendungen.

Die 4 wichtigsten Gerüche in der GUI Testautomatisierung

Codegerüche sind seit langem ein weit verbreiteter Begriff in der Software-Entwicklung, um potenzielle Fehler im Quelltext aufzudecken. Es wurde vor allem durch Martin Fowler und Kurt Beck mit dem Werk "Refactoring - Improving the Design of Existing Code" bekannt, das die gebräuchlichsten Codegerüche und Korrekturmöglichkeiten in Gestalt von "Refactorings" systematisierend aufzeigt.

Da die Testautomatisierung ein wichtiger Teil der modernen Software-Entwicklung ist (siehe Thomas Bucsics Artikel "Testautomatisierung auf dem Vormarsch"), ist es auch hier durchaus angebracht, das Codegeruchskonzept aufzugreifen. In diesem Artikel werden die Top 4 (Code) Gerüche in der GUI Testautomatisierung beschrieben und mögliche Varianten aufgezeigt.

Martin Fowlers Einführung ist die recht klare Begriffsbestimmung, die für den Anwendungsbereich dieses Beitrags vollkommen ausreichend ist und Codegerüche wie folgt umschreibt: "Ein Codegeruch ist eine Oberflächenanzeige, die in der Regel einem tieferen Systemproblem entspricht. Bei automatisierten GUI-Tests wollen wir uns nun die vier nachfolgenden Gerüche näher ansehen:

click (); Wie man gleich sehen kann, beinhaltet die Testfall-Spezifikation eine Fülle von realen Testdaten: Oft wird dieser Geruch bei aufgenommenen Tests (Capture & Replay) gefunden, die ohne weitere Verarbeitung ausgenutzt wurden. Problematisch dabei ist, dass der Gelingen eines Testfalles von realen Versuchsdaten abhängt, die nichts mit dem tatsächlichen Versuchsziel zu tun haben (das Anmelden von Nutzern ist nur eine Voraussetzung).

click (); Dieses Beispiel verdeutlicht auch sehr gut, dass eine Code-Shell nicht notwendigerweise ein zugrunde liegendes Fehlerbild anzeigen muss. Beispielsweise kann die Nutzung einer bestimmten Produktkennzeichnung angenommen werden, wenn man sich darauf verlässt, dass dieses Gerät in jedem Falle auffindbar ist. Weiterhin muss deutlich sein, dass der Test aufgrund dieser Veränderung natürlich noch lange nicht "optimal" ist, aber zumindest eine Code-Shell entfernt wurde und die Implementierung einer programmlokalen Variablen "defaultValidUser" die verwendete Wortbedeutung der Messdaten ausdrücklich dokumentieren und damit das tatsächliche Messziel verdeutlichen kann.

Ähnlich wie in der Software-Entwicklung ist der redundante Quelltext ein großes Hindernis für zukunftsfähige Software-Komponenten und führt zu unnötigem Aufwand und Fehlerpotenzial. Daher ist das Vorhandensein von überflüssigem oder doppeltem Quelltext eine wichtige Shell, die oft auf eine verborgene und noch nicht realisierte abstrakte Darstellung hindeutet (z.B. eine Methodik oder Klassen, die diese Funktion kapselt).

In allen Ausführungen sind jedoch auch Prüfschritte ("Webshop starten", "Login mit Benutzer und Passwort" und "Benutzer anmelden") enthalten, die für das tatsächliche Prüfziel gegenstandslos sind. Ab sofort werden diese von jedem einzelnen Anwendungsfall automatisiert referiert und müssen nur noch einmal gepflegt werden. Nehmen wir den nachfolgenden automatischen Test an: Hier sind nicht nur die in einem Test beschriebenen funktionalen Vorgänge, sondern auch, wie sie auf die technischen Bestandteile einer Webanwendung gemappt werden (z.B. durch CSS-Selektoren wie "#usernameInput" oder "#profile.welcomeMessage").

Auch hier ist die Frage, wie man damit umgeht, sehr situationsabhängig und wie allgemein für Gerüche zutreffend, dass nicht jedes Ereignis auch auf ein konkretes Problemfeld hinweisen muss. Wir werden jedoch im praktischen Beispiel den Versuch unternehmen, die technische Seite so weit wie möglich aus dem Test zu entfernen. Dies ist besonders dann von Bedeutung, wenn ein Test nicht nur auf einer Technik ausgeführt werden soll, sondern wenn verschiedene einschlägige Ziel-Plattformen bereitstehen.

Zum Beispiel ein Testcase, der eine Desktop-Webanwendung, eine Handy-Webanwendung und möglicherweise nativ auf Android und iPhone ausprobiert. Dann müßte der Beispielfall für jede Technik doppelt ausgeführt werden, obwohl der Geschäftsprozeß auf jeder dieser Plattformen gleich ist. In vielen GUI-Testautomatisierungsprojekten ist der Geruch zu finden, dass es eine unmittelbare Beziehung zwischen der Spezifikation des Testfalls und der tatsächlichen Ausführung gibt. Privates BrowserWindow-Fenster; dies.

fenêtre; Keyboard.SendKeys(this. inputField(), searchQuery) ; Mouse.click(this. submitSearchButton()); Rückgabe neuer SearchResultsPageWithoutClient(this. window) ; UITestControl SuchergebnisEingabeFeld = neues UITestControl(this. window) ; searchQueryInputField = neues UITestControl(this. window) ; searchQueryInputField = neues UITestControl(this. window); searchQueryInputField. In diesem Beispiel kann der Test also nur auf einer bestimmten Technik (SeeTest auf iOS) ausgeführt werden, obwohl die selbe Funktionsbeschreibung auch für andere Techniken (z.B. zum Test einer Webanwendung mit dem WebDriver Selenium) gelten könnte.

Bei leicht zu wartenden automatisierten Testfällen ist es daher wünschenswert, von einer bestimmten Schicht der Ausführung weitestgehend abhängig zu sein. Dies kann durch die Implementation einer weiteren Abstraktionsebene ( "Client") erfolgen: dem privaten Kunden für den WebUIClient; dies. Mandant = Mandant; Mandant. TypeText(searchQuery, "sb_form_q"); Kunde. Cliquez On("sb_form_go") ; liefert neue SuchergebnissePageWithClient(this. client) ; fenêtre privée; Fenster = Fenster; variables Elem.

SendKeys (element, text); variable Elemente = dies. findElementBy(identifier); Maus. Klicken (Element); UITestControl-Element = neues UITestControl(dieses. Fenster); Elemen. TechnologieName = "Web"; Element.SearchProperties.Add(HtmlControl.PropertyNames. Id, identificateur); Rückgabeelement; Rückgabeelement; Rückgabeelement; Rückgabefenster. Doch nicht jedes Vorkommen des Geruchs deutet auf ein zugrunde liegendes Phänomen hin. Aus eigener Anschauung können Sie sich viele weitere Gerüche in der GUI-Testautomatisierung denken und berichten: "Fehlende Separation von Voraussetzungen und tatsächlichem Testziel", "Mehr als ein Testobjekt pro Testfall" oder "Fehlende oder ungenügende Fehlerbearbeitung und Protokollierung".

Deshalb die Fragestellung: Was ist Ihr (un)liebstes Beispiel von Gerüchen in automatischen Tests und vor allem, wie haben Sie damit umzugehen? Nach dem Bachelorstudium der Computerwissenschaften an der FH Technikum Wien und dem anschließenden Masterstudium in den Bereichen Multimediale Entwicklung und Software-Entwicklung konzentrierte sich Stefan Gwihs vor allem auf die Bereiche der agilen Software-Entwicklung und Testautomatisierung.

Auch interessant

Mehr zum Thema