Praktikum bei der Bibliotheca RFID Library Systems...

Software Engineering Gruppe

Departement für Informatik

Universität Freiburg (Schweiz)

Praktikum bei der Bibliotheca RFID Library Systems AG

Als Test Ingenieurin

Praktikumsbericht

Bettina Dober

Juli 2008

Unter der Aufsicht von:

Prof. Dr. Jacques Pasquier-Rocha

und

Dr. Patrik Fuhrer

Software Engineering Gruppe

Praktikumsbericht Bettina Dober

I

Zusammenfassung

Während drei Monaten habe ich mich als Praktikantin bei der Bibliotheca RFID Library Systems

AG intensiv mit der Entwicklung eines Test Frameworks für die Durchführung von automati-

schen Tests an der BiblioSelfCheck Software beschäftigt. Dieses Softwareprodukt läuft auf

Selbstverbuchungsstationen von Bibliotheken und bietet den Benutzern die Möglichkeit Bücher

und andere Media selbstständig auszuleihen, zu verwalten und zurückzubringen. Mit dem von

mir entwickelten Testframework können Testsequenzen, sprich Geschäftsprozesse, definiert

werden und automatisch über die normale Benutzeroberfläche der BiblioSelfCheck Anwendung

abgespielt und ausgewertet werden. Das Testframework steuert die Selbstverbuchungsstation

quasi fern, speichert die durchgeführten Prozesse und untersucht diese auf Fehler.

Das Testframework lag von Beginn bis zum Abschluss des Projektes in meiner Verantwortung.

Ich arbeitete selbständig, konnte all mein Wissen und meine Ideen einbringen und in regelmäs-

sigen Abständen besprach ich mein Vorgehen mit Softwareentwickler und dem Chief Technolo-

gy Officer (CTO).

Neben diesem Hauptprojekt war ich tätig als allgemeine Testerin, Dokumentationsverfasserin

und Trainerin an Produkteschulungen.

Das Praktikum hat mir Zugang gewährt in den Arbeitsalltag eines Softwaretesters. Bald stellte

ich grosse Unterschiede zwischen dem Arbeitsalltag und dem Universitätsleben fest. Egal an was

gerade gearbeitet wird, das hektische Alltagsgeschäft drängt sich immer wieder in den Vorder-

grund. Ich habe viele positive Erfahrungen gemacht und auf fachlicher sowie menschlicher Ebe-

ne dazugelernt. Neben der guten Zusammenarbeit im Team bleibt mir allerdings hauptsächlich

der Mangel an Ressourcen in Erinnerung. Während meines ganzen Praktikums fehlte es an Ar-

beitskräften und materiellen Ressourcen, aber auch das scheint für die Branche und den aktuel-

len Arbeitsmarkt typisch zu sein.

Stichwörter: Praktikum, Software Testing, Test Automation Framework, AutoIt v3


II

Inhaltsverzeichnis

Zusammenfassung ....................................................................................................................... I

Inhaltsverzeichnis ........................................................................................................................ II

Abbildungsverzeichnis ................................................................................................................ III

Abkürzungen .............................................................................................................................. III

1 Einleitung ............................................................................................................................... 1

1.1 Aufbau ....................................................................................................................... 1

1.2 Bibliotheca RFID Library Systems AG ........................................................................... 1

1.3 Aufgaben .................................................................................................................... 1

1.4 Resultate .................................................................................................................... 2

2 Software Testing .................................................................................................................... 4

2.1 Testverfahren ............................................................................................................. 5

2.2 Testprozess und –phasen ........................................................................................... 6

2.3 Testautomation .......................................................................................................... 7

3 AutoIt Test Framework ........................................................................................................... 9

3.1 Überblick .................................................................................................................... 9

3.2 Projektphasen .......................................................................................................... 10

3.3 Verbesserungsmöglichkeit ........................................................................................ 11

3.4 Gelernte Lektionen ................................................................................................... 12

4 Andere Tätigkeiten ............................................................................................................... 14

4.1 Testen ...................................................................................................................... 14

4.2 Dokumentation ........................................................................................................ 14

4.3 Interne Schulungen .................................................................................................. 14

5 Erworbene Kompetenzen und Kenntnisse ............................................................................ 16

5.1 Fachliche Fähigkeiten ............................................................................................... 16

5.2 Allgemeine Fähigkeiten ............................................................................................ 17

5.3 Wissenschaftliche Fähigkeiten .................................................................................. 18

6 Fazit ..................................................................................................................................... 19

6.1 AutoIt Test Framework ............................................................................................. 19

6.2 RFID Bibliotheca Library Systems AG ......................................................................... 19

Literaturverzeichnis ................................................................................................................... 20

Webresourcen .......................................................................................................................... 20


III

Abbildungsverzeichnis

Abb. 1.1 AutoIt Test Framework [Dober 2008, S.2] ...................................................................... 3

Abb. 3.1 Softwareentwicklungsprozess in Form einer Spirale nach Boehm (1988) ..................... 11

Abb. 5.1 AutoIt Engine - GUI mode ............................................................................................ 17

Abkürzungen

bez. beziehungsweise

Bibliotheca Bibliotheca RFID Library Systems AG

BSC BiblioSelfCheck

d.h. das heisst

DLL Dynamic Link Library

GUI Graphical User Interface

RFID Radio-frequency identification

z.B. zum Beispiel


1

1 Einleitung Im Rahmen meines Masterstudiums in Wirtschaftsinformatik an der Universität Freiburg, absol-

vierte ich vom 1.April bis am 30.Juni 2008 ein Wahlpraktikum als Test Ingenieurin bei der Biblio-

theca RFID Library Systems AG.

Dieser Praktikumsbericht bietet einen Überblick über meine Tätigkeiten und Erfahrungen wäh-

rend dieser interessanten und lehrreichen Zeit. Dies ist keine exakte Dokumentation der Prakti-

kumsresultate. Das AutoIt Test Framework, das Hauptresultat des Praktikums, wird in [Dober,

2008] detailiert beschrieben.

1.1 Aufbau

Dieser Praktikumsbericht ist wie folgt aufgebaut. Die Einleitung gibt einen groben Überblick über

die Firma, die Aufgaben und die Resultate. Kapitel 2 Software Testing bietet hauptsächlich Hin-

tergrundinformation zum Thema Software Testing, welches das Hauptthema meines Praktikums

war. In den Kapitel 3 AutoIt Test Framework und 4 Andere Tätigkeiten werden meine Tätigkei-

ten bei der Bibliotheca RFID Library Systems AG beschrieben. Anschliessend fasst Kapitel 5 die

erworbenen Kompetenzen und Kenntnisse zusammen. Ein Fazit des Praktikums wird im letzen

Kapitel gezogen.

1.2 Bibliotheca RFID Library Systems AG

Während zwei Jahren ging ich neben dem Studium einer Teilzeitarbeit als Test Ingenieurin und

technische Redakteurin bei der Bibliotheca RFID Library Systems AG (nachfolgend Bibliotheca

genannt) in Cham nach. Anschliessend an die letzten Vorlesungen und Prüfungen an der Univer-

sität erhöhte ich mein Arbeitspensum und absolvierte mein Wahlpraktikum bei dieser Firma.

„Bibliotheca RFID Library Systems ist Spezialist in Entwicklung, Herstellung und Marketing von

Soft- und Hardware zur Automatisierung, Inventarisierung und Mediensicherung in Bibliothe-

ken. Mit über 300 installierten Projekten ist das Schweizer Unternehmen europäischer Markt-

führer; weltweit positioniert sich das Unternehmen auf Platz zwei.“ [Biblio08]

Weiterführende Informationen zur Firma sind auf der Firmenwebseite [Biblio08] zu finden.

1.3 Aufgaben

Während meinem Praktikum war ich hauptsächlich als Test Ingenieurin und Softwareentwickle-

rin tätig. Innerhalb des Test Teams war ich verantwortlich für die Erstellung eines Test Frame-

works für die Durchführung automatischer Tests an der BiblioSelfCheck Software. Die BiblioSelf-

Check Applikation ist eines von mehreren Softwareprodukten von Bibliotheca, sie läuft auf

Selbstverbuchungsstationen von Bibliotheken und bietet den Bibliothekskunden die Möglichkeit

Bücher und andere Medien selbständig auszuleihen, zu verwalten und zurückzugeben.

Mein Praktikum beinhaltete die komplette Abwicklung des Projektes Test Framework für Biblio-

SelfCheck. Von der Design- und Analysephase bis hin zur Produktschulung und Einführung ge-

hörte alles zu meinem Aufgaben. Die Grobspezifikation des Frameworks wurde aufgrund von


2

mir schon durchgeführter Automationsprojekte bei Bibliotheca erstellt. Auch die verwendeten

Entwicklungswerkzeuge waren von früheren Projekten gegeben. Da ich mit dem Umfeld ver-

traut war, bekam ich sehr viel Entscheidungs- und Gestaltungsfreiheit. Mit meinem Vorgesetz-

ten bei Bibliotheca, der gleichzeitig auch der Auftraggeber war, traf ich mich regelmässig um

Status und weiteres Vorgehen zu besprechen. Auf diese Weise herhielt ich regelmässig mündli-

che Anweisungen zu Änderungen und Ergänzungen am Test Framework.

Die durchgeführten Aufgaben an dem AutoIt Test Framework sind in der folgenden Auflistung in

chronologischer Abfolge zusammengefasst und in Kapitel 3 AutoIt Test Framework ausführlich

beschrieben:

• Die Analyse der bestehenden Testfälle der BiblioSelfCheck Software und die Entschei-

dung welche Testfälle vollständig automatisiert werden können.

• Erstellung der Spezifikation für das AutoIt Test Framework anhand der Testfälle, die zu

automatisieren sind.

• Definition der Schnittstellen zwischen allen beteiligten Komponenten.

• AutoIt Test Framework entwickeln.

• Test Input (Test Sequenzen, Konfigurationen, Medien und Benutzer) erstellen für die

Testfälle, welche in der Analyse als vollständig automatisierbar bewertet wurden.

• AutoIt Test Framework testen und allfällige Korrekturen vornehmen.

• Alle notwendigen Dokumentationen zur Benutzung und Weiterentwicklung des Frame-

works erstellen.

• Das Bibliotheca Test Team für das AutoIt Test Framework schulen und das Framework

einführen.

Zusätzlich zur Hauptauftrag hatte ich immer wieder kleine Aufgaben zu erledigen, die aus dem

Alltagsgeschäft heraus entstanden. Beschrieben sind diese im Kapitel 4 Andere Tätigkeiten.

1.4 Resultate

Das AutoIt Test Framework für die BiblioSelfCheck Software und die Dokumentation dazu ist

das Hauptresultat, das aus dem Praktikum hervorgeht. Eine Übersicht des Test Frameworks bie-

tet Abb. 1.1. Alle blau eingefärbten Komponenten gehören zum Test Framework. Die grünen

Komponenten stellen die Bibliotheca Anwendungen dar, welche mit dem Framework getestet

werden. Eine detaillierte Übersicht und genaue Beschreibungen der einzelnen Komponenten ist

in der Framework Beschreibung [Dober, 2008] zu finden. Diese Dokumentation ist als wesentli-

ches Resultat des Praktikums diesem Bericht im Anhang angefügt. [Dober, 2008] beinhaltet zu-

dem Informationen zur Entwicklung, Weiterentwicklung und Benutzung des Frameworks.


3

Abb. 1.1 AutoIt Test Framework [Dober 2008, S.2]


4

2 Software Testing Die Basis zur Erstellung des Test Frameworks für automatische Tests sind Kenntnisse im Bereich

Software Testing. Aus diesem Grund fasst dieses Kapitel alle für das Praktikum relevanten Punk-

te zum Thema Software Testing zusammen. In anderen Worten diese Kapitel beschreibt das nö-

tige Hintergrundwissen zum Projekt „AutoIt Testing Framework“. Besonders fokussiert wird das

Thema Testautomation.

Was ist Software Testing überhaupt? Eine gute Übersicht zum Thema bietet die Webseite [Ans-

wers08]. Der Vielfältigkeit des Begriffes kann dieser kurze Praktikumsbericht nicht gerecht wer-

den. Es wird allerdings versucht die für das Praktikum nötigen Grundlagen zu beschreiben.

Zusammengefasst in ein paar Punkten heisst Software Testing:

• Fehler finden, d.h. Fehler systematisch und nachvollziehbar aufzudecken.

• Mit Validationen und Verifikationen die Korrektheit der Anwendung nachweisen.

• Überprüfen ob die spezifizierten Anforderungen und die implementierte Funktionalität

übereinstimmen.

• Die Qualität einer Anwendung sicherstellen und erhöhen.

• Testen von qualitativen Eigenschaften wie Robustheit, Probabilität, und Benutzerfreund-

lichkeit.

In der effektiven Durchführung der oben aufgelisteten Punkte des Software Testing liegen einige

Herausforderungen, die unbedingt zu beachten sind und welche auch für das Testen der Biblio-

SelfCheck Software zutreffen.

• Verschiedene Umgebungen (Software- und Hardwareumgebung).

• Unterschiedliche Konfigurationen (z.B. konfigurierbarer Funktionsumfang, Ablaufvarian-

ten der Anwendung).

• Nicht funktionale Anforderungen, die in der Testumgebung nicht der Realität entspre-

chen können (z.B. die Anzahl der Benutzer einer Anwendung).

• Mehrsprachigkeit einer Anwendung; die Sprachvarianten und deren Darstellung im GUI.

Schnell wird ersichtlich, dass man sich beim Software Testing einschränken und den Fokus auf

das Machbare setzen muss. In jeden Software Testing Projekt stellt sich die Frage welche Mög-

lichkeiten mit den vorhanden Ressourcen (Testpersonen, Zeit, Testmaterial und Testumgebung)

abgedeckt werden können. Des Weiteren ist zu beachten, dass das Testen einer Anwendung in

einer Testumgebung nie hundertprozentig der Realität entsprechen wird. Eine Software wird

von Testern und den richtigen Benutzer verschieden bedient. Im Falle der hier zu testenden

BiblioSelfCheck Anwendung ist der Tester immer ein Experte, der die Software gut kennt. Der

reale Benutzer hingegen ist ein Laie, der die Anwendung ab und zu benutzt.

Um die Anforderungen des Software Testing trotz den hohen Herausforderungen so optimal wie

möglich erfüllen zu können braucht es in jedem Fall ein Testkonzept. Zu einem Testkonzept ge-


5

hören die Festlegung des Testumfang, der Vorgehensweise, der Ressourcen und eine Zeitpla-

nung.

In der Praxis gibt es viele Vorgehensweisen, d.h. Testverfahren zur Durchführung von Tests. In

der Literatur z.B. [Rätzmann 2004] sowie im Internet z.B. [Answers08] werden diese Testverfah-

ren ausführlich beschrieben. Der folgende Abschnitt gibt lediglich eine kurze Einführung in die

für das Praktikum relevanten Testverfahren.

2.1 Testverfahren

In diesem Abschnitt werden bei Bibliotheca angewandten Testverfahren in Bezug auf die Biblio-

SelfCheck Software zusammengefasst.

Bis anhin wurde sehr viel Ad-hoc-Testing betrieben. Aufgrund der Ressourcenknappheit und

fehlenden Testkonzepten wurde versucht das Testing auf das Wichtigste zu beschränken. Jeder

Entwickler testet die Anwendung ad-hoc, wenn er gerade daran am Arbeiten war. Vieles blieb so

nicht getestet und nicht dokumentiert.

Mit der kürzlichen Einführung eines kleinen Testteams kamen strukturiert manuelle und auto-

matische Testverfahren dazu.

Zu den automatisierten Testverfahren gehört der Langzeit-Test (Systemtest). Dieser testet ob

die Anwendung über mehrere Wochen stabil läuft. Der Langzeit-Test analysiert sowohl den

Speicherverbrauch als auch Online-/Offline-Aktivitäten der Anwendung. Die Programmlogik wird

allerdings nicht getestet. Mit Hilfe dieses automatischen Langzeit-Tests konnte die BiblioSelf-

Check Software stark verbessert werden. Viele Speicherlecks, Deadlocks und Leistungsprobleme

konnten aufgedeckt und reproduziert werden. Das Hauptziel dieser automatisierten Systemtests

ist das Testen der nichtfunktionalen Anforderungen wie z.B. Sicherheit, Robustheit, Geschwin-

digkeit und Zuverlässigkeit. Zusätzlich können externe Schnittstellen zu Hardwarekomponenten

und anderer Softwarekomponenten auf ihre Konnektivität getestet werden.

Zu den manuellen Testverfahren der Tests der BiblioSelfCheck Software gehören:

• Regressionstests, d.h. selektives wiederholtes Testen von Systemkomponenten zum

Nachweis, dass die Modifikationen keine Auswirkungen auf die schon existierenden

Funktionalitäten haben. Zu Regressionstests sagt (Rätzmann, S.51): „Da Regressionstest

nach jeder Programmänderung oder spätestens vor der Freigabe der nächsten Version

wiederholt werden sollen, ist hier der Drang zum Automatisieren dieser Tests beson-

ders stark.“

• Smoketests, dies ist ein Minimalsatz an Regressionstests, die sich auf grundlegende

Funktionen beschränken. Smoketests sind Positivtests, d.h. sie sollen nachweisen, dass

eine bestimmte Funktionalität vorhanden ist und keine Fehler aufweist. Wenn die Smo-

ketests fehlschlagen, wird eine Software nicht für weitere Tests freigegeben. Innerhalb

von kurzer Zeit kann festgestellt werden, ob das Programm unter „Gut-Wetter Bedin-

gungen“ seinen Dienst tut. Mehr zu Smoke Tests in [Rätzmann 2004, S. 52]. Die Smoke-

tests gelten bei Bibliotheca als minimale Abnahmetests, die testen ob das Verhalten

den Anforderungen entspricht.


6

• Integrationstests, die verifizieren das Zusammenspiel einzelner Softwarekomponenten.

Im Falle der BiblioSelfCheck Anwendung beziehen sich diese Tests hauptsächlich auf die

Integration von verschiedenen Hardwarekomponenten, dessen Treibersoftware und

der BiblioSelfCheck Software. Quittungsdrucker, Benutzerkartenleser, Barcodeleser und

Touchbildschirm sind Beispiele solcher Komponenten.

• Konfigurationstests. Die BiblioSelfCheck Software bietet hunderte von Konfigurations-

parameter, die in tausenden von Kombinationen funktionieren müssen. Historisch be-

dingt, gibt es keine Standardkonfiguration der BiblioSelfCheck Anwendung. Jeder Kunde

hat eine andere, kundenspezifische Konfigurationseinstellung. Bevor ein Software Up-

date einem Kunden ausgeliefert wird, führt die Bibliotheca kundenspezifische Konfigu-

rationstests durch. Auch diese Tests haben sollten automatisiert werden. Der grosse

Zeitverlust beim Umstellen der Konfiguration könnte so vermieden werden.

Bis auf die Integrationstests, besitzen die heutigen manuellen Tests von Bibliotheca grosses Po-

tential für die Automation. Bevor allerdings im Detail auf die Testautomation eingegangen wird,

beschreibt der nächste Abschnitt den bei Bibliotheca üblichen Testprozess und dessen Testpha-

sen.

2.2 Testprozess und –phasen

Ob automatisiert oder manuell getestet wird, es gibt Testprozesse und Konzepte, die sich in der

Praxis etabliert haben. Bei der Bibliotheca RFID Library Systems AG hält man sich für alle Tests

an den einen Testprozess, welcher iterativ folgende Testphase durchläuft.

Grundsätzlich fliesst das Testen von Software ein in den Softwareentwicklungsprozess und be-

ginnt meistens nachdem die Entwickler an einem Program Änderungen oder Erweiterungen

vorgenommen haben.

1. Planung

Der erste wichtige Schritt in jedem Testprozess ist die Planung. Ad-hoc Testing oder an-

deres unkoordiniertes Testen führt nicht zu einer nachvollziehbaren Verbesserung der

Softwarequalität und sollte deshalb vermieden werden. In der Planung werden Testfälle

identifiziert, Testverfahren festgelegt und Ressourcen verplant. Im Idealfall liefert die

Softwarespezifikation beziehungsweise der Anforderungskatalog die Grundlage für die

Identifikation der Testfälle.

2. Testfälle definieren

Sind die Testfälle identifiziert, so müssen sie genau definiert werden. Im Falle der Biblio-

SelfCheck Applikation werden die Testfälle in einer Excel-Liste erfasst, welche laufend

erweitert wird. Jeder Änderungsauftrag und Fehler erzeugt neue Testfälle. Zur Definition

eines Testfalls gehören die folgenden Angaben:

• Name, Titel des Testfalls,

• Priorität,

• Voraussetzungen, Konfigurationen,

• Testbeschreibung, d.h. Ablaufschema des Testfalles,


7

• Erwartetes Resultat,

• Angabe ob es ich um einen automatisierten oder manuellen Test handelt und

• Falls vorhanden Link zum Änderungsauftrag bez. Fehlerbericht des Testfalls

3. Testumgebung schaffen

Die allgemein gültige Testumgebung ist definiert in den Systemanforderungen, welche

zu Projektbeginn erstellt wurde und den Testern zur Verfügung steht. Durch den vielsei-

tigen Einsatz der BiblioSelfCheck Applikation entstehen Systemvarianten und von Test-

fällen abhängige Konfigurationen. Deshalb müssen für jeden Test beziehungsweise jede

Testgruppe die entsprechenden Konfigurationsdateien geschaffen und mit der Testfall-

definition abgelegt werden.

4. Testfälle durchführen

Jetzt folgt das eigentliche Testen. Mit der Art des Tests (z.B. Konfigurationstests, Regres-

sionstests oder Dauertests) wird bestimmt welche Testfälle auszuführen sind. Zur Aus-

führung gehören auch die Erstellung des Testprotokolls und die Dokumentation der

Testresultate.

5. Resultate auswerten

Nach der Durchführung der Tests, werden die Resultate ausgewertet. Nicht alle uner-

warteten Ergebnisse sind auf Softwaremängel zurückzuführen und müssen deshalb gut

analysiert und dokumentiert werden. Zur Auswertung gehört auch eine statistische Ana-

lyse.

6. Probleme melden und dokumentieren

Entdeckte Mängel müssen am Ende der Tests über den Prozess der Fehler- und Ände-

rungserfassung dokumentiert werden. So fliessen die Resultate der Tests in den Soft-

ware-Entwicklungsprozess ein.

2.3 Testautomation

Meine Hauptaufgabe während dem Praktikum war es ein Test Framework für Regressions- und

Konfigurationstests der BiblioSelfCheck Software zu erstellen. Dieser Abschnitt dokumentiert

das Hintergrundwissen der Testautomation.

Software nach jeder Programmänderung zu prüfen ist Arbeit, die sich ständig wiederholt und

sich deshalb zur Automation eignet. Dank Drittsoftware und besonderes geeigneten Program-

mier- bez. Skriptsprachen kann eine Automation fast bei jeder Software vorgenommen werden.

Eine Testautomation soll in erster Linie einen Mehrwert gegenüber dem manuellen Software

Testing generieren. Wenn von Testautomation die Rede ist, da wird deshalb als erstes daran ge-

dacht, dass durch die Automation Zeit und Ressourcen gespart werden sowie, dass das Testen

effektiver und effizienter wird. [Wieder, Giri 2007, S.338] kommen zum Schluss, dass sich aus

der Automation von Workflow-basierten Tests viele Vorteile ergeben. Die Arbeitsleistung kann

signifikant gesteigert werden. Ihre Experimente haben eine Verbesserung der Ausführzeit und

der Kosten um mehr als 70% ergeben. Die Ausführung der Tests alleine deckt allerdings noch

nicht die gesamten Aktivitäten, die bei der Testautomation beachtet werden sollten.


8

[Rätzmann, S. 273] besagt, dass für das einmalige Automatisieren eines Tests mit dem 10-fachen

Aufwand der manuellen Testdurchführung gerechnet werden muss. Der Aufwand für die War-

tung der automatisierten Testfälle liegt nach [Rätzmann, S. 273] pro Hauptversion der Software

im Schnitt bei 30% des manuellen Testaufwands. Eine Testautomation wird damit erst nach ei-

ner gewissen Anzahl der Wiederverwendung zu einem Gewinn. Damit dies geschieht sollten

nach [Rätzmann, S.47f] die folgenden Punkte beachtet werden:

• Testautomation muss erlernt werden und das Erstellen von automatischen Tests bedeu-

tet zunächst einmal erhöhten Zeitaufwand. Das zu erlernende darf nicht unterschätzt

werden.

• Testwerkzeuge sind kein Ersatz für Tester.

• Auch automatisch kann nicht alles getestet werden und es bedarf immer noch gute

Teststrategien, um einem möglichst grossen Teil der Software zu testen.

• Automatische Tests müssen gepflegt werden, dazu dienen klare Verantwortlichkeiten

und eine Versionsverwaltung für die Testdaten und Testsequenzen.

• Unbedingt auf eine dynamische Architektur der Automationssoftware und der Testfälle

achten. Tests die einmal erstellt sind, sollten gültig bleiben und nicht nach jeder Version

wieder verändert und angepasst werden müssen.

• Testautomatisierung kostet Zeit und Geld.

Für den Fall der BiblioSelfCheck Software von Bibliotheca kann diese Liste mit dem folgenden

Punkt ergänzt werden:

• Engere Zusammenarbeit von Tester und Softwareentwickler. Das Test Framework muss

das zu testende Software Produkt ansteuern können und dazu braucht es klar definierte

Schnittstellen. Zu tief sollte die Zusammenarbeit der Entwickler und Tester allerdings

nicht sein, da sonst die Qualität und Objektivität der Tests darunter leiden könnte.

Grosse Vorteile in der Testautomation sehe ich in der Tatsache, dass die Software für die Auto-

mation und die Testfalldefinitionen zwar von einem Experten erstellt werden müssen, diese

dann aber von Testern mit relative wenig Wissen, benutzt werden kann. Einmal gestartet laufen

die Tests 24/7 im Hintergrund. Erst bei der Auswertung der Resultate braucht es wieder die An-

wesenheit eines Testers.


9

3 AutoIt Test Framework

Die Bibliotheca RFID Library Systems AG vertreibt mehrere eigene Softwareprodukte und hat

selbst limitierte Ressourcen für das Testen der Software. Dazu kommt, dass die einzelnen Soft-

wareprodukte in sehr unterschiedlichen Konfigurationen bei Bibliotheca Kunden installiert sind.

Alleine die BiblioSelfCheck Software besitzt mehrere hundert Konfigurationsparameter, welche

theoretisch alle getestet werden müssten. Das Testen der Softwareprodukte ist komplex und

aufwändig. Zur Bewältigung dieser Herausforderung entschied sich Bibliotheca einen Teil des

Software Testing zu automatisieren. Vorerst begrenzt sich die Automation auf das Software

Testing der BiblioSelfCheck Software.

Die Automation hat zum Ziel die wichtigsten Testfälle zu definieren und diese anschliessend effi-

zient auszuführen. Die Durchführung bestehender Testfälle kann beliebig wiederholt werden,

einmal erstellte automatische Testfälle können immer wieder benutzt werden. Die Automatisie-

rung geht so weit, dass sie von einem Tester manuell gestartet werden muss, danach über Stun-

den läuft und die Resultate in Logdateien festhält.

Bestehende, manuell ausgeführte Testfälle dienten als Basis der automatisierten Tests. Mit den

manuellen Tests hat das Testteam schon Erfahrungen und dank denen konnten die zu automati-

sierenden Testfälle optimal ausgewählt werden. Und genau dies ist wichtig für eine erfolgreiche

Test Automation. [Kamer, Bach et al. 2004, Chapter5] schreibt zum Thema Test Automatisie-

rung: Entwerfe deine Testfälle bevor entschieden wird welche Testfälle automatisiert werden.

Dies verhindert, dass man mit der Automation in die Falle tritt indem einfach zu automatisie-

rende Tests implementiert werden, diese aber schwach sind im Auffinden von Fehlern.

Im AutoIt Test Framework wurden im Rahmen des Praktikums zuerst die Smoketests der Biblio-

SelfCheck Software automatisiert. Gleichzeitig ist das Framework so konzipiert, dass später alle

Regressions-Tests und die Konfigurations-Tests einfach in die automatisierte Testumgebung

übergeführt werden können.

Die Smoketests sind sie wichtigsten Tests, die nach jeder kleinen Änderung der Software durch-

geführt werden. Dies ist so, weil als erstes bei Tests der Best Case getestet werden sollte. Das

heisst, zuerst ist zu beweisen, dass ein Programm unter Gut-Wetter Bedingungen funktioniert.

Erst wenn dies der Fall ist, kann ein Schritt weiter gegangen werden und die Software kann wei-

tergehend getestet werden.

Für die Automation dieser Tests ist vorgegeben, dass die bestehenden Werkzeuge bei Bibliothe-

ca benutzt werden müssen, welche schon für die Erstellung der existierenden automatisierten

Systemtests halfen. Die Entwicklungsumgebung ist klar definiert und kann im Rahmen der Prak-

tikumsarbeit nicht geändert werden. Aus diesem Grund wird an dieser Stelle nicht auf die Ent-

wicklungsumgebung eingegangen. Mehr dazu in [Dober 2008, Kapitel 8].

3.1 Überblick

Die Aufgabenstellung zum AutoIt Test Framework ist in der Einleitung Abschnitt 1.3 Aufgaben

von diesem Dokument gegeben. Alle Fakten zum AutoIt Test Framework sind in der separaten


10

Bibliotheca Dokumentation [Dober, 2008] beschrieben. In diesem Praktikumsbericht wird des-

halb möglichst wenig wiederholt und einfach auf die AutoIt Test Framework Dokumentation

verwiesen.

Die Framework Dokumentation “AutoIt Test Framework for BiblioSelfCheck” ist wie folgt aufge-

baut:

• Einleitung

• Komponenten (graphische Übersicht Abb. 1.1)

o BiblioSelfCheck

o Bibliothek-System-Software

o Virtueller RFID-Leser

o Medien- und Benutzerkartensammlung

o AutoIt Test Engine

o Test Input (Testfälle, Testsequenzen, Konfiguration, virtuelle Medien und Be-

nutzerkarten)

o Datenbank

o IST- und SOLL-Logdateien

o Testresultat Zusammenfassung

• Wie wird ein neuer Testfall erstellt

• Wie wir eine Testsequenz durchgeführt

• Die Definition von Testsequenzen

• Technische Referenz der AutoIt Test Engine

• Entwickeln mit AutoIt v3

• Bekannte Probleme

• Zukünftige Arbeit und Verbesserungen

3.2 Projektphasen

Bei der Entwicklung des AutoIt Test Framework und all seinen Komponenten ging ich nach dem

klassischen Spiralmodell nach Boehm vor (Abb. 3.1). Begonnen habe ich mit der Festlegung der

Ziele für die Framework-Basis. In einem ersten Durchlauf schuf ich die Grundfunktionalitäten

des Frameworks. Zunehmend wurden die Ziele (zu automatisierende Testfälle) und die Entwick-

lung komplexer, die durchlaufenen Entwicklungsphasen blieben allerdings immer dieselben.


11

Abb. 3.1 Softwareentwicklungsprozess in Form einer Spirale nach Boehm (1988)

Die Grundfunktionalitäten der BiblioSelfCheck Software, wie beispielsweise das einfaches Aus-

leihen und Zurückbringen von Medien, waren schon nach wenigen Entwicklungszyklen vorhan-

den. Später kam dann die Handhabung von Testfällen wie Medien verlängern, Ausleihe mit ei-

nem Benutzerpasswort und der Quittungsdruck dazu.

3.3 Verbesserungsmöglichkeit

Aus technischer Sicht gibt es einen Bereich im AutoIt Test Framework, der aus meiner Sicht

grosses Verbesserungspotential besitz. Die Verbesserungsmöglichkeit liegt in den die Testfallde-

finitionen, welche in INI Konfigurationsdateien abgelegt sind. Anstelle von INI Dateien könnten

die Testfälle auch in XML Dateien definiert werden. Das würde mehrere Vorteile mit sich brin-

gen. XML Dateien kann ein Schema hinterlegt werden und damit können sie auf eine gültige

Struktur hin überprüft werden. Die Testfalldefinitionen könnten so vor dem automatischen Tes-

ten besser validiert und verifiziert werden.


12

3.4 Gelernte Lektionen

Neben all den positiven Effekten der Testautomation, gibt es auch viele kritische Punkte, die

während der Entwicklung des AutoIt Test Framework auftauchten.

Lessons learned (gelernte Lektionen) in Software Testing heisst das Buch [Kaner, Bach et al.

2002]. In Kapitel 5 dieses Buches beschreiben die Autoren 40 gelernte Lektionen im Bereich der

Testautomation. Sehr viele dieser Lektionen kamen mir beim Lesen bekannt vor. Sie entspre-

chen Erfahrungen, die ich im Zusammenhang mit dem automatischen Testen auch gemacht ha-

be. Lektionen, die mir besonders wichtig erscheinen, oder meine Arbeit besonders betreffen,

sind in diesem Abschnitt beschrieben nach [Kaner, Bach et al. 2002] und von mir kommentiert.

3.4.1 Trennung von Testdaten und Testausführung

[Kaner, Bach et al. 2002, Lessons 130]

Testdaten und das Programm für die Testausführung zu trennen, war im Fall des AutoIt Test

Frameworks von Beginn weg vorgesehen. Diese Separation verringert die Komplexität einzelner

Komponenten und bietet auch noch andere Vorteile. Verschiedene Tools und verschiedene Per-

sonen können in die Erstellung von Testsequenzen und die Testprogrammierung integriert wer-

den. Jede integrierte Person kann sich auf ihr Spezialgebiet fokussieren und selbständig arbei-

ten.

3.4.2 Vermeide die Gleichstellung von manuellen und automatischen Tests


Bei automatischen Tests kann nicht auf taktisches Wissen, das Bewusstsein und die Programm-

kenntnisse von einer Testperson zurückgegriffen werden. Eine reelle Testperson hingegen kann

Fehlalarme und auffällige Nebenerscheinungen problemlos registrieren.

Automatische Tests sollten die manuellen Tests deshalb nicht ersetzen, sondern ergänzen.

3.4.3 Testautomation ist ein Softwareentwicklungsprozess


Dass die Testautomation ein richtiger Softwareentwicklungsprozess ist, habe ich schon bald

nach dem Projektstart festgestellt. Bei der Testautomation entsteht grundsätzlich eine neue

Anwendung, die genauso spezifiziert, dokumentiert und durchdacht sein muss, wie jede andere

Software. Zu Beginn war mir dies zu wenig bewusst.

3.4.4 Automatisierte Regressionstests finden wenig Fehler


Das AutoIt Test Framework erstellte ich in erster Linie genau für diese automatisierten Regressi-

onstests. Und wenn ich die Auswertungen der bisher ausgeführten Tests betrachte, dann stimmt

die Aussage von [Kaner, Bach et al. 2002, Lessons 110]. Während der Testentwicklung wurden

mehr Fehler gefunden, wie bei dem eigentlichen Testen.


13

Da die Regressionstests vom AutoIt Test Framework allerdings auch das komplexe Konfigurati-

onsmanagement der BiblioSelfCheck Anwendung vereinfacht, bin ich überzeugt, dass sich die

Automatisierung in diesem Fall trotzdem lohnte.

3.4.5 Schlechte Automation wird nicht bemerkt


Der Programmierer der Testautomation muss genauso mitdenken wie ein Tester bei manuellen

Tests. Die Testabdeckung ist vielleicht schlecht, unabhängig von der Menge der Tests, die ge-

macht werden. Eventuell löst die Automation Fehlalarme aus. Und neue Funktionalitäten in der

Software bedeuten auch neue Features in der Testumgebung.

3.4.6 Test Tools sind fehlerhaft


Da das Test Framework auch eine Softwareanwendung ist, und jede Software Fehler hat, haben

auch die Test Tools selber Fehler. Während der Entwicklung des Test Frameworks erstellte ich

auch diesem Grund ein spezielles Set an Testsequenzen, die nur das Test Framework selbst tes-

ten.


14

4 Andere Tätigkeiten Neben meiner Hauptaufgabe, das AutoIt Test Framework zu erstellen, beteiligte ich mich wäh-

rend dem Praktikum auch an anderen Tätigkeiten innerhalb des Technik- und Operationsteam

bei der RFID Bibliotheca Library Systems AG. Meine zusätzlich ausgeführten Aufgaben werden in

diesem Kapitel kurz beschrieben und kommentiert.

4.1 Testen

Ich beteiligte mich aktiv an der Entwicklung und Verbesserung des Prozesses für die manuellen

Tests verschiedener Softwareprodukte von Bibliotheca. Neben der Prozessentwicklung, -

überwachung und der Testauswertung beteiligte ich mich selbst aktiv am Testen der BiblioSelf-

Check Software und anderen kleineren Anwendungen.

Das manuelle Testen half mir sehr bei der Erstellung des Test Frameworks. Anforderungen und

viele Ideen der Umsetzung entstanden aus meinen eigenen Testaktivitäten. Auch wenn das ma-

nuelle Testen für mich nicht immer sehr interessant erschein, so war es schlussendlich doch sehr

hilfreich für das Verständnis der BiblioSelfCheck Software und die Erstellung der automatischen

Tests.

4.2 Dokumentation

Die Softwaredokumentation für den Kunden wird in der RFID Bibliotheca Library Systems AG

vom Technikteam selbst geschrieben und verwaltet. Meine Aufgabe war es die Englischen Be-

nutzerdokumentationen, Installations- und Konfigurationsdokumentationen verschiedener Pro-

dukte auf dem aktuellsten Stand zu halten. Bei einzelnen Produkten war ich zusätzlich für die

Deutschen Übersetzungen zuständig.

Auch in meiner Verantwortung war die Verwaltung, Aktualisierung und Ergänzung der Sprach-

ressourcen mehrere Softwareprodukte. Die Benutzeroberfläche der BiblioSelfCheck Software

beispielsweise ist standardmässig in 15 Sprachen erhältlich. Das bringt mit sich, dass bei den

meisten Änderungen an der Benutzeroberfläche die entsprechenden Ressourcen in 15 Sprachen

gepflegt werden müssen. Bibliotheca verwaltet die Sprachressourcen in Excel Dateien und ex-

portiert diese mit einem selbstentwickelten Tool in INI und UNI Konfigurationsdateien. Die Bibli-

otheca Softwareprodukte greifen dann über diese Konfigurationsdateien auf die Sprachressour-

cen zu.

4.3 Interne Schulungen

In die Zeit des Praktikums fiel bei Bibliotheca auch eine interne Partnerschulung. Im Rahmen

dieser Schulung gab es für mich verschiede kleinere Aufgaben zu erledigen. Zu diesen gehörten

die Organisation und Mitgestaltung des technischen Teils der Partnerschulungen. Die Vorberei-

tung, Gestaltung und Erstellung der Schulungsunterlagen sowie die Vorbereitung und Durchfüh-

rung der Abschlussprüfung.

Die Mitarbeiterschulung für neue Verkaufsmitarbeiter übernahm ich teilweise vollständig.


15

Durch die Schulungen bekam mir einen breiten Einblick in die RFID Bibliotheca Library Systems

AG. Bei diesen Aufgaben waren komplett andere Fähigkeiten gefragt, wie beim allen anderen

Tätigkeiten. Dies machte mein Praktikum einerseits vielseitig und spannend, andererseits war

dies aber auch eine grosse Herausforderung.


16

5 Erworbene Kompetenzen und Kenntnisse Durch das vielseitige Praktikum konnte ich meine praktischen Erfahrungen stark erweitern und

erwarb viele neue Kenntnisse in verschiedenen Bereichen. Die Bibliotheca gewährte mir viele

Freiheiten und liess mich sehr selbständig arbeiten. Die Ziele und Prioritäten meiner Haupttätig-

keit, der Entwicklung des Test Frameworks, durfte ich selbst definieren. Die Zusatztätigkeiten

brachten Abwechslung und zusätzliche Disziplinen wie Präsentieren und Projektmanagement ins

Praktikum.

Mit der Entwicklung des AutoIt Test Frameworks erwarb ich hauptsächlich Kompetenzen im Be-

reich der Softwareentwicklung und des Software Testings. Mit der Skriptsprache AutoIt v3 [Au-

toIt08] lernte ich eine weitere mächtige Skriptsprache für die Windows Umgebung kennen und

konnte meine Programmierfähigkeiten erweitern.

In den folgenden Abschnitten ist zusammengefasst welche fachlichen, allgemeinen und wissen-

schaftlichen Kompetenzen und Kenntnisse aus dem Praktikum resultieren.

5.1 Fachliche Fähigkeiten

Software Testing ist ein Fachgebiet, das in der Praxis und in der Ausbildung tendenziell vernach-

lässigt wird. Meistens werden die Schwerpunkte Architektur, Design und Implementierung so

stark gewichtet, dass für das Software Testing schlussendlich nur noch begrenzt Ressourcen zur

Verfügung stehen. In meinem Praktikum beschäftigte ich mich 80% der Zeit mit dem Thema

Software Testing. Dadurch habe ich einen tiefen Einblick in die Thematik bekommen. Ich konnte

mir so Wissen aufbauen, das bei vielen Softwareentwicklern zu kurz kommt. Ich habe gelernt

wie Software Testing anzugehen ist, auch wenn die Ressourcen knapp und die Komplexität des

zu testenden Produktes hoch sind.

Mit meiner Hauptaufgabe, dem Erstellen des AutoIt Test Frameworks, beinhaltete mein Prakti-

kum neben dem Testing noch ein zweites grosses Thema: die Automatisierung und Simulation

von Benutzerprozessen in der Benutzeroberfläche einer Anwendung in der Windowsumgebung.

Für diese Aufgabe war die Skriptsprache AutoIt v3 [AutoIt08] vorgegeben. Mit Skriptsprachen

hatte ich bis zum Praktikum wenig Erfahrung. Meine Kenntnisse aus den Lehrveranstaltungen im

Bereich Software Engineering halfen mir beim Einstieg in das Thema. Ich war erstaunt wie viele

der Prinzipien aus der Objekt Orientierten Softwareentwicklung auch für die Entwicklung mit

einer Skriptsprache angewandt werden konnten. Auch über den Funktionsumfang von AutoIt v3

war ich erstaunt. Zu Beginn der Entwicklung des AutoIt Test Framework hatte ich ein AutoIt

Command Line Tool, konnte damit die Maus fernsteuern, an gewünschten Stellen klicken und so

das Benutzerverhalten simulieren. Das Endprodukt des AutoIt Test Framework ist eine richtige

Softwareanwendung mit Benutzeroberfläche, Zugriff auf das Dateisystem im Hintergrund, DLLs

von anderen Programmen und eine Datenbank. Die Möglichkeiten der Skriptsprache sind ge-

nauso mächtig wie jede andere Programmiersprache.

Fachlich habe ich nicht nur eine Skriptsprache kennengelernt, mit ihr vertiefte ich auch meine

Kenntnisse über das Windows Betriebssystem und seine Funktionalitäten vertieft.


17

5.2 Allgemeine Fähigkeiten

Das Praktikum bot mir die Gelegenheit meine Kenntnisse im Bereich Organisation, Kommunika-

tion und Projektmanagement zu benutzen und zu verbessern. Meine Ideen und Vorstellungen

wurden immer angehört und mit kritischen Fragen und Tipps ergänzt. Es war sehr interessant

die verschiedenen Vorgehensweisen und Methoden der einzelnen Teammitglieder kennen zu

lernen und dann diese in meinem eigenen Projekt anzuwenden.

Im Alltagsgeschäft der Bibliotheca lernte ich den praktischen Unterschied von strategischen und

operativen Aufgaben kennen. Das war sehr bereichernd, da dies in den Lehrveranstaltungen der

Universität immer wieder ein Thema ist, ich mir in der Praxis allerdings nichts vorstellen konnte

darunter.

Die Aufgabe, die Komplexität einer Problematik für den Endbenutzer zu verringern, forderte

mich das ganze Praktikum durch immer wieder. Ich konnte meine Fähigkeiten Komplexität zu

erkennen und zu verringern weiter entwickeln.

Ein Beispiel dafür ist die Erkenntnis, dass in der Softwareentwicklung die Benutzerfreundlichkeit

und Benutzerführung in einem Softwareprodukt besonders wichtig sind. Das AutoIt Test Fra-

mework ist auch ein Softwareprodukt. Zu Beginn wurde es entwickelt als Command Line Tool,

nach einigen Tests mit zukünftigen Benutzer des Test Frameworks programmierte ich eine ein-

fach zu bedienende Benutzeroberfläche zum Framework (Abb. 5.1). Der Benutzer hat Schaltflä-

chen zum Starten, Pausieren und Beenden der Tests, sieht sofort die Log-Einträge und den all-

gemeinen Status des Testverlaufs. Obwohl mit dem GUI keine neuen Funktionen in das Test

Framework eingebaut wurden, fiel es den Benutzern gleich viel leichter Test auszuführen.

Abb. 5.1 AutoIt Engine - GUI mode


18

5.3 Wissenschaftliche Fähigkeiten

Meine wissenschaftlichen Fähigkeiten baute ich im sehr praxisorientierten Praktikum nicht aus,

aber ich konnte meine bisher an der Universität gewonnenen Kenntnisse sehr gut einsetzen. Das

theoretische Wissen in den Bereichen Projektplanung, Analyse, Modellierung, Dokumentation

sowie das gelernte strukturierte Vorgehen war eine grosse Unterstützung bei der Umsetzung

meiner Haupt- und Zusatzaufgaben im Praktikum.


19

6 Fazit Die Schlussfolgerung ist aufgeteilt in zwei Abschnitte, die noch einmal die Erkenntnisse aus den

beiden wichtigsten Bereichen des Praktikums zusammenfassen. Einerseits sind das die Erfah-

rungen aus dem Projekt AutoIt Test Framework und andererseits die Eindrücke aus der Arbeits-

welt bei Bibliotheca.

6.1 AutoIt Test Framework

Die selbständige Konzeption, Implementierung und Nutzung des Test Framework gewährte mir

einen vielseitigen Einblick in die Themen Software Testing, Software Automation und Projekt-

management im Informatikumfeld. Neben den Entwicklungsarbeiten steckt hinter dem AutoIt

Test Framework viel Koordinations- und Kommunktionsaufwand. Alle betroffenen Teams, das

heisst das Testing- und Softwareentwicklungsteam sowie Benutzer und Firmenpartner mussten

bei der Festlegung der Anforderungen und bei der Umsetzung mit einbezogen werden. Wäh-

rend der täglichen Arbeit stellte ich immer wieder fest, dass diese administrativen Arbeiten

mehr Zeit als geplant beanspruchten.

Schon vor dem Praktikum war mir bekannt, dass die Definition der Anforderungen, Dokumenta-

tionen in der Softwareentwicklung häufig vernachlässigt werden. Aus diesem Grund rechnete

hielt ich mir immer genügend Zeit frei um diese Aufgaben zuverlässig durchzuführen. Durch das

Praktikum wurde mir zusätzlich bewusst, dass auch die Administration und das Testing von den

Zeitaufwänden her häufig unterschätzt werden.

Das AutoIt Test Framework betrachte ich als ein gelungenes Projekt, welches jetzt benutzt wer-

den kann, das Testteam entlastet und sich einfach mit weiteren Testfalldefinitionen und Testse-

quenzen erweitern lässt.

Besonders schwierig gestaltete sich die Literatursuche zum Thema Testing und Testautomation.

Es erfreut mich allerdings, dass mein Praktikumsthema auch ein aktuelles Forschungsthema zu

sein scheint. [Wieder, Giri 2007] beschreiben in “A Workflow-Based Test Automation Frame-

work for Web Based Systems” ganz ähnliche Konzepte, wie die hinter meinem AutoIt Test Fra-

mework. Auch sie bieten ein Framework zur automatischen Durchführung von Testfällen.

6.2 RFID Bibliotheca Library Systems AG

Die RFID Bibliotheca Library Systems AG ist in der Softwareentwicklungsbranche ein Kleinbe-

trieb. Alle Softwareprodukte werden für die eigenen Hardware-Produkte entwickelt. Fünf bis

sieben Softwareentwickler und ein bis zwei Tester sind für den gesamten Software Lebenszyklus

verantwortlich. Von der Zusammenstellung von Anforderungen für ein neues Produkt bis zur

Wartung älterer Produkte gehört alles zum Job eines Entwicklers. Das Arbeitsumfeld war dem

entsprechend sehr dynamisch und fordernd. Dies alles ermöglichte mir einen spannenden und

breiten Einblick in die Softwareentwicklung bei Bibliotheca. Die Zeit des Praktikums war für mich

intensiv und lehrreich auf fachlicher, aber auch auf menschlicher Ebene.


20

Literaturverzeichnis

Abran, Moore et al. 2004 Guide to the Software Engineering Body Of Knowledge: SWEBOK,

Alain Abran, James W. Moore, IEEE ComputerSociety, 2004

Dober, 2008 AutoIt BSC Test Framework, Bettina Dober, Bibliotheca RFID Library

Systems AG, Cham, 2008

Kaner, Bach et al. 2002 Lessons Learned in Software Testing: A Context-Driven Approach,

Cem Kaner, James Bach and Bret Pettichord, 2002

Rätzmann 2004 Software-Testing & Internationalisierung, Manfred Rätzmann, 2. Auf-

lage, Galileo Press GmbH, Bonn, 2004

Wieder, Giri 2007 A Workflow-Based Test Automation Framework for Web Based Sys-

tems, Wieder D. Yu, Giri Patil, Computer Engineering Department,

San Jose State Universtiy, California, 2007

Webresourcen

Answers08 Answers.com, verfügbar via

http://www.answers.com/software%20testing, zugegriffen am

28.06.2008

AutoIt08 AutoIt v3, verfügbar via

http://www.autoitscript.com/autoit3/index.shtml, zugegriffen am

30.06.2008

Biblio08 Bibliotheca RFID Library Systems AG, verfügbar via

http://www.bibliotheca-rfid.ch, zugegriffen am 28.06.2008

Praktikum bei der Bibliotheca RFID Library Systems...

Documents

Transcript of Praktikum bei der Bibliotheca RFID Library Systems...