In unserem aktuellen Projekt werden ziemlich viele Selenium Tests erstellt und ausgeführt. Selenium Tests bedürfen einer besonders Intensiven Wartung und Pflege. Der Künde wünschte sich ein Monitoring über den Zustand der Tests in zeitlicher Hinsicht. Jenkins bietet einige Plugins zur Visualisierung an, aber das reichte uns nicht. Ziel war es eine Gesamtsicht  und Einzelsicht auf alle Test Module zu haben. Bei jeden Test sollte erkennbar sein bei welchen Build Lauf er erfolgreich war oder nicht.

UnitTH ist ein kleines Java Tool das aus den Unit Test Ergebnis Dateien einen Report erzeugen kann.

Das Tool untersucht bestehende Unit Test Report XML Dateien und erzeugt daraus ein einen Report. Die zeitliche Achse wird durch Build Läufe erzeugt. UnitTH erkennt die Build Läufe anhand von Ordnern.

Die Reports muss in dieser Struktur vorliegen:

/build1/junit_log1.xml
/build1/junit_log2.xml
/build2/junit_log1.xml
/build2/junit_log2.xml

In den Ordnern können beliebig viele XML Dateien liegen.

Testsuiten sind für das Tool sogenannte Module. Damit wird der Report gegliedert. Man muss also darauf achten das die Suiten in den Reports eindeutige Namen haben und nicht verschachtelte Suiten haben. Meine Report Dateien haben nicht ganz dem Schema entsprochen. Ich wandel die Dateien mit XSLT um.

Der Aufruf erfolgt so:

