Passend zu Ostern bin ich gestern im Robot Framework genau über das Feature gestolpert, dass ich schon immer vermisst habe und welches dabei schon die ganze Zeit da war … aber eins nach dem anderen.
Bei automatisierten Tests ist es eigentlich fast immer so, dass bestimmte Werte in den Tests von der Testumgebung abhängen. Klassiker sind hier URLs (Servernamen) in Selenium-Tests oder Login-Informationen für die Datenbank. Diese unterscheiden sich fast immer auf z.B. den Entwicklermachinen und der CI-Umgebung und müssen daher “irgendwie” als Parameter an die Tests (genaugenommen an die entsprechenden Keywords) übergeben werden. Dies geht beim Robot Framework über die Kommandozeile mittels “–variable NAME:VALUE”, was bei mehr als zwei Variablen allerdings schon sehr unübersichtlich und damit auch schwer wartbar wird.
(weiterlesen…)
Für das Testen in agilen Projekten ist die Testautomatisierung von zentraler Bedeutung. Und Testautomatisierung bedeutet, dass die Tests entwickelt werden. Dies ist ein fundamentaler Unterschied zu manuellen Tests, bei denen Tests anhand von Testplänen ausgeführt werden, in denen die Ausführung der Tests dann mehr oder weniger gut beschrieben ist. Automatisierte Tests wiederum beinhalten im allgemeinen wesentlich mehr als nur ein Aufzeichnen und Abspielen fester Szenarien. Automatisierte Tests sollen einen Rahmen schaffen, um die Funktionalität der zu testenden Applikationen einfach und schnell mit verschiedenen Parametern testen zu können. Dies wird im Idealfall durch ein agiles Test-Tool unterstützt, das hierfür bereits entsprechende Funktionen anbietet. Fast immer wird es jedoch notwendig sein eigene Erweiterungen zu implementieren, um bestimmte Aspekte einer konkreten Anwendung testen zu können.
(weiterlesen…)
Wir nutzen das Robot Framework seit einiger Zeit für die Automatisierung unserer Fachtests und haben damit gute Ergebnisse erzielt. Wobei ich persönlich das Tool schon etwas länger einsetze und von den grundlegenden Konzepten wirklich extrem überzeugt bin. Eine weitere Stärke sind die frei verfügbaren Testbibliotheken, die direkt in eigenen Tests genutzt werden können, z.B. für Selenium und SSH. Bisher hat jedoch eine generische Bibliothek für Tests der Datenbank gefehlt. Ich glaube ich habe entsprechende Testbibliotheken in zwei Firmen schon dreimal geschrieben, da fast jede Anwendung am Ende des Tages eine Datenbank nutzt. Das heisst ein automatisierter Test sollte – zumindest stichprobenartig – prüfen, dass Daten korrekt in die Datenbank geschrieben werden. Auf diese Weise kann eine Anwendung dann wirklich End-to-End getestet werden.
(weiterlesen…)
Das Testen von Web-Seiten mit Selenium ist dank umfangreicher Tools sehr effizient möglich. Mit dem Firefox-PlugIn Selenium-IDE lassen sich die Testschritte aufzeichnen und später dann wieder abspielen. Um eine echte Testautomatisierung zu erreichen wird häufig auch eine Integration mit einem agilen Test-Tool – wie z.B. dem Robot Framework – vorgenommen, welches seine eigene Selenium-Implementierung mitbringt.
Das automatisierte Testen von Webseiten wird jedoch in dem Moment jäh aus gebremst in dem eine Seite angesteuert, die mit SSL verschlüsselt ist, jedoch ein nicht autorisiertes Zertifikat nutzt. Der Browser macht eine Vollbremsung und es öffnet sich ein Dialog, der den Benutzer auffordert das Zertifikat zu akzeptieren. Das ist natürlich nicht wirklich praktisch während eines automatisierten Tests.
(weiterlesen…)
Im Folgenden wird eine echte Detektivgeschichte erzählt mit Jython, Hudson und Tomcat in den Hauptrollen. Unsere Umgebung für kontinuierliche Integration basiert auf dem Robot Framework und Hudson. Dabei läuft der Hudson auf einem Tomcat-Server unter Linux. Von dort werden dann die Robot-Tests gestartet und da wir die Tests (Keywords) in Java implementieren wird hierzu Jython genutzt.
(weiterlesen…)
Wer mit Selenium arbeitet kennt sicherlich das Problem, dass sich bei “komplizierten” Webseiten ein mit der Selenium IDE aufgezeichneter Testfall nicht immer erfolgreich abspielen lässt. Kompliziert bedeutet hierbei oft, dass viel JavaScript im Spiel ist. Manchmal kommt es aber noch schlimmer und man findet einfach keinen passenden XPath- oder DOM-Ausdruck, um ein bestimmtes Element korrekt anzusteuern. In einem solchen Fall kann das Simulieren eines “nativen Tastendrucks” die letzte Rettung sein.
(weiterlesen…)
Kategorie: 
