Testen im industriellen Umfeld -Testautomatisierung von Systemtests mitContinuous Integration & CoContinuous Integration Umgebungen werden in der Regel im Software-Entwicklungszyklus für die kontinuierliche Integration derSoftware eingesetzt. In diesem Artikel zeigen wir, dass sich solche Systeme auch hervorragend für die Realisierung von automati-sierten Test-Infrastrukturen im industriellen Umfeld eignen. Die konkrete Umsetzung ermöglicht vollständig automatisierteSystem- und Akzeptanztests von Softwareprodukten zur Überwachung und Steuerung von Messtechnik-Sensoren.

■ Nightly-Tests sollen eine automatisierteAus führung der Tests über Nacht erlau-ben. Die sonst ungenutzten Rechner -ressourcen kön nen damit sinnvoll einge-setzt werden. Die Tests können manuellüber einen zeitlichen Trigger oder auchdurch eine neue Version der zu testendenApplikation angestoßen werden.

■ Multi-Plattform-Tests sollen es erlauben,die zu testenden Applikationen aufmehreren Betriebssystemen und inunterschiedlichen Sprachen automati-siert zu testen.

■ Da die Software nur in Kombinationmit Hardware (Messgeräte) eingesetztwird, müssen auch “Real-World”-Testsdurchgeführt werden. Dies bedeutet,

Aufgrund der stetig größer werdendenSoftware-Produktpalette wird das manuel-le Testen immer zeitaufwendiger und damitauch kostspieliger. Aus diesem Grund sol-len die Tests der Software in Zukunft weit-estgehend automatisiert ausgeführt werdenkönnen. In diesem Beitrag beschreiben wirdie Konzeption und den Aufbau einer kom-pletten Test-Infrastruktur, die eine weitge-hend automatisierte Durchführung vonSystem- und Akzeptanztests ermöglicht.

ZielsetzungenDurch die automatisierte Test-Infrastruktursoll in erster Linie der enorme Aufwand fürSystemtests gemindert werden. Zusätzlichwerden damit folgende Ziele verfolgt:

AusgangslageDas Unternehmen, für das die Test-Automatisierungslösung entwickelt wurde,ist ein weltweit führender Hersteller vonMess- und Sensortechnik. Immer wichtigerwerden dabei auch Komplettlösungen fürKunden, welche auch Software-Anwen -dungen zur Steuerung und Überwachungder Anlagen beinhalten.

Die Software wird auf unterschiedlichenWindows-Betriebssystemen und in unter-schiedlichen Sprachen eingesetzt.

Für das Unternehmen mit hohenQualitätsansprüchen nimmt das Testen derSoftware einen entsprechend hohenStellenwert ein. Umfangreiche Testspezifi -ka tionen und ausführliche Tests stellen dieSoftwarequalität sicher.

Aktuell werden die Tests auf System- undAkzeptanztestniveau (Black-Box-Tests)vorwiegend manuell ausgeführt. Hierfürwird die zu testende Applikation auf unter-schiedlichen Betriebssystemen installiertund anhand der Testspezifikation manuellgetestet. Die Testergebnisse werden eben-falls manuell erfasst und dokumentiert. Diezu testende Applikation liegt in allen Fällennur als Binär-Datei vor. Der Quellcode derApplikation wird bei diesen Tests nichtberücksichtigt.

der au tor

1 www.objektspektrum.de

fachartikel

Martin Kropp

(E-Mail: martin.kropp@fhnw.ch)Informatik-Dozent am Institut für Mobile und Verteilte Systeme der FHNordwestschweiz in Brugg-Windisch. Seine Interessen gelten allenAktivitäten der Software Konstruktion, inklusive Automatisierung, Testen,Refactoring und Agile Methoden. Er steht dem Software EngineeringNetzwerk SWEN vor.

Anja Kellner

(E-Mail: anja.kellner@students.fhnw.ch) Studentin des Master of Science in Engineering, Fachrichtung ComputerSciences an der FH Nordwestschweiz. Ihre Interessen gelten dem Testen vonSoftware, insbesondere der Automatisierung von Software-Tests.

Abb. 1: Screenshot-Ausschnitt Testsuite-View (Beispiel: WindowsCalculator)