java -jar -Dunitth.report.dir=/…/unitth/report unitth.jar /…/unitth/xml/*

Man gibt also nur das Ziel Verzeichnis für die Reports und den Pfad zu den XML Dateien.

In den Report bekommt man eine praktische Übersicht über den aktuellen Stand der Tests und den Trend.

Über die Graphen kann man erkennen, wie sich die Testdauer verhält und ob sich die Anzahl der Tests verändert.

Man bekommt eine Liste der Build Läufe und darin zusammengefasst wie deren Status war. Hier sieht man auch schön die aktuellen Trends.

Die Module (Testsuiten) werden auch zusammengefasst dargestellt und man kann sich auf einer Unterseite den Verlauf auf Testcase Basis anschauen. Dadurch kann man besonders kritische Testfälle erkennen und dann stabilisieren.

Das spannendste Feature ist die Spread Ansicht. Hier sieht man, bei welchen Build die Testfälle fehlgeschlagen sind. Damit kann man sogenannte “Blinker” Test finden. Um diese dann zu Isolieren.

Serverumzug mit Kunagi

Um Kunagi auf einen neuen Server zu transferieren muss man keine Datenbank kopieren, da Kunagi ausschließlich XML Dateien zur Speicherung der Daten verwendet. Es gibt aber 2 Dinge die beachtet werden müssen:

1. Url Änderung
   Wenn sich die URL ändert muss das auch in in der Datei /webapps/kunag/iconfig.properties angepasst werden.
2. Starten des Kunagi
   Das Startup Script muss immer von dem gleichen Verzeichniss aus gestartet werden damit Kunagi die richtigen XML Dateien findet. Mann muss das Script auf den neuen Server vom gleichen Verzeichniss starten wie auf den alten Server. Oder relativ gesehen zum /webapps/kunagi Verzeichnis.

Fehlender Burndown Chart unter Linux

Unter Linux kann es beim Erzeugen des Burndown Chart zu folgenden Fehler kommen:

FATAL AHttpServlet         GET failed: scrum.server.sprint.SprintBurndownChartServlet -> 
java.lang.NoClassDefFoundError: Could not initialize class org.jfree.chart.JFreeChart

Das Problem liegt nicht an Kunagi sondern an Java und kann behoben werden in dem man beim Starten des Tomcat folgende Optionen mitgibt:

-Djava.awt.headless=true

Kunagi  http://kunagi.org/ ist eine art digitales Whiteboard zu Unterstützung von Scrum Prozessen.

Das Tool ist webbasiert und kostenlos. Es basiert auf der GWT http://code.google.com/intl/de-DE/webtoolkit/ von Google und benötigt einen Tomcat.

Kunagi hält sich streng an die Regeln von Scrum. So kann im Backlog auch nur der Product Owner eine Story anlegen.

Die Story kann erst in den Sprint aufgenommen werden wenn es geschätzt wurde.  Dafür kann man das Planing Poker starten. Dann erscheint bei allen Usern dieser Poker Screen.

Die Storys können dann in den Sprint übernommen werden. Dort sieht man dann alles Story und die Zusammenfassung

der Punkte.

Dreh und Angel Punkt beim Scrum ist das Whiteboard. Dieses bekommt man in Kunagi mit den 3 Spalten angezeigt und kann zu jeder Story Tasks erstellen. Das sind dann die Notizzettel die man nehmen kann und schließen kann. Hier sieht man auch wer an welchen Punkten arbeitet.

In den Task kann man auch angeben wie viel man davon schon gemacht hat.

Kunagi generiert auf dieser Daten Basis den Burndown Chart.

Hier kann man sehen ob man noch in dem Zeitplan ist und ob man noch Punkte aufnehmen kann oder entfernen muss.

Wir nutzen das Tool jetzt seit einem Sprint und ich bin begeistert. Man hält sich viel strenger an die Scrum Regeln und der Burndown Chart hat wirklich einen Mehrwert. Dem Kunden gefällt das Tool auch da er immer den Überblick hat was das Team gerade macht und ob zeitlich alles hinhaut. Ab und zu kommen mal kleine Fehlermeldungen aber es nichts Gravierendes. Das Tool macht einen professionellen Eindruck.

In diesen Artikel geht es darum wie Selenium Grid installiert wird.

Wozu Selenium Grid?

Man kann Selenium Tests über einen Selenium RC Server automatisiert ausführen. Wer das schon mal gemacht hat, weiß das dieser Prozess sehr lange dauern kann. Insbesondere wenn man verschiedene Browser testen möchte und die Tests mit Dataprovidern verwendet. Das bedeutet das die Tests nicht nur einmal, sondern mehrmals laufen und dann kommen schnell ein paar Stunden zusammen. Diese Zeit ist besonders unangenehm wenn man die Software ausliefern möchte und lange auf die Test Ergebnisse warten muss.

Selenium Grid behebt das Problem in dem es wie eine Art Load Balancer arbeitet. Es existiert ein Hub der genau wie der RC Server die Test Kommandos entgegen nimmt.  Der Hub verhält sich für den Test Client (z.Bsp.: PHPUnit) genauso wie der Selenium RC Server. An den Hub können sich verschieden RC Server Instanzen registrieren. Diese Server können auch auf ganz anderen Host Systemen oder Virtuellen Hosts laufen. Somit kann man auch wirklich alle Browser Varianten testen.

Installation

Man benötigt einen Host der vom Test Client erreichbar ist. Also der Rechner auf der PHPUnit oder JUnit läuft. Auf diesem Host muss Ant installiert sein um den Grid Hub zu starten. Selenium Grid muss man nur herunterladen und entpacken.

Hub Starten

Zum Starten des Hubs wechselt man ich den Grid Verzeichniss und startet den Hub über die buid.xml

ant launch-hub

Damit ist der Hub auf diesen Host unter localhost:4444 erreichbar.

RC Server starten

Den RC Server kann man entweder auf dem dem gleichen Host starten.

ant launch-remote-control -Dport=5555

oder auf einen anderen Host oder VHost

ant launch-remote-control -Dport=5555 -Dhost=vhost1 -DhubURL=http://grid-hub:4444

Host: Das ist die Adresse vom Hub aus gesehen zum Host auf dem der RC Server liegt.

HubUrl:  Das ist die Adresse zum Hub vom Host mit dem RC Server.

Sinnvollerweise betreibt man die RC Server auf getrennten Hosts.

RC Server Einstellungen

Man kann den RC Server der unter Grid läuft genauso anpassen wie einen normalen RC Server. Um beispielsweise ein spezielles Firefox Profil zu verwenden kann man beim Starten des RC Servers noch das Selenium Argument firefoxProfileTemplate mit dem Ant Property seleniumArgs angeben.


ant launch-remote-control -Dport=5555 -DseleniumArgs="-firefoxProfileTemplate C:\selenium_ff"

Umgebungen

Der RC Server unter Grid läuft im Gegensatz zum normalen RC Server immer nur mit einer Umgebung. Standardmäßig ist das “*firefox”. Um eine andere Umgebung zu starten muss das Argument environment angeben.

-Denvironment="*iexplore"

PHPUnit und Grid

Leider ist es nicht möglich den vollen Nutzen aus Grid zu ziehen wenn man mit PHPUnit arbeitet. Da PHPUnit nicht in der Lage ist die Tests parallel auszuführen.

Man kann aber dennoch die Tests mit dem –filter oder –group Argument aufteilen und diese dann parallel ausführen. Hierbei muss man aber dann die Ergebnisse aus den verschiedenen Ausführungen zusammenfassen.

Auf jeden Fall lohnt sich aber die Aufteilung für verschiedene Browser.

Absolut notwendig wird Grid wenn man verschiedene Build Prozesse hat die einen Selenium Server nutzen.

Fazit

Grid lässt sich relativ einfach aufsetzen und erhöht die Test Performance deutlich.

Picabee ist ein Service bei dem man sich kostenlos Fotos entwickeln lassen kann. Das ganze hört sich unglaublich an und hat auch ein paar Nachteile.

1. Mann kann nur alle 30 Tage einen Auftrag absenden.
2. Es können pro Auftrag maximal 60 Bilder bestellt werden.
3. Auf den Bildern ist Werbung.

Die Werbung auf den entwickelten Bildern ist leider sehr present, so das ein Wegschneiden oft gar nicht geht. Teilweise ist die Werbung nicht nur neben den Bild, sondern als Logo auf dem Bild am Rand.

Hier ein paar Beispiele:

Schön gemacht ist aber das Interface zum Hochladen der Bilder. Die gesamte Oberfläche ist in Flash gemacht und sehr performant. Daran könnten sich andere Anbieter ein Beispiel nehmen.

Aktuell bekommt man nur einen Zugang per Einladung. Ich habe noch 3 Einladungen frei, falls jemand dass auch mal ausprobieren möchte.

Bei Google Analytics kann man jetzt die Daten in Segmente aufteilen und anzeigen lassen. Dazu gibt es über den Hauptchart einen neuen Button mit der Beschriftung: Erweiterte Segmente. Mit diesem kann man die Segemente einstellen.

Diese werden dann auf den Chart angezeigt und man kann sie damit gut vergleichen.

Darüber hinaus gibt es noch die Möglichkeit eigene Segmente zu erstellen. Die Segmente erstellt man in mittels einer komfortablen Drag & Drop Oberfläche.

Man kann die Segmente sehr genau einstellen. Wenn man dieses Segment gespeichert hat kann man es in dem Chart auswählen und anzeigen lassen.

Eine Versionsverwaltung gehört mittlerweile zu fast jeden Software Projekt. Für Webeprojekte nutze ich gerne den Anbieter Springloops. Dieser bieten für wenig Geld einen Subversion Server und eine schicke Oberfläche für das Deployment. Wunderbar ist auch die Möglichkeit eines Rollbacks, die ich schon des öfteren benutzt habe.

Seit kurzem haben die Macher von Springloops das Automatische Deployment eingebaut. Man kann jetzt individuell für jeden Ziel Server einstellen ob die aktuellste Version automatisch oder manuell deployed werden soll.

Besonders praktisch ist das, wenn man einen Testserver aufgesetzt hat. Normalerweise setzte ich immer einen Test Server und einen Live Server in Springloops auf. Das geht auch mit ganz simplen Webhosting Packeten. Einfach ein anderes Zielverzeichniss auf den Server auswählen und eine Test Domain darauf konfigieriern.

Bei diesen Testserver macht ein automatisches Deployment Sinn und spart die Klickerei. Man kann es auch gut für die Continuus Integration verwenden wenn man auf diesen Testserver Per Cronjob regelmäßig die Tests ablaufen lasst.

Das schöne an Springloops ist dass man keinerlei Administratoren Kenntnisse braucht und auch keinen eigenen Webserver mit Root Rechten.