Testautomatisierungs-Framework: ArchiArchitektur und Typen

Was ist ein Framework beim Automatisierungstest?

A Testautomatisierungs-Framework ist eine Reihe von Richtlinien wie Kodierungsstandards, Testdatenhandhabung, Behandlung von Objektrepositorys usw., die, wenn sie bei der Automatisierungsskripterstellung befolgt werden, positive Ergebnisse wie erhöhte Codewiederverwendung, höhere Portabilität, geringere Skriptwartungskosten usw. erzielen. Dies sind nur Richtlinien und keine Regeln; sie sind nicht obligatorisch und Sie können auch ohne Befolgung der Richtlinien Skripte erstellen. Aber Sie werden die Vorteile eines Frameworks verpassen.

Warum brauchen Sie ein Framework?

Betrachten wir ein Beispiel, um zu verstehen, warum Sie ein Framework benötigen.

Ich bin sicher, Sie haben an einem Seminar/einer Vorlesung/einer Konferenz teilgenommen, bei dem/der die Teilnehmer aufgefordert wurden, die folgenden Richtlinien zu beachten –

• Die Teilnehmer sollten ihre Plätze 5 Minuten vor Beginn einer Vorlesung einnehmen.
• Bringen Sie zum Notieren ein Notizbuch und einen Stift mit.
• Lies die Bauchmuskelntract, damit Sie eine Vorstellung davon haben, worum es in der Präsentation gehen wird.
• Mobiltelefone sollten auf lautlos gestellt werden.
• Benutzen Sie die Ausgangstore am gegenüberliegenden Ende des Vortrags, falls Sie mitten in der Vorlesung gehen müssen.
• Am Ende der Sitzung werden Fragen beantwortet.

Glauben Sie, dass Sie ein Seminar durchführen können? OHNE Einhaltung dieser Richtlinien?

Die Antwort ist groß JA! Natürlich können Sie ein Seminar/eine Vorlesung/eine Konferenz/eine Demonstration auch ohne die oben genannten Richtlinien durchführen. Tatsächlich werden einige von uns sie nicht befolgen, obwohl sie festgelegt sind!

Werden die Richtlinien jedoch befolgt, führt dies zu einem positiven Ergebnis, wie beispielsweise einer geringeren Publikumsverärgerung.traction während der Vorlesungen, erhöhte Teilnehmerbindung und besseres Verständnis des Themas.

Basierend auf dem oben Gesagten, a Ein Rahmenwerk kann als eine Reihe von Richtlinien definiert werden, deren Befolgung zu vorteilhaften Ergebnissen führt.

Testautomatisierungs-Framework ArchiArchitektur: Schlüsselkomponenten

Bevor man die verschiedenen Typen vergleicht, ist es hilfreich, sich anzusehen, was jedes Framework beinhaltet. ArchiDie Struktur beschreibt, wie diese Teile geschichtet sind, sodass eine Veränderung in einer Schicht die anderen nicht beeinträchtigt.

• Testskriptebene: Enthält die Testfälle. Die Skripte bleiben kurz, da sie wiederverwendbare Funktionen aufrufen, anstatt Navigationsschritte zu wiederholen.
• Funktionsbibliothek: Speichert gemeinsam genutzte Aktionen wie Anmelden, Suchen und Abmelden, sodass eine Workflow-Änderung nur einmal vorgenommen werden muss.
• Objekt-Repository: Ordnet benutzerfreundliche Namen GUI-Elementen zu. Bei Änderungen der Benutzeroberfläche wird nur diese Ebene bearbeitet.
• Testdatenschicht: Speichert Eingabe- und Sollwerte in Excel-, CSV- oder Datenbankquellen anstatt im Code.
• Konfigurationsschicht: Enthält Umwelt URLs, Browserauswahl, Timeouts und Anmeldeinformationen.
• Berichtsebene: Erstellt Ausführungsberichte, Screenshots von Fehlern und Diagnoseprotokolle.
• Ausführungsschicht: Löst Build-Suites von einem Build-Server aus und verknüpft die Automatisierung mit kontinuierliche integration.

Die unten aufgeführten Framework-Typen unterscheiden sich hauptsächlich darin, wie strikt sie diese Ebenen trennen.

Arten von Testautomatisierungs-Frameworks

Nachfolgend sind die verschiedenen Arten von automatisierten Test-Frameworks aufgeführt:

1. Lineares Scripting
2. Die Testbibliothek ArchiStruktur-Framework.
3. Die datengesteuerte Tests Rahmen.
4. Das schlüsselwortgesteuerte oder tabellengesteuerte Testframework.
5. Das hybride Testautomatisierungs-Framework.

Schauen wir sie uns im Detail an –

1) Lineares Scripting – Aufnahme und Wiedergabe

Es ist das einfachste aller Testautomatisierungs-Frameworks und wird auch als bezeichnet „Aufnahme und Wiedergabe“. In diesem Automatisierungstests Framework: Der Tester zeichnet jeden Schritt manuell auf (Navigation und Benutzereingaben) und fügt in der ersten Runde Prüfpunkte (Validierungsschritte) ein. Anschließend spielt er das aufgezeichnete Drehbuch in den folgenden Runden ab.

Ejemplo: Erwägen Sie, sich anzumelden Flugreservierungsantrag und Überprüfen, ob die Anwendung bei erfolgreicher Anmeldung geladen wurde. Hier zeichnet der Tester einfach die Schritte auf und fügt Validierungsschritte hinzu.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

Vorteile

• Der schnellste Weg, ein Skript zu erstellen
• Automatisierungskenntnisse sind nicht erforderlich
• Der einfachste Weg, die Funktionen des Testtools kennenzulernen

Nachteile

• Wenig Wiederverwendung von Skripten
• Testdaten sind im Skript fest codiert
• Wartungs-Albtraum

2) Die Testbibliothek ArchiStruktur-Framework

Es ist auch bekannt als „Strukturiertes Scripting“ or "Funktionale Zersetzung".

In diesem Automation Testing Framework werden Testskripte zunächst aufgezeichnet durch „Aufnahme & Wiedergabe" Methode. Laterwerden allgemeine Aufgaben innerhalb der Skripte identifiziert und in Funktionen gruppiert. Diese Funktionen werden vom Haupttestskript aufgerufen LED Treiber auf unterschiedliche Weise, um Testfälle zu erstellen.

Ejemplo: Mit dem gleichen Beispiel wie oben sieht die Funktion zum Anmelden bei Flight Reservation so aus.

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

Nun rufen Sie diese Funktion im Hauptskript wie folgt auf

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

Vorteile

• Im Vergleich zu „Aufzeichnen und Wiedergeben“ wird bei strukturiertem Scripting ein höheres Maß an Code-Wiederverwendung erreicht.
• Die Entwicklung der Automatisierungsskripte ist aufgrund der höheren Wiederverwendung des Codes kostengünstiger
• Einfachere Skriptwartung

Nachteile

• Zum Schreiben von Skripten mit dem Test Library Framework ist technisches Fachwissen erforderlich
• Für die Planung und Vorbereitung von Testskripten wird mehr Zeit benötigt.
• Testdaten sind in den Skripten fest codiert

3) Das datengesteuerte Test-Framework

In diesem Rahmen, während Testfall Die Logik befindet sich in den Testskripten, die Testdaten sind separat und werden außerhalb der Testskripte gespeichert. Die Testdaten werden aus externen Dateien (Excel-Dateien, Textdateien, CSV-Dateien, ODBC-Quellen, DAO-Objekte, ADO-Objekte) gelesen und in Variablen innerhalb des Testskripts geladen. Variablen werden sowohl für Eingabe- als auch für Prüfwerte verwendet. Die Testskripte selbst werden entweder mit linearem Scripting oder dem Testbibliothek-Framework erstellt. Die Technik wird im Folgenden näher erläutert. datengetriebenes Testen Tutorial.

Ejemplo: Entwickelnping Das Skript für die Flugreservierungsanmeldung, das diese Methode verwendet, umfasst zwei Schritte.

Schritt 1) Erstellen Sie eine Testdatendatei, die Excel, CSV oder eine andere Datenbankquelle sein kann.

Schritt 2) Entwickeln Sie ein Testskript und verweisen Sie auf Ihre Testdatenquelle.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

Vorteile

• Änderungen an den Testskripten haben keinen Einfluss auf die Testdaten
• Testfälle können mit mehreren Datensätzen ausgeführt werden
• Eine Vielzahl von Testszenarien können ausgeführt werden, indem einfach die Testdaten in der externen Datendatei variiert werden

Nachteile

• Es wird mehr Zeit benötigt, um sowohl Testskripte als auch Testdaten zu planen und vorzubereiten

4) Das schlüsselwortgesteuerte oder tabellengesteuerte Test-Framework

Das Keyword-gesteuert Oder: Die Entwicklung eines tabellengesteuerten Automatisierungsframeworks erfordert Datentabellen und Schlüsselwörter. unabhängig von der Testautomatisierungswerkzeug verwendet, um sie auszuführen. Tests können mit oder ohne die Anwendung entworfen werden. Bei einem schlüsselwortgesteuerten Test wird die Funktionalität der zu testenden Anwendung in einer Tabelle sowie in Schritt-für-Schritt-Anleitungen für jeden Test dokumentiert.

Es gibt drei grundlegende Komponenten eines Keyword-Driven Frameworks, nämlich Schlüsselwort, Anwendungszuordnung und Komponentenfunktion.

Ein Schlüsselwort ist eine Aktion, die an einer GUI-Komponente ausgeführt werden kann. Beispiele für Schlüsselwörter (Aktionen) für Textfelder von GUI-Komponenten sind InputText, VerifyValue, VerifyProperty usw.

Was ist die Anwendungskarte?

Eine Anwendungszuordnung stellt benannte Referenzen für GUI-Komponenten bereit. Anwendungskarten sind nichts anderes als „Objekt-Repository"

Was ist Komponentenfunktion?

Komponentenfunktionen sind Funktionen, die die GUI-Komponente aktiv manipulieren oder abfragen. Ein Beispiel für eine Funktion wäre: Klicken Sie auf die Web-Schaltfläche mit vollständiger Fehlerbehandlung und geben Sie Daten in eine Web-Bearbeitung mit vollständiger Fehlerbehandlung ein. Komponentenfunktionen können anwendungsabhängig oder unabhängig sein.

Beispiel: Um die Keyword-Ansicht zu verstehen, nehmen wir dasselbe Beispiel. Es umfasst 2 Schritte

Schritt 1:: Erstellen einer Datentabelle (anders als die im Data Driven Framework erstellte Testdatentabelle). Diese Datentabelle enthält Aktionen, die für GUI-Objekte ausgeführt werden sollen, und gegebenenfalls entsprechende Argumente. Jede Zeile stellt einen Testschritt dar.

Schritt 2:: Schreiben Code in Form von Komponentenfunktionen.

Sobald Sie Ihre Datentabelle(n) erstellt haben, schreiben Sie einfach ein Programm oder eine Reihe von Skripten, die jeden Schritt einlesen, den Schritt basierend auf dem im Feld „Aktion“ enthaltenen Schlüsselwort ausführen, eine Fehlerprüfung durchführen und alle relevanten Informationen protokollieren. Dieses Programm oder dieser Skriptsatz würde dem folgenden Pseudocode ähneln:

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

Das ist alles zum Keyword Driven Framework.

Der Vorteil des Keyword Driven Frameworks besteht darin, dass die Schlüsselwörter wiederverwendbar sind. Um dies zu verstehen, stellen Sie sich vor, Sie möchten den Anmeldevorgang für eine Website, beispielsweise YAHOO MAIL, überprüfen. Die Tabelle sieht dann so aus:

Beachten Sie, dass in diesem Fall die Schlüsselwörter „Set“, „Click“ und „Verify“ unverändert bleiben, da entsprechende Komponentenfunktionen bereits entwickelt wurden. Sie müssen lediglich die Anwendungszuordnung ändern.ping (Objekt-Repository) von der früheren Flugreservierung zu Yahoo Mail , mit einer Änderung der Argumentwerte und das gleiche Skript wird funktionieren!

Vorteile

• Bietet eine hohe Wiederverwendbarkeit des Codes
• Unabhängig vom Testtool
• Unabhängig von der zu testenden Anwendung funktioniert dasselbe Skript für AUT (mit einigen Einschränkungen).
• Tests können mit oder ohne AUT entworfen werden

Nachteile

• Da die Anfangsinvestition recht hoch ist, können die Vorteile nur dann realisiert werden, wenn die Anwendung beträchtlich groß ist und die Testskripte über mehrere Jahre hinweg gepflegt werden müssen.
• Für die Erstellung des Keyword Driven Framework ist eine hohe Automatisierungskompetenz erforderlich.

HINWEIS: Obwohl OpenText UFT One (ehemals Micro Focus) UFTObwohl es sich selbst als Keyword-Driven Framework bewirbt, kann man damit keine vollständige Unabhängigkeit von Testwerkzeugen und Anwendungen erreichen.

5) Das Hybrid Test Automation Framework

Wie der Name schon sagt, handelt es sich bei diesem Framework um eine Kombination aus einem oder mehreren der oben besprochenen Automatisierungs-Frameworks, die ihre Stärken ausnutzen und versuchen, ihre Schwächen abzuschwächen. Das hybride Test-QA-Automatisierungs-Framework ist das, woraus sich die meisten Testautomatisierungs-Frameworks im Laufe der Zeit und mehrerer Projekte entwickeln. Maximum Industry verwendet das Keyword Framework in einer Kombination aus Funktionszerlegungsmethoden.

PS: Andere erwähnenswerte Automatisierungs-Frameworks sind

Testen Sie das Modularitäts-Framework

In diesem Framework werden häufige Aufgaben im Testskript als Module gruppiert.

Beispiel: Verwendung von Aktionen in QTP Der Benutzer kann modulare Skripte erstellen.

Beispielskript für die Anmeldung

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

Jetzt können Sie diese Aktion im Hauptskript wie folgt aufrufen:

RunAction ("Login[Argument]", oneIteration)

Geschäftsprozesstests (BPT)

Diese Automatisierungs-Frameworks unterteilen große Geschäftsprozesse in Komponenten, die im selben oder in verschiedenen Testskripten mehrfach wiederverwendet werden können. Beispielsweise ist der Geschäftsprozess der Flugbuchung in Komponenten wie Anmeldung, Flugsuche, Buchung, Zahlung und Abmeldung unterteilt, die im selben Geschäftsprozess oder in verschiedenen Prozessen wiederverwendet werden können. Außerdem erleichtert BPT eine engere Koordination zwischen KMU und Automatisierungsingenieuren.

Wie man das richtige Testautomatisierungs-Framework auswählt

Es gibt keine allgemeingültige Lösung. Die richtige Wahl hängt von den Fähigkeiten des Teams, der Größe der Anwendung und der erforderlichen Laufzeit der Suite ab. Die folgende Tabelle vergleicht die fünf Lösungstypen anhand der ergebnisentscheidenden Faktoren.

Beantworten Sie diese Fragen, bevor Sie sich festlegen:

1. Wie lange wird die Suite bestehen? Jahrelange Wartung rechtfertigt die hohen Anfangsinvestitionen eines keywordbasierten oder hybriden Designs. Bei einem Kurzzeitprojekt ist dies nicht der Fall.
2. Wer erstellt die Tests? Wenn manuelle Tester Testfälle beisteuern, ermöglicht ihnen eine Schlüsselworttabelle, zu arbeiten, ohne die Skriptsprache lernen zu müssen.
3. Wie volatil ist die Schnittstelle? Häufige Bildschirmwechsel machen ein separates Objektrepository unerlässlich, andernfalls muss jedes Skript bearbeitet werden.
4. Wie viel Datenvariation ist erforderlich? Viele Eingangskombinationen deuten direkt auf ein datengetriebenes Design hin.
5. Welches Werkzeug ist bereits im Einsatz? Das Rahmenwerk muss zu den gewählten Spezifikationen passen. Automatisierungswerkzeug und eine Sprache, die das Team beherrscht, wie zum Beispiel Selenium und Java or Cucumber.

Die meisten Teams beginnen mit einem bibliotheks- oder datengetriebenen Ansatz und entwickeln sich dann zu einem Hybridmodell weiter. Regression Die Suite wird erweitert.

Vorteile des Testautomatisierungs-Frameworks Architektur

Im Folgenden sind die Vorteile der Testautomatisierungs-Framework-Architektur aufgeführt:

• Ein Testautomatisierungs-Framework hilft, das Risiko und den Kostenaufwand zu reduzieren
• Es verbessert die Effizienz von Tests
• Es trägt dazu bei, die Wartungskosten zu senken
• Ermöglicht die Wiederverwendung von Code
• Dadurch kann eine maximale Testabdeckung erreicht werden
• Es maximiert die Anwendungsfunktionalität
• Hilft, die Duplizierung von Testfällen zu reduzieren
• Es hilft, die Testeffizienz und -leistung durch Testautomatisierung zu verbessern

Häufig gestellte Fragen