dass die Tests immer mit realenMessgeräten durchgeführt werden.Hierfür soll die notwendigeInfrastruktur aufgebaut werden.

■ Die automatisierte Archivierung derTestergebnisse soll es erlauben, zu jederZeit die Ergebnisse von bereits ausge-führten Tests einzusehen. Dies ist insbe-sondere im Fall von Servicefällen wich-tig, für die geprüft werden muss, mitwelchem Ergeb nis die Tests ausgeführtwurden.

■ Auch die Reproduzierbarkeit inKombina tion mit der Verwendung vonrealer Hardware ist eines der Ziele, mitder die Qualität der Tests verbessertwerden soll.

■ Hierfür ist auch die Verwaltung desTest -Codes in einem Versionsverwal -tungssystem wichtig. Damit ist es mög-lich, jederzeit auf den Test-Code einerälteren Version der zu testendenApplikation zu springen.

TestkonzeptDas gesamte Testkonzept lässt sich in dreiHauptbereiche unterteilen:

■ die eigentliche Automatisierung derSystemtests (Testautomatisierung),

■ den Aufbau einer geeigneten System-Landschaft (Infrastruktur) und

■ die Definition des Testablaufs (Test -prozess).

TestautomatisierungBei den durchzuführenden Tests handelt essich um Systemtests, d. h. reine Black-Box-

Tests, bei welchen die zu testendeApplikation zur Ausführung kommt. Fürdie Automatisierung dieser Tests bieten sichidealerweise GUI-Testautomatisierungs-Werk zeuge an (GUI: Graphical UserInterface). Diese ermöglichen es, auf derGUI der zu testenden ApplikationAktionen auszuführen und danach denZustand zu prüfen. Die meisten dieserWerkzeuge verfügen auch über einenCapture-Replay-Mechanismus, der esermöglicht, Bedienabläufe aufzuzeichnen,als Skript anzupassen und ablaufen zu las-sen.

Nach einer ausgiebigen Evaluation ver-schiedener Werkzeuge, haben wir uns fürRanorex (vgl. [Ran]) entschieden. DiesesProdukt war insbesondere in Bezug auf dieObjekt-Erkennung der graphischen Steuer -elemente auf der GUI der zu testendenApplikationen den anderen evaluiertenProdukten überlegen.

Die Objekterkennung von Ranorexbasiert auf XPath-ähnlichen Pfaden. JedesObjekt auf der GUI der zu testendenApplikation ist über einen solchen Pfad ein-deutig identifizierbar. Über das sogenannteObject-Repository werden diese PfadeObjekten zugeordnet.

Ranorex Testmodule bilden die möglichenAktionen ab und werden in C# implemen-

tiert. Die neueste Version Ranorex 3.x ver-fügt zudem über eine sogenannte Testsuite-View (siehe Abbildung 1), die es erlaubtmittels Drag&Drop Testmodule in beliebi-ger Reihenfolge auszuführen.

InfrastrukturDie Infrastruktur für die Testautoma -tisierung soll möglichst vor Einflüssen vonaußerhalb geschützt sein. Aus diesemGrund wurde ein eigenes Netzwerk für dieTestautomatisierung aufgebaut (sieheAbbildung 2):

■ File-Exchange Server: Mit diesem kön-nen Daten zwischen dem Firmen -netzwerk und dem Automati -sierungsnetzwerk ausgetauscht werden.Insbesondere dient dieser Server dazu,die Installationspakete der verschiede-nen Produkte und Produktversionen zuverwalten.

■ Proxy: Dieser dient als Schnittstellenach außen (Zugriff auf Lizenzserver,Internet und das Versionsverwal tungs -system).

■ Rack mit Automation-PC: Die sogenannten Racks enthalten dieHardware (Messgeräte, Bussysteme,…), die für die Ausführung der Testsbenötigt werden („Real-World“-Tests).Zusätzlich steht hier ein Computer, aufdem die Tests in der benötigtenUmgebung ausgeführt werden. DieserRechner verfügt über zwei Netz -werkkarten:■ eine ist mit dem Automatisierungs-

Netzwerk verbunden,■ die zweite mit den Geräten im Rack

(privates Netzwerk des Racks). Der Automation-PC hat weder einenBildschirm, noch Maus oder Tastatur.

■ Remote-PC: Dieser PC dient dazu, perRemote-Verbindung auf die Automa -tion-PCs zuzugreifen. Dies kann nötigsein, um den Status des Rechners zuprüfen, aber auch für die Entwicklungund Ausführung von Testskripten

■ CI- & Build-PC: Auf diesem Computerist die Continuous-Integration-Umge -bung installiert. Er ist somit der Master,der die Ausführung der automatisierten

2Online-Themenspecial Testing 2011

Online-Themenspecial Testing 2011 fachartikel

Abb. 2: Netzwerk für Testautomatisierung

Abb. 3: Testprozess

reproduzierbar ist. Die virtuellen Maschi -nen werden automatisiert auf dieAutomation-PCs der Racks geladen undgestartet.

Der Testprozess soll entweder manuellfür eine ausgewählte Produktversion, auto-matisch über Nacht oder Ereignis-gesteuertbei einer neu verfügbaren Produktversionauf dem File-Exchange-Server angestoßenwerden.

Die Ausführung des gesamtenTestprozesses wird über ein Continuous-Integration-Werkzeug gesteuert. Die kon-krete Umsetzung wird weiter untenbeschrieben wird.

Abbildung 3 stellt den gesamten reali-sierten Testprozesses graphisch dar:

Im Folgenden werden die einzelnenSchritte genauer beschrieben:

1. Trigger: Die Testausführung wird aufdem CI-Server entweder durch einenzeitlichen Trigger (Nightly-Tests),manuellen Trigger oder durch eine neueVersion der zu testenden Software aufdem File-Exchange-Server angestoßen.Alle folgenden Aktionen werden aufdem Slave ausgeführt:

2. Testskripte: Der Test-Code wird ausdem Versionsverwaltungssystem ge -holt. Ältere Versionen der Testfälle (inClearCase, eine andere Baseline) kön-nen in Jenkins nur zur Laufzeit ausge-wählt werden, so dass diese Tests nurmanuell angestoßen werden können.Mittels MSBuild wird der Test-Codekompiliert und zu ausführbaren Tests.

3. Virtuelle Maschine: Die benötigte vir-tuelle Maschine wird im gewünschten

automatisiert installierten Applika -tionen ausgeführt.

Als Resultat wird in beiden Fällen ein Test-Report erstellt.

Um die Software-Produkte des Unterneh -mens in verschiedenen Sprachen undBetriebssysteme testen zu können, werdenbereits vorkonfigurierte virtuelle Maschi -nen (VM) verwendet. Dies ermöglicht dieSimulation der unterschiedlichsten System-Setups (Multi-Plattform-Tests). Zusätzlichbietet dieser Ansatz die Möglichkeit, dievirtuelle Maschine gemeinsam mit denTestergebnissen zu archivieren, so dassdamit auch die Umgebung der Tests selbst

Tests auf den Automation-PCs koordi-niert.

Für die Test-Code-Verwaltung wird dasVersionsverwaltungssystem (VCS – VersionControl System) ClearCase UCM von IBM(siehe [IBM-CC]) eingesetzt, welches beidem Unternehmen schon seit längerem imEinsatz ist. Es kann somit auf den Test-Code zu jeder beliebigen Produktversionder zu testenden Applikation zugegriffenwerden.

TestprozessDer gesamte Testprozess soll vom Holender benötigten Test-Quellcodes bis zurArchivierung des Test-Reports vollständigautomatisiert werden.

Für die Automatisierung der Systemtestseignet sich eine Continuous-Integration-Umgebung wie sie üblicherweise für dieSoftware-Integration eingesetzt wird. BeideProzesse weisen einige Gemeinsamkeitenauf:

■ Der benötigte Test-Quellcode muss inbeiden Fällen aus einem Versionsver -wal tungssystem geholt werden.

■ Das Kompilieren und Bilden desQuellcodes ist beiden gemein.

■ In beiden Fällen werden die Software -tests ausgeführt. Während dies bei Soft -ware-Entwicklungsprojekten jedoch inder Regel Unit- und Integrationstestssind, werden im gegebenen Fall dieSystemtests auf den bereits fertigen und

fachartikel

3 www.objektspektrum.de

Abb. 4: Screenshot-Ausschnitt eines erfolgreichen Testreports (Beispiel:WindowsCalculator)

Abb. 5: Jenkins Projekt Übersicht

Zustand gestartet, so dass die Voraus -setzungen für die Tests erfüllt sind.

4. Ausführen der Tests: Die Ausführungder Tests findet in der virtuellenMaschine statt. Auf die VM selbst wirdüber ein Remote-Excecution-Werkzeugzugegriffen.

5. Ergebnis Aufbereitung: Wenn alle Testsdurchlaufen sind, werden die Test -ergebnisse aufbereitet. Die Testergeb -nisse von Ranorex sind XML-Dateien,die innerhalb von Jenkins leicht ver-linkt und mittels Dashboard angezeigtwerden können. Zudem werden dieErgebnisse im Versionverwaltungs -system abgelegt (siehe Abbildung 4).

Umsetzung des Testprozess mittelsContinuous IntegrationZur Steuerung und Ausführung des gesam-ten Testprozesses wird ein ContinuousIntegration (kurz: CI) Werkzeug eingesetzt.Dabei kommt das Open-Source-ProduktJenkins (siehe [Jen]) zum Einsatz.Ausschlaggebend für dessen Wahl warendie große Funktionalität, die sehr guteIntegration mit dem verwendetenVersionsverwaltungssystem, sowie die sehrgute Erweiterbarkeit mittels Plugins. Es hateine große Entwickler-Gemeinde, die sichsehr aktiv an der Weiterentwicklung desSystems beteiligt.

Jenkins selbst wird typischerweise aufeinem eigenen Server installiert und betrie-ben. Jedes Projekt wird in Jenkins als sepa-rater Job definiert. Jeder Job kann separatkonfiguriert werden und so für jedesProjekt der individuelle Build-Prozess defi-niert werden. Hierfür steht in Jenkins einsehr komfortables Web Interface zurVerfügung.

Die folgende Abbildung zeigt einenAusschnitt einer Projekt-Übersicht von

Jenkins für eine Umgebung mit 5 Pro -jekten.

Die Übersicht zeigt durch entsprechendeingefärbte Ballons für jedes Projekt an, obder letzte Build-Durchlauf erfolgreich war,sowie die Stabilität des Build-Prozessesüber die letzten 5 Durchläufe mit Hilfeeines „Wetter“-Symbols.

Die folgenden Abbildungen zeigen exem-plarisch wie mittels Konfiguration inJenkins der zuvor beschriebene Testprozessschrittweise umgesetzt wurde.

Abbildung 6 zeigt die beiden Optionenzum Auslösen des Build-Prozesses. DerDatei-basierte Trigger prüft alle 30Minuten, ob eine bestimmte Datei (in die-sem Fall: irgendein Textdokument) ineinem ebenfalls spezifizierten Verzeichnisvorhanden ist (Hinweis: dies konnte durchdas zusätzlich installierte Plugin „FilesFound Trigger“ erreicht werden). Der zeit-gesteuerte Trigger sorgt dafür, dass dasProjekt mindestens jede Nacht um 0:22Uhr gebildet wird.

Die folgende Abbildung zeigt dieKonfiguration zur Ausführung des eigent-lichen Build- und Test-Prozesses.

Jenkins erlaubt die Konfiguration vonbeliebig vielen Einzelschritten. In Abbil -dung 7 sehen wir, dass zunächst die

MSBuild-Datei zur Kompilation desProjektes ausgeführt wird. Anschließendwird die vorkonfigurierte virtuelleMaschine auf dem Automation-PC gestar-tet und danach mittels Batch-Skript dieTestausführung angestoßen.

Die im Testprozess beschriebeneArchivierung und Veröffentlichung derTestergebnisse wird in Jenkins mit Hilfesogenannter „Post-Build“ Aktionen konfi-guriert wie dies in Abbildung 8 dargestelltist.

Um die vollständige Testausführungwährend der Nacht überhaupt erst zuermöglichen, sollte die Testausführungmöglichst parallel und gleichzeitig auf denverschiedenen Automation-PCs durchge-führt werden. Für die gleichzeitige paralle-le Ausführung der Tests bietet Jenkins dasMaster/Slave-Konzept (siehe [Jen2]).

Dieses Konzept erlaubt es mittelsJenkins-Konfiguration weitere Rechner alssogenannte Knoten in das System aufzu-nehmen. Dazu wird auf dem gewünschtenRechner ein Jenkins-Service gestartet, deres erlaubt, diesen als Knoten in die CI-Umgebung aufzunehmen. Nun kann fürjedes Projekt dezidiert angegeben werden,auf welchem Knoten das Projekt gebildetund ausgeführt werden soll. Wird für einbestimmtes Projekt der Trigger aktiv undstellt fest, dass das Projekt ausgeführt wer-den soll, so wird die komplette Ausführungan den entsprechenden Knoten delegiert,wie dies in Abbildung 9 dargestellt ist. Imgegebenen Fall wurden die Automation-PCs aus den Racks als Knoten registriert,so dass diese parallel Tests ausführen kön-nen.

Erste Erfahrungenund AusblickMit dem beschriebenen Testkonzept ist esmöglich, sehr viele der bisher manuell aus-

4Online-Themenspecial Testing 2011

Online-Themenspecial Testing 2011 fachartikel

Abb. 6: Build Trigger Konfiguration

Abb. 7: Konfiguration des Build- und Test-Prozesses

haben. Beispiele solcher Fehler sind dasFehlschlagen eines Builds, eine falsche oderfehlerhafte virtuelle Maschine. Der Auf -wand der Analyse ist jedoch vertretbar,wenn er mit dem Aufwand manueller Testsverglichen wird.

Continuous-Integration-Umgebungenscheinen auch den Anforderungen für auto-matisierte System- und Akzeptanztestsgerecht werden zu können. Eine Um setzungmit diesen Systemen ermöglicht es, dass dieTest-Sourcen immer zur Laufzeit compiliertwerden können. Dies stellt sicher, dass immerdie aktuellste Version des Test-Codes ver-wendet wird. Zusätzlich ist es möglich, eineUmgebung für die Tests zu schaffen, in derauch Hardware und unterschiedlicheBetriebssysteme verwendet werden können

Was am vorgestellten Ansatz noch nichtso ideal ist, ist die Ausführung der Testsmittels Remote-Werkzeugen in der virtuel-len Maschine. Die Tests werden mittelseiner Remote-Comand-Line auf der virtuel-len Maschine angestoßen. Sind die Testsbeendet (egal mit welchem Ergebnis), lie-fert die Remote-Anwendung einen Erfolgzurück. Das tatsächliche Testergebnis kannnur durch Analyse des Test-Reports ausge-lesen werden. Hier wäre es denkbar, auchdie VM an sich als Slave zu registrieren unddas Build-Projekt in mehrere Teile aufzutei-len, die nacheinander auf jeweils unter-schiedlichen Slaves ausgeführt werden.Dies bedeutet allerdings, dass die VM ent-sprechend vorbereitet werden müsste.

noch manuell vorgenommen werden, dasonst eventuell auch Fehler in ein Bug-Tracking-System eingetragen werden wür-den, die nichts mit den Testergebnissen,sondern mit dem gesamten Prozess zu tun

geführten Tests automatisiert auszuführen.Durch Nightly-Tests können die sonstungenutzten Rechnerressourcen überNacht sinnvoll genutzt werden. DieAnalyse der Testergebnisse muss allerdings

fachartikel

5 www.objektspektrum.de

Abb. 8: Archivierung und Veröffentlichung

Abb. 9: Jenkins Master/Slave Konzept

Literatur & Links

[Ran] Ranorex Homepage, siehe: www.Ranorex.com, 15.08.2011

[Jen] Jenkins, Continuous Integration, siehe www.jenkins-ci.org/, 15.08.2011

[Jen2] Kohsuke Kawaguchi, Distributed Builds, siehe

https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds, 15.08.2011

[IBM-CC] IBM Homepage, siehe http://www-01.ibm.com/software/awdtools/clearcase/, 15.08.2011