 |
OpenKeyWord
Version: 426, Datum:
|
|
OpenKeyWord
Version: 426, Datum:
|
Bestehende Software zu testen muss schnell vorgenommen werden können. Der Einfluss von Erweiterungen und Änderungen an den Objekten des Projektes muss idealerweise sofort und ohne größere Umstände zu testen sein. Ein Testlauf darf keinen hohen Arbeitsaufwand fordern, sonst wird gänzlich auf einen Test verzichtet.
Unittests müssen durch den Entwickler sofort durchführbar sein. Der Unittest muss innnerhalb von Sekunden ablaufen können. Es muss unmittelbar geprüft werden können welche Auswirkungen die Änderungen haben.
Wenn das nicht möglich ist steht zu vermuten, dass die Regeln des Clean Code nicht beachtet worden sind.
Effizientes automatisiertes Testen erfordert die Reduzierung auf eine einzige Stelle, damit erfolgt die Reduzierung des Erstellungs- und Pflegeaufwands auf DAS MINIMUM.
Klonen, bzw. Kopieren von Testfällen oder von Skriptabschnitten erzeugt bei kleinen Änderungen viel Arbeit im Bereich Anpassung. Wenn kleine Änderungen im "Software under Test (SUT)" vorgenommen werden, dann kann das einen großen Aufwand für die Testautomatisierung bedeuten.
{Beispiel} Beispiel . {Beispiel}
Die nun folgenden Absätze verfolgen alle das Ziel das Testen effizient zu machen und befassen sich mit der Aufwandsreduzierung bei der Erstellung von funktionalen, fachlichen GUI Tests.
Dem steht entgegen, dass jeder Test einen Einzelfall darstellt, der EINZELN SPEZIFIZIERT WERDEN MUSS! Führt man die vorbeschriebenen Maßnahmen aber konsequent durch, bedeutet das eine enorme Reduzierung des Erstellungs- und Pflegeaufwandes.
Zur besseren Beherrschung der Testumgebung emfpiehlt es sich eine Synchronisation in die Testumgebung einzubauen. Hierbei ist auch eine gute Benennung der Klassen, Methoden und Sequenzen wichtig. Erst hierdurch wird dann letztlich die Lesbarkeit des Skripts und dessen Nachvollziehbarkeit verwirklicht.
Bei der üblichen Erstellung von Testfällen fallen folgende Arbeiten an:
Hieraus folgt, dass zur Belegung der fachlichen Anforderung eines Testfalls zwei Übersetzungen erforderlich sind:
Folgende Mängel im Übersetzungsprozess können die Erstellung der Automatisierungsscripte erschweren oder verhindern:
Durch eine exakte Beschreibung der Testfälle inkl. der notwendigen Eingabedaten können die genannten Aufwände verringert werden. - Der Arbeitsaufwand wird minimiert, weil Rückfragen der technischen Tester an die fachlichen Tester reduziert werden.
Aber: Eine Fehlinterpretation der Testfälle kann in der Prosa-Notation nicht ausgeschlossen werden. Es sind weiterhin zwei Übersetzungen notwendig:
Die beste Aufwandsreduzierung wird erreicht, wenn Tätigkeiten vollständig beseitigt werden: Wenn die Testfälle mit Schlüsselwörtern beschrieben werden, dann ist eine Übersetzung der Testfälle in die Skriptsprache des Automatisierungswerkzeuges nicht notwendig.
Mit Schlüsselwörtern kann die Notation zur Beschreibung von Testfällen so nahe an einer Prosabeschreibung erfolgen, dass ein Fachtester nicht nur eine manuelle Testfalldurchführung problemlos vornehmen kann, sondern die Beschreibung mit Schlüsselwörtern ist formal genug, dass diese ohne weitere Änderungen automatisierbar sind.
Die Grundidee des schlüsselwortbasierten Testens besteht darin, die Testsequenz, d.h. die Abfolge von Testschritten in einem Testfall, aus vorgefertigten, wohl definierten Schlüsselwörtern zu erstellen.
Wenn jedes Schlüsselwort durch ein Skript einmal automatisiert ist, dann ist auch jede beliebige Testsequenz, die aus diesen Schlüsselwörtern besteht, ohne einen weiteren Arbeitsschritt ebenfalls automatisiert.
(Object-Repository, GUI-Map, Test-Frame)
Die gängingsten GUI-Automatisierungswerkzeuge erkennen ein GUI-Objekt an einer oder mehreren charakteristischen Eigenschaften (Properties oder Attribute). Das kann z.B. die Position oder Größe des Objektes sein. Wichtig ist nur, dass ein GUI-Objekt mit Hilfe dieser Eigenschaften eindeutig identifiziert werden kann.
Die optimale Lösung wäre eine jedem GUI-Objekt eindeutig zugewiesene Test-ID, die über den gesamten GUI-Objektlebenszyklus konstant bleibt und über alle Objekte eindeutig ist. Es gäbe damit keine zwei GUI-Objekte mit einer identischen Test-ID.
Hier stellen wir Selenium vor. Selenium automatisiert Browser, insbesondere für die Automatisierung von Web-Applikationen zu Testzwecken. Es ist nativer Bestandteil vieler gängiger Webbrowser. (weiterführende Infos in engl. Sprache unter http://www.seleniumhq.org/ )
Hier zu nächst ein typisches Beispiel für Selenium:
{lstlisting}[caption={Selenium Beispiel für die Objekterkennung //Quelle: {http://www.anujchaudhary.com/2012/11/selenium-automating-ui-testing-for.html}}, label=SeleniumObjectRecognition] [TestMethod] public void TestBing()
{ Test Case Steps _webDriver.Navigate().GoToUrl("http://www.bing.com");
IWebElement search = _webDriver.FindElement(By.Name("q")); IWebElement go = _webDriver.FindElement(By.Name("go"));
search.SendKeys("james bond"); go.Click();
Verfication
IWebElement msWebsite =
_webDriver.FindElement(
By.XPath( "//a[@href='http://en.wikipedia.org/wiki/James_Bond']")
);
Assert.IsNotNull(msWebsite, "Could not find wikipedia link for James Bond");
}
{lstlisting}
In großen Projekten existieren sehr viele solcher Tests. Hier können mehrere tausend Testfälle mit sehr viel mehr Schritten existieren. Betrachten wir nun die Stellen mit "\_webDriver.FindElement(...)".
Die Objekt-Erkennungseigenschaften ist z.B. "q" in
{IWebElement search = _webDriver.FindElement(By.Name("q"));}
Hier wurde das Objekt erkannt, weil das Attribut {name="q"} ist.
Nach diesem Prinzip arbeiten alle GUI-Automatisierungwerkzeige, womit alle GUI-Objekt erkannt werden. In diesem Beispiel gibt es Wechselwirkungen (Interaktionen) zu drei GUI-Objekten:
Wenn sich eine Objekt-Erkennungseigenschaft ändert, folgert das die Änderung im Testfall. Hier aber kann das Objekt mehrfach verwendet werden, was die Änderung für jedes einzelne Objekt im Testfall erforderlich macht. Das können Tausende sein...
Bei einer solchen Anpassung ergeben sich mehrere Unsicherheiten:
Pauschal "Suchen und Ersetzen" hilft nicht immer: Wenn sich verschiedene Objekte nicht im gleichen Fenster befinden und an identischen Eigenschaften erkannt werden können, funktioniert "Suchen und Ersetzen" nicht.
Verschiede Testautomatisierungswerkzege haben das vorbenannte Problem wie folgt gelöst: Die Objekterkennungseigenschaften werden zentral verwaltet und per Referenz verwendet.
Einige ausgewählte Bezeichnungen für die zentrale Verwaltung der Objekterkennungseigenschaften:
Allen Lösungen ist gemeinsam, dass jedes GUI Objekt einen (fachlichen) Namen erhält und die Objekterkennungseigenschaft dahinter abgelegt wird. So muss nur noch an einer Stelle eine Anpassung vorgenommen werden, wenn sich eine Objekt-Erkennungseigenschaft ändert.
Unter Synchronisation versteht man, das Warten des Skriptes auf die Anwendung.
Eine typische Lösung eines solchen Synchronisation besteht darin eine Methode "WartenAufEigenschaft()" oder "WartenAufObjekt()" einzufügen.
Beispiel: Nach dem Login (Klick auf Login-Button) wird auf das HauptFenster der Anwendung gewartet.
Wird in eintausend Testfällen beispielsweise eintausendmal ein WartenAufObjekt("HauptFenster") eingefügt, müsste im Änderungsfalle (weil evtl. ein Sicherheitsdialog eingefügt wird) an diesen eintausend Stellen das jeweilige Objekt WartenAufObekt ("Hauptfenster") angepasst werden. Auch hier gäbe es keinen Verlass auf "Suchen und Ersetzen".
Hieraus resultieren die nachfolgenden wichtigen Gründe die Synchronisation nicht wie beschrieben vorzunehmen:
Wie sieht aber nun die Lösung aus?
Die Methode 'WartenAufObjekt("HauptFenster")' wird in die Klick-Methode des Login-Buttons integriert.
Beispiel: In Silktest-Klassik, ein Werkzeug für die automatisierte Funktions- und Regressionstests von Unternehmensanwendungen, ist es eine Erweiterung der Klick-Methode. (Mehr Informationen zu Silktest: http://www.borland.com/Products/Software-Testing/Automated-Testing/Silk-Test)
In 4Test ist es abgeleitet: Click() ist der Aufruf der Methode Klick der Super-Klasse. (Mehr Information zu 4Test: http://sqa.fyicenter.com/FAQ/SilkTest/What_is_4Test_.html)
{lstlisting}[caption={Methoden-Überschreibungs-Beispiel für 4Test, (Scriptsprache Silktest-Classik)}, label= ] [-] window PushButton Login [-] Click( ) [ ] [ ] WartenAufObjekt("HauptFenster") [ ] derived::Click() [ ] {lstlisting}
Mit Methoden-Überschreibung (OOP) erfolgt hier die Implementierung an einer Stelle: Die Implementierung der Synchronisation des Logins erfolgt an genau einer Stelle. -> Reduzierung von {n}-Stellen in der Testfallbeschreibung auf eine Stelle im Skript.
1.8.10