Home

Dokument 1. - Dokumentenserverhosting der SUB

image

Contents

1. SKS H Y lz ag E 7 amp Details Design Steps sl Test Script Attachments Req Coverage ET pij i dN 5 Flight Reservation SL A8 Unattached Test ID Test Name Flig 2 1 BPT Resources Status Reay Ir Designer ae ac Ile nn ionDete suoos 1 Advanced 1374 2005 3 Compiled Modules en RH Seier ie RH 21 Cruises Priority 5 Urgent DH Reviewed Reviewed gt Flight Application BPT Demo d shelly_gc E Flight Reservation Haar 1 e 3 1 Book Flight Flight Confirmation 4 Flight Cost Flight Finder Select Flight B Flight Reservation Description Comments 23 Flight_Reservation RE Flight_Reservation_Stress SAY 4 Itinerary The test verifies the flight reservation process 2 Mercury Tours Site The test is the reusable template other tests can contain a call to it in order to 3 7 Profiling guide a user through the flight reservation procedure Description The test is composed of the following stages 1 Connection to Mercury Tours application and sign on Abbildung 5 4 HP Quality Center Test Plan Bei manuellen Tests werden unter dem Reiter Design Steps die durchzuf hrenden Testschritte erstellt Dort wird hinterlegt was genau gemacht werden soll und welches Ergebnis erwartet wird Bei automatischen Tests werden Testskripte hinterlegt Des Weiteren werden die Tests mit de
2. 7 Available Flights List IO Flight Booking Il Not Completed Ch Names Of Passengers Il Not Completed Meal Preference 27 Not Completed Ticketless Travel Il Hot Completed Delivery Address Il Not Completed Abbildung 5 2 HP Quality Center Requirements Neben der Zuordnung zu den Releases und Cycles zu denen die Anforderungen geh ren erh lt man auch eine bersicht ber die Abdeckung mit Testf llen Es gibt die Kategorien Not Covered Es wurde kein Testfall zugewiesen Not Completed Nicht alle zugewiesenen Testf lle wurden ausgef hrt Failed mindestens ein zugewiesener Testfall hat einen Fehler aufgedeckt und Passed alle zugewiesenen Testf lle wurden erfolgreich durchgef hrt Der jeweilige Status wird durch ein Symbol gekennzeichnet Au erdem bietet das Quality Center eine Unterst tzung f r die Risikoabsch tzung Die Risiken werden in Gesch ftsrisiken Business Criticality und Fehlerwahrscheinlichkeit Failure Propability unterteilt In beiden Kategorien kann man verschiedene Bewertungen abgeben Bei den Gesch ftsrisiken k nnen Absch tzungen dazu abgegeben werden wie oft die entsprechende Funktion verwendet wird wie viele Benutzer von einem eventuellen Fehler betroffen sind und wie hoch der Schaden im Fehlerfall w re Aus diesen Angaben berechnet das Quality Center einen Vorschlag zur Einstufung in die Kategorien A B ode
3. Schl ssel eingeben Window ExceedWindow Type DataTable DataTable Schluessel dtLocalSheet dtGlobal Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 69 Mir Return Funktion ausf hren Window ExceedWindow Type micReturn End If Der Aufruf DataTable Parameter Datenblatt gibt den Wert des jeweiligen Parameters aus dem angegebenen Datenblatt zur ck Bei dem verschachtelten Aufruf DataTable DataTable Schluessel dtLocalSheet dtGlobal wird zun chst der Schl sseltyp aus dem Local Sheet dem Datenblatt der aktuellen Action hier Function ermittelt und an das globale Datenblatt geleitet um den tats chlichen Wert zu erhalten Als n chstes muss noch in dem Men Test Settings bei Data Table Iterations die Option Run on all rows gew hlt werden Dies bedeutet dass f r jede Zeile in der Data Table der Test einmal durchlaufen werden soll In diesem Fall hat das globale Datenblatt eine Zeile und das Datenblatt f r die Action Function ca 500 Zeilen Also wird beim Durchlauf des ganzen Tests die Action Function ca 500 mal ausgef hrt Damit ist die Automatisierung der Funktionsaufrufe von technischer Seite her abgeschlossen Wie gut diese Automatisierung funktioniert h ngt in diesem Fall von der Qualit t der Daten aus der Data Table ab Die Grundlage f r diese Daten bildet eine Excel Tabelle in der d
4. Defect Incorrect time format used in Mercury Tours site Details Page 2 ai ch a Details Category Detect 7 sttus oen 1 1 177 2 Project Mercury Tours Web Site D Detected in Version Ir H 7 Subject Flight Reservation Detected on Date 01 09 2005 D Attachments Reproducible Regression N EE SR EES Linked Entities Assigned To peter_qc M Priority 3 High DR History _ Description Comments Add Comment Time format used in site is incorrect For example the current format is 16 30 pm It should be 4 30 pm or 16 30 paine oe een Her Abbildung 5 7 HP Quality Center Defects Um die Nachvollziehbarkeit eines Fehler zu erhalten wird vom Quality Center eine Historie gepflegt in der alle Anderungen die w hrend des Projektverlauf vorgenommen wurden dargstellt werden 5 2 7 Zusammenfassung Das Quality Center bildet eine Grundlage f r eine umfassende Dokumentation kompletter Softwareprojekte Viele Eingabefelder k nnen ber ein Administrationstool f r jedes Projekt individuell angepasst werden Hier lassen sich m gliche Eingaben und Pflichteingaben festlegen Die M glichkeit automatisierte Tests mit verschiedenen Tools vom Quality Center auszuf hren sowie die Kombinationsm glichkeit mit manuellen Testabl ufen bieten eine hohe Flexibilit t Damit ist es m glich jede Art von Applikation mit dem Quality Center zu verwalten Die
5. 3 und Kritikalit t A C f r den Betrieb bewertet werden Auf Basis dieser Einteilung soll eine Priorisierung der Testf lle erfolgen Die Funktionen sollen mit verschiedenen Datens tzen ausgef hrt werden Es wird also mehrere Testf lle pro Funktion geben Da f r die Tests Daten aus dem Produktivsystem verwendet werden m ssen zu den jeweiligen Datenst nden passende Datens tze festgelegt werden Der Test der Funktionen kann aus zwei Blickwinkeln betrachtet werden M chte man die Funktionalit t testen m ssen Gesch ftsabl ufe berpr ft werden wie zum Beispiel das Anlegen eines Containers das Aufrufen des Datensatzes um zu pr fen ob er tats chlich angelegt wurde Anschlie end k nnte man die Daten des Containers ver ndern wieder pr fen ob die nderungen in die Datenbank bernommen wurden und anschlie end den Datensatz wieder l schen Ein solcher Gesch ftsablauf umfasst bereits den Aufruf von unterschiedlichen Funktionen Vorher erscheint es allerdings sinnvoll berhaupt zu pr fen ob alle Funktionen in das neue System bernommen wurden Aufgrund des risikobasierten Testens w rden einige Funktionen gar nicht aufgerufen werden Diese Funktionen sind dann zwar sicherlich als wenig benutzt und unkritisch eingestuft aber es K nnte trotzdem fatale Folgen haben wenn ihr Fehlen erst nach der Testphase festgestellt wird Die genaue Vorgehensweise f r den Test der Datenbank und der Batchl ufe ist noch nicht spezi
6. COIN wurde 1983 in Betrieb genommen und ist in COBOL Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 11 programmiert Seit der Inbetriebnahme wurde es regelm ig weiterentwickelt COIN wird mittels der Terminalemulation Exceed www hummingbird com auf Windows Rechnern ausgef hrt Die Oberfl che ist rein textbasiert und wird durch die Eingabe von Funktionen Schl sselwerten und bestimmten Aktionen bedient Die Datenhaltung erfolgt auf einem hierarchischen Datenbanksystem auf einem Unisys Host F r diesen Host l uft der technische Support in naher Zukunft aus Aus diesem Grunde wurde eine Modernisierung von COIN beschlossen Ein externer Dienstleister soll die Codes auf ein moderneres Micro Focus COBOL konvertieren und die Datenhaltung auf eine Oracle Datenbank portieren F r dieses Migrationsprojekt soll ein Testkonzept aufgestellt werden das an sinnvollen Punkten durch automatisierte Prozesse optimiert wird Die Tatsache dass ein Neu und ein Altsystem mit den gleichen Anforderungen parallel existieren sollen ist nicht allt glich bietet aber f r den Test M glichkeiten die bei einer einfachen Entwicklung nicht gegeben sind Dieser Test ist trotzdem kein Einzelfall da solche Migrationsprojekte in der Praxis h ufiger vorkommen 1 5 2 TOPX Bei TOPX handelt es sich um eine operative Planungssoftware f r die Abl ufe an Container Terminals
7. Hier hat man nun den Squish Spy zur Unterst tzung Der Spy erh lt eine Liste alle Steuerelemente die in der ausgew hlten Maske der AUT sichtbar sind Nun kann man mit Anhakfeldern die Eigenschaften verschiedener Elemente markieren die f r die berpr fung relevant sind Die aktuellen Werte werden als Referenzwerte bernommen Bei jeder weiteren Ausf hrung des Skripts wird nun berpr ft ob alle angehakten Felder die erwarteten Werte enthalten Werte der Elemente k nnen Inhalte von Textfeldern sein aber Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 61 auch Anzahl von Knoten in einer Liste oder andere Eigenschaften die das jeweilige Element besitzt Test Suite Spy Window Help ER SILKE B i 1 E Toleo ram Test Suite Z verification Point up blv w l P e Z TObject Type Object Properties Screenshots ite_addressbook_js ppm FE en ect Map 4 ee Property value Itst_add_address O gt_viewport Qwidget oO enabled true i E childCount 1 Jtestjs O at_default_comer QWidget defaultRename ction a testdata O list view header QHeader o treeStepSize eme 20 4 verificationPoints O oa upa QScrollBar O resizeMode 0 O gem 3 QListview YP10000644 O showToolTips true Jist_adc Degree E ioj x O rootisDecorated false Itest js R O itemMargin 1 Ytestdat Eile O
8. die Anzahl und den Verlauf der Fehlerzust nde Das Quality Center wird in einem Webbrowser ausgef hrt ben tigt allerdings ActiveX Komponenten die den Internet Explorer ab Version 6 voraussetzen Da keine Clientinstallation notwendig ist Kann recht einfach ein unternehmensweiter oder sogar weltweiter Zugriff bers Internet auf die Projekte erm glicht werden Die Zugriffsrechte werden ber ein Administrationsmodul verwaltet Es k nnen QC spezifische Benutzerkonten angelegt oder Daten ber LDAP Lightweight Directory Access Protocol importiert werden Die Datenhaltung selbst erfolgt mit Hilfe eines DBMS Database Management Systems wie MS SQL Server oder Oracle In HPQC Tut2007 wird beispielhaft der Test einer Webseite die das Buchen von Fl gen erm glicht dargestellt Dieses Beispiel wird auch in HPQTP Tut2008 einem Tutorial zum Automatisierungstool QuickTest Professional verwendet Im Folgenden stammen alle Screenshots aus diesem Beispielprojekt Die dazugeh rige Webseite ist unter http newtours demoaut com zu erreichen HP hat diese Tools von der Firma Mercury bernommen und weiter entwickelt deshalb taucht der Name Mercury weiterhin an einigen Stellen auf 5 2 1 Releases Zu einem Projekt k nnen verschiedene Releases verwaltet werden Zu jedem dieser Releases k nnen mehrere frei definierbare Cycles angelegt werden Mit Cycles lassen sich die Releases in kleinere Abl ufe gliedern Diese Art der Untert
9. hnlichen Sprache in Sense Talk ist Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 58 Hier ein weiteres Beispiel das auch die Objektorientierung verdeutlich aus der Sense Talk Dokumentation put name Michael into mike create an object put a new object into property cat of mike create a nested object put Fido into the name of mike s cat put mike s cat s name Fido put mike name Michael Hier wird der Befehl put mit into verwendet In diesem Fall wird ein Wert einer Variablen zugewiesen die dem Schl sselwort into folgt 5 5 3 Bilderkennung F r alle entscheidenden Komponenten werden Bilder in dem Testprojekt abgelegt anhand derer das Tool beim Ausf hren der Testskripte die Objekte erkennt und auf dem Bildschirm lokalisiert Was passiert aber wenn ein Button den Fokus besitzt Nun hat das Icon einen kleinen Rahmen der nicht auf dem Pr senzbild vorhanden ist Somit weicht die Darstellung des Icons von dem gespeicherten Bild ab F r diesen und hnliche F lle gibt es in Eggplant die M glichkeit mehrere Bilder f r ein Objekt zu hinterlegen Nun wird beim Suchen des Objektes eine bereinstimmung mit einem der Bilder gesucht Diese Funktionalit t kann auch sinnvoll eingesetzt werden um plattform bergreifende Tests zu erzeugen Die Darstellung einer Java Applikation unter Windows und MacOS unterscheidet sich
10. http www eurogate eu ps tools download php file live eg_site_de eg_html_de psfile htmlfi le 91 EG_PortInf4579522e98ccd pdf amp name EG_PortInfo_HH pdf Abruf 13 02 2009 Eurogate2008 1 EUROGATE GMBH amp Co KGAA Firmenprofil Stand 2008 08 01 http www eurogate eu live eg_site_de show php3 id 30 Abruf 2008 09 11 Eurogate2008 2 EUROGATE GMBH amp Co KGAA CT Hamburg Stand 2008 08 01 http www eurogate eu live eg_site_de show php3 id 18 Abruf 2008 09 11 Eurogate2008 3 EUROGATE GMBH amp Co KGAA Eurogate IT Services Stand 2008 01 29 http www eurogate eu live eg_site_de show php3 id 28 Abruf 2008 09 11 Fewster1999 FEWSTER Mark GRAHAM Dorothy Software test automation effective use of test execution tools Mark Fewster Dorothy Graham Harlow Addison Wesley New York ACM 1999 1999 Ga dorf2008 GAB DORF Ulrich 25 Kilometer Stau wegen eines Computers In Hamburger Abendblatt online verf gbar http www abendblatt de daten 2008 06 04 889401 html Abruf 08 09 2008 Gericke2007 GERICKE J rg WIEMANN Matthias Fehlerprognosen zur Qualit tssteigerung in fr hen Entwicklungsphasen der Automobilindustrie In Software Engineering 2008 Fachtagung des GI Fachbereichs Softwaretechnik 18 22 02 2008 in M nchen Bonn Seite 92 95 Ges f r Informatik 2007 ISBN 978 3 88579 215 4 3 88579 215 X Fakult t Technik und Informatik Faculty of Engineering and Comput
11. r 40 Fu Container mit geraden Steht als ein Container in der Bay 2 so ist es ein 40 Fu Container der die 20 Fu Bays 1 und 3 belegt Containernummer weltweit eindeutige Nummer zur Identifizierung eines Containers Sie besteht aus 4 Buchstaben 6 Zahlen und einer Pr fziffer Die ersten 3 Buchstaben sind das K rzel des Besitzers meistens einer Reederei Der 4 Buchstabe ist standardm ig ein U COPRAR Container discharge loading order message EDI Nachricht die Informationen ber Lade bzw L schinformationen zu einem Schiff enth lt EDI Electronic Data Interchange Datenaustausch ber definierte Nachrichten z B zwischen Terminalbetreibern und Reederein Intermodal Eine Transportkette an der verschiedene Verkehrsmittel beteiligt sind Beispielsweise eine Anlieferung per LKW und ein Weitertransport per Schiff oder Bahn K hlcontainer auch Reefer Container Container mit K hlaggregat Ben tigt besonderen Stellplatz mit Stromanschluss L schcontainer Ein Container der zum Entladen bestimmt ist L schen Bezeichnet den Vorgang des Entladens eines Schiffes Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 92 Stellplatz Durch einen Code bezeichnete Position auf dem Terminal oder einem Schiff auf der ein Container abgestellt ist St ckgut auch Break Bulk Ware die aufgrund ihrer Gr e nicht in Containern verschifft we
12. um die Abweichungen nachvollziehen zu k nnen Hier fiel die Entscheidung f r die dritte Variante Somit k nnen bereits Referenzdaten mit dem Altsystem erstellt werden bevor das Neusystem zur Verf gung steht Da nicht alle Ausgaben des Neusystems beim Test gespeichert werden wird das Anlegen berfl ssiger Daten vermieden Zu den Referenzdaten werden nur Daten angelegt die Fehler im Neusystem beschreiben Die gespeicherten Daten sind Textdateien die den jeweiligen Maskeninhalt repr sentieren Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 70 6 3 1 Erstellung von Referenzdaten Die Erstellung der Referenzdaten wird mit einer im Rahmen dieser Arbeit entwickelten VBSkript Bibliothek vorgenommen Diese Bibliothek kann in mehreren QuickTest Professional Projekten referenziert werden und enth lt weitere Funktionen zum Vergleich und zur Aufbereitung der Testdaten Die Reihenfolge und die Art der Funktionen und Parameter die aufgerufen werden wird ber die Data Table gesteuert Mit dem Parameter MakeReferences in dem globalen Datenblatt kann entschieden werden ob die Ausgaben gespeichert werden sollen oder ob mit bereits gespeicherten Daten verglichen werden soll Die gespeicherten Ausgaben werden Referenzdaten genannt Der Test soll so aussehen dass mit dem Altsystem Referenzdaten erstellt werden und diese dann mit den Ausgaben des Neusystems vergl
13. 2 C O K LINE KUNDE Name 3 DEUTSCHLAND GMBH AKTIV Strasse ANCKELMANNSPLATZ 1 Postf PLZ Ort 20537 HAMBURG Land Kz D Telefon Kontakt Person Telex Telefax Teletex Agentur Reederei Makler Code Inh Geschaeftsfuehrer Ansprechpartner AKTION NEXT STOP EXIT FUNKTION SCHLUESSEL Es wurden automatisch folgende Abweichungen entdeckt Position 12 Position 13 Position 54 Position 55 Fehler in Zeil Fehler in Zeil Fehler in Zeil Fehler in Zeil ppm On On Oh On Aus diesen Angaben und den fett formatierten Zeilen wird schnell ersichtlich dass im Neusystem bei den Feldern Branche und Leistu Ber jeweils OO angezeigt wird w hrend die Felder im Altsystem leer bleiben Im Altsystem werden bei leeren Zahlfeldern automatisch die Nullen mit Leerzeichen ersetzt Diese Einstellung wurde zu diesem Zeitpunkt im Neusystem noch nicht umgesetzt 6 4 Wirtschaftlichkeit der Automatisierung Jede Kombinationsm glichkeit aus Funktion und verf gbaren Schl ssel ergibt einen Testfall Insgesamt gibt es 400 Testf lle F r den Test aller Funktionen werden 800 Aufrufe ben tigt 400 Aufrufe um die Referenzdaten mit dem Altsystem zu erzeugen und 400 Aufrufe um die Ausgaben des Neusystems mit den Referenzdaten zu vergleichen In einem Test mit 72 Aufrufen wurde ermittelt dass f r jeden Aufruf mit Erstellung von Referenzdaten bzw der Vergleich
14. Abbildung 6 3 Data Table in QuickTest Professional 1 l1o101 1 1 1 1 1 1 l l Die Spalten berschriften sind der Parametername der sp ter in dem Automatisierungsskript zur Verf gung steht Die Zelleninhalte sind die dazugeh rigen Werte Jede Zeile stellt einen neuen Testfall dar Die Spalte enable wurde eingef hrt um von Fall zu Fall entscheiden zu k nnen ob die Funktion tats chlich ausgef hrt werden soll Als Schl ssel sind in dieser Tabelle weitere Parameternamen eingetragen Somit wird es erm glicht f r alle Tests einen globalen Wert f r jeden Schl sseltypen festzulegen Dadurch wird die Wartbarkeit der Tests Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 68 erh ht da nur an einer zentralen Stelle neue Daten eingetragen werden m ssen wenn die Tests mit einem anderen Datenbestand ausgef hrt werden sollen Diese zentrale Stelle befindet sich hinter dem Reiter Global der Data Table Die dort eingetragenen Werte sind in allen Testf llen g ltig In QuickTest Professional wird von Actions gesprochen In diesem Projekt gibt es also eine Action Login und eine Action Function In der Action Login Kann nur auf Werte zugegriffen werden die in den Datenbl ttern Login und Global festgelegt wurden Die Action Login meldet sich lediglich an COIN an damit dann die Tests der F
15. Ausblick auf eine weitere Vorgehensweise erg nzt Der Schwerpunkt liegt hier zum einen auf Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 10 den Problemen die die Umsetzung der Automatisierung erschweren und zum anderen auf den Vorschl gen wie sie umgangen oder behoben werden k nnen 1 4 Abgrenzung Sowohl die Neuentwicklung von COIN als auch die Entwicklung von TOPX wird au er Haus von externen Dienstleistern durchgef hrt Diese Firmen sind somit auch f r die Durchf hrung von Softwaretests auf unterschiedlichen Entwicklungsstufen verantwortlich Der Quellcode dieser Produkte liegt nicht vor Somit k nnen von ITS nur Black Box Tests also Tests ohne Kenntnis des Quellcodes ausgef hrt werden Weitere Testmethoden und Teststufen werden zwar im theoretischen Teil erl utert aber im praktischen Teil nicht weiter vertieft Wenn im Rahmen dieser Arbeit von einer Qualit tsverbesserung die Rede ist dann bezieht sich dies lediglich auf den Testprozess nicht aber auf die Software die getestet wird Eine Verbesserung w re ein Zeitgewinn bei der Durchf hrung der Tests oder eine bessere Fehlererkennung zum Beispiel durch eine h here Testabdeckung der Anforderungen Die erkannten Fehler sollen dann an die Entwickler weitergegeben werden damit diese sie dann hoffentlich beheben Dies f hrt nat rlich zu einer Verbesserung der Qualit t der Software
16. Containerverwaltung o E 67 client SES T 67 Client Activate Anlieferung Stellplatz Ergaenzung Auslieferung Ergaenzung xl Schalter SCHIN L B o 1 D Function Iteration 2 Row 2 LKU ST ICIN E I D A C INSTP 320 330 E I D A C 340 EG ST o 1 Dig Function Iteration 3 Row 3 LKU LT LT310 LT320 LT330 LT340 5 E wa Function Iteration 4 Row 4 LKU RM 410 A C T 8 2 320 412 A C T 8 2 x Z 67 Cient LKW EKOM KVINC KVIN E I D KVOUT E I D KVOUT C S T 67 Client Activate Schiff 312 MAM 322 332 E I D C W WU aa E 67 client Type Interne Bewegung 350 DE DI DD ED ID IE Einzel Aend Anl 362 AZ AE KEY ST E 67 Cient Type i E T SA 350 LS SL STL Einzel Aend Ausl 363 AZ AE E 67 Client Type Cont Stanmsatz 360 NEU AE AZ ST Sammel Aenderung 366 AN AUS STEI T 67 client Type Sonderfunktionen 375 Sammel Aenderung 366 ANB BNR BUN EJ 67 Client Aufklaren AUFKLA Monitur Code 366 MOC 77 67 Client Activate Vorstau VOR AUF ANZ LOE Sammel Aenderung 366 STM IMC OS B schten WI ere EE T 67 client Type CUST Kunden coss Stellpl 500 CSOP Shippl 305 CRCS Bahn Allg 609 x ZZ 362A2_Container Nr COTA Tabellen 450 COFA Fahrauft 501 CORE ReMain 401 CRUS Bahn Entl 620 E X Function Iteration 5 Row 5 COLI Listen 390 CTRU TRO2 664 CTDS Bahn Verl 610 3 71 67 Client AKTION i EXIT T 67 Client Activate FUNKTION SCH
17. Es ist eine Standardsoftware die an die spezifischen Gegebenheiten der unterschiedlichen Terminals und Betreiber angepasst wird TOPX wurde 2008 bei Eurogate eingef hrt und wird durch regelm ige Patches und Releases weiter entwickelt Es basiert auf dem QT Framework von Trolltech www trolltech org und wird auf einem SUN Solaris System ausgef hrt Der Zugriff von den Windows Rechnern bei Eurogate erfolgt ebenfalls ber Exceed Mit der Gr ndung des Fachbereichs Testmangement sollen die Testverantwortung st ckweise von einem externen Dienstleister bernommen werden Im Rahmen dieser Arbeit soll erarbeitet werden wie die ben tigten Tests mit einer Automatisierung unterst tzt werden k nnen Das optimale Wunschziel w re ein komplett automatisierter Regressionstest Welche Voraussetzungen dabei erf llt werden m ssen und ob dies in der Praxis durchf hrbar ist wird in dieser Arbeit ermittelt 1 6 Begriffe Folgende Begriffe treten im Zusammenhang mit Softwaretests immer wieder auf und werden deswegen hier einmal erl utert Alle Begriffe und Erkl rungen sind Linz2005 entnommen Fehler 1 Oberbegriff f r Fehlerhandlung Fehlerzustand Fehlerwirkung 2 Nichterf llung einer festgelegten Anforderung Fehlermaskierung Ein vorhandener Fehlerzustand wird durch einen oder mehrere andere Fehlerzust nde kompensiert so dass dieser Fehlerzustand keine Fehlerwirkung hervorruft Fehlerwirkung 1 Wirkung eines Fehlerzustands die be
18. KLV Buch Nr Bestimmung Siegel XXX Turn I FahrNr 00000 SE ek Bemerk Zugehoerige CHASSIS NR Aggregat Nr K2 AKTION S NEXT SCRO RETU STOP EXIT FUNKTION SCHLUESSEL Row 23 Col 12 In dieser Maske sind noch einige Daten vorhanden die f r einen automatisierten Vergleich problematisch sind Die erste Zeile besteht aus dem Windows Anmeldenamen und der Rechnernummer Diese Informationen stammen von dem Exceed Fenster und werden nicht in COIN angezeigt sie sind f r den Test irrelevant und w rden bei einer Ausf hrung mit einem anderen Benutzernamen und oder auf einem anderen Rechner zu einer falschen Fehlermeldung f hren Die Angaben in der rechten oben Ecke w rden ebenfalls zu einem Fehler f hren Dies sind das aktuelle Datum die Uhrzeit und eine Session ID Alle drei Angaben w ren als Referenzdaten bei einem sp teren Vergleich nicht identisch mit den Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 71 Werten der aktuell angezeigten Maske In der letzten Zeile wird die aktuelle Position des Cursors in der COIN Maske angezeigt Diese Angabe k nnte unter Umst nden sogar hilfreich sein wird jedoch von dem neuen COIN System nicht geliefert Alle diese Daten werden bei den Referenzdaten nicht gespeichert In einigen Masken werden Datum und Uhrzeit noch mal in der dritten oder vierten Zeile angezeigt auch diese Daten m ssen vor d
19. Korrektheit der COIN Migration sicherzustellen So wird beispielsweise nicht berpr ft ob eingegebene oder ver nderte Daten tats chlich in der Datenbank gespeichert oder aktualisiert werden Hierzu sind Tests n tig die aus mehr als nur dem Aufrufen einer Funktion bestehen Es werden mindestens drei Schritte ben tigt 1 Maske aufrufen 2 Daten eingeben 3 Sicherstellen dass diese Daten gespeichert wurden Dies w re ein sehr einfacher Gesch ftsprozess da nur eine Programmmaske beteiligt ist In QuickTest Professional wurde das Anlegen von Containerdatens tzen realisiert Dieser Prozess wird durch Eingaben in die entsprechende Maske umgesetzt Um zu berpr fen ob die Container tats chlich gespeichert wurden werden nach dem Anlegen die entsprechenden Datens tze angezeigt Alternativ k nnte an dieser Stelle eine Datenbankabfrage per SQL erfolgen F r die COIN Migration kann zur Validierung der Ergebnisse wieder der Vergleich ber die Referenzdaten erfolgen Das Anlegen des gleichen Containerdatensatzes in beiden Systemen muss auch zu dem gleichen Ergebnis f hren Nach diesem Prinzip lassen sich auch komplexere Vorg nge automatisieren Es m ssen die jeweiligen Eingabemasken aufgerufen und mit Daten gef llt werden Anschlie end k nnen die Ergebnisse ber geeignete Anzeigemasken gepr ft werden Durch die Verwendung von Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department
20. Testprozess wird auch durch Automatisierung nicht zu einem besseren Prozess Automating chaos just gives faster chaos Fewster1999 S 11 Tests zu automatisieren ist eine Idee die es schon l nger gibt Entsprechend gibt es umfangreiche Literatur zu diesem Themenkomplex Hierbei handelt es sich meistens um generelle Vorgehensweisen und Hinweise darauf wo Probleme entstehen k nnen Wie die tats chliche Umsetzung einer solchen Automatisierung erfolgen kann ist oftmals nicht beschrieben Dies mag daran liegen dass es offensichtlich keine feste Vorgehensweise gibt Jedes Softwareprojekt ist anders und wird in einer anderen Umgebung eingesetzt Unterschiedliche Programmiersprachen verschiedene Plattformen andere Hardwarearchitekturen all diese Faktoren haben Einfluss darauf wie eine Automatisierung realisiert werden kann Auch die Automatisierung kann verschiedene Zielsetzungen haben So Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 9 kann entweder die Menge an Tests gleich bleiben aber in k rzerer Zeit ausgef hrt werden oder man m chte in der gleichen Zeit die f r manuelle Tests ben tigt wurde wesentlich mehr und somit gr ndlicher testen Daraus w rden sich selbst f r identische Projekte schon zwei unterschiedliche Ans tze ergeben Um diese Br cke zwischen Theorie und Praxis zu bauen werden in einigen Fachb chern Erfahrungsberichte ber
21. Verzahnung der verschiedenen Module bildet eine Grundlage f r sehr viele Auswertungen die alle ben tigten Metriken bereitstellen um einen berblick ber den Projektfortschritt und den Testprozess zu verschaffen Bei Eurogate werden in der Phase der Einf hrung des Quality Centers alle Daten zu kommenden Releases und den damit verbundenen Requirements von TOPX erfasst Die Erfassung der Defects erfolgt weiterhin in einer selbstprogrammierten Webapplikation Auf Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 51 diese Daten hat der Hersteller von TOPX Zugriff und kann diese direkt in seinen Entwicklungsprozess einflie en lassen F r die COIN Migration ist geplant die Defects ebenfalls im Quality Center zu verwalten und dem Lieferanten des Neusystems auf diesen Teil des Projektes den Zugriff zu erm glichen um eine effektive Kommunikation und somit eine zeitnahe Fehlerkorrektur zu erm glichen 5 3 Auswahl der Automatisierungstools F r die Projekte TOPX und COIN sollen Tools zur Automatisierung ausgew hlt werden Zuerst ist es notwendig eine Kriterienmatrix aufzustellen anhand derer die verf gbaren Tools bewertet werden k nnen Die Tools sollen alle von einem Windowsrechner aus bedient werden und m ssen f r TOPX mit einer auf QT basierten Oberfl che arbeiten k nnen TOPX selbst wird auf Sun Solaris ausgef hrt COIN wird auf einem Unisys Gro rec
22. auskennen um die zu testende Software zu verstehen Nur mit einem guten berblick ber die allgemeine Funktionsweise von Software k nnen Skripte erstellt werden die die wesentlichen Aspekte berpr fen und trotzdem robust ablaufen Dies impliziert die F higkeit sich in komplexe Projekte einzuarbeiten und sich einen fundierten berblick zu verschaffen Dar ber hinaus sollte der Testautomatisierer in der Lage sein die g ngigen Testmethoden auf die Projekte anzuwenden Au erdem werden sehr gute kommunikative F higkeiten ben tigt Die Ergebnisse der Automatisierung m ssen gut pr sentiert werden um Vertrauen in die Automatisierung zu schaffen Es m ssen viele Details mit den Kollegen gekl rt werden Diese Gespr che m ssen ausf hrlich sein d rfen aber nicht zu einem St rfaktor werden Von einem kompetenten Gespr chpartner f hlen sich die Kollegen sicherlich weniger schnell gest rt und sind eher bereit eine ausf hrliche Unterst tzung zu bieten Der Testautomatisierer muss selbst berzeugt sein dass die Testautomatisierung eine wichtige Sache ist Nur so Kann er auch andere davon berzeugen Es sollte also niemand aus dem Unternehmen die Automatisierung bernehmen m ssen nur weil er seine eigentlichen Aufgaben ihm daf r etwas Zeit lassen Ab einer gewissen Gr e und Komplexit t der Projekte sollte mindestens eine Person in Vollzeit f r die Automatisierung verantwortlich sein Es empfiehlt sich eine zweite Person zumind
23. besser vgl Fewster1999 S 248 256 Es sollte sichergestellt sein dass die Situation f r die Einf hrung einer Automatisierung geeignet ist Folgende Aspekte k nnen ausschlaggebend sein keine gro en Umbr che im Unternehmen keine Personalengp sse mit Automatisierung berbr cken Meistens f llt durch die Implementierung zun chst mehr Arbeit an Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 42 eine Person sollte hauptverantwortlich f r die Evaluation und Implementierung sein es sollte eine gewisse Unzufriedenheit mit den bisherigen Tests existieren Unterst tzung durch das Top Management sollte vorhanden sein vgl Fewster1999 S 256 257 5 1 2 Auswahlkriterien Nach einer erfolgten Marktanalyse sind verschiedene Faktoren f r die Bildung einer engeren Auswahl an Tools relevant Zuerst sind dies technische Kriterien Das Tool muss die verwendeten Hardwareplattformen Betriebssysteme und Anwendungen unterst tzen Hierbei sollten soweit m glich auch zuk nftige Projekte beachtet werden Bei den Betriebssystemen kann es auch m glich sein dass das Tool auf einem anderen Betriebssystem l uft als die Anwendung die getestet werden soll F r den Einsatz weiterer Betriebssysteme k nnen weitere Kosten entstehen aber diese Alternative sollte bedacht werden falls nicht ausreichend viele Testtools f r ein Betriebssystem zur Verf gung s
24. der Schwerpunkt zu weit hinten auf dem Schiff kann es f r die Besatzung der Br cke zu Problemen f hre da die Sichtlinie zum Wasser beeintr chtig wird Au erdem kann die Stabilit t des Schiffes gef hrdet werden wenn eine Querlast entsteht also das meiste Gewicht z B vorne links und hinten rechts liegt Der Schwerpunkt darf nicht zu hoch oder zu tief liegen dies h tte Auswirkungen auf das Rollen des Schiffes und k nnte in Extremsituationen sogar zum Kentern f hren Ein zu hoher Schwerpunkt kann z B dann entstehen wenn im Laderaum unter Deck viele Leercontainer stehen und ber Deck beladene Container verstaut sind Abbildung 4 3 Lade und L schvorgang am CT Bremerhaven Eurogate2007 S 14 Ein dritter Aufgabenbereich in dem TOPX eingesetzt wird ist die Planung des Ger teeinsatzes Ger te sind Van Carrier und Br cken Die Van Carrier k nnen einer Br cke zugeordnet werden w hrend die Br cke einem Schiff zugeordnet ist An Bord der Van Carrier befinden sich Handheld Ger te die mit TOPX verbunden sind ber diese Ger te erh lt der Van Carrier Fahrer seine Fahrauftr ge Ein Fahrauftrag besteht aus einem Quell und einem Zielstellplatz sowie der dazugeh rigen Containernummer Diese Containernummer ist weltweit eindeutig Sie besteht aus 4 Buchstaben 6 Zahlen und einer Pr fziffer Die ersten 3 Buchstaben stellen das K rzel des Besitzers dar w hrend der 4 Buchstabe immer ein U ist Beginnt eine Containernummer
25. detaillierte Spezifikation voraus Ist diese nicht vorhanden wird es selten m glich sein schnell eine entsprechende Spezifikation zu erstellen Also m ssen die Testf lle mit anderen Methoden ermittelt werden Bei der weiteren Analyse werden derartige Probleme der Praxis dargestellt Es soll ein Konzept gefunden werden mit dem trotz dieser Probleme schrittweise ein funktionierender Testprozess entstehen kann 7 1 Ist Zustand Es werden Tests f r aktuell angek ndigte Releases von TOPX durchgef hrt Diese Releases basieren auf Change Requests nderungsanforderungen die in der Zeit nach der Einf hrung der Software am Container Terminal Hamburg erfasst wurden Viele dieser nderungen sind Korrekturen an den umgesetzten Gesch ftsprozessen da diese nicht den gew nschten Vorgehensweisen entsprechen Hinzu kommen noch diverse Bugfixes Die Durchf hrung der Tests bernimmt noch der externe Dienstleister unter Anleitung durch das Testmanagement von Eurogate ITS 7 1 1 Testfallermittlung Die Ermittlung der Testf lle wird von Mitarbeitern aus den Fachabteilungen vorgenommen Es wird zu den nderungsanforderungen ermittelt welche Bereiche von TOPX betroffen sind und dann entschieden was getestet werden muss Die Analyse erfolgt anhand von drei Kriterien Welchen Einfluss hat die nderungen auf Gesch ftsprozesse benachbarte Systemkomponenten und Schnittstellen zu Umgebungssystemen Die Fachabteilungen die mit den betroffenen Systemteile
26. die erzeugten Ausgaben automatisch verifiziert werden k nnen In das Automatisierungsskript k nnen verschiedene Pr fungen eingebaut werden Es k nnen Checkpoints verwendet werden die den Zustand von Steuerelementen Werte in Variablen oder Daten in Datenbanken auf ihre G ltigkeit pr fen Ung ltige Werte w ren Abweichungen von den erwarteten Werten Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 55 Hunt vawe BookFlight Book a Flight Mercury ai Book a Flight Mercury Check CheckPoint CheckLinks BE passFirst0 Set hans H Be passFirst CL sl CL sl DI Sen MIEL e lh a ses D ebe x Ei creditCarc Name CheckLinks BEE creditnum Class P Bee lass Page ee ep d Type Property D i buyFlights M number of images 11 M number of links 12 Configure value Constant jo Parameter DataT able _load_time dtGlobalSheet HTML verification T HTML source Edit HTML Source I HTML tags Edit HTML Tags All objects in page VW Links Filter Link Check IV Images Filter Image Check I Broken links Checkpoint timeout 0 seconds al Cancel Her Abbildung 5 9 HP QuickTest Professional Checkpoint In diesem Beispiel aus dem Tutorial wird berpr ft ob auf der geladenen Webseite 11 Bilder und 12
27. die zudem noch sehr unbeliebt ist Aber eine gute Dokumentation nachtr glich zu erstellen ist erheblich aufwendiger und meistens ist gerade dann wenn bemerkt wird dass die Dokumentation nicht ausreichend ist Zeit ein knappes Gut Es wurde ebenfalls deutlich dass mit der Testautomatisierung erhebliche Verbesserungen am Testprozess erreicht werden k nnen Es k nnen effektivere Tests ausgef hrt werden es k nnen mehr Tests ausgef hrt werden oder die Testphase kann verk rzt werden gegebenenfalls auch mit dem Einsatz von weniger Ressourcen Aber der anfallende Aufwand f r die Automatisierung darf nicht untersch tzt werden Es kostet Zeit die richtigen Tests f r die Automatisierung zu identifizieren und die richtigen Tools f r die Testausf hrung auszuw hlen Dies sind zwei elementare Aspekte die zun chst keinen produktiven Nutzen erzeugen aber das Grundger st f r die weitere Arbeit bilden Werden an dieser Stelle Fehler gemacht Kann dies bereits immense Auswirkungen auf den Erfolg beziehungsweise den Misserfolg des Automatisierungsprozesses haben Dem Testautomatisierer sollte daher ausreichende Zeit zur Verf gung stehen sich einen gr ndlichen berblick ber die vorhandenen Softwareprojekte zu verschaffen An dieser Stelle wird wieder die Bedeutung einer zuverl ssigen Dokumentation sichtbar Es wird sicherlich trotzdem notwendig sein dass sich der Testautomatisierer bei den entsprechenden Kollegen ausgiebig ber die Projekte
28. eingespart wird Es ist ebenfalls sinnvoll die Zeit zu betrachten die ben tigt wird um vorhandene Testf lle zu warten Wenn die Anpassung der vorhandenen Tests f r eine Aktualisierung der zu testenden Software einen zu hohen Aufwand bedeutet ist es unter Umst nden n tig den Automatisierungsstandard zu berarbeiten Um einen Vorteil der Testautomatisierung zu messen kann die Anzahl der automatisch ausgef hrten Tests mit der Anzahl der Tests die manuell h tten ausgef hrt werden k nnen gegen bergestellt werden Bei einer vollst ndigen Automatisierung ist es leicht m glich 100 der Testf lle auszuf hren auch wenn mehrere Testzyklen durchlaufen werden Bei Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 31 einer manuellen Testausf hrung w ren in der gleichen Zeit nur ein Teil der Tests vielleicht 10 ausgef hrt worden vgl Fewster1999 S 226 227 3 5 Was kann und sollte automatisiert werden Grunds tzlich gilt dass nicht zu viel auf einmal automatisiert werden sollte Es ist sinnvoll erst einen kleinen Anteil der Tests zu automatisieren und sich davon zu berzeugen dass die Implementierung in der bestm glichen Art und Weise geschehen ist Sollte die Praxis zeigen dass eine andere Herangehensweise notwendig ist m ssen nicht zu viele Tests aktualisiert oder neu implementiert werden Hieraus resultiert das Problem sich entscheid
29. haben Redundanzen vermeiden Redundanzen erscheinen unproblematisch allerdings besteht die Gefahr dass bei nderungen z B w hrend eines Reviews nicht alle Anforderungen bearbeitet werden Es entstehen Widerspr che Widerspr che Widerspr che die sich in eine umfangreiche Liste an Anforderungen eingeschlichen haben sind nur sehr schwer zu identifizieren Ungenaue Angaben Der Kunde hat sicher ganz genaue Vorstellungen wie das Produkt aussehen soll Werden diese genauen Vorstellungen nur ungenau spezifiziert werden die Entwickler mit Sicherheit an den Kundenvorstellungen vorbei entwickeln vgl Rupp2007 S 26 Anforderungen lassen sich in funktionale und nicht funktionale Anforderungen unterteilen Entsprechende Tests werden auch funktionale oder nicht funktionale Tests genannt je nachdem auf welcher Art von Anforderung sie basieren Funktionale Anforderungen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 23 beschreiben das Verhalten das ein System oder ein Teil des Systems erbringen soll Nicht funktionale Anforderungen beschreiben mit welcher Qualit t die funktionalen Anforderungen erf llt werden Wichtige Kriterien f r nicht funktionale Anforderungen sind Zuverl ssigkeit Benutzbarkeit oder Effizienz vgl Linz2005 S 69 73 2 5 Testfallerstellung Nachdem das Ziel also die Anforderungen definiert wurden m ssen Testf
30. lle erstellt werden die aus diesen Anforderungen resultieren Dies ist jedenfalls das Vorgehen beim Black Box Test bei dem im Gegensatz zum White Box Test keine Kenntnisse aus dem Quellcode entnommen werden Der Black Box Test berpr ft das Verhalten der Software gegen ber den Erwartungen aus den Anforderungen Es sollten m glichst viele Anforderungen mit Testf llen verifiziert werden Der Quotient aus mit Test abgedeckten Anforderungen und der Gesamtzahl der Anforderungen wird berdeckungsgrad genannt Dieser sollte m glichst hoch sein Der berdeckungsgrad wird bei der Ausf hrung der Tests auch als Testendekriterium herangezogen Wenn also ein vorher festgelegter berdeckungsgrad mit ausgef hrten Tests erreicht wurde kann man den Test f r beendet erkl ren Je nach Testergebnissen muss dann die Entscheidung gef llt werden ob die Software berarbeitet werden muss oder ob sie die Anforderungen erf llt Eine Schwierigkeit beim Erstellen der Testf lle liegt darin zu entscheiden ab wann eine Anforderung ausreichend abgedeckt ist Dynamische Tests sind Stichproben und aufgrund der Vielzahl an m glichen Eingaben ist es unm glich alle Kombinationen zu testen Man stelle sich nur einen einfachen Taschenrechner vor der lediglich zwei reelle Zahlen miteinander addiert Schon gibt es unendlich viele M glichkeiten an Additionen und somit auch eine unendliche gro e Anzahl an Testf llen Es ist offensichtlich dass es nicht sinnvoll ist
31. nnen Mausklicks auf Fensterkoordinaten verwendet werden Da nicht zu erwarten ist dass das Maskenlayout ver ndert wird stellt diese Technik keine Einschr nkung dar Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 57 5 5 Redstone Software Eggplant Bei der Applikation Eggplant handelt es sich um ein Capture and Replay Tool welches mit einer Bilderkennung arbeitet W hrend Tools wie Quicktest Professional auf die interne Repr sentation der Steuerelemente zugreifen findet Eggplant die entscheidenden Komponenten anhand gespeicherter Bildausschnitte Dies ist vor allem dann sinnvoll wenn man nicht auf die interne Repr sentation zugreifen Kann wie es zum Beispiel bei einer Terminalsession der Fall ist da dem Clientrechner meistens lediglich ein Bild der Oberfl che zur Verf gung steht N here Informationen ber die Art der Objekte oder gar die interne Repr sentation k nnen so nicht erfasst werden Die Idee von Eggplant ist dass jede Applikation getestet werden kann und dies plattform und technologieunabh ngig Die einzige Voraussetzung ist eine grafische Benutzeroberfl che die auf einem Rechner im Netzwerk ausgef hrt wird auf den per VNC Verbindung zugegriffen werden kann 5 5 1 Skripterstellung Eggplant wird unter MacOS ausgef hrt und stellt eine Verbindung ber einen eigenen VNC Client zur AUT her Im Capture Modus kann man die Skrip
32. of Computer Science 79 synthetischen Daten lassen sich die berpr fungen einfach implementieren da genau vorhersagbar ist welches Ergebnis erzeugt werden muss 6 7 Aktueller Stand und weiteres Vorgehen Mit dem automatisierten Aufruf aller relevanten Funktionen und Masken k nnen viele Fehler die in der Entwicklungsphase des Migrationsprojektes auftreten schnell gefunden werden Aufgrund der kurzen Dauer der Ausf hrung k nnen diese Tests in regelm igen Abst nden durchgef hrt werden Somit ist ein kurzfristiges Reporting an die Entwickler m glich die ihrerseits schnell auf Probleme reagieren k nnen Es wurde gezeigt dass die Automatisierung in diesem Bereich sowohl einen finanziellen als auch einen qualitativen Vorteil bringt Leider kann nicht weiter auf aufgedeckte Fehler eingegangen werden da sich die Auslieferung des Neusystems aufgrund verschiedener Probleme verz gert hat Es wurde dargestellt dass mit relativ wenig Aufwand synthetische Daten f r weitere Tests erzeugt werden k nnen und dass mit dem Know how ber Gesch ftsprozesse diese auch als Testf lle in QuickTest Professional implementiert werden k nnen Das entstandene Automatisierungskonzept ist entsprechend erweiterbar und es k nnen komplexere Tests realisiert werden Nach einer erfolgreichen Migration wird das Neusystem von den Entwicklern bei Eurogate weiterentwickelt und gegebenenfalls an neue Gesch ftsprozesse angepasst Mit dem vorhandenen Automatisi
33. testenden Programme und Testprozesse die Auswahl von Automatisierungstools sowie die konkrete Arbeit mit diesen Tools Die Arbeit mit den Automatisierungstool HP QuickTest Professional wird mit Praxisbeispielen verdeutlicht Sascha Bartels Title of the paper Automation of Black Box Softwaretests with Risc Based Priorization at Eurogate IT Services GmbH Keywords Software test Black Box Test Test Automation Regression Test Quality Assurance HP Quality Center QuickTest Professional Squish Abstract This thesis specifies an approach to the implementation of automatic black box software tests in a business environment Requirements and essential steps of an implementation are described on the basis of two different projects This concept includes the analysis of the applications under test and the test process the selection of automatic test tools as well as the practical work with these tools The work with the automation tool HP Quick Test Professional is exemplified by practical examples Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 3 Inhaltsverzeichnis ee e EE 6 IN SO TE 7 1 1 Umfeld sr sn 7 12 7 Motiyalion se eis nalen 9 1 3 EE 10 14 E E E E EEEE SR 11 1 5 Einleitende Projektbeschreibungen nie 11 1 5 1 COIN AE a E ee E 11 1 52 TOPX E na a u 12 Ir Se Te e 12 e Eeer 15 Sch KE 15 2 1 1 Komponententest nase niet 16 21 2 Inlesrati
34. und somit ber Plattformgrenzen hinaus gearbeitet werden kann Au erdem fehlt eine Integrationsm glichkeit zum HP Quality Center Die Variante mit zwei Tools zu arbeiten also HP Quick Test Professional f r COIN und Squish f r TOPX zu verwenden bietet erhebliche Vorteile Beide Tools arbeiten mit dem HP Quality Center zusammen und die Realisierung ist erheblich g nstiger F r QuickTest Professional m ssen keine Lizenzen angeschafft werden Squish hingegen ist erheblich preisg nstiger als Eggplant F r den Einsatz von Eggplant w rden zus tzlich noch die Kosten f r die Anschaffung von Mac OS anfallen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 65 6 Automatisierung der Tests f r die COIN Migration In diesem Kapitel wird beschrieben wie der Testprozess in diesem Migrationsprojekt mit automatisieren Tests verbessert werden konnte In diesem recht speziellen Projekt sollte das textbasierte in COBOL entwickelte COIN durch eine neue Software abgel st werden Das Besondere liegt hierbei darin dass die neue Software genau die gleichen Anforderungen hat wie das Altsystem Es soll lediglich eine moderne Architektur verwendet werden Das neue System soll durch einen stark automatisierten Konvertierungsprozess entstehen und nicht durch eine manuelle Neuimplementierung Im Test soll gepr ft werden ob das Neusystem tats chlich die gleichen Anforderungen
35. von Daten aus einem Produktivsystem bietet aber viele Vorteile Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 76 6 5 1 Verwendung von synthetischen Daten Bei Eurogate ITS ist es g ngige Praxis dass die Testumgebungen in regelm igen Abst nden mit Daten aus dem Produktivsystem gef llt werden Es gibt verschiedene Argumente die gegen eine solche Vorgehensweise sprechen Bei automatisierten Tests kann es n tig sein dass die Skripte an die aktuellen Daten angepasst werden m ssen Datens tze werden anhand einer Schl sselnummer aufgerufen Wenn der verwendete Schl ssel nun gerade keinem Datensatz zugeordnet ist weil er in der Produktivumgebung nicht vergeben ist schl gt der Test fehl Wenn gr ere Testl ufe geplant sind die unbeobachtet ber l ngere Zeit laufen sollen kann ein erheblicher Aufwand entstehen wenn alle Skripte an die neuen Daten angepasst werden m ssen Die Suche nach passenden Datens tzen bleibt auch beim manuellen Testen nicht aus aber dem Tester wird es auffallen wenn er einen bestimmten Datensatz nicht findet und selbstst ndig einen anderen suchen Dieses Verhalten muss in einem Testskript aufwendig implementiert werden Viele Tests ben tigen einen bestimmten Zustand des Systems Der Test kann nur dann sinnvoll ausgef hrt werden wenn ein definiertes Testszenario vorliegt Arbeitet man mit Daten aus der Produktion so
36. wenn man alle diese M glichkeiten ausprobiert bevor man sicher sagen kann dass dieser Taschenrechner die Addition beherrscht Wenn er 5 3 richtig berechnen kann kann davon ausgegangen werden dass er auch bei der Eingabe von 5 4 zu einem richtigen Ergebnis kommt Man spricht hier von der Bildung von quivalenzklassen Mit Hilfe der quivalenzklassen l sst sich die Anzahl der m glichen Eingaben reduzieren Die Problematik liegt hier in der Identifizierung der Klassen In dem Beispiel mit dem Taschenrechner k nnte man folgende g ltige quivalenzklassen identifizieren also solche die eine g ltige Ausgabe erzeugen sollten positive Zahl positive Zahl negative Zahl negative Zahl positive Zahl negative Zahl negative Zahl positive Zahl Bei der Erstellung der zugeh rigen Testf lle sollten auch die Grenzen beachtet werden Hier ist die Grenze die 0 In der Beispielbeschreibung wurde gesagt dass es sich um die Addition von reellen Zahlen handelt also k nnen noch weitere quivalenzklassen erstellt werden zum Beispiel unter Ber cksichtigung von Nachkommastellen Neben g ltigen quivalenzklassen gibt es auch ung ltige quivalenzklassen Diese enthalten eben solche Werte die keine g ltigen Eingaben darstellen In diesem Beispiel w re es unter anderem die Eingabe von Buchstaben Mit ung ltigen quivalenzklassen wird berpr ft ob die Software in der Lage ist Fehler korrekt zu erkennen und abzufangen Fakult t T
37. wie das Altsystem erf llt 6 1 Testkonzept Dieses Kapitel behandelt nicht das gesamte Testkonzept der COIN Migration sondern nur die Aspekte die mit einer Automatisierung im Zusammenhang mit dieser Arbeit betrachtet wurden Hier eine Zusammenfassung der Ausgangssituation Ps sollen zwei Programme auf Gleichheit in verschiedenen Punkten berpr ft werden Die Bedienung der Programme ist durch das Aufrufen verschiedener Funktionen mit einem Schl ssel nicht sehr umfangreich im Vergleich zu einer GUI mit Mausbedienung und mehreren Fenstern Im Rahmen dieser Arbeit soll gezeigt werden wie sich beide Programme mit QuickTest Professional automatisieren lassen Ps sollen viele Dialoge und Funktionen berpr ft werden Bevor man mit einer Automatisierung beginnt sollte man sich die Fragen stellen ob sich eine Automatisierung berhaupt lohnt Ist die automatische Ausf hrung der Tests schneller und oder gr ndlicher als die manuelle Ausf hrung Bei der COIN Migration sollen Dialoge Zeichen f r Zeichen miteinander verglichen werden dies erscheint als eine typische Aufgabe f r einen Rechner F r einen automatisierten Vergleich muss also eine M glichkeit gefunden werden diese Masken rechnergest tzt zu vergleichen Die Idee ist daher dass der gleiche Funktionsaufruf mit dem gleichen Datenbestand die gleiche Ausgabe erzeugt Daf r sind zwei Voraussetzungen n tig 1 Automatisiertes Aufrufen der Funktionen 2 Automatisierte
38. wird aber in dieser Arbeit nicht behandelt Einer vollst ndigen Automatisierung dieser Projekte stehen verschiedene Faktoren entgegen Die Komplexit t dieser Aufgabenstellen erlaubt nur die Darstellung eines exemplarischen Vorgehens unter Herausarbeitung ausgesuchter Testf lle Es wird kein vollst ndiger Test dokumentiert weder ein manueller noch ein automatisierter Das gesamte Softwaresystem bei Eurogate besteht aus diversen Programmen mit einer Vielzahl an Schnittstellen Aufgrund dieser Komplexit t werden nur die beiden gro en Programmteile COIN und TOPX n her beschrieben Auf eine detaillierte Aufstellung aller Umsysteme und Schnittstellen wird verzichtet 1 5 Einleitende Projektbeschreibungen Diese Beschreibungen der beiden Softwareprojekte die in dieser Arbeit aus dem Blickwinkel des automatisierten Testens betrachtet werden dienen zu einer ersten Orientierung und um einige Fakten herauszustellen Eine genauere Beschreibung erfolgt in den Kapiteln Automatisierung der Tests f r die COIN Migration und Automatisierung von TOPX die sich vor allem auf die Umsetzung der eher theoretischen Teile dieser Arbeit auf die Praxis beziehen 1 5 1 COIN COIN ist die Abk rzung f r Container Information In diesem System werden alle Daten ber Container erfasst die per Schiff LKW oder Bahn angeliefert werden Diese Daten enthalten unter anderem s mtliche Details ber die Container wie Gr e Gewicht Zielort Ankunftszeiten etc
39. wobei die Funktion die gleiche bleiben soll Speichert man nun zu einem Objekt die Darstellung unter Windows und MacOS ab kann das gleiche Skript f r beide Betriebssysteme verwendet werden F r den Fall dass man eine Aktion auf ein ver nderbares Objekt ausf hren m chte gibt es die M glichkeit einen sogenannten Hotspot zu setzen Eine solche Aktion k nnte eventuell der Klick auf die Adressleiste des Browsers sein W rde man ein Bild der Adressleiste speichern m sste ein Bild f r jeden m glichen Inhalt vorhanden sein Dies w re bei einem Textfeld eine sehr schwierige wenn nicht sogar unm gliche Aufgabe Hier kann sich mit folgendem Trick geholfen werden Man sucht ein Symbol neben der Adressleiste und kann nun in Eggplant angeben dass der Klick einige Pixel neben dem gefundenen Element ausgef hrt werden soll Dann w re der Cursor in der Adressleiste positioniert und k nnte zum Beispiel die Eingabe einer URL entgegen nehmen Lesezeichen Extras Hilfe D http ww redstonesoftware com Abbildung 5 10 Eggplant Hotspot setzen 5 5 4 Texterkennung Es gibt mehrere Situationen in denen das Erkennen von Texten n tig ist So kann es notwendig sein den Inhalt einer Nachricht auszuwerten um zu erkennen ob eventuell ein Fehler aufgetreten ist oder ob die richtigen Daten angezeigt werden Man kann auch eine Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Co
40. 4 2 3 Projektbeschreibung Im Juni 2008 wurde TOPX beim Containerterminal Hamburg eingef hrt und hat das bisherige System um Funktionalit ten erweitert und viele manuelle Ablaufe abgel st Es setzt auf den mit COIN erfassten Datenbestand auf Getestet wurde TOPX auf Integrations und Systemtestebene sowohl vom Hersteller als auch von einem eigens beauftragten Dienstleister Trotzdem gab es bei der Einf hrung Probleme Ein Resultat daraus ist der Aufbau einer eigenen Testabteilung die mit den Abl ufen an einem Containerterminal vertraut ist und ihre Testdurchf hrung mit automatisierten Abl ufen optimiert Parallel zu diesem Aufbau der Testabteilung bei Eurogate ITS werden regelm ig weitere Patches f r TOPX implementiert Diese Patches und neuen Releases m ssen getestet werden Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 40 4 2 4 Testanforderung Um die Funktionsf higkeit der neuen Releases zu gew hrleisten werden verschiedene Regressionstests ausgef hrt In einer fr heren Projektphase wurden hier haupts chlich Funktionstests ausgef hrt jedoch wurde nicht auf die Korrektheit der Gesch ftsabl ufe getestet Dass dabei gravierende Probleme mit den Prozessen bersehen werden wurde im Test vor der Einf hrungsphase im Juni 2008 bemerkt Der Testprozess wurde dahin gehend modifiziert dass haupts chlich auf Gesch ftsprozesse getestet wurden Die E
41. 6 4 Wirtschaftlichkeit der Automatisierung nn 75 6 5 Synthetsehe Datei a2 Lana 76 6 5 1 Verwendung von synthetischen Daten 77 6 5 2 Erzeugung von synthetischen Daten in COIN A 77 6 6 lt Testenwon Gesch fssprozessen 2A 79 6 7 Aktueller Stand und weiteres Norgchen nn 80 7 Automatisierung der TOPX Tess nass ek 8l 7 1 Ist ZU an Eee ine ee 81 Teb Lesifallermutl uns eege 81 7 12 Lestdokumenlalion una lauten 82 213 Ree EE 82 7 1 4 Tes Seren 82 225 lt RIeIZUSIaRd ea el NN 82 1 3 Skizzierung einer m glichen Umsetzung 83 8 Zusammenfassung und Ausblick ugeet Eege aere ec 87 Quellen verzeichnis esane A a a a T N 90 GOSSE eege 92 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 5 Abbildungsverzeichnis Abbildung 1 1 Eurogate Container Terminal Hamburg see enennnnen en 8 Abbildung 2 1 allgemeines V Modell A 15 Abbildung 4 1 EOIN Hauptmenl 2 2 a Rn 35 Abbildung 4 2 Aufgereihte Container mit Van Carriern ursuesnseesseersnersnnennnennnnennnen sen 38 Abbildung 4 3 Lade und L schvorgang am CT Bremerhawven 39 Abbildung 4 4 Verladung von St ckgut snesensseeeeeeeesseesseessersseresseessseesserssresseresseeesseesseesse 40 Abbildung 5 1 HP Quality Center Graphen Testfall berdeckung ne 45 Abbildung 5 2 HP Quality Center Requirements nennen 46 Abbildung 5 3 HP Quality Center Risikoanalyse n nsneseenseesseeesseeesseesseess
42. 7 Die Implementierung von Automatisierungsskripten ist Softwareentwicklung Es werden Sprachen verwendet wie Visual Basic Script oder JavaScript die alle M glichkeiten einer Programmiersprache bieten Das bedeutet wiederum dass sie auch alle Fehlerm glichkeiten einer Programmiersprache enthalten Alle Skripte m ssen sorgf ltig programmiert dokumentiert und getestet werden Um den Aufwand hier zu minimieren ist es ratsam einen keep it simple Ansatz zu verfolgen Wenn ein erh hter Programmieraufwand ben tigt wird um einen Fehler zu entdecken der unbedeutend ist dann sollte man an dieser Stelle vielleicht von der Pr fung dieses Fehlers absehen Dies ist ein Mittel um die Wartbarkeit der Testskripte zu erhalten H ufig ben tigte Funktionalit ten sollten in Libraries ausgelagert werden Diese k nnen in weiteren Tests verwendet werden und es kann eine bessere Strukturierung der Skripte erfolgen So kann nach und nach ein Testframework entstehen auf dessen Basis sich sp ter schneller zuverl ssige Testskripte erzeugen lassen Aus Sicht des Unternehmens kommt sicherlich die Frage auf welche Anforderungen an einen Testautomatisierer zu stellen sind Aus den vorhergehenden Abs tzen kann abgeleitet werden dass der Testautomatisierer ber gute Kenntnisse in der Softwareentwicklung verf gen muss Er muss sorgf ltig programmieren k nnen um zuverl ssige Testskripte zu erstellen und er muss sich mit verschiedenen Systemarchitekturen
43. Bachelorarbeit Sascha Bartels Automatisierung von Black Box Softwaretests mit risikobasierter Priorisierung bei Eurogate IT Services GmbH Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science Sascha Bartels Automatisierung von Black Box Softwaretests mit risikobasierter Priorisierung bei Eurogate IT Services GmbH Bachelorarbeit eingereicht im Rahmen der Bachelorpr fung im Studiengang Technische Informatik am Department Informatik der Fakult t Technik und Informatik der Hochschule f r Angewandte Wissenschaften Hamburg Betreuender Pr fer Prof Dr Bettina Buth Zweitgutachter Prof Dr Franz Korf Abgegeben am 26 3 2009 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science Sascha Bartels Thema der Bachelorarbeit Automatisierung von Black Box Softwaretests mit risikobasierter Priorisierung bei Eurogate IT Services GmbH Stichworte Softwaretest Black Box Test Automatisierung Regressionstest Qualit tssicherung HP Quality Center QuickTest Professional Squish Kurzzusammenfassung Thema dieser Arbeit ist die Vorgehensweise zur Einf hrung von automatisierten Black Box Softwaretests in einem betrieblichen Umfeld Anhand von zwei unterschiedlichen Projekten werden Voraussetzungen und wichtige Schritte zur Implementierung beschrieben Dies umfasst die Analyse der zu
44. GmbH einem Tochterunternehmen der Eurogate GmbH amp Co KGaA Im Kapitel 1 1 Umfeld werden diese Unternehmen kurz vorgestellt Welche Ziele diese Arbeit hat und welche nicht wird in Kapitel 1 2 Motivation und Kapitel 1 4 Abgrenzung dargestellt Anschlie end folgt eine Begriffskl rung zu den wichtigsten Ausdr cken die w hrend der Arbeit mit Softwaretests verwendet werden Jede Branche hat ihre eigene Fachsprache Gerade die Begriffe in einem Container Terminal sind nicht immer leicht verst ndlich Aus diesem Grund befindet sich im Anhang ein Glossar mit den wichtigsten Begriffen die zum Verst ndnis der Arbeitsabl ufe n tig sind Um den Lesefluss nicht zu st ren werden diese Begriffe beim ersten Vorkommen im Text kurz erl utert 1 1 Umfeld Die Eurogate GmbH amp Co KGaA ist mit einem Umschlag von 13 9 Mio TEU 20 Fu ISO Container Twenty feet Equivalent Unit im Jahre 2007 und neun Terminal Standorten Europas gr ter Container Terminal Betreiber Zusammen mit der Contship Italia S p A werden Seeterminals an der Nordsee im Mittelmeerraum und am Atlantik mit Verbindungen ins europ ische Hinterland betrieben Neben dem Containerumschlag werden diverse Dienstleistungen angeboten von cargomodalen Services Transportdienstleistungen ber Container Depot bis Container Wartung und Reparatur sowie intermodaler Transport Transportkette mit verschiedenen Verkehrstr gern und Logistik Management IT Logistik L sungen und
45. Internal Actions A Login Item vf BookFlight v Book a Flight Mercury v CS Book a Flight Mercury Operation It H A FlightFinder E passit ix erch EEE passLast0 Set meier 4 FlightConfirmation JE creditCard Select Diners Club A External Actions BEE creditnumber Set 12346578 ce ep d mn Select SI E cc_exp_dtyr Select 2009 E buyFlights Click Abbildung 5 8 HP QuickTest Professional Action im Keyword View Auf dem Screenshot sind im linken Bereich eine verlinkte Funktionsbibliothek und die Action zu sehen die der Reihe nach abgearbeitet werden Rechts erkennt man die Details zu der Action BookFlight Bei der AUT handelt es sich in diesem Fall um eine Webapplikation die von HP f r das Tutorial zu QTP HPQTP Tut2008 bereit gestellt wird Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 54 In dem Tutorial sind die wichtigsten Grundfunktionalit ten von QTP erl utert Die Page ist unter http newtours demoaut com zu erreichen Diese Webanwendung ist nicht mit den in dieser Arbeit vorgestellten Projekten vergleichbar aber um die Arbeitsweise von QuickTest Professional darzustellen ist diese Anwendung sehr gut geeignet Die Sicht auf das Automatisierungsskript ist umschaltbar zwischen dem Keyword View und dem Expert View A
46. LUESSEL 8 T 67 client Click T 67 client Type T 67 Client Type Wert E 67 Client Type E 67 client Type COIN_ohne sstrrr COIN D Failed E 67 Cient zs 301 Hauptverteiler Containerverwaltung Abbildung 6 5 HP QC Reporter Zus tzlich zu dem Eintrag im Reporter werden zwei Dateien erzeugt Eine Datei enth lt die aktuellen Referenzdaten die andere den Maskeninhalt der bei der aktuellen Ausf hrung angezeigt wurde Als Namenskonventionen wurden funktion_schl ssel_compTo_jjjmmtthhmmss txt Junktion_schl ssel_err_jjjmmtthhmmss txt gew hlt Somit ist sicher dokumentiert wann welcher Fehler aufgetreten ist Es w re durchaus vorstellbar dass diese Dateien im HP Quality Center abgespeichert werden um eine Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 73 konsistente Dokumentation zu erm glichen und diese Dateien gegebenenfalls den entsprechenden Fehlern zuordnen zu k nnen Somit k nnte das Defect Tracking unterst tzt werden 6 3 3 Analyse der Testergebnisse Mit einer fr hen Version des Neusystems wurde ein Testlauf mit 8 Aufrufen durchgef hrt Aufgrund des fr hen Entwicklungsstadiums wurden einige Abweichungen aufgedeckt Zuerst war aufgefallen dass beim Testexport der Masken im Altsystem alle Eingabefelder Unterstriche enthalten w hrend im Neusystem an dieser Stelle Leerzeichen vorhanden sind Der Komparator wurde daher so an
47. Links angezeigt werden Um zu verhindern dass ein langsamer Aufbau der Seite dazu f hrt dass nicht sofort alle Bilder angezeigt werden kann in das Feld load time eine Zeit eingetragen werden nach der die Seite fertig aufgebaut sein muss Es besteht auch die M glichkeit per Quellcode eigene Abfragen zu generieren und gegebenenfalls einen Fehler zu melden Alle Fehler die w hrend eines Testlaufs aufgetreten sind werden nach der Testdurchf hrung in einem Berichtsfenster angezeigt Im Automatisierungsskript k nnen mit dem Befehl reporter ReportEvent Fehler Warnungen oder Erfolgsmeldungen erzeugt werden Diese erhalten noch einen Namen und eine genauere Beschreibung und werden somit nach der Testdurchf hrung angezeigt Bei Fehlern die mit Hilfe der Checkpoints aufgedeckt wurden werden alle berpr ften Daten angezeigt und es wird ein Screenshot der Anwendung zu dem entsprechenden Zeitpunkt dargestellt Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 56 5 4 3 Datengetriebener Test In der Data Table k nnen Daten zu jeder Action und globale Daten f r das Testprojekt angelegt werden Die Data Table ist nichts anderes als eine Excel Tabelle die in QTP eingebunden ist Diese Tabelle liegt im Projektverzeichnis und kann auch mit Excel bearbeitet werden Die Spaltennamen sind Namen von Parametern die in den Testschritten verwendet werden
48. NSCHOW Uwe Objektorientiertes Testen und Testautomatisierung in der Praxis Konzepte Techniken und Verfahren 1 Aufl Heidelberg dpunkt Verl 2005 ISBN 3 89864 305 0 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 91 Glossar BAPLIE Bayplan Stowage Plan Occupied And Empty Locations Message EDI Nachricht enth lt den aktuellen Stauplan eines Schiffes Bay Row Tier System Prinzip der Staupl ne eines Schiffes Der Stauplatz wird mit Koordinaten in L nge Breite und H he identifiziert Es wird zuerst die Bay dann die Containerreihe Row l ngsschiffs und zuletzt die Lage Tier angegeben B Nr Bearbeitungsnummer Zoll Durch Vergabe dieser Nummer ist ein Container vom Zoll zum wasserseitigen Export freigegeben CAL Container Anmelde Liste Verladepapier f r Container Soll Ladeliste Enth lt Einzelheiten ber gebuchte Container Containernummer Gewicht Inhalt etc Cargomodale Dienstleistung Dienstleistungen die mit dem Transport von Waren zu tun haben wie Lagerung und Zollabwicklung Transportdienstleistungen COIN Container Information Softwaresystem das am Container Terminal Hamburg eingesetzt wird Containerbay Laderaum in Querrichtung eines Schiffes Jede Bay wird mit einer fortlaufenden Nummer von vorne nach hinten zur Identifizierung versehen Die Baypl tze f r 20 Fu Container sind mit ungeraden Nummer versehen die f
49. Neu und Altsysteme gewollt unterscheiden was aber erst im Lauf des Projektes ersichtlich wurde Auch wurde deutlich dass weitere Verbesserungen in der Dokumentation der Anwendungen COIN und TOPX ben tigt werden Aber trotz dieser Schwierigkeiten Konnten schnell Fehler in dem Neusystem identifiziert werden sogar mehr als urspr nglich erwartet Diesen ersten Erfolge und positiven Erfahrungen sollten zeitnah ausgenutzt werden um die Testautomatisierung weiter voran zu treiben Im Projektplan der COIN Migration ist vorgesehen dass der gesamte Test von Eurogate ITS ausgef hrt wird Der knappe Zeitplan kann nur eingehalten werden indem eine effektive Testautomatisierung eingesetzt wird Deswegen sollte zuerst die Umsetzung dieser Tests im Mittelpunkt stehen Eine parallele Implementierung von automatisierten Tests f r TOPX wird mit den aktuellen Ressourcen nicht m glich sein F r die COIN Migration bedeutet dies dass nun Testf lle erstellt werden sollten die Gesch ftsprozesse umfassen beginnend mit einfachen Tests wie dem Erstellen eines Containerdatensatzes Anzeigen der Daten ndern der Daten und L schen der Daten Somit k nnen alle Arten des Datenbankzugriffs auf diesen Bereich sichergestellt werden Dieser Ablauf sollte automatisiert werden Er kann anschlie end so modifiziert werden dass nicht nur ein Container bearbeitet wird sondern sehr viele Damit lie e sich eine bessere Aussage ber die Zuverl ssigkeit des Systems tre
50. Schritt am Server berpr fen ob diese korrekt angekommen und verarbeitet worden sind In diesem Fall sind die Client und die Serveranwendung jeweils in einer eigenen VNC Session ge ffnet Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 60 Leider fehlt eine direkte Unterst tzung des HP Quality Centers wie sie bei Quick Test Professional verf gbar ist Da alle Daten von Eggplant als Text bzw Tiff vorhanden sind und keinerlei Daten in propriet ren Formaten verwendet werden ist es sicher m glich eine Integration im Quality Center als Workaround selbst zu konstruieren Eggplant kann als Konsolenanwendung ausgef hrt werden und lie e sich so mit einem entsprechenden Startskript ber das Quality Center starten Dies wurde allerdings nicht ausprobiert und basiert lediglich auf den Aussagen des Technikers von Redstone Software der die Live Demo durchgef hrt hat Alle Erkenntnisse basieren zurzeit auf Dokumentationen und einer Live Demo sowie zwei einst ndigen Telefonkonferenzen Wie leistungsf hig das Tool in der Praxis ist wird sich erst im Rahmen einer Teststellung evaluieren lassen 5 6 Froglogic Squish Bei Squish von der Hamburger Firma Froglogic handelt es sich um Tool f r automatisierte GUI Tests mit Applikationen die auf dem QT Toolkit basieren Squish hat die M glichkeit die innere Repr sentation von QT Elementen in einer AUT zu ermitteln
51. Sicht abgel st werden soll Man m chte erreichen dass die Tests komplett von Eurogate ITS bernommen werden Aktuell werden nur die nderungen die die einzelnen Patches beinhalten berpr ft Es werden keine speziellen Tests durchgef hrt die gezielt Fehler aufdecken sollen die in diesen neuen Versionen hinzu gekommen sind Das Traumziel w re die M glichkeit einen kompletten Systemtest automatisch laufen lassen zu k nnen Man m sste dann nur noch ein neues Release einspielen und anschlie end den automatischen Test berpr fen lassen ob irgendwo ein Fehler neu aufgetreten ist Dieses Ziel ist nicht ohne gr eren Aufwand zu erreichen sofern es berhaupt m glich ist Trotzdem sollen die Testabl ufe optimiert werden eben auch durch die Einf hrung automatischer Tests 1 3 Aufbau Diese Arbeit beginnt mit einem einf hrenden Teil ber den Themenkomplex Softwaretests mit einem Schwerpunkt in der Testautomatisierung Anschlie end wird die Auswahl von Tools zur Unterst tzung von automatisierten Tests diskutiert Einer Beschreibung der allgemeinen Vorgehensweise folgt die Darstellung der konkreten Umsetzung bei Eurogate mit Bezug auf die beiden hier herausgearbeiteten Projekte Im Praxisteil dieser Arbeit wird gezeigt wie mit den gew hlten Hilfsmitteln eine Automatisierung in den hier vorgestellten Projekten implementiert werden kann Im Abschluss werden die hierbei gewonnenen Erkenntnisse zusammen getragen und um einen
52. Systementwurf Ka Technischer Integrationstest Systementwurf Ber Komponententest nn Z Abbildung 2 1 allgemeines V Modell Auf der linken Seite beginnen die konstruktiven Aktivit ten mit der Anforderungsdefinition Hier werden die Anforderungen des Auftragsgebers spezifiziert Im funktionalen Systementwurf werden die Anforderungen auf Funktionen des neuen Systems abgebildet Die technische Realisierung wie die Definition der Schnittstellen zur Systemumwelt und das Festlegen der Systemarchitektur erfolgt in dem technischen Systementwurf In der Komponentenspezifikation werden die Aufgaben der innere Aufbau und die Schnittstellen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 15 jedes Teilsystems festgehalten Erst danach beginnt die eigentliche Programmierung in der die spezifizierten Teile in einer Programmiersprache implementiert werden vgl Linz2005 S 40 Jeder dieser Entwicklungsstufen sind Teststufen auf der rechten Seite der Darstellung zugeordnet Diese werden im Folgenden n her erl utert 2 1 1 Komponententest Der Komponententest ist der Test auf der untersten Stufe der Entwicklung Er ist der erste systematische Test dem die neu programmierten Module unterzogen werden Man kann hier noch zwischen einem Modultest und einem Klassentest unterscheiden Dies ist abh ngig von der eingesetzten Programmiersprache Bei prozeduralen Sprac
53. Ticket System f r den User Help Desk verwendet Hier k nnen aus erfassten Tickets gegebenenfalls Defects erzeugt werden Der Hersteller von TOPX hat Zugriff auf dieses System und kann die bestehenden Defects einsehen Dieses System wurde bereits vor der Einf hrung des HP Quality Centers verwendet Es sind also Fehler in diesem System hinterlegt die vor der Einf hrung des HP Quality Centers aufgetreten sind aber noch bearbeitet werden Neue Fehler werden weiterhin in Intrexx erfasst aber ber eindeutige Indizes im Quality Center referenziert So muss der Lieferant nicht mit zwei Systemen arbeiten aber trotzdem wird die Funktionalit t des HP Quality Centers in Bezug auf Defect Tracking und Analysem glichkeiten des Testprozesses voll ausgenutzt F r zuk nftige Projekte ist geplant dass nur noch das HP Quality Center verwendet wird 7 1 3 Testpriorisierung Zu jedem Release wird betrachtet in welchem Funktionsbereich die meisten nderungen vorgenommen wurden Diese Bereiche werden generell am st rksten mit Testf llen berdeckt Die Fachabteilungen die sich in den jeweiligen Bereichen auskennen priorisieren die Testf lle innerhalb dieser Bereiche Die Kritikalit t wird in 5 Kategorien unterteilt von 1 kritisch bis 5 gering Die Kategorie wird danach bemessen wie schnell und wie stark ein Ausfall des entsprechenden Bereiches Auswirkungen auf die Produktion hat 7 1 4 Testausf hrung Die Tests werden von Testern des externen Dien
54. ULT P 2 Test Sets Edt Yiew Tests Analysis Releases 13 x 5 5 T Gh seectTests prun naiss d X ala a AlO Root Execution Grid Execution Flow Test Set Properties Linked Defects E H Unattached Requirements BPT tests Flight e E 24 Completed BPT Tutorial D Je EZ Mercury Tours Web Site PER ua Mercury Tours Functionality en El Functionality And UI Be i er Business a Components D H bi H mi Mercury Tours Sal SS gt CH E E B Mercury Tours UI 8 Sa erer eet Trip Type User Name 1 Change First amp Test Plan E Z Release 10 5 Ei H Cycle 1 4 db B New Features Si gt gt Test Lab Bai Cycle 2 1 Departing And l Password Diet Emil E A Cycle 3 er le 4 Ka PZ v v Defects S 7 K K 1 amp irline Prefer 1 Departing Date 1 Confirm Password 1 Change Phone v V V S D 5 5 B 1 Service Class 1 Retuming Date 1 F st amp Last N 1 Sign On User Name 1 Change Mailing V V Es gt u u 1 Flight Time Pr 1 Range of Dates 1 Email Contact 1 Sign On Password ZG v 2 a gt 1 Number Of Pass l View Calendar 1 Phone Contact A v gt Ei 1 Passenger Name 1 Mailing Infoma Abbildung 5 5 HP Quality Center Test Lab Execution Flow Der gestrichelte Pfeil bedeutet dass der Test ausgef hrt wird sobald der vorherige Test gelaufen ist Ein blauer durchgezogener Pfeil bedeutet dass de
55. Voraussetzung ist dass der Zugriff auf eine shared QT Library die auch die AUT verwendet gew hrleistet ist Squish wird also auf dem Server selbst installiert der die AUT bereit stellt Es kann zum Beispiel ber eine XWindow Session von einem Windowsrechner aus bedient werden F r Squish existiert ein Plug In welches eine Integration mit dem HP Qualitiy Center erm glicht Somit k nnen Testf lle in der Datenbank des Quality Centers abgelegt werden Au erdem k nnen die Tests ber das Quality Center ausgef hrt und verwaltet werden 5 6 1 Skripterstellung Die Erstellung des Automatisierungsskripts erfolgt in Squish IDE im Capture and Replay Verfahren Die AUT wird von Squish gestartet und die Benutzeraktionen mit dieser werden aufgezeichnet daraus ergibt sich ein Skript in der zuvor gew hlten Sprache Je nachdem welche Skriptsprachen auf dem Rechner unterst tzt werden stehen JavaScript Tcl Python und Perl zur Verf gung Mit diesem aufgezeichneten Skript lassen sich die Interaktionen automatisch wiederholen 5 6 2 Verifikation der Ergebnisse Zur automatisierten berpr fung der Ergebnisse k nnen sogenannte Verification Points in das Skript eingepflegt werden Es wird ein Breakpoint an der Stelle im Skript gesetzt an welcher der Verification Point eingef gt werden soll Nun l sst man das Skript bis zu diesem Breakpoint laufen und f gt den Verification Point ein Dies passiert per Knopfdruck in der Squish IDE
56. artment Informatik Department of Computer Science 32 oder einen Satz an Stichprobentests die ber das System verteilt sind zu automatisieren Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 33 4 Projektbeschreibungen Es folgt eine Beschreibung der Projekte f r die eine Testautomatisierung implementiert werden soll Diese Beschreibungen stellen die Grundlage f r das weitere Vorgehen dar 4 1 COIN Im Zuge einer 1 1 Migration soll das bisherige COIN System durch ein System das auf einer aktuellen Architektur basiert ersetzt werden Im Folgenden werden die Systemarchitektur und die Aufgaben die mit COIN erledigt werden beschrieben Anschlie end folgt die Beschreibung des Projektes sowie der Testanforderungen 4 1 1 Technische Beschreibung COIN ist eine COBOL Entwicklung die im Jahre 1983 in Betrieb genommen wurde Seit dieser Zeit wurde es kontinuierlich weiterentwickelt und an die sich ver ndernden Anforderungen angepasst Es l uft auf einer Unisys Host Systemumgebung mit dem Betriebssystem OS2200 und wird auf Windowsrechner mit Hilfe der Terminalsoftware Exceed von Hummingbird www hummingbird com verwendet Die Datenhaltung erfolgt auf dem Datenbankmanagementsystem DMS in einer hierarchischen Datenbank Im Gegensatz zu relationalen Datenbanken werden die Daten hier in einer Baumstruktur verwaltet Schnittstellen zu anderen System
57. bh ngigkeiten den Testvorgang erschweren 2 1 2 Integrationstest Der Integrationstest schlie t an den Komponententest an und setzt voraus dass die einzelnen Komponenten bereits ausreichend getestet und gegebenenfalls korrigiert wurden Anschlie end werden verschiedene Komponenten zu einem Teilsystem zusammengesetzt Ziel ist es nun das Zusammenspiel dieser Komponenten und deren Schnittstellen zu testen vgl Linz2005 S 50 Fehler in den Schnittstellen also inkonsistente Parameterlisten oder R ckgabewerte fallen sofort beim Zusammensetzen von Komponenten auf Diese Fehler sind sehr leicht aufzudecken schwieriger wird es bei Problemen die sich erst im dynamischen Test also beim Ausf hren des Codes zeigen M gliche Fehlerzust nde die auftreten k nnen sind folgende Es werden keine oder syntaktisch falsche Daten zwischen den Komponenten ausgetauscht so dass es zu Fehlern oder Abst rzen kommt bergebene Daten werden falsch interpretiert Timing Probleme oder Kapazit tsprobleme k nnen auftreten Daten kommen zu sp t an oder es werden zu viele Daten in zu kurzer Zeit gesendet bzw empfangen Alle diese Fehler fallen in einem Komponententest nicht auf da sie ausschlie lich durch Wechselwirkungen mit mehreren Komponenten entstehen vgl Linz2005 S 53 54 Der Integrationstest von gr eren objektorientierten Anwendungen kann im Allgemeinen in drei Stufen unterteilt werden Klassenintegration Komponenteninte
58. che System beschr nkt bleiben Keine Auswirkung auf Umsysteme C Im Fehlerfall ist lediglich mit leichten Einschr nkungen zu rechnen Die Fehlerwahrscheinlichkeit wird aus der H ufigkeit der Benutzung der jeweiligen Funktionalit t ermittelt Es erfolgt eine Einteilung von 1 3 wobei Funktionalit ten mit der Fehlerwahrscheinlichkeit 1 am h ufigsten verwendet werden Somit hat eine Funktionalit t mit der Risikobewertung A 1 die h chste Priorit t Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 25 Eine geschickte Einteilung in die entsprechenden Kategorien ist keine einfache Aufgabe Bei Eurogate wird die Fehlerwahrscheinlichkeit im COIN System daran festgemacht wie h ufig eine Funktion aufgerufen wird Daf r werden im laufenden Betrieb Statistiken gef hrt Es wird also davon ausgegangen dass es wahrscheinlicher ist dass ein Fehler im Betrieb auftritt je h ufiger eine Funktion verwendet wird Ein Alternative w re hier die Erstellung einer Fehlerprognose Dies kann auf Basis verschiedener Metriken anhand des Quellcodes geschehen Auch Analysen ber die Komplexit t und die Vererbungsstruktur k nnen herangezogen werden Ein entsprechendes Verfahren ist in Gericke2007 beschrieben Eine Einteilung in die Kategorien A C f r den m glichen Schaden ist nur durch Fachleute m glich die sich sehr genau in den entsprechenden Projekten auskennen Der Au
59. che VB Script Tel Sense Talk Datenbank Zugriff ja nein geplant Lasttest nein nein Betriebssystem Windows UNIX MacOS ca 3 000 EUR 2 Lizenzen bereits Kosten Lizenz vorhanden k a ca 3 750 EUR F r den GUI Test von TOPX wird eine Erkennung von QT Elementen zwingend vorausgesetzt Aufgrund dessen bleiben nur die Tools Squish und Eggplant brig Beide Tools haben Vor und Nachteile die mit Evaluationsversionen genauer betrachtet wurden QuickTest Professional ist leider nicht in der Lage mit QT Elementen zu arbeiten Da aber bereits 2 Lizenzen bei Eurogate vorhanden sind wird der Einsatz f r den Test von COIN bewertet Es folgt eine Beschreibung der drei Tools sowie eine Bewertung Abschlie end wird das Ergebnis der Toolauswahl dargestellt Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 53 5 4 HP Quicktest Professional HP Quicktest Professional QTP ist ein Tool zur Automatisierung von GUI Tests unter Windows Die internen Repr sentationen von Windows Steuerelementen k nnen erkannt und verwendet werden Durch Plug Ins ist es unter anderem auf SAP und Javaanwendungen erweiterbar Das Aufzeichnen der Testabl ufe wird mittels Capture amp Replay realisiert Da QTP von HP entwickelt wird wird auch eine gute Anbindung an das Quality Center angeboten Testf lle k nnen hier abgelegt verwaltet und ausgef hrt werden 5 4 1 Skr
60. chiedenen Bedingungen gestestet werden Es werden also gleiche Tests sehr h ufig ausgef hrt oder sogar von vielen Benutzern gleichzeitig Eine manuelle Ausf hrung ist hier fast unm glich Es ist zum Beispiel sehr schwierig 200 Benutzer zu koordinieren sofern man diese berhaupt zur Verf gung hat um ein System zu testen Auch muss man hierf r gegebenenfalls die Hardwarekosten mit ber cksichtigen Schwer zu automatisieren sind hingegen viele andere Tests von nicht funktionalen Anforderungen Das sind Tests die folgende Aspekte verifizieren sollen Wartbarkeit Portierbarkeit Testbarkeit Benutzbarkeit Es ist f r ein Automatisierungstool unm glich festzustellen wie komfortabel eine Oberfl che ist oder ob die Farben der Bildschirmanzeige harmonieren F r diese F lle ist immer ein manueller Test erforderlich Steht man nun vor der Aufgabe zu entscheiden welche Testf lle als erstes automatisiert werden sollen k nnen verschiedene Faktoren entscheidend sein Welche wirklich relevant sind h ngt von den spezifischen Gegebenheiten ab Man kann sich entscheiden zuerst die wichtigsten Tests sofern diese zu identifizieren sind die Tests der wichtigsten Funktionen die Tests die am einfachsten zu automatisieren sind die Tests bei denen sich eine Automatisierung am schnellsten bezahlt macht die Tests die am h ufigsten ausgef hrt werden Fakult t Technik und Informatik Faculty of Engineering and Computer Science Dep
61. dass die Software sich in die Gesch ftsprozesse eingliedert Die Software sollte alle wichtigen betrieblichen Vorschriften und Benutzerkriterien erf llen Dabei handelt es sich unter anderem um folgende Kriterien Datenschutz ergonomische Normen f r Benutzeroberfl chen Abbildung der Gesch ftsprozesse etc vgl Sneed2002 S 232 234 Der Funktionstest soll berpr fen ob die Software alle fachlichen Anforderungen ausreichend erf llt Dabei ist es Voraussetzung dass alle Funktionen genau spezifiziert sind Dies kann in einem Fachkonzept einer Systemspezifikation oder einem Benutzerhandbuch geschehen Die Testf lle decken dann alle spezifizierten Funktionen ab und pr fen diese Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 18 anhand des entsprechenden Dokuments Dieses Dokument wird auch als Testorakel bezeichnet vgl Sneed2002 S 234 Nachdem die Klassen Integrations und Funktionstests erfolgreich abgeschlossen wurden empfiehlt es sich gerade bei komplexen Client Server Systemen aber auch bei Host Systemen einen Performanz und Belastungstest durchzuf hren Unter Umst nden kann man auch mit bestimmten Prototypen in einer fr heren Phase Belastungstests durchf hren Das Ziel ist es das Verhalten des Systems bei Lastspitzen und die Leistungsf higkeit bei Belastung zu testen F r den Performanztest m ssen viele Clients simuliert wer
62. daten sehr viele Variablen die zu unterschiedlichen Gesch ftsprozessen f hren k nnen Bespiele f r solche Angaben sind H he L nge Leergewicht Gesamtgewicht Gefahrstoffe K hlcontainer Standardcontainer Zielhafen Reeder usw Eine M glichkeit der Verwendung von synthetischen Daten f r COIN ist das Anlegen von Containern die per Schiff exportiert werden sollen Es erfolgt eine Vorabmeldung per EDI Nachricht COPRA Load die beschreibt welche Container auf das Schiff geladen werden sollen Hier sind bereits die Staupositionen an Bord vermerkt Die Container werden am Containerterminal per LKW Zug oder per Schiff angeliefert Diese Anlieferung wird in Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 77 COIN erfasst Diese Daten bilden die Grundlage f r verschiedene Aktivit ten in COIN und auch in dem operativen Planungssystem TOPX Empfang EDI Anlieferung Erfassung Weiterverar Nachricht der Export der Container beitung der COPRA Load Container in COIN Daten Abbildung 6 6 Gesch ftsprozess Exportcontainer erfassen Um auf diese Weise eine Datengrundlage f r diverse Testausf hrungen zu erzeugen wird eine EDI Nachricht erzeugt die mehr als 100 unterschiedliche Containerdaten enth lt Diese EDI Nachricht wird ber die entsprechende COIN Schnittstelle importiert F r die Erfassung der Anlieferung muss jeder einzelne Container mit ein
63. dem werden die Internet und Intranetauftritte des gesamten Konzerns mittels eines CMS Content Management Systems betreut Zu diesen Online Anwendungen kann man auch das Infogate z hlen Es ist ein Internet Portal in dem Daten f r Kunden bereitgestellt werden Der Kunde kann dar ber Informationen ber den Schiffsverkehr am Terminal erhalten sowie L sch und Ladelisten und wichtige Informationen ber seine Container vgl Eurogate2008 3 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 8 1 2 Motivation Software muss getestet werden das ist keine neue Erkenntnis Bekannt sind vielleicht solche verheerende Softwarefehler wie jener der die Venussonde Mariner 1 im Jahre 1962 zur kontrollierten Selbstzerst rung veranlasste Der Schaden belief sich auf ca 18 5 Mio Ein hnlicher Vorfall zerst rte 1996 die Ariane 5 deren Entwicklungskosten innerhalb von 10 Jahren 5 5 Mrd betrugen vgl Vigenschow2005 S 9 12 Mit Sicherheit hat sich schon jeder ber Fehler in kommerziellen und nicht kommerziellen Softwareprodukten ge rgert Im betrieblichen Umfeld k nnen solche Fehler immense finanzielle Verluste bedeuten Das Testen von Individualsoftware ist nicht nur dem Hersteller dieser vorbehalten auch der Kunde der eine solche Software in Auftrag gegeben hat ist sp testens beim Abnahmetest dazu angehalten das Produkt ausreichend zu berpr fen W
64. den die gleichzeitig auf das System zugreifen Es k nnen Testf lle aus dem Integrationstest verwendet werden die auf mehreren Clients ausgef hrt werden Der Belastungstest f r Client Server Anwendungen soll das Verhalten des Systems berpr fen wenn ein hohes Datenaufkommen generiert wird vgl Sneed2002 S 243 F r den Performanztest sind automatisierte Testf lle sehr hilfreich So k nnen mit einigen Tools viele Clients an einem Rechner simuliert werden die zugleich die automatisierten Tests ausf hren Eine manuelle Testausf hrung an vielen Clients bedeutet einen erheblichen Mehraufwand 2 1 4 Abnahmetest Bevor eine Software beim Kunden in Betrieb genommen werden kann erfolgt der so genannte Abnahmetest Der Abnahmetest kann der einzige Test sein an dem der Kunde direkt beteiligt oder f r den er selbst verantwortlich ist Typischerweise kann unter anderen auf vertragliche Akzeptanz und Benutzerakzeptanz getestet werden Zwischen dem Kunden und dem Hersteller wird vor der Entwicklung ein Entwicklungsvertrag geschlossen in dem die Abnahmekriterien festgehalten sind Beim Abnahmetest pr ft der Kunde die Einhaltung dieser Kriterien Es ist sicherlich ratsam dass der Entwickler zuvor in seinem Systemtest diese Kriterien bereits berpr ft hat Im Gegensatz zu dem Systemtest findet der Abnahmetest in der Systemumgebung des Kunden statt F r die Abnahmetests k nnen durchaus die gleichen Testf lle verwendet werden die auch schon
65. den Daten eingetragen werden Erst wenn alle wichtigen Felder mit korrekten Daten gef llt wurden wird dieser Datensatz in der Datenbank angelegt Ohne den Datensatz anzulegen kann die Maske nur mit den Aktionen STOP oder EXIT verlassen werden Im manuellen Test w rden diese Anforderungen so umgesetzt werden dass der Tester jeden Dialog sowohl im Alt als auch im Neusystem ffnet und Zeichen f r Zeichen auf Gleichheit berpr ft anschlie end die Tab Reihenfolge kontrolliert und die Aktionen testet Zum einen w rde hier ein erheblicher Testaufwand entstehen zum anderen ist die Wahrscheinlichkeit dass ein Fehler bersehen wird recht hoch Aufgrund der automatischen bersetzung des Neusystems ist davon auszugehen dass nicht viele Fehler entstehen werden Da das Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 36 Vergleichen von Bildschirmmasken als eher langweilige T tigkeit zu betrachten ist muss man mit einem hohen Erm dungsfaktor rechnen Hat der Tester bereits einige Masken erfolgreich getestet wird seine Sorgfalt in den weiteren Masken nachlassen Dies ist ein ganz normales menschliches Verhalten Weiter gefordert ist der Test der ca 500 verschiedenen Funktionen Aufgrund dieser gro en Menge an Funktionen soll von den Fachabteilungen eine Risikobewertung erfolgen Es ist von Eurogate gefordert dass die Funktionen nach Benutzungsh ufigkeit 1
66. den des Schiffes entstehen Abbildung 4 2 Aufgereihte Container mit Van Carriern Eurogate2006 S 8 Ein weiterer Aufgabenbereich in dem TOPX ben tigt wird ist die Schiffsplanung In der Schiffsplanung wird entschieden welcher Container welchem Ladeplatz des Schiffes zugeordnet wird Auch hier ist eine ganze Reihe an Rahmenbedingungen zu beachten So ist es nicht der Fall dass ein voll beladenes Schiff komplett gel scht und mit anderen Containern beladen wird Ein Schiff f hrt auf seiner Tour verschiedene H fen an An jedem Hafen werden Container gel scht und geladen Die Container haben entsprechend unterschiedliche Zielh fen So muss bei der Schiffplanung darauf geachtet werden dass die Container die am Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 38 n chsten Zielhafen gel scht werden sollen nicht unter Containern stehen die erst sp ter gel scht werden Sonst m ssten erst alle Container die auf dem eigentlichen L schcontainer stehen vom Schiff genommen und anschlie end wieder verladen werden Da jede Containerbewegung dem Auftraggeber in Rechnung gestellt wird kann es im Fall einer Fehlplanung leicht zu Differenzen mit dem Kunden kommen Ebenfalls sind die verschiedenen Gewichte der Container zu beachten Das Gewicht sollte m glichst gleichm ig auf dem Schiff verteilt sein damit das Schiff nicht in eine Schr glage ger t Liegt
67. e Testsdaten f r den n chsten Test darstellen So eine Konstellation l sst sich nicht immer vermeiden und ist h ufig auch sehr effektiv Es sollte trotzdem vorsichtig mit dieser Technik umgegangen werden Weitere Regeln aus der Softwareentwicklung wie eine ausreichende Dokumentation und die Verwendung von Namenskonventionen sollten bei der Erstellung von automatisierten Tests ebenfalls eingehalten werden vgl Fewster1999 S 191 ff 3 4 Metriken Wenn eine Firma in die Verbesserung ihres Softwaretest Prozesses oder in die Automatisierung von Tests investiert m chte sie wissen ob sich diese Investition gelohnt hat Eine wichtige Metrik kann das ROI Return on investment sein Folgende Tabelle zeigt eine Beispielrechnung wie das ROI f r einen verbesserten Testprozess ohne Automatisierung ermittelt werden kann Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 29 aktueller Prozess verbesserter Prozess Testkosten 10 000 20 000 Defect Detection Percentage DDP 70 90 gefundene Defects 700 900 Kosten der Defectbehebung im Test 70 000 90 000 gefundene Defects nach Release 300 100 Kosten der Defectbehebung nach Release 300 000 100 000 Summe Kosten 380 000 210 000 Ersparnis durch Prozessverbesserung 170 000 Investition zur Prozessverbesserung 10 000 ROI Einsparung Investi
68. echnik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 24 Eine gute Quelle f r Testf lle sind Anwendungsf lle einer Software Im betrieblichen Umfeld sind diese die Abbildung der Gesch ftsabl ufe Die Gesch ftsabl ufe m ssen hierf r dokumentiert sein mit Vor Nachbedingung und Szenarien Bei diesem Funktionstests mit Anwendungsf llen wird die Software systematisch mit sinnvollen Anfangszust nden und Eingaben die einen Gesch ftsablauf abbilden getestet M gliche Fehler die hierbei aufgedeckt werden k nnen sind unvollst ndig implementierte Anwendugsf lle fehlerhaft implementierte Gesch ftslogik und nicht beachtete Abh ngigkeiten zwischen den Anwendungsf llen vgl Sneed2002 S 238 239 2 6 Risikoanalyse und Priorisierung von Testf llen Bei dynamischen Tests ist ein vollst ndiger Test nicht m glich Jeder Test ist nur eine Stichprobe Doch auch die Anzahl dieser stichprobenartigen Tests Kann ein sehr hohes Ma annehmen besonders bei komplexeren Softwareprojekten Aufgrund von Ressourcenmangel und Termindruck kann es durchaus sein dass auch bei diesen Stichproben nicht alle Tests ausgef hrt werden k nnen Es muss also entschieden werden welche Tests tats chlich ausgef hrt werden Dabei spielt auch die Reihenfolge der Testausf hrung eine wichtige Rolle Sollte man w hrend der Testausf hrung bemerken dass die Zeit bis zur Deadline nicht ausreic
69. eesseresseeesseesseesse 47 Abbildung 5 4 HP Quality Center Test Plan 48 Abbildung 5 5 HP Quality Center Test Lab Execution low 49 Abbildung 5 6 HP Quality Center Test Lab manuelle Testausf hrung 50 Abbildung 5 7 HP Quality Center Defects 22200222000200000nnneennnnennnnnnennnnnsnsnnnnnnnenensnanenn 51 Abbildung 5 8 HP QuickTest Professional Action im Keyword View 54 Abbildung 5 9 HP QuickTest Professional Checkpoint sseeeseseeeseeeessesesesresseseresresseseresresse 56 Abbildung 5 10 Eggplant Hotspot setzen ea 59 Abbildung 5 11 Squish Adressbuch Beispiel 62 Abbildung 6 1 COIN Fenster mit Funktionsaufruf AAA 67 Abbildung 6 2 COIN Maske 362 Contameranzege nennen 68 Abbildung 6 3 Data Table in QuickTest Professional A 68 Abbildung 6 4 Quick Test Professional Data Table Global AAA 69 Abbildung 6 5 HP QC Reporter an linie ed 73 Abbildung 6 6 Gesch ftsprozess Exportcontainer erfassgen nennen 78 Abbildung 6 7 HP QTP Data Table Container anlegen nme 78 Abbildung 6 8 HP QTP Data Table globales Datenblatt A 79 Abbildung 7 1 TOPX mit ge ffneter Schiffsansicht 2220220r nern nnnennnnennnen nennen 84 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 6 1 Einleitung Diese Arbeit entstand im Rahmen der Gr ndung des Bereichs Testmanagement in der Eurogate IT Services
70. eilung entspricht dem iterativen Entwicklungsmodell Zu einem Release kann eine Beschreibung erfasst sowie mehrere Anh nge in Form von Bildern Dateien Links etc angef gt werden Au erdem k nnen Start und Enddaten f r das Release angelegt werden so dass eine Aussage ber den Fortschritt gemacht werden kann Die gleichen Daten k nnen f r die Cycles erfasst werden Auf Grundlage dieser Daten und verschiedenen Daten aus den anderen Modulen k nnen Auswertungen ber den Status der Releases erstellt werden Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 44 Details Attachments Progress Quality Total days in release Days Remaining days in release Total test instances for release Elapsed Remaining test instances to run Test Instance Runs Required execution rate test instancesiday Actual execution rate test instancesiday i Completed Remaining Cycle 1 New F Cycle 2 New F Cycle 3 Sanit Cycle 4 Full Cycle VIEH ssigned requirements V P Planned coverage VIEH Executed coverage M EEE Fassed coverage Abbildung 5 1 HP Quality Center Graphen Testfall berdeckung Diese Grafik zeigt den Verlauf der Testabdeckung zu dem gew hlten Release Die unterschiedlichen Graphen stellen die zugewiesenen Requirements Assigned requirements die geplante Testfallabdeckung Planned coverage d
71. eines Projekt das als Pilotprojekt f r die Automatisierung benutzt werden kann Die Aufgaben die f r das COIN Projekt realisiert wurden k nnen zwar als Pilot angesehen werden aber TOPX hat andere technische Eigenschaften die ein anderes Vorgehen und ein anderes Tool erfordern Um trotzdem einen Einstieg zu finden sollten Aufgaben automatisiert werden deren Implementierung nicht zu aufwendig erscheint Das Ergebnis sollte aber einen Gewinn f r den Testprozess darstellen Die Automatisierung ganzer Tests scheint hier zu aufwendig TOPX verwendet eine GUI die aus mehreren Fenstern besteht es werden Men leisten eingeblendet deren Funktionalit t abh ngig von aktiven Fenster ist es gibt viele Listen und etliche Informationen die nur grafisch dargestellt werden Zum Beispiel die Belegung der Bays Lader ume wie in Abbildung 7 1 Um mit TOPX zu arbeiten werden zwei Monitore verwendet damit trotz der Vielzahl an Fenstern Masken und Tabellen die bersicht erhalten bleibt Diese Gesamtkomplexit t macht eine GUI Test Automatisierung zu einer echten Herausforderung und zwar besonders wenn eine zuverl ssige berpr fung des Verhaltens von TOPX erfolgen soll Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 83 erminal Operational Package TopX Advance Release 3 0 141 Datei Schiff Platz Ger testeuerung Werkzeuge Management System Fenster Favori
72. em Speichern gel scht also durch Leerzeichen ersetzt werden Nach der Entfernung dieser variablen Werte sieht der Inhalt der Textdatei wie folgt aus EIER EE C O I N CONTAINER ANZEIGE 2 362 SCHUTE Anlieferung EXPORT OA xxxxxx x x CONTAINERNR TGHU9507987 IC 537542 KD IC 06335000 e Angel 22 09 08 13 58 ICuser L1 VS KT P G 4430 0 0071 810 015 00000 Ausgel 27 09 08 05 36 Status E VIEW Bestim Ausl Sperre N L H T 40 96 DCS Berech J A M N Loesch Check N Nocheck J Tara 3890 ZVA 3 RD Nr 002 Bahnhof CSG ACEP MGW 32500 KD Nr 1 1 11798 Waggon 000000000000 Typ Brutto 10385 WA 0 Name ANL GS 000 0 000 Anz 0 Stellp SSS 01000301 RM St 0 Zollverf Empf C Zug IMCO T Pack N Pack R K Empf Un Nr o Co 1 00 00 00 Land Plz 00 00 00 00 Ort S Ref Nr Schiff 2100 S 01 0101 LKW Temperatur Ueberg N OH 000 Name DBR Truck KO Min Max OW OL 000 000 000 000 Haf Co BWE Lad H BWE Spedit N BKG NR ANLF92553 KLV Buch Nr Bestimmung Siegel XXX Turn I FahrNr 00000 EE ee Bemerk Zugehoerige CHASSIS NR Aggregat Nr K2 AKTION NEXT SCRO RETU STOP EXIT FUNKTION SCHLUESSEL In diesem Format k nnen die Textdateien als Referenzdaten verwendet werden Um die Dateien sicher den entsprechenden Testf llen zuordnen zu k nnen werden Dateinamen mit folgender Syntax erzeugt Funktionsname_Schl sseltyp
73. em Testfall ausgef hrt werden Da es sich h ufig um gleiche oder hnliche Aufgaben handelt die nicht sehr komplex sind bietet sich eine Automatisierung an Meistens handelt es sich hierbei um Aufgaben wie das Kopieren von Dateien Es ist schwer vorstellbar von einem automatisierten Testablauf zu reden wenn vor und nach jedem Test der Tester manuell sehr viele Dateien Kopieren oder l schen muss Die Aufgaben der Vor und Nachbereitung k nnen h ufig in einem Test Execution Tool genau so mit Skripten automatisiert werden wie die Tests selbst Wenn man in diesem Tool mit Funktionen arbeiten kann bietet es sich an die Vor und Nachbereitung in entsprechende Funktionen zu kapseln und an den entscheidenden Stellen in das Automatisierungsskript zu implementieren Es sollte noch beachtet werden dass bei der Nachbereitung andere Aufgaben anfallen k nnen wenn der Test nicht erfolgreich abgeschlossen wurde In diesem Fall ist es durchaus sinnvoll keine Bereinigung vorzunehmen damit am Ende alle Daten zur Analyse des Fehlers vorliegen vgl Fewster1999 S 176 ff 3 3 Erstellung von wartbaren Tests Die Wartbarkeit bei automatisierten Tests muss einen h heren Stellenwert erhalten als es bei manuellen Tests der Fall ist Jedes Mal wenn die Software angepasst wird m ssen die Tests berpr ft und angepasst werden Wird bei einer Adressbuch Anwendung ein Feld Telefonnummer hinzugef gt so muss bei einem automatisierten Testskript das F ll
74. en dieses Feldes hinzugef gt werden Bei einem manuellen Test steht vielleicht die Anweisung Alle Felder sollen mit Daten gef llt werden In diesem Fall wird der Tester das Telefonnummer Feld f llen obwohl die Testbeschreibung nicht angepasst wurde Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 28 Es ist also entscheidend dass die bersicht ber die Testf lle nicht verloren geht Ein wichtiges Hilfsmittel hierzu ist die Verwendung einer Testsuite wie des HP Quality Center das weiter unten beschrieben wird Ein solches Tool verwaltet alle Tests und die dazugeh rigen Daten zentral Aber auch wenn man ein solches Tool verwendet sollte beachtet werden dass die Anzahl der Tests nicht berhand nimmt Dieses Problem kann zum Beispiel auftreten wenn viele Mitarbeiter Tests anlegen Es k nnen Redundanzen entstehen durch Testf lle die mal als Versuch angelegt und sp ter nicht wieder entfernt wurden Je gr er die Anzahl der Tests desto mehr Wartungsaufwand entsteht wenn der zu testenden Software neue Funktionalit ten hinzugef gt werden Es ist also unbedingt darauf zu achten dass nur wirklich sinnvolle Tests angelegt werden und in regelm igen Abst nden der Bestand nach nicht verwendeten Tests abgesucht wird Letzteres kann zum Beispiel dann geschehen wenn die Tests gerade einer Wartung unterzogen werden weil ein neues Release ansteht E
75. en erfasst werden sollten h ngt von den Zielen ab die verfolgt werden M gliche Ziele die mit einer Testautomatisierung erreicht werden k nnen sind konsistente wiederholbare Tests Tests unbeaufsichtigt ausf hren Fehler durch Regressionstests finden Tests h ufiger ausf hren h here Softwarequalit t gr ndlicher Testen Vertrauen in die Qualit t der Software erh hen Kosten reduzieren mehr Fehler finden Testphase schneller abschlie en bessere Testdokumentation vgl Fewster1999 S 210 Neben den anfangs beschriebenen ROI k nnen folgende Metriken einen Analysewert f r den Testprozess darstellen Der Defect Detection Percentage DDP gibt an wie hoch der Anteil der gefundenen Fehler gegen ber den vorhandenen Fehlern ist Nat rlich kann keine garantiert richtige Angabe dazu gemacht werden da die Anzahl der vorhandenen Fehler nicht bekannt ist Als Wert f r die vorhandenen Fehler kann die Anzahl der Fehler herangezogen werden die nach dem Softwaretest aufgefallen sind Mit dem DDP lassen sich gravierende M ngel im Testprozess aufdecken oder Vergleiche anstellen wenn der Testprozess gerade optimiert wird Die durchschnittliche Zeit die ben tigt wird um einen Testfall zu automatisieren ist ein wichtiger Anhaltspunkt um den Aufwand f r die weitere Automatisierung abzusch tzen Werden Optimierungen am Automatisierungsprozess vorgenommen kann mit dieser Metrik feststellt werden ob und wie viel Zeit
76. en zu m ssen mit welchen Testf llen begonnen werden sollte F r gew hnlich existieren Tests die automatisiert werden k nnen und solche die nicht automatisiert werden k nnen Im Falle der automatisierbaren Tests ist es meistens unsinnig die zu automatisieren bei denen der Automatisierungsprozess mehr Zeit in Anspruch nimmt als die manuelle Ausf hrung Dazu ein Beispiel F r einen Test der manuell in 10 Minuten ausgef hrt wird und einmal im Monat l uft ben tigt man 120 Minuten im Jahr Ben tigt die Automatisierung aber 10 Stunden so hat sich diese erst nach 5 Jahren rentiert Es k nnen trotzdem Faktoren daf r sprechen die Automatisierung durchzuf hren So kann es sehr kompliziert sein den Test manuell abzuarbeiten Vielleicht brauchen die Tester vier Versuche um die korrekten Eingaben vorzunehmen Dies kann zu einer hohen Frustration bei den Testern f hren und eine Automatisierung w rde somit das Engagement des Testteams steigern F r den Test einer Applikation existieren verschiedene Arten von Tests von denen einige leichter zu automatisieren sind als andere Bei Funktionstests wird analysiert ob die Software sich bei bestimmten Eingaben korrekt verh lt Es gibt also fest definierte Eingaben Zust nde und Ergebnisse Diese Art von Tests lassen sich in der Regel gut automatisieren Dies gilt ebenfalls f r Performance und Lasttests die zu den nicht funktionalen Tests geh ren Die Reaktionszeit der Software soll unter vers
77. endet werden Mit dem Aufruf Reporter ReportEvent EventStatus ReportStepName Details k nnen Eintr ge im Reporter erzeugt werden Der Status kann drei m gliche Werte annehmen Fail Warning und Pass In den Details sollten dann die relevanten Daten die zur Nachvollziehbarkeit des Testergebnisses wichtig sind angegeben werden Bei fehlgeschlagenen Tests sollte hier die Ursache schnell ersichtlich sein F r die berpr fung der COIN Masken wurde entschieden dass die Referenzdaten der aktuelle Maskeninhalt und die Positionen der abweichenden Zeichen relevant sind Standardm ig zeigt der Report die Details immer zentriert formatiert in der Standardschriftart an Um die Maskeninhalte optisch vergleichen zu k nnen ist diese Darstellung schlecht da die urspr ngliche Darstellung der Masken verloren geht Unter Verwendung des Scripting Dictionary Objektes kann eine HTML formatierte Darstellung erreicht werden vgl Anhang S Funktionstest_G7 TempResults_2 Test Results u File Wiew Tools Help ESVARIRAU 1 E NS Test Funktionstest_67 Summary H Run Time Data Table E X Funktionstest_67 Iteration 1 Row 1 Step Name COIN_ohne EX Function Summary E xC Function Iteration 1 Row 1 Step Failed E X Z 67 Client Z 67 Client Activate Object Details Result T 67 Client Click 77 67 client Type Referenz Z 67 Client Type 77 67 Client Type EE EE COIN e T 67 Client Type 301 Hauptverteiler
78. entation dieser Elemente zuzugreifen Eine weitere Alternative ist das Speichern von Bildschirmkoordinaten um Aktionen auszuf hren Allerdings ist ein solches Skript nicht sonderlich robust da es scheitert sobald ein Element verschoben wird Das Anlegen der Skripte in Eggplant ist umst ndlicher und wohl auch fehleranf lliger als bei vergleichbaren Tools wie Quick Test Professional Beim Capture and Replay kann man die Elemente nicht einfach nur anklicken sondern man muss immer einen repr sentativen Ausschnitt der Anzeige als Bild speichern Gegebenenfalls m ssen f r ein Objekt sogar mehrere Bilder erfasst werden Auch ist es nicht m glich einfach die Texteigenschaft eines Steuerelements auszulesen und auszuwerten Man muss f r den Vergleich immer denselben Schriftstil verwenden sonst gibt es f lschlicherweise Abweichungen Dies klingt alles mehr nach Nachteilen als nach Vorteilen aber man darf nicht vergessen dass dieses Verfahren eventuell die einzige M glichkeit ist mit einer AUT zu arbeiten auf deren interne Repr sentation man nicht zugreifen kann Und in diesem Bereich kann man mit Eggplant fast genau so arbeiten wie mit Quicktest und einer Standard Windowsanwendung Man ist plattformunabh ngig und kann ber mehrere VNC Verbindungen sogar verschiedene AUT parallel testen Zum Beispiel ist dies bei einer verteilten Client Server Anwendung hilfreich Man k nnte ber den Client Daten an den Server senden lassen und im n chsten
79. er Funktion in COIN erfasst werden Diese Erfassung der Daten wurde mit Quick Test Professional automatisiert Alle relevanten Daten der 100 Container wurden in einer Exceltabelle erfasst Diese Daten werden dann mit einem Skript in die daf r vorgesehene Maske eingetragen Da die EDI Nachricht ebenfalls aus einer Excel Tabelle erzeugt wird ist die Erstellung der Datengrundlage f r das Testskript denkbar einfach F r die automatisierte Eingabe der Containerdaten in die entsprechende COIN Maske wird der Umstand genutzt dass COIN automatisch mit dem Eingabecursor in das n chste Feld wechselt wenn die maximale Anzahl an Zeichen in ein Eingabefeld eingegeben wurde Der Cursor wird im ersten Feld positioniert anschlie end werden der Reihe nach alle Daten eingegeben In der Data Table sind in der richtigen Reihenfolge alle Eingabefelder mit dem Wert der eingegeben werden soll und die Gr e des Eingabefeldes angegeben Wet Sie C Laenge 2 Hoehe 2 3 4 1 A 5 6 4 ReedereiNr 3 5 1 13 108 1 Abbildung 6 7 HP QTP Data Table Container anlegen Somit besteht der Quellcode f r die Eingabe der Daten nur noch aus wenigen Zeilen Die diskreten Werte stehen wieder in dem Tabellenblatt global der Data Table und werden von dort bernommen Bei der Eingabe werden die Werte mit Leerzeichen aufgef llt damit die maximale Eingabegr e erreicht wird und der Cursor in das n chste Feld springt Dies h tte auch mit dem Senden eine
80. er Science Department Informatik Department of Computer Science 90 HPQC Tut2007 HEWLETT PACKARD Hrsg HP Quality Center 9 2 Tutorial 2007 HPQTP Tut2008 HEWLETT PACKARD Hrsg HP QuickTest Professional 9 5 Tutorial 2008 Liggesmeyer2002 LIGGESMEYER Peter Software Qualit t Testen Analysieren und Verifizieren von Software Heidelberg Berlin Spektrum Akad Verl 2002 ISBN 3 8274 1118 1 Linz2005 Linz Tilo SPILLNER Andreas Hrsg Basiswissen Softwaretest Aus und Weiterbildung zum Certified Tester Foundation Level nach ISTOB Standard 3 berarb und aktualisierte Aufl Heidelberg dpunkt 2005 ISBN ISBN 3 89864 358 1 O Reilly2008 O REILLY amp ASSOCIATES INC Hrsg Xlib Programming Manual Online verf gbar unter http www sbin org doc Xlib index_contents html Abruf 18 02 2009 Rupp2007 RUPP Chris Hrsg Requirements Engineering und Management professionelle iterative Anforderungsanalyse f r die Praxis 4 aktualisierte und erw Aufl M nchen u a Hanser 2007 ISBN 3 446 40509 7 SWOP2007 SWOP SEAWORTHY PACKING GMBH Hrsg SWOP SEAWORTHY PACKING VERTRAUEN IST GUT BEI SWOP VERPACKEN IST BESSER 2007 Firmenbrosch re Sneed2002 SNEED Harry M WINTER Mario Testen objektorientierter Software das Praxishandbuch f r den Test objektorientierter Client Server Systeme M nchen u a Hanser 2002 ISBN ISBN 3 446 21820 3 49 90 2075408 Vigenschow2005 VIGE
81. er machen wie diese Validierung auszusehen hat Es besteht die M glichkeit genau vorherzusagen wie die Software sich zu verhalten hat oder alternativ die Ergebnisse eines Testdurchlaufs zu speichern manuell zu berpr fen und f r weitere Tests als Referenzdaten zu benutzen Ob es besser ist die Ergebnisse vorherzusagen oder ob man Referenzergebnisse zur Validierung verwendet h ngt von verschiedenen Faktoren ab 1 Die Menge der Ergebnisse Wenn eine einzelne Zahl oder ein kurzer String berpr ft werden soll ist es einfach das Ergebnis vorherzusagen Ist das Ergebnis aber ein Bericht der mehrere Seiten lang ist Kann es erheblich einfacher sein mit Referenzdaten zu arbeiten 2 Kann ein Ergebnis berhaupt vorhergesagt werden Wird mit Echtdaten gearbeitet kann es eventuell sein dass man keine Vorhersagen machen kann 3 Verf gbarkeit der AUT Application under test Man kann die ersten Referenzergebnisse erst erstellen wenn man die Software zur Verf gung hat Aber aus Zeitgr nden m chte man die Tests schon vorbereiten bevor man die eigentliche Software erh lt 4 Qualit t der berpr fung Meistens ist es besser die Ergebnisse vorherzusagen als die ersten Testergebnisse manuell zu berpr fen So wird die Gefahr umgangen dass bei der manuellen Pr fung Fehler bersehen werden und alle weiteren automatischen Testausf hrungen gegen falsche Referenzwerte gepr ft werden Fakult t Technik und Informatik Faculty o
82. erungskonzept k nnen diese Modifikationen mit einem automatisierten Regressionstests validiert werden Es w rden dann nicht mehr die Ausgabe des Altsystems mit der des Neusystems verglichen werden wie es bei der Migration der Fall ist sondern es w rden die unterschiedlichen Versionsst nde gegeneinander gepr ft werden An dieser Stelle sollte evaluiert werden ob es einen effektiven Nutzen gibt wenn die berpr fung von eingegebenen Daten und das Anlegen von synthetischen Daten mit SQL Statements an die Oracle Datenbank erfolgt QuickTest Professional ben tigt hierzu eine ODBC Verbindung zu der Datenbank Da diese Verbindung mit dem Unisys Host nicht m glich ist wurde auf SQL Statements f r die Tests w hrend der Migration verzichtet Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 80 7 Automatisierung der TOPX Tests In diesem Kapitel wird analysiert wie die Ausf hrung der Tests f r das System TOPX mit Automatisierungen unterst tzt werden Kann Es wird zun chst der Ist Zustand ermittelt und dem Zielzustand gegen ber gestellt Um den optimalen Zielzustand zu erreichen sind bestimmte Bedingungen Voraussetzung Sind alle diese Bedingungen erf llt kann eine lehrbuchartige Umsetzung erfolgen Dies betrifft zum Beispiel die Testfallermittlung Die Testf lle f r Black Box Tests sollen aus der Spezifikation abgeleitet werden Dies setzt eine ausreichend
83. esamte Entwicklungsprozess beschleunigt wird Analog zu Kapitel 3 4 Metriken l sst sich der ROI wie folgt berechnen manueller Test automatischer Test Kosten f r die Testfallerstellung 8 000 8 000 Toolkosten 3 000 Kosten Implementierung autom Tests 6 000 Gesamtkosten Automatisierung 9 000 Kosten f r einen Testzyklus 2 310 46 66 Anzahl der Zyklen pro Release 5 5 Testkosten pro Release 19 550 8 233 30 Einsparungen pro Release 11 316 70 ROI Einsparung Investition 126 Die Kosten f r die Testfallerstellung beinhalten alle Arbeiten zur Erstellung der Tabellen mit den Funktionsnamen und Schl sseln sowie die Erarbeitung des Vorgehens f r den Test Die Implementierungskosten setzen sich aus den Kosten f r das Erstellen der VBSkripte inklusive der Library f r den Vergleich der Textdateien zusammen Die hier erarbeiteten Funktionen k nnen allerdings in anderen Tests weiter verwendet werden Dies wurde in der Rechnung nicht ber cksichtigt genau wie der Umstand dass sich die Kosten f r weitere automatisierte Testausf hrungen halbieren sofern die Referenzdaten nicht neu erstellt werden m ssen 6 5 Synthetische Daten Synthetische Daten sind Testdaten die speziell f r die Tests angelegt werden und nicht aus dem Datenbestand der in der Praxis entstanden ist stammen Das Erzeugen dieser Daten ist mit einem h heren Aufwand verbunden als das Kopieren
84. est in Teilzeit mit der Automatisierung zu beauftragen Somit k nnen zwischen den Personen Absprachen ber weiteres Vorgehen Techniken etc getroffen werden Ebenfalls lie e sich so eine Urlaubsregelung treffen Testautomatisierung ist je nach Unternehmen eine nicht unwesentliche Investition die einen gro en Nutzen bieten kann sofern sie sorgf ltig betrieben wird Wurde die Entscheidung f r eine Automatisierung getroffen muss sie konsequent weiter verfolgt werden Automatisierungsskripte die ein Mitarbeiter nebenbei erstellt hat w hrend er mit anderen Aufgaben und Projekten besch ftigt ist fehlt es an Zuverl ssigkeit Wenn man sich nicht auf die Richtigkeit der automatisierten Tests verlassen Kann ist es vielleicht sogar notwendig sich in einem manuellen Test davon zu berzeugen oder die Testl ufe mit einer aufwendigen Qualit tssicherung zu berpr fen Dann wiederum h tten die Kosten f r die Automatisierung gleich gespart werden k nnen Es besteht die Gefahr dass das Bestreben eine Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 88 Automatisierung umzusetzen nachl sst und niemand mehr die daf r gekauften Tools verwendet Die Komplexit t der Projekte bei Eurogate ist so hoch dass es ratsam ist ein Team ausschlie lich f r die Testautomatisierung zu besch ftigen F r aufwendige Regressionstests werden Tests ben tigt die mit zwe
85. existieren nur durch den Austausch sequentieller Dateien zum Beispiel als EDI Nachrichten Die Abarbeitung der Nachrichten erfolgt mit verschiedenen Batchl ufen 4 1 2 Funktionalit t von COIN COIN ist die Abk rzung f r Container Information und bezeichnet das administrative Container Daten Verwaltungsprogramm bei Eurogate In COIN k nnen Daten ber Container erfasst ge ndert und angezeigt werden Das Erfassen der Daten kann manuell geschehen oder durch den Import von EDI Nachrichten M gliche Nachrichten sind COPRAR Container discharge loading order message oder BAPLIE Bayplan Stowage Plan Occupied And Empty Locations Message Die COPRAR enth lt Informationen dar ber welche Container auf ein Schiff geladen oder welche gel scht werden sollen Die BAPLIE ist der aktuelle Ladeplan eines Schiffes Ihre Informationen beschreiben welche Container sich an welchen Ort auf dem Schiff befinden Auch diese Informationen lassen sich in COIN nachtr glich editieren Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 34 bartelss ws96091 h22c1 Abbildung 4 1 COIN Hauptmen Au erdem k nnen in COIN Einzelheiten ber Anlieferungen und Auslieferungen angezeigt und bearbeitet werden Auch gibt das System Auskunft dar ber welche Container sich im Zulauf befinden Hinzu kommt die Abwicklung der landseitigen und seeseitigen Annahme und Ausgabe von C
86. f Engineering and Computer Science Department Informatik Department of Computer Science 27 Das automatisierte Vergleichen bringt die meisten Vorteile im Bereich der Testautomatisierung Bei der berpr fung ist es h ufig notwendig dass sehr viele Daten Bildschirminhalte und Zahlen verglichen werden m ssen Dies ist eine langweilige und anstrengende Arbeit Die Wahrscheinlichkeit dass beim manuellen Pr fen Fehler bersehen werden ist sehr hoch Deshalb ist es sinnvoll diese Arbeit dem Computer zu berlassen vgl Fewster1999 S 101 ff 3 2 Automatisierte Vor und Nachbereitung Unter Testvorbereitung versteht man das Schaffen von Vorraussetzungen damit ein Test ausgef hrt werden kann Dies kann zum Beispiel das Anlegen bestimmter Datens tze sein mit denen im Test gearbeitet werden soll Unter Umst nden ist es n tig diese Datens tze bei jedem Testdurchlauf erneut anzulegen Testnachbereitung bezeichnet alle Schritte die nach dem eigentlichen Test erforderlich sein k nnen Eventuell liegen die Testergebnisse an verschiedenen Stellen im System und m ssen in das daf r vorgesehene Verzeichnis gelegt werden Manche Protokolle die keine Fehlermeldungen enthalten k nnen gel scht werden oder bestimmte Datens tze die nur f r den Test ben tigt wurden m ssen wieder aus der Datenbank entfernt werden Es gibt eine Menge an Vor und Nachbereitungsaufgaben Diese Aufgaben sind normalerweise sehr zeitintensiv und m ssen nach jed
87. ffekt auf den weiteren Testprozess haben Aus n tzlichen Funktionen die dabei entwickelt werden kann ein Testframework erzeugt werden Die Gesch ftsprozesse die diesen Tests zu Grunde liegen m ssen in einer Form dokumentiert werden die auch von Mitarbeiten verstanden wird die nicht in den entsprechenden Fachbereichen t tig sind So ein Mitarbeiter w re unter anderem der Testautomatisierer Da die Dokumentation in dieser Tiefe noch nicht existiert sollten die Prozesse ausf hrlich dokumentiert werden die zuerst automatisiert werden sollen Eine Zusammenarbeit zwischen der Fachabteilung und dem Testautomatisierer ist unerl sslich Eine Erfassung verschiedener Metriken w re ebenfalls ratsam Durch den konsequenten Einsatz des Quality Centers von HP k nnen einige wichtige Punkte wie die erreichte Testabdeckung auf Knopfdruck ermittelt werden Es k nnte somit eine Qualit tssicherung f r den Testprozess entstehen Eine ausf hrliche Gegen berstellung der Metriken vor und nach Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 85 der bernahme des Tests durch Eurogate ITS kann ein wichtiger Punkt im Reporting gegen ber der Gesch ftleitung sein Auch mit der hier dargestellten Vorgehensweise wird die Umsetzung der Vision nicht in kurzer Zeit m glich sein es kann sogar Jahre dauern Die Analyse und die Verbesserungen am Testprozess sind ein Vorgan
88. ffen Nach und nach werden auf diese Weise weitere Testf lle hinzukommen die schlie lich zu einem ausf hrlichen Regressionstest f r COIN werden Da diese Testf lle auf das Neusystem angewendet werden K nnen kann dieser Regressionstest f r die zuk nftigen Erweiterungen eingesetzt werden die von Eurogate selbst vorgenommen werden Diese Tests k nnen somit als Referenzprojekt f r die Testautomatisierung verwendet werden An ihnen kann der Nutzen der Automatisierung gut verdeutlicht werden um eine breite Akzeptanz f r weitere Umsetzungen zu erlangen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 89 Quellenverzeichnis Bauer2007 BAUER Thomas ESCHBACH Robert METZGER Andreas Risikobasierte Ableitung und Priorisierung von Testf llen f r den modellbasierten Systemtest In Software Engineering 2008 Fachtagung des GI Fachbereichs Softwaretechnik 18 22 02 2008 in M nchen Bonn Seite 99 111 Ges f r Informatik 2007 ISBN 978 3 88579 215 4 3 88579 215 X Dustin2001 Dustin Elfriede RASHKA Jeff PAUL John Software automatisch testen Verfahren Handhabung und Leistung mit 100 Tabellen mit CD ROM Berlin u a Springer 2001 ISBN 3 540 67639 2 Eurogate2006 EUROGATE GMBH amp Co KGAA InTeam 6 2006 2006 Mitarbeiterzeitung Eurogate2007 EUROGATE GMBH amp Co KGAA Port Information Hamburg online verf gbar unter
89. finden Soll zum Beispiel ein Testfall mit einem Gefahrgutcontainer der von einem Schiff gel scht wird ausgef hrt werden muss erst in dem Datenbestand ein entsprechender Container gesucht werden In manchen F llen kann dies l nger dauernals die Ausf hrung des eigentlichen Tests W hrend des Testens kann es auch vorkommen dass die Anzahl der Container die im System vorhanden sind nicht ausreichen um alle geplanten Tests auszuf hren Hier kann die Verwendung von synthetischen Daten eine gro e Hilfe sein vgl Kap 6 5 Synthetischen Daten Die Container die in TOPX verwendet werden werden ber das COIN System erfasst und ber Schnittstellen in die Datenbank von TOPX importiert Allerdings sind teilweise weitere Schritte n tig um die Daten so zu manipulieren dass sie f r die TOPX Tests verwendet werden k nnen Solche Schritte k nnen zum Beispiel die Zuordnungen zu bestimmten Ger ten Containerbr cken Schiffen o sein Ein Ansatz w re die Daten direkt in die Datenbank von TOPX zu schreiben Dies w re per SQL Statement m glich Allerdings werden durch bestimmte GUI Aktionen in TOPX diverse Schalter in der Programmlogik gesetzt so dass reine nderungen an der Datenbank m glicherweise nicht die gew nschten Ergebnisse liefern und gegebenenfalls zu Inkonsistenzen in der Datenbank f hren w rden Da der Hersteller von TOPX auch das Datenbankschema entwickelt hat ist das Know How bei Eurogate nicht ausreichend um zuverl s
90. fiziert worden Deswegen werden diese in der folgenden Betrachtung nicht oder nur am Rande betrachtet 4 2 TOPX Dieses Kapitel behandelt ein zweites Softwareprojekt welches in Hinblick auf eine Unterst tzung durch automatisierte Tests betrachtet wird Im Gegensatz zum textbasierten COIN Programm handelt es sich bei TOPX um eine Anwendung mit einer grafischen Benutzeroberfl che die auf dem GUI Tool QT von Trolltech weitere Informationen unter http gtsoftware com basiert 4 2 1 Technische Beschreibung TOPX l uft auf einem Sun Solaris 10 Applikationsserver f r die Datenhaltung wird ein Oracle Datenbankserver verwendet TOPX wird von Windows Workstation mit der Host Emulation Hummingbird Exceed ausgef hrt Die Anzeige der GUI erfolg mittels des X Window Systems in der Version 11 Hierbei agiert die Windows Workstation als X Server sie stellt also das Display f r die Applikation bereit vgl O Reilly2008 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 37 Via Handheld Terminals HHT k nnen Daten mit TOPX ausgetauscht werden Diese HHT s kommen unter anderen in den Van Carriern VC zum Einsatz Auf diesen Terminals werden die Start und Zielpositionen von Containern angezeigt die von dem Van Carrier bewegt werden sollen Im Gegenzug werden die neuen Positionen nach einer Umfuhr Bewegen eines Containers an einen anderen Stellplatz des Co
91. fwand einer solchen Analyse kann je nach Projekt sehr hoch sein W hrend des Testprozesses kann m glicherweise deutlich werden dass die Bewertung nicht korrekt war Werden beispielsweise in als relativ unbedenklich eingestuften Bereichen berm ig viele Fehler gefunden kann es notwendig sein eine Neupriorisierung vorzunehmen die ihrerseits auch wieder mit einem hohen Aufwand verbunden sein kann Ein Ansatz zur Verbesserung dieser Problematik mit dem ranTEST Ansatz risiko und anforderungsbasiertes Testen ist in Bauer2007 beschrieben Im Groben beinhaltet dieser Ansatz die Dokumentation von Anforderungen durch Anwendungsf lle die risikobewertet werden Auf Basis dieser Anforderungen werden Testmodelle als Zustandsautomaten erstellt deren Transitionen mit den entsprechenden Risiken gewichtet sind Szenarien die sich aus m glichen Wegen vom Start zum Zielzustand ergeben k nnen anhand ihrer Risikoabdeckung eingeordnet werden Da diese risikobasierte Ableitung und Priorisierung automatisiert werden kann ergibt sich eine erhebliche Aufwandseinsparung Auch eine Neupriorisierung l sst sich erheblich komfortabler durchf hren N here Informationen zu diesem Projekt gibt es im Internet bei der Universit t Duisburg Essen unter http www sse uni due de wms de index php go 204 web und auf der offiziellen Projektseite www rantest de Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Depart
92. g der niemals enden wird Es wird neue Testf lle und neue Programme geben die getestet werden sollen Mit einem gut strukturierten und geplanten Testprozess k nnen diese Anpassungen minimiert werden Ein gut funktionierender automatisierter Testprozess ist keine Selbstverst ndlichkeit 40 bis 50 Prozent der Unternehmen die einen solchen Prozess realisieren wollten und bereits ein Tool zur Automatisierung erworben haben nutzen es nicht da die Umsetzung nicht konsequent erfolgt ist vgl Fewster1999 S 299 300 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 86 8 Zusammenfassung und Ausblick In den Kapiteln 2 Testgrundlagen und 3 Testautomatisierung wurde dargestellt was beim Testen von Software und bei der Automatisierung wichtig ist Diese Erkenntnisse wurden in den sp teren Kapiteln umgesetzt und auf die beiden hier vorgestellten Projekte angewandt Die Ergebnisse und Hinweise zum weiteren Vorgehen k nnen den entsprechenden Kapiteln 6 7 Aktueller Stand und weiteres Vorgehen und 7 3 M gliche Vorgehensweise f r die Umsetzung entnommen werden W hrend der Entstehung dieser Arbeit wurde deutlich wie wichtig eine gute Dokumentation der Anforderungen ist Sicherlich ist dies ein Punkt der in vielen Fachb chern angemerkt wird aber leider in der Praxis nicht konsequent umgesetzt wird In der Entstehung bedeutet Dokumentation meistens eine Mehrarbeit
93. gef hrt werden Einige Tools ben tigen daf r ein kostenpflichtiges Add On Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 52 7 Betriebssystem Auf welchem Betriebssystem wird 2 das Tool ausgef hrt Kann es einfach auf einem Windowsrechner betrieben werden oder werden weitere Systeme oder Terminalemulationen ben tigt 8 Kosten Lizenz Wie teuer ist das Tool pro Lizenz 2 Nach der Markanalyse per Internet Hersteller Homepage Fachforen und aufgrund von Erfahrungsberichten von Kollegen wurden folgende Tools anhand der oben genannten Kriterien bewertet Ziel war es Kandidaten f r eine engere Auswahl zu ermitteln AutomatedQA Testcomplete Froglogic Squish Integration HP QC Nein ja mit Add In Objekterkennung QT Nein ja Objekterkennung Windows Ja nein Skriptsprache VBScript JScript Delphi Script C Script JScript Tel Python Datenbank Zugriff Ja ja Lasttest nein ja Windows Linux Betriebssystem Windows MacOS UNIX Kosten Lizenz ca 3 000 EUR ca 2 400 EUR HP QuickTest ICS Replay Redstone Software Professional Xcessory Eggplant Integration HP QC ja nein bedingt m glich Objekterkennung OT nein nein nur Motif ja ber Bilderkennung Objekterkennung Windows ja nein ja ber Bilderkennung Skriptspra
94. genannt Wobei Alpha Tests beim Hersteller stattfinden und Beta Tests beim Kunden vgl Linz2005 S 61 64 2 2 Klassifizierung von Pr ftechniken Generell lassen sich Softwaretests nach verschiedenen Kriterien klassifizieren So gibt es die Einteilung in Black Box und White Box Verfahren vgl Linz2005 S 105 ff In Liggesmeyer2002 S 36 steht hingegen Die Unterteilung der Testtechniken in White Box und Black Box Techniken muss als zu grob nach dem heutigen Stand des Wissens betrachtet werden Hier wird eine Unterteilung in statische und dynamische Testtechniken vorgeschlagen Im Folgenden werden beide M glichkeiten der Klassifikation vorgestellt 2 2 1 Black Box und White Box Pr ftechniken Bevor man mit dem Testen einer Software beginnen kann sollte man sich berlegen was genau getestet werden soll Sicherlich ist ein Ad hoc Ansatz m glich wird aber meistens nicht zu den erw nschten Ergebnissen f hren Es werden nur die Programmteile getestet die man zuf llig ausgew hlt hat Dabei besteht die Gefahr dass wesentliche Tests vergessen werden und dass Zeit mit berfl ssigen Tests vergeudet wird Es sollten also systematisch Testf lle entworfen werden F r diesen Entwurf gibt es unterschiedliche Pr ftechniken die sich in Black Box und WhiteBoxPr ftechniken unterteilen lassen Bei WhiteBox Pr ftechniken wird der Programmcode zur Erstellung der Testf lle herangezogen bei Black Box Pr ftechniken nicht So ka
95. gepasst dass der Vergleich eines Leerzeichens im Neusystem mit einem Unterstrich in den Referenzdaten keine Abweichung erzeugt Im Folgenden wird das Testergebnis einer Maske exemplarisch analysiert Referenzwert aus dem Altsystem f r den Aufruf 481ANZ Reederei Nr KAAKKAKAAKK C U sS T x x 481 ANZEIGEN KUNDENSTAMM EUROGATE x KAAKKAKAKK EVRE Kunden Nr 01 01 00030119 Reederei Nr 025 Kurzname KKL Kurzort TOKYO Branche Leistu Ber Kundenart 0 Name 1 K LINE_ EUROPE_LIMITED D Name 2 C O_ K LINE KUNDE Name 3 DEUTSCHLAND _GMBH AKTIV Strasse ANCKELMANNSPLATZ_1 Postf PLZ Ort 20537 HAMBURG Land Kz D Telefon Kontakt Person Telex Telefax Teletex Agentur Reederei Makler Code Inh Geschaeftsfuehrer Ansprechpartner 3 AKTION NEXT STOP EXIT FUNKTION SCHLUESSEL Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 74 Ergebnis des Aufrufs 481ANZ Reederei Nr im Neusystem KAKKAKAKK E U Ss T 481 ANZEIGEN KUNDENSTAMM EUROGATE Ki KAKKAKAAKK EVRE x Kunden Nr 01 01 00030119 Reederei Nr 025 Kurzname KKL Kurzort t TOKYO Branche 00 Leistu Ber 00 Kundenart 0 Name 1 K LINE EUROPE LIMITED D Name
96. gration und Schichtenintegration Bei der Klassenintegration werden einzelne Klassen zusammengebunden die zu einer Komponente geh ren und getestet Wird nur eine kleine Applikation betrachtet so ist an dieser Stelle der Integrationstest bereits abgeschlossen Gr ere Anwendungen k nnen in einer mehrschichtigen Architektur aufgebaut sein Hierbei kann es sich um eine Client und eine Serverschicht handeln oder um Architekturen mit drei und mehr Schichten Werden alle Komponenten die zu einer Anwendungsschicht geh ren nach und nach zusammengesetzt und getestet spricht man von einer Komponentenintegration Hier werden die Beziehungen zwischen den Komponenten sowie s mtliche Effekte die durch das Zusammensetzten auftreten getestet Die dritte Stufe ist die Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 17 Schichtenintegration Es werden verschiedene Anwendungsschichten zusammengef hrt wie zum Beispiel Client und Serverschicht vgl Sneed2002 S 195 197 2 1 3 Systemtest Bei der dritten Teststufe wird berpr ft ob das ganze System den spezifizierten Anforderungen entspricht Das System wird hier aus Sicht des Kunden oder Anwenders betrachtet im Gegensatz zu der technischen Herangehensweise der vorangegangenen Teststufen Das System wird in einer Testumgebung getestet die der sp teren Produktivumgebung so nahe wie m glich kommt Daraus ergibt s
97. hen spricht man vom Modultest da diese in Module aufgeteilt sind w hrend der Klassentest das quivalent zu den objektorientierten Sprachen bildet Beim Komponententest wird darauf geachtet dass jede Komponente einzeln betrachtet wird Es werden m gliche komponentenexterne Fehlerquellen ausgeschlossen so dass eine gegebenenfalls auftretende Fehlerwirkung dieser einen getesteten Komponente zugeordnet werden kann Ein Komponententest ben tigt f r gew hnlich einen Testtreiber Ein Testtreiber ist ein Programm das die zu testenden Schnittstellen der Komponente aufruft und den zur ckerhaltenen Wert auf Richtigkeit berpr ft Dieser Testtreiber kann nat rlich weitere sinnvolle Funktionalit ten enthalten wie zum Beispiel eine Protokollierung der Ergebnisse Da der Komponententest entwicklungsnah ist und f r die Erstellung eines Testtreibers Entwicklungs Know how ben tigt wird werden die Komponententests meistens von den Entwicklern selbst durchgef hrt Deswegen wird auch vom Entwicklertest gesprochen Nat rlich ist es nicht unbedingt vorteilhaft wenn die Entwickler ihren Code selber testen meistens ist es eher hinderlich Viele Entwickler konzentrieren sich lieber auf das Programmieren und weniger auf das Testen was zu oberfl chlichem Testen f hren kann Verst rkt wird dieser Effekt dadurch dass den eigenen Programmierarbeiten f r gew hnlich mit einem gro en Optimismus entgegengetreten wird vgl Linz2005 Zwischen Modultes
98. hner ber eine Hostemulation ausgef hrt Hier wird es unwahrscheinlich sein ein Tool zu finden dass ebenfalls auf dem Unisys Rechner l uft Deshalb wird es notwendig sein dass das Automatisierungstool auf Windows ausgef hrt wird und ber den Hostemulator mit COIN kommuniziert Die erstellten Tests sollten ber das HP Quality Center verwaltet werden k nnen um eine einheitliche Dokumentation zu erm glichen Sehr vorteilhaft w re es wenn man f r beide Projekte das gleiche Tool verwenden k nnte Folgende Kriterien wurden identifiziert und in einer Tabelle dargestellt Die Priorit t wird in mit l oder 2 festgelegt 1 notwendig 2 w nschenswert ID Kriterium Beschreibung Priorit t 1 Integration in das HP Quality Center Die Testf lle die mit dem Tool 1 generiert werden sollen mit dem Quality Center verwalten werden k nnen 2 Objekterkennung von QT Objekten Das Tool sollte in der Lage sein 1 Objekte des QT Toolkits zu erkennen 3 Objekterkennung von Windows Nicht zwangsweise notwendig 1 Objekten kann aber f r sp tere Projekte eventuell vom Vorteil sein 4 Skriptsprache Es sollten gel ufige oder leicht 2 erlernbare Skriptsprachen unterst tzt werden die einen entsprechenden Funktionsumfang besitzen 5 Datenbank Zugriff Kann das Tool auf externe 2 Datenbanken zugreifen F r datengetriebene Tests oder Verifikation von Dateninhalten 6 Lasttest Kann mit dem Tool ein Lasttest 2 durch
99. ht erf llt Pr fung der nicht funktionalen Anforderungen Nach ISO 9126 Zuverl ssigkeit Benutzbarkeit Effizienz Kriterien die vorab festgelegt werden und erf llt sein m ssen um eine Test Aktivit t als abgeschlossen bewerten zu k nnen Bedarf an Ressourcen f r den Testprozess Anhand der Testprotokolle wird ermittelt ob Fehlerwirkungen vorliegen ggf wird eine Einteilung in Fehlerklassen vorgenommen Informationsquelle zur Ermittlung der jeweiligen Sollergebnisse eines Testfalls z B die Anforderungsspezifikation Eine Teststufe ist eine Gruppe von Testaktivit ten die gemeinsam ausgef hrt und verwaltet werden Zust ndigkeiten in einem Projekt k nnen sich auf Teststufen beziehen Beispiele sind Komponententest Integrationstest Systemtest nach allg V Modell Kriterium zur Beendigung des Tests unterschiedlich je nach Testmethode meist durch Werkzeuge ermittelt Es gibt viele Bezeichnungen f r unterschiedliche Arten von Softwaretests Nachfolgend sind einige Kategorien dargestellt nach denen Testarten benannt werden k nnen Nicht jeder Begriff beschreibt eine v llig andere Art von Test ausschlaggebend ist der Blickwinkel aus dem die Testarbeit betrachtet wird Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 13 1 Testziel Zweck des Tests z B Lasttest 2 Testmethode Methode die zur Spezifikation oder Durchf h
100. ht um wie geplant zu testen sollten doch die wichtigsten Tests erledigt sein Es w re fatal wenn durch eine Fehlplanung oder das Eintreten von unerwarteten Ereignissen essentielle Funktionen nicht berpr ft werden k nnen Au erdem k nnen schwerwiegende Probleme fr hzeitig erkannt werden Eine eventuell aufwendige Korrekturarbeit ist somit weniger kritisch f r das Einhalten des Projektplans Daraus ergibt sich also die Notwendigkeit einer Priorisierung auch wenn geplant ist alle ermittelten Testf lle auszuf hren Die Testf lle m ssen also in wichtige und weniger wichtige unterschieden werden Und das am besten mit verschiedenen Abstufungen damit eine Sortierung vorgenommen werden kann Als sinnvolles Kriterium ist das Risiko anzusehen wobei Risiko als das Produkt aus der H he des m glichen Schadens und der Schadenswahrscheinlichkeit anzusehen ist Der Begriff Schaden bezeichnet alle Kosten die aus einer Fehlfunktion der Software resultieren k nnen Die Wahrscheinlichkeit h ngt von der Art der Benutzung der Software ab Dies macht eine genaue Risikobewertung schwierig vgl Linz2005 S 184 185 Bei Eurogate ist es blich den Schaden in die Kategorien A C zu unterteilen Dabei haben die Kategorien folgende Bedeutung A Im Fehlerfall ist die Arbeitsf higkeit des Betriebs nicht mehr gew hrleistet und Umsysteme sind betroffen B Im Fehlerfall treten Einschr nkungen im t glichen Arbeitsablauf auf die aber auf das eigentli
101. i der Ausf hrung des Testobjekts nach au en in Erscheinung tritt 2 Abweichung zwischen Sollwert und Istwert Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 12 Fehlerzustand Fehlhandlung Funktionaler Test Mangel Nicht funktionaler Test Testendekriterium Testaufwand Testauswertung Testorakel Teststufe berdeckungsgrad 1 Inkorrektes Teilprogramm Anweisung oder Datendefinition die Ursache f r eine Fehlerwirkung ist 2 Zustand eines Softwareprodukts oder einer seiner Komponenten der unter spezifischen Bedingungen eine geforderte Funktion des Produkts beeintr chtigen kann bzw zu einer Fehlerwirkung 1 Die menschliche Handlung des Entwicklers die zu einem Fehlerzustand in der Software f hrt 2 Eine menschliche Handlung des Anwenders die ein unerw nschtes Ergebnis Fehlerwirkung zur Folge hat Fehlbedienung 3 Unwissentlich versehentlich oder absichtlich ausgef hrte Handlung oder Unterlassung die unter gegebenen Umst nden dazu f hrt dass eine geforderte Funktion eines Produkts beeintr chtigt wird Dynamischer Test bei dem die Testf lle unter Verwendung der funktionalen Spezifikation des Testobjekts hergeleitet werden und die Vollst ndigkeit der Pr fung berdeckungsgrad anhand der funktionalen Spezifikation bewertet wird Eine gestellte Anforderung oder berechtigte Erwartung wird nic
102. i stark unterschiedlichen Programmen arbeiten den hier vorgestellten Anwendungen COIN und TOPX F r eine weitgehende Automatisierung auf Basis des bisher Erreichten ist es notwendig ein Testframework zu schaffen das die Automatisierungstools QuickTest Professional und Squish mit Hilfe des Quality Centers miteinander verbindet So kann eine Basis an Funktionen und Erfahrungen entstehen die auf andere Projekte und Standorte bertragen werden k nnen Da an den Container Terminals von Eurogate verschiedene Softwaresysteme eingesetzt werden wird es nicht m glich sein die in Hamburg erstellten Tests ohne Anpassungen zu bernehmen Es m ssen gr ere Anpassungen vorgenommen werden oder sogar gro e Teile der Skripte neu implementiert werden Die Realisierung von automatisierten Tests f r mehrere Standorte ist also als langfristiges Projekt anzusehen wobei neue Softwareversionen h ufig auch Anpassungen an den automatisierten Tests bedeuten werden In der Endphase der COIN Migrationstests wie sie hier beschrieben sind konnten recht schnelle und deutliche Erfolge produziert wurden die die allgemeine Akzeptanz von automatisierten Tests gesteigert haben Hier war eine Verbesserung im Vergleich zur Anfangsphase deutlich bemerkbar Nach ersten Lieferungen des Neusystems wurde aber auch deutlich dass f r einen umfassenden automatischen Test noch viel Arbeit investiert werden muss Diese Arbeit wird zum Teil durch Details verursacht in denen sich die
103. ich auch dass auf den Einsatz von Testtreibern und Platzhaltern verzichtet werden soll vgl Linz2005 S 58 Das System wird ber externe Schnittstellen getestet also ber die Benutzeroberfl che oder ber Importschnittstellen Da bei einem Systemtest von au en getestet wird ist hier die Unterscheidung zwischen objektorientierten und strukturierten Systemen nicht mehr so stark wie beim Integrationstest Allerdings ist die Menge der zu bearbeitenden Testf lle unterschiedlich da objektorientierte Systeme h ufig komplexer sind und viele Abh ngigkeiten haben Beim Systemtest werden mindestens drei Testarten unterschieden Umgebungstest Funktionstest und Performanz Belastungstest vgl Sneed2002 S 231 Ein Softwaresystem befindet sich in zwei Umgebungen in der technischen Systemumgebung und in der Organisationsumgebung Es ist daher wichtig dass bei einem Systemtest die Kompatibilit t und die Interoperabilit t mit beiden Umgebungen gepr ft werden Zur Systemumgebung z hlen die Hardware Konfiguration Basissoftware und Middleware Bei verteilten Systemen geh ren zur Hardware nicht nur alle Serverrechner sondern auch alle Clientrechner Das Ziel des Systemtest in Bezug auf die Systemumgebung ist also sicherzustellen dass die Software mit allen m glichen Hard und Software Zusammenstellungen zusammenarbeitet Auch Performanz und Sicherheitsaspekte spielen eine wichtige Rolle F r die Organisationsumgebung ist es wichtig
104. ichen werden Als Format f r die Referenzdaten wurden Textdateien gew hlt Diese lassen sich einfach erzeugen und jederzeit per Editor einsehen Das zu erwartende Datenaufkommen ist nicht so hoch als dass es sich lohnen w rde eine Datenbank zu verwenden Auch werden keine komplizierten Suchabfragen ben tigt Mit dem VBSkript Befehl Window ExceedWindow GetVisibleText wird der aktuell angezeigte Maskeninhalt als String zur ckgegeben Bei der Maske 362 sieht der R ckgabewert folgenderma en aus bartelss ws96091 h22c1l ERERFRERK C O I N CONTAINER ANZEIGE 02 02 09 362 SCHUTE Anlieferung EXPORT OA 30 01 09 14 43 43 15 43 10 xxxxxx x x CONTAINERNR TGHU9507987 IC 537542 KD IC 06335000 TR o Angel 22 09 08 13 58 ICuser L1 VS KT P G 4430 0 0071 810 015 00000 Ausgel 27 09 08 05 36 Status E V L V Bestim Ausl Sperre N L H T 40 96 DCS Berech J A M N Loesch Check N Nocheck J Tara 3890 ZVA 3 RD Nr 002 Bahnhof CSG ACEP MGW 32500 KD Nr 1 1 11798 Waggon 000000000000 Typ Brutto 10385 WA 0 Name ANL GS 000 0 000 Anz 0 Stellp SSS 01000301 RM St 0 Zollverf Empf C Zug IMCO T Pack N Pack R K Empf Un Nr o Co 1 00 00 00 Land Plz 00 00 00 00 Ort Ref Nr Schiff 2100 S 01 0101 LKW S Temperatur Ueberg N OH 000 Name DBR Truck KO Min Max OW OL 000 000 000 000 Haf Co BWE Lad H BWE Spedit N BKG NR ANLF92553
105. ie Funktionen von den Entwicklern des Altsystems dokumentiert wurden Diese Dokumentation wurde f r das Migrationsprojekt angelegt und nicht von Beginn der COIN Entwicklung an gepflegt Aufgrund der gro en Anzahl an Funktionen und dem somit verbundenen Aufwand der Erstellung dieser Dokumentation k nnen Fehler und Unvollst ndigkeiten auftreten Diese Daten wurden parallel in dem System Adonis einer Software zur Dokumentation von Gesch ftsprozessen hinterlegt Von dort ist es m glich die Daten in eine Excel Tabelle zu exportieren Somit kann nach einer Fehlerkorrektur eine aktuelle Exceltabelle erstellt werden die mit wenig Aufwand f r den Test aufbereitet werden kann 6 3 Automatisiertes berpr fen der Maskeninhalte Um die Inhalte der Masken der beiden Systeme zu vergleichen gibt es im Prinzip drei L sungsans tze Erstens Es k nnen beide Systeme parallel ausgef hrt werden und die jeweiligen Masken direkt vergleichen werden Zweitens Ein System wird ausgef hrt und die Ausgaben werden gespeichert Anschlie end wird das zweite System ausgef hrt auch hier werden die Ausgaben gespeichert Danach werden die gespeicherten Daten verglichen Drittens Zuerst werden wie bei Variante zwei mit dem ersten System Referenzdaten erzeugt Aber bei der Ausf hrung des zweiten Systems werden die Ausgaben sofort mit den Referenzen verglichen und nicht abgespeichert Nur im Fehlerfall m ssen die Ausgaben des zweiten Systems gespeichert werden
106. ie Abdeckung mit tats chlich ausgef hrten Tests Executed coverage und die Abdeckung mit erfolgreichen Tests Passed coverage dar Die Zeitachse wird durch die verschiedenen Cycles gegliedert Zur Unterst tzung des Defect Trackings kann ber den Reiter Quality eine Auswertung aufgerufen werden die den zeitlichen Verlauf der Defects darstellt Die Defects sind nach ihrem Schweregrad gruppiert Es gibt eine Auswertung ber die Anzahl noch offener Defects und ber die Anzahl an Defects die im Verlauf des Releases oder Cycles aufgetreten sind 5 2 2 Requirements Das Requirements Modul dient zur Verwaltung der Anforderungen an das Softwareprojekt Die Anforderungen k nnen in funktionale und verschiedene nicht funktionale Anforderungen gegliedert werden Sie werden in einer Baumstruktur organisiert und dargestellt Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 45 Requirements Edt View Favortes Analysis Name 4 Direct Cover Status 3 Requirements een Mercury Tours Application en 8 Online Travel Booking Services E Products Services On Sale Not Covered Flight Tickets Failed Hotel Reservations Not Covered Car Rentals Not Covered Tours Cruises NI Not Covered I Flight Reservation Service o Flight Search u Passed HH Search Conditions
107. im Systemtest ausgef hrt wurden Aufgrund der unterschiedlichen Umgebungen kann es durchaus zu Abweichungen kommen die beim Systemtest nicht aufgetreten sind Wenn Kunde und sp terer Anwender nicht identisch sind ist es ratsam die Akzeptanz der Benutzer zu testen Jeder Anwender hat andere Erwartungen an eine Software und falls das System als zu umst ndlich empfunden wird kann es zum Scheitern des Softwareprojektes f hren selbst wenn das Programm funktional alle Anforderungen erf llt F r den Akzeptanztest sollten von jeder Anwendergruppe Tests durchgef hrt werden die den typischen Anwendungsszenarien entsprechen Es Kann auch sinnvoll sein diese Tests bereits in fr heren Projektphasen durchzuf hren da starke Akzeptanzprobleme m glicherweise zu einem sp ten Zeitpunkt gar nicht oder nur mit einem erheblichen Aufwand behoben werden k nnen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 19 Anwendungen die in vielen verschiedenen Umgebungen zum Einsatz kommen wie es bei Standardsoftwareprojekten der Fall ist k nnen einem Feldtest unterzogen werden Es w re f r den Hersteller sicherlich sehr kostenintensiv wenn er alle m glichen Produktivsysteme selber nachstellen w rde In einem solchen Fall wird die Software nach erfolgreichem Systemtest den sp teren Anwendern zur Verf gung gestellt Diese Tests werden auch Alpha bzw Beta Tests
108. inem Trennzeichen versehen Einige Funktionen k nnen auch unterschiedliche Parametertypen annehmen Da der Parametertyp nicht immer anhand seines Wertes identifizierbar ist wird der Wert mit einem Pr fix versehen Eine Nummer stellt zum Beispiel Typ 1 dar w hrend eine Nummer mit einem vorangestellten den Parametertyp 2 kennzeichnet 4 1 3 Projektbeschreibung Es wird beabsichtigt sich von der Unisys Systemumgebung zu trennen und auf eine Client Server Umgebung mit Windows Clients und Unix Servern umzusteigen Das Host Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 35 System soll aufgrund der hohen Wartungskosten und dem bald endenden Support komplett abgel st werden Die Datenhaltung soll in Zukunft auf Oracle Servern erfolgen Eine Neuentwicklung des Systems erscheint aufgrund der hohen Komplexit t der Gesch ftsabl ufe als schwierig und langwierig Deshalb soll eine weitgehend automatisierte Umsetzung des Quellcodes auf Micro Focus COBOL erfolgen Die Konvertierung der Datenbank nach Oracle soll ebenfalls in einem hochautomatisierten Prozess erfolgen Mit der Umsetzung wurde ein externer Dienstleister beauftragt der bereits Erfahrung mit derartigen Projekten besitzt und eine entsprechende Auswahl an Automatisierungstools entwickelt hat Die Datenschnittstellen zum operativen System TOPX getHost und putHost die bisher als COBOL Batch
109. inf hrungsphase ist beendet und es werden verschiedene nderungsanforderungen umgesetzt und in mehreren Releases umgesetzt Ziel ist es nun dieses nderungen zu testen und die betroffenen Bereiche in TOPX mit Regressionstests zu berpr fen Das Ziel das durch die Unterst tzung durch Testautomatisierung erreicht werden soll ist die Durchf hrung dieser Tests mit weniger Ressourcen Die bernahme der Tests vom externen Dienstleister durch Eurogate ITS soll in naher Zukunft erfolgen Bei ITS sollen aber weniger Leute mit den Tests beauftragt werden als jetzt von dem Dienstleister eingesetzt werden Die bernahme der Tests ist ein aktuell laufender Prozess Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 41 5 Toolauswahl und Bewertung Ein entscheidender Schritt bei der Einf hrung einer Testautomatisierung ist die Auswahl der richtigen Werkzeuge Hierzu stehen im Kapitel 5 1 Hinweise was bei einer solchen Auswahl zu beachten ist und Erkl rungen dazu warum diese Auswahl so wichtig f r die weitere Arbeit ist In Kapitel 5 2 wird das HP Quality Center behandelt welches zu Beginn dieser Arbeit bei Eurogate eingef hrt wurde Die Entscheidung zu dieser Einf hrung wurde bereits im Vorfeld gef llt und ist nicht Bestand der hier behandelten Toolauswahl die ab Kapitel 5 3 beginnt 5 1 Hinweise zur Toolauswahl Je nach Unternehmen ist die Wahl des Automat
110. informiert aber mit einem fundierten Basiswissen k nnen diese Gespr che erheblich effektiver ausfallen Sollten an dieser Stelle L cken in der Dokumentation auffallen w re es wohl auch ein guter Zeitpunkt diese zu schlie en Dabei sollte das Erstellen oder berarbeiten der Dokumentation nicht die Aufgabe des Testautomatisierers sein Ebenfalls wichtig f r den Erfolg der Testautomatisierung ist die allgemeine Akzeptanz Wenn die Mitarbeiter die Besprechungen mit dem Testautomatisierer eher als Zeitverschwendung f r eine neue Spielerei ansehen werden sie vermutlich nicht mit der notwendigen Sorgfalt vorgehen und versuchen die Gespr che kurz zu halten Dabei kann es unter Umst nden vorkommen dass wichtige Informationen nicht weitergegeben werden Ein gutes Mittel um diese Akzeptanz zu erzeugen ist die Fortschritte regelm ig zu pr sentieren Viele Kollegen haben sich vielleicht noch nie mit dem Thema besch ftigt Wenn das erste Mal gesehen wird wie eine Software von einem Automatisierungstool bedient wird kann das eine faszinierende Wirkung haben die den Glauben st rkt dass diese kleine Spielerei erfolgreich sein kann Nat rlich sollte dabei darauf geachtet werden dass keine falschen oder berzogenen Erwartungen erzeugt werden damit kurze Zeit sp te keine gro e Entt uschung folgt Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 8
111. ipterstellung Die Application under Test AUT wird auf dem Rechner ausgef hrt auf dem auch QuickTest Professional gestartet wurde Dann wechselt man in einen Capture Modus und f hrt den geplanten Testfall in der AUT aus Alle Benutzeraktionen werden von QTP erkannt und im Skript gespeichert Mit diesem Skript kann der Testfall automatisch wiederholt werden Als Skriptsprache steht VBScript zur Verf gung Allerdings kann QTP auch in andere Entwicklungsumgebungen wie Microsoft Visual Studio eingebunden werden Somit stehen dann alle Sprachen dieser Entwicklungsumgebung bereit Die einzelnen Tests sind in Actions untergliedert die einzelne Testschritte darstellen Es ist m glich diese Actions auch in andere Tests einzubinden So m ssen h ufig verwendete Schritte nicht jedes Mal neu aufgezeichnet werden Falls sich an diesen Schritten etwas ndert weil vielleicht etwas an der AUT angepasst wurde m ssen diese nderungen an der Action nur einmal durchgef hrt werden an die referenzierten Actions werden die nderungen weitergegeben Neben den Actions k nnen auch Funktionsbibliotheken projekt bergreifend verwenden werden Dies steigert die Wartbarkeit der Testf lle RD ee oe e Lr va w s sve ve jr u Wi Resources 7A X stat page g tutorial E Lea Associated Function Libraries e Booki z i CheckDateFunction gfl SS Bookrlight Loi Associated Recovery Scenarios 229 Associated Repositories per Action E
112. ird das Softwareprodukt f lschlicherweise f r einsatzf hig erkl rt k nnen je nach Vertrag weitere Kosten auf den Kunden zu kommen um diese Fehler zu beheben Softwarefehler verursachen gro e Kosten und meistens sind diese Kosten umso gr er je sp ter sie entdeckt werden Am fatalsten sind also die Fehler die erst bei der Nutzung des Softwareprodukts auffallen vgl Liggesmeyer2002 S 29 Auch bei Eurogate kam es zu einer solchen Situation Im Juni 2008 wurde am Containerterminal Hamburg der Firma Eurogate ein Teil der Terminal Operation Software TOS ersetzt Das neue Modul TOPX Terminal Operation Package XWindow ist f r die Schiff Platz und Ger teplanung zust ndig Doch bereits am ersten Tag traten verschiedene Probleme mit TOPX auf Diese Probleme f hrten dazu dass die LKW Abfertigung nur u erst schleppend durchgef hrt werden konnte Da bei Eurogate t glich bis zu 3500 LKW abgefertigt werden entstand ein Verkehrsstau von 25 km L nge vgl Ga dorf2008 Auch das Testen verursacht Kosten Gr ndliche Tests von komplexen Softwaresystemen sind zeitintensiv und personalaufwendig Also liegt es nahe dass Softwaretests optimiert werden sollen Ein Mittel zur Optimierung ist die Einf hrung von automatisierten Softwaretests Meistens werden sehr hohe Erwartungen an den durch Automatisierung erreichten Vorteil gestellt Und sehr h ufig ist es nicht m glich diese Erwartungen zu erf llen Ein schlecht organisierter
113. isierungstools ein Projekt mit unterschiedlich gro en Auswirkungen Die Entscheidung kann die Arbeit von 2 3 Leuten beeinflussen die eher experimentell eine Automatisierung erarbeiten oder den Arbeitstag von mehr als 100 Leuten ver ndern Entsprechend weitreichend k nnen auch die Folgen sein wenn das falsche Tool ausgew hlt wurde Die Produktpalette der verf gbaren Tools geht vom kostenlosen Opensource Tool bis zur kommerziellen Anwendung die mehrere tausend Euro pro Lizenz kostet Es wird deutlich dass die Toolauswahl ein essentielles Thema ist wenn eine Automatisierung implementiert werden soll 5 1 1 Anforderungen an eine Einf hrung von automatisierten Tests Eine Anforderung an ein Testtool oder an eine Einf hrung von automatisierten Tests ist zumeist das Beheben aktueller Testprobleme Solche Probleme k nnen sein manuelles Testen Zeitaufwendig Fehleranf llig keine M glichkeit f r Regressionstests Erstellung von Testdaten und Testf llen ist fehleranf llig schlechte Testdokumentation unzureichende Test berdeckung ineffektives Testen Nicht alle dieser Probleme k nnen mit einem Tool gleichzeitig gel st werden deswegen sollten hier Priorit ten gesetzt werden Eventuell sollte an dieser Stelle auch bedacht werden dass der Testprozess berarbeitet werden sollte und dass eine Automatisierung nicht die L sung der Probleme ist Ein schlecht organisierter Testprozess wird durch eine Automatisierung nicht
114. k nnen Somit stellt jede Zeile in der Tabelle einen Datensatz dar Man kann zum Beispiel die Eingabe in ein Textfeld mit Hilfe dieser Parameter erledigen Tr gt man nun in die Tabelle mehrere m gliche Eingaben in die Zeilen ein kann man QTP so konfigurieren dass f r jeden Datensatz ein neuer Durchlauf des Testschrittes erfolgen soll 5 4 4 Zusammenfassung Mit Quicktest Professional lassen sich recht schnell Automatisierungsskripte erzeugen Die Erkennung von Objekten unter Windows erfolgt zuverl ssig und das Capture and Replay f hrt schnell zu brauchbaren Ergebnissen Voraussetzung ist nat rlich dass die zu testende Anwendung eine Windows Java oder Webanwendung ist Es gibt auch f r bestimmte Terminalclients eine Unterst tzung Diese konnte jedoch nicht zur Ausf hrung gebracht werden Es wurde versucht die unixbasierte QT Anwendung TOPX die mittels Hummingbird Exceed auf einem Windowsrechner ausgef hrt wird mit QTP zu automatisieren Das Terminalprogramm konnte von QTP nicht erkannt werden und der Support von HP gab an dass es keinerlei Unterst tzung von Unixanwendungen gibt Die Integration in das Quality Center erfolgt problemlos QTP kann beim Start bereits eine Verbindung mit dem OC aufbauen und somit seine Daten gleich in den entsprechenden OC Projekten ablegen Die Testf lle erscheinen dann im Test Plan und k nnen anschlie end im Test Lab zu komplexeren Testabl ufen modelliert werden Auch die Ausf hru
115. kann es vorkommen dass bestimmte Szenarien nicht vorhanden sind Somit wird die erfolgreiche Ausf hrung dieser Tests zu einem zuf lligen Ereignis Die nderung der Testdaten durch einen neuen Produktionsabzug erschwert die Nachvollziehbarkeit von Tests Unter Umst nden kann ein Fehler mit neuen Daten nicht reproduziert werden Diese Probleme k nnen umgangen werden indem synthetische Daten also Daten die f r den Test erstellt wurden und nicht in der Produktivumgebung entstanden sind verwendet werden Somit ist sichergestellt dass unter einem bestimmten Index immer ein Datensatz mit bestimmten Eigenschaften vorhanden ist Au erdem kann das System in einen definierten Zustand gebracht werden um Tests in dem gew nschten Szenario ausf hren zu k nnen Es ist nicht notwendig dass der gesamte Datenbestand aus synthetischen Daten besteht Dies ist auch nicht immer m glich oder nur mit einem nicht vertretbaren Aufwand zu realisieren Es ist ausreichend alle relevanten Datens tze vor dem Testlauf zu erzeugen Da diese Erzeugung immer gleich abl uft und verantwortlich f r eine korrekte Testausf hrung ist sollte sie automatisiert werden Ein sp terer Test mit Produktionsdaten sollte nicht vernachl ssigt werden Es besteht immer die M glichkeit dass Datenkonstellationen entstehen die im Test nicht beachtet wurden 6 5 2 Erzeugung von synthetischen Daten in COIN Die zentrale Information in COIN sind Containerdaten Es gibt bei Container
116. ment of Computer Science 26 3 Testautomatisierung Testen und Testautomatisierung sind zwei verschiedene auf einander basierende Handlungen Mit dem Test wird versucht Fehler zu finden w hrend das Ziel der Testautomatisierung ist effizient und langfristig konomisch testen zu k nnen Um dies zu erreichen werden die Testaktivit ten durch die Entwicklung und Ausf hrung von Testskripts unterst tzt Meistens kommen dabei Automatisierungstools zum Einsatz In diesem Kapitel wird erl utert welche M glichkeiten die Automatisierung bietet und was beachtet werden sollte 3 1 Automatisierter Vergleich Automatisiertes Testen ist nicht nur das Aufzeichnen und Wiedergeben von Testabl ufen ein wichtiger Bestandteil ist auch der automatisierte Vergleich der Testergebnisse mit den Sollwerten Werden Tests manuell ausgef hrt ist es h ufig der Fall dass der Tester sich das Ergebnis des Tests anschaut und dann entscheidet ob es richtig oder falsch ist In diesem Fall ist das erwartete Ergebnis im Kopf des Testers vorhanden In der Testdokumentation steht eventuell berpr fe ob die Software das Richtige macht Das kann ein Tester sicherlich erf llen sofern er das entsprechende Hintergrundwissen hat auch wenn es sich dabei nicht um ein empfehlenswertes Vorgehen handelt Bei der Automatisierung ist dies nicht m glich Um automatisiert berpr fen zu k nnen ob sich die Software korrekt verh lt muss man sich pr zise Gedanken dar b
117. mit MSCU so geh rt dieser Container der Reederei Mediterranean Shipping Company Auf den Containern ist diese Nummer an mehreren Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 39 Seiten sichtbar angebracht Mit dieser Containernummer kann der Fahrer visuell pr fen ob er tats chlich den richtigen Container bewegt Die Erstellung dieser Fahrauftr ge erfolgt im Zuge der Platzoptimierung ber TOPX automatisch Van Carrier die keiner Containerbr cke zugeordnet sind werden f r die Optimierung der Stellpl tze eingesetzt bei der die Container nur ihre Position auf dem Yard ver ndern sollen Abbildung 4 4 Verladung von St ckgut SWOP2007 S 1 Viele Sonderf lle verkomplizieren diese Abl ufe die hier nur grob skizziert wurden Es gibt Container die eine eigene K hlung besitzen Diese K hlcontainer m ssen einen Stellplatz erhalten an dem ein Stromanschluss verf gbar ist Einige Gefahrgutcontainer m ssen gesondert behandelt werden Es d rfen weder auf dem Yard noch auf einem Schiff gewisse Stoffe nebeneinander gelagert werden F r Container die von Insekten befallen wurden gibt es spezielle Begasungsanlagen Au erdem k nnen nicht alle Waren mit Containern verschifft werden Solche gr eren Teile wie zum Beispiel Schiffschrauben werden als St ckgut verfrachtet Auf St ckgut kann meistens keine andere Ladung gestapelt werden
118. mit den Referenzdaten 3 Sekunden ben tigt werden Somit ben tigt ein automatisierter Test aller relevanten Funktion ca 40 Min F r die Testkosten wurde der der Stundensatz f r einen Tester in H he von ca 70 Euro angesetzt Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 75 Art der Anzahl Dauer Testkosten Kosten Testart Zeiterfassung Funktionsaufrufe Testdauer Aufruf Std Test manuell gemessen 16 40 Min 2 5 Min 70 175 automatisch gemessen 144 420 Sek 3Sek 70 8 16 manuell berechnet 800 33 Std 2 5 Min 70 2 310 automatisch berechnet 800 40 Min 3 Sek 70 46 66 Bei einem weiteren Testdurchlauf halbieren sich die Kosten f r den automatischen Test da die Referenzdaten nicht neu erstellt werden m ssen au er es wurden nderungen an dem Datenbestand vorgenommen Die manuelle Ausf hrung der Tests ist also bei der ersten Ausf hrung 50mal teurer als die automatisierte danach jeweils 100mal teurer Hinzu kommt dass bei der Automatisierung eine automatische Dokumentation der Ergebnisse erfolgt und die Ergebnisse genauer sind da keine Erm dungserscheinungen den Test beeinflussen Aufgrund der kurzen Laufzeit von 40 Minuten f r einen Test aller Funktionen kann dieser Test nach jedem neuen Versionstand der Software ausgef hrt werden Die Ergebnisse k nnen so sehr schnell an die Entwickler weitergeben werden wodurch der g
119. mputer Science 59 Aktion auf einen bestimmten Dialog z B Date ausf hren Hier w rde man nach dem Wort Datei suchen um dort die gew nschte Aktion auszuf hren Nat rlich kann man sich in den meisten F llen mit der einfachen Bilderkennung behelfen Wenn aber der Entwickler entscheidet die Schrift zu ndern ist man gezwungen alle Skripte zu berarbeiten und alle Bilder neu zu erfassen Dies w re sicherlich nicht akzeptabel In Eggplant k nnen Schriften dynamisch gerendert werden Man gibt also in dem Automatisierungsskript lediglich den Text und den Schriftstyle an Von diesen Styles k nnen verschiedene angelegt und verwaltet werden ndert nun der Entwickler die Schriftart braucht man nur noch den Style anzupassen und die Skripte sind wieder lauff hig Im Skript w rde eine solche Aktion so aussehen Click text Open textStyle WindowsExplorer Ein weiterer Vorteil des dynamischen Renderns der Texte ist die M glichkeit datengetriebene Tests zu erstellen Man kann in dem Beispielskript den String Open auch aus einer Textdatei gelesen haben die als Grundlage f r den datengetriebenen Test dient Normalerweise wird es sich bei einer solchen Datei um eine Tabelle handeln deren Datens tze in einer Schleife abgearbeitet werden 5 5 5 Zusammenfassung Die Erkennung von Steuerelementen anhand von Bildern kann man als Workaround betrachten f r den Fall dass man nicht in der Lage ist auf die innere Repr s
120. n Requirements die sie abdecken und eventuell mit Defects verlinkt Diese Verlinkungen sind wichtig um mit Hilfe der diversen Auswertungen den berblick ber das Projekt zu behalten 5 2 5 Test Lab Im Test Lab werden die Tests die im Test Plan erstellt wurden zu Test Sets zusammengef gt Diese so erstellten Sets k nnen dann im Test Lab auch ausgef hrt werden Die Test Sets k nnen wie gewohnt in einer Baumstruktur geordnet werden Um die gew nschten Tests auszuw hlen kann man entweder den Test Plan Baum oder den Requirements Baum einblenden je nach dem ob man Tests zu bestimmten Requirements Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 48 sucht oder in der Struktur des Test Plan schneller f ndig wird Die Test Sets k nnen wieder mit Defects verkn pft werden Mit dem Execution Flow k nnen Bedingungen erstellt werden die bestimmen wann und ob welcher Test ausgef hrt werden soll Diese Bedingungen k nnen Datum und Uhrzeit sein oder der Status eines vorherigen Tests So kann man zum Beispiel festlegen dass ein Test nur ausgef hrt wird wenn einer oder mehrere vorherige Tests erfolgreich abgeschlossen wurden Diese Abh ngigkeiten lassen sich mit Drag and Drop erstellen Das Ergebnis ist ein Diagramm wie in Abbildung 4 6 gezeigt D up Scottwore Quality Center BACK FORW Domain DEFA
121. n arbeiten beschreiben die Testf lle und Testszenarien Ein Testszenario w re zum Beispiel das L schen Entladen eines Schiffes mit einer bestimmten Ladung Dazu kann es mehrere Testf lle geben die zum Beispiel die unterschiedliche Behandlung von verschiedenen Containertypen berpr fen K hlcontainer bekommen einen Stellplatz mit einem Stromanschluss und bestimmte Gefahrstoffcontainer d rfen nicht ber oder nebeneinander gelagert werden Die Gesch ftsprozesse die diesen Tests zugrunde liegen sind in einer Form dokumentiert die ein Mitarbeiter der entsprechenden Fachabteilung nachvollziehen kann Ein Mitarbeiter dem diese Abl ufe v llig fremd sind ist nicht in der Lage anhand dieser Dokumentation einen Testfall zu erstellen Daf r fehlt der tiefgehende Detailgrad dieser Dokumentation Zu diesen Tests die aktuelle nderungen berpr fen werden Regressionstests ausgef hrt die sicherstellen sollen dass durch die nderungen keine bestehenden Funktionalit ten Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science EH beeintr chtigt werden und keine bisher eventuell maskierten Fehler das Hauptgesch ft von Eurogate beeintr chtigen 7 1 2 Testdokumentation Die Testf lle die Testausf hrungen und die nderungsanforderungen werden im HP Quality Center dokumentiert Ermittelte Fehler werden in Intrexx erfasst Intrexx wird eigentlich als
122. n dann wenn ein Fehler der Vorg ngerversion korrigiert wurde Andernfalls ist in der neueren Version ein Fehler hinzugekommen oder es wurde ein bereits bestehender Fehler demaskiert Bei der Durchf hrung von Regressionstests ist darauf zu achten dass sich die jeweiligen Programme vor der Ausf hrung der Tests in dem selbem Zustand befinden da es sonst zu falschen Fehlererkennungen kommt Bei der manuellen Ausf hrung von Regressionstests m ssen also Testdaten und Testschritte die in Testdokumentationen festgehalten sind abgearbeitet werden Die hierbei entstehenden Ausgaben der Software die getestet wird m ssen anschlie end mit den erwarteten Ergebnissen verglichen werden Je mehr Testf lle abgearbeitet werden desto eher kann es passieren dass der Tester eine Abweichung bersieht Da dokumentierte Arbeitsschritte abgearbeitet werden und Ausgaben mit ebenfalls dokumentieren Werten verglichen werden bietet sich eine Automatisierung von Regressionstests an Ein manueller Eingriff in den Testablauf ist im Allgemeinen nur n tig Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 22 wenn Abweichungen zwischen den Referenz und den Regressionsergebnissen festgestellt wurden Mit einer entsprechenden Automatisierung kann viel Zeit und somit Kosten gespart werden und es werden keine Abweichungen bersehen Es ergeben sich also wirtschaftliche und techni
123. nd vgl Liggesmeyer2002 S 36 2 3 Regressionstests Da nicht davon ausgegangen werden kann dass eine Software nach ihrer Auslieferung nicht mehr weiterentwickelt werden muss sind bestimmte Techniken zum Test von neuen Produktversionen n tig Software wird weiterentwickelt wenn sich die Anforderungen ge ndert haben oder wenn Defekte behoben werden sollen Hierbei muss sichergestellt werden dass durch die nderungen erkannte Fehler behoben wurden keine neuen Fehler entstanden sind und dass keine maskierten Fehler durch die Korrektur eines anderen Fehlers wirksam werden F r diesen Zweck werden Regressionstests eingesetzt vgl Linz2005 S 65ff Die Regressionstests fallen in die zuletzt angesprochene Kategorie der dynamischen diversifizierenden Pr ftechniken Es werden also die Ergebnisse verschiedener Programmversionen miteinander verglichen Es werden Testf lle generiert die m glichst viele Funktionalit ten die in der Anforderung spezifiziert sind abdecken Diese Testf lle werden ausgef hrt und die Ergebnisse anhand der Spezifikation verifiziert Die so entstandenen Testf lle und Testergebnisse stellen die Referenztestf lle f r folgende Regressionstests dar Wird nun eine neue Version der zu testenden Software erstellt so werden die Referenztestf lle mit dieser Version erneut abgearbeitet und die Ergebnisse mit denen der Referenztestf lle verglichen Werden hierbei Abweichungen festgestellt Kann dies gewollt sein ebe
124. ng der Tests ist direkt ber QC m glich Die Tests k nnen lokal oder remote auf einem Testrechner ausgef hrt werden Auf dem Zielrechner muss jedoch QTP installiert sein Die Ergebnisse der Testausf hrung werden im QC gespeichert Bei auftretenden Fehlern k nnen hier auch die Verlinkungen zu Defects erzeugt werden Die implementierte Unterst tzung der datengetriebenen Tests mit Hilfe der Excel Tabelle kann sehr viel Zeit ersparen Sofern man die Testschritte geschickt parametrisiert hat k nnen hier sehr viele Tests ausgef hrt werden indem lediglich neue Zeilen zu der Excel Tabelle hinzugef gt werden Eine Beispielanwendung w re die Automatisierung einer Bestellsoftware Die Bestellung eines Artikels ist immer gleich nur dass eine andere Artikelnummer eingegeben werden muss Nun sollte ein Bestellvorgang automatisiert werden bei der die Artikelnummer ein Parameter ist der zur Laufzeit aus der Excel Tabelle ermittelt wird Durch die Ausf hrung mehrerer Iterationen werden nun so viele Artikel bestellt wie Artikelnummern in der Excel Tabelle hinterlegt sind In Hinblick auf den m glichen Einsatz von QuickTest Professional f r Tests mit COIN wurde die Zusammenarbeit mit der Hostemulation Exceed getestet Der Maskeninhalt der textbasierten COIN Masken l sst sich problemlos als String auslesen und Tastatureingaben k nnen ohne Aufwand an das Exceed Fenster gesendet werden F r die Positionierung des Cursors in bestimmten Eingabefeldern k
125. nn es durchaus sein dass der Quellcode einer zu testenden Software gar nicht vorliegt und auf die Black Box Pr ftechniken zur ckgegriffen werden muss Dies ist zum Beispiel bei den Projekten die in dieser Arbeit besprochen werden der Fall vgl Linz2005 S 208 2 2 1 1 White Box Pr ftechniken Das Kennzeichen der White Box Pr ftechniken ist dass f r die Erstellung der Testf lle die innere Struktur der Software also der Quellcode verwendet wird Bei diesen Tests kann der Quellcode gegebenenfalls ver ndert oder erweitert werden Das Ziel ist dass m glichst viele Quellcodeteile zur Ausf hrung gebracht werden Die zu erreichende berdeckung mit Testf llen sollte vorher festgelegt werden Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 20 2 2 1 2 Black Box Pr ftechniken Bei Black Box Tests werden die Testf lle anhand der Spezifikation erstellt und nicht unter Zuhilfenahme des Quellcodes Da die Eingabe und Auswertung aller m glichen Eingabewerte aufgrund der gro en Anzahl an Kombinationsm glichkeiten nicht sinnvoll ist muss eine sinnvolle Auswahl an Tests getroffen werden Zum Treffen dieser Auswahl gibt es verschiedene Herangehensweisen 2 2 2 Statische und dynamische Pr ftechniken Nach Liggesmeyer2005 lassen sich Pr ftechniken in zwei Klassen einteilen in die statischen und die dynamischen Pr ftechniken Hauptmerkmal bei dieser Un
126. nsaufruf Die Funktion 362AZ soll eine Maske aufrufen die Informationen ber einen Container darstellt TGHU9507987 ist eine g ltige Containernummer Durch die Returntaste wird die Funktion ausgef hrt und es wird ein neuer Dialog angezeigt der die Daten zu dem Container anzeigt Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 67 bartelss ws96091 h22c1 Abbildung 6 2 COIN Maske 362 Containeranzeige Nachdem der Aufruf einer Maske automatisiert wurde ist das n chste Ziel den Aufruf zu parametrisieren und somit beliebige Kombinationen von Funktionen und Schl sseln aufrufen zu k nnen Zur Unterst tzung eines solchen datengetriebenen Tests bietet sich die Verwendung der Data Table von Quick Test Professional an Vgl das Kapitel 5 3 3 Datengetriebener Test Es werden Parameter f r den Funktionsnamen und f r den Schl sseltyp ben tigt In der Data Table sieht dies so aus I mer J _ Funktion Schluessel enable 1 362AE Container Nr 2 362AEA Container Nr 3 1362AZ Container Nr 4 ISCHINL ohne 5 SCHINL rt Buchungs Nr 6 I SCHINL at Reederei Nr 7 I SCHINL Container Nr 8 481AEN Reederei Nr 9 481ANZ Reederei Nr 10 481LOE Reederei Nr 11 48INEU Reederei Nr 12 482AEN Reederei Nr 4S2ANZ _ Reederei Nr Global A Login A Function HH Data Table Sl ctive Screen E Information
127. nt zur Modellierung von Gesch ftsabl ufen durch Experten der entsprechenden Fachabteilungen Hier k nnen Abl ufe beschrieben werden auf deren Grundlage Tests erstellt werden Dies kann bereits vor der Fertigstellung der Software geschehen In einem sp teren Schritt kann der Testautomatisierer die beschriebenen Abl ufe zum Beispiel in QuickTest Professional automatisieren Hierf r ist eine Schnittstelle sowohl in QuickTest Professional als auch im Quality Center vorgesehen Das Automatisierungsskript kann im Quality Center eingesehen und editiert werden Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 47 Die im Business Components Modul erzeugten Tests k nnen nach ihrer Vervollst ndigung als Business Process Test im Test Plan Modul eingebunden und analog zu den anderen Testarten im Test Lab ausgef hrt werden 5 2 4 Test Plan Das Test Plan Modul wird zum Erstellen der Testf lle benutzt Die Tests k nnen in einer Ordnerstruktur organisiert werden die mit einer Baumansicht auf der linken Seite dargestellt wird Es k nnen verschiedene Arten an Tests angelegt werden Dies sind zum Beispiel manuelle Tests Business Process Tests oder Quick Test Professional Tests Zu jedem Test werden zus tzliche Daten wie Priorit t und Status erfasst Tests Edt view Favortes Analysis
128. ntainers an TOPX best tigt Diese Fahrauftr ge die von den VCs abgearbeitet werden werden von TOPX generiert Die Kommunikation mit dem COIN System folgt ber die Schnittstellen Gethost und Puthost Deren Aufgabe ist es Daten zwischen dem TOPX Oracle Server und dem COIN DMS Datenbankserver auszutauschen 4 2 2 Aufgaben von TOPX TOPX ist ein grafisches Planungstool zur zentralen Administration der operativen Abl ufe auf dem Containerterminal Hamburg Es ist eine propriet re Software die vom Hersteller an die spezifischen Anforderung der Kunden angepasst wird Das System bietet Unterst tzung und Optimierung in der Platzplanung Die Platzplanung beschreibt welcher Container zu welcher Zeit an welchem Platz auf dem Terminal stehen soll F r gew hnlich wird ein Container der f r den Export bestimmt ist per LKW oder Bahn angeliefert Die Containerdaten sind in COIN erfasst und dem Container wird von TOPX ein Stellplatz zugewiesen In der Zeit bevor ein Schiff am Kai anlegt werden alle Container f r dieses Schiff in die N he der Containerbr cke gefahren Auch diese Planungsaufgabe wird mit TOPX erledigt Die Container werden in Reihen aufgestellt und bis zu 3 Container hoch gestapelt Nach M glichkeit stehen alle Container f r dasselbe Schiff mit demselben Zielhafen in einer Reihe Ziel der Optimierung ist es dass die Van Carrier m glichst kurze Wege zur ck legen m ssen und dass keine Wartezeiten beim L schen und Bela
129. onstest nenetsi E A E 17 21 3 EIERE en a ae 18 2 1 4 Abnahmetest Ania sense eines 19 2 2 Klassifizierung von Pr ftechniken us 20 2 2 1 Black Box und White Box Pr ftechniken s sseneseseseesseseessesseessersseressseessees 20 222 Statische und dynamische Pr ftechniken uursersnersnneennennnnennnnesnnennnen 21 2 3 RegressionstestS nner ses 22 24 Anf rder ngeh EE 23 2 5 Testfallerstellung nice ocine EE E EE A AERE 24 2 6 Risikoanalyse und Priorisierung von Testen 25 3 Testa t matisiern Sose a a Bes 27 3 1 Automalisierter Vergleich u ueuieanesuheusebe hun heben 21 3 2 Automatisierte Vor und Nachbereitung ssseseseseeesseeesseesseesseesseresseesssresseesseessees 28 3 3 Erstellung von warbaren Tess asked 28 3 4 Ee E 29 3 5 Was kann und sollte automatisiert werden 32 d Projektbeschreibunsen ascendens skin nn 34 4 1 COIN eisen nes estate el 34 4 1 1 Technische Beschreibung ea ae 34 4 1 2 Eunktionalit t von COIN u sisueuein in gan 34 4 1 3 Projektbeschreib ung ugesaat Dr ien Eet es 35 4 1 4 Testanforderune 2 2 As iE e E R ER EAR R EE E S 36 nh e TEE 37 4 2 1 Technische Beschreibung eu ne 37 4 2 2 Aufsaben von TOPR uni ER DEES die 38 4 2 3 Projckibeschreibung ege reinigen 40 4 2 4 EE 41 5 Toolauswahl und Bewertuns cucsecenesunsknassunchinsusehnneineiaenn 42 5 1 Hinweise zur KEE 42 5 1 1 Anforderungen an eine Einf hrung von automatisierten Tests 42 3 62 Au
130. ontainern Bei der seeseitigen Ausgabe von Containern also beim Laden eines Schiffes sind die Zollbestimmungen zu beachten Auch hier gibt es ein EDI basiertes Kommunikationssystem zwischen dem Zoll dem Reeder dem Terminalbetreiber sowie weiteren beteiligten Parteien Dieses System tr gt im Hamburger Hafen den Namen ZAPP Zoll Ausfuhr im Paperless Port ber diese Kommunikation k nnen Container durch die Vergabe einer B Nr Bearbeitungsnummer Zoll zum Export freigegeben oder vom Zoll gesperrt werden Gesperrte Container d rfen nicht verladen werden da sie entweder noch vom Zoll gesondert kontrolliert werden oder bei einer Kontrolle die Ausfuhr nicht erlaubt wurde Diese Informationen sind ebenfalls in COIN ersichtlich Die Bedienung basiert auf der Eingabe von Funktionsnamen die meistens mit einem Parameter versehen werden Die meisten Funktionsnamen setzen sich aus der Maskennummer und der gew nschten Funktion zusammen So bringt der Aufruf 362AZ gefolgt von einer Containernummer alle Informationen ber diesen Container auf den Bildschirm w hrend mit 362 AE eine Maske aufgerufen wird in der die Informationen zu diesem Container ge ndert werden k nnen Nicht alle Funktionen folgen diesem Schema Dies betrifft sowohl die Funktionsnamen als auch die Parameter Es gibt Funktionen die zwei Parameter ben tigen Da aber nur ein Eingabefeld f r Parameter vorhanden ist werden beide Werte in das Feld eingetragen und mit e
131. programme realisiert sind sollen durch Perl Skripte ersetzt werden Bevor diese neue Version von COIN in Betrieb genommen wird ist ein umfassender Test erforderlich Dieser Test soll sowohl die Funktionalit t als auch die Originaltreue der konvertierten COBOL Anwendung und der durch Perl Skript ersetzten Batchl ufe zeigen Au erdem soll die Integrit t und die Originaltreue der Daten berpr ft werden COIN umfasst ca 500 verschiedene Funktionen die in 163 Dialogen 24x80 Zeichen aufgerufen werden k nnen Hinzu kommen noch ca 150 Batchl ufe 4 1 4 Testanforderung Dieser Test hat eine sehr besondere Ausgangsbedingung Es soll zwei Programme geben die sich gleich verhalten und auch das gleiche Layout haben Ein Fehler ist also eine Differenz zwischen den beiden Systemen selbst dann wenn ein fehlerhaftes Verhalten im Altsystem vorliegt das im neuen System nicht vorhanden ist Ein Test von zwei Programmen mit der gleichen Spezifikation wird Back to Back Test genannt F r die 163 Dialoge soll im Test sichergestellt werden dass sie in folgenden Punkten mit dem COIN Altsystem bereinstimmen Maskeninhaltlich Layout Tabulator Reihenfolge der Eingabefelder Programmierte Aktionen STOP NEXT BACK Dn GP Mit den Aktionen kann in Listen weiter gebl ttert werden NEXT BACK oder es k nnen Funktionen abgebrochen werden Wird mit einer bestimmten Funktion das Anlegen eines Datensatzes initiiert K nnen in der Maske die entsprechen
132. r C Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 46 C Exclude from Analysis Only complete assessments will be included in the analysis Business Criticality Failure Probability Analysis Results Assign values to the following criteria to assess the Business Criticality of this requirement Type of process Impact of failure G Frequency of use very often v NumberSignificance of affected users Many High SS Description of Criterion Type of process The type of process represented by the requirement This criterion has the following possible values Calculation Validation The feature represented by the requirement is an important calculation or validation Calculated Assessment value Calculated Business Criticality C Override calculated value ipii Custom Business Criticality Abbildung 5 3 HP Quality Center Risikoanalyse Die Einstufung der Fehlerwahrscheinlichkeit in die Kategorien 1 2 und 3 erfolgt anhand der Angaben zur Anderungsart neue Anforderung Anderungen keine Anderung Reifegrad der Software Anzahl der bekannten Fehler und der Anzahl der betroffenen Programmteile 5 2 3 Business Components Das Business Components Modul ist eine optionale Erweiterung von HP f r das Quality Center die nicht in jeder Ausbaustufe enthalten ist Es wird eine extra Lizenz ben tigt Das Modul die
133. r Test ausgef hrt wird wenn der vorherige Test mit finished beendet wurde Das Ergebnis finished bedeutet dass der Test nicht aufgrund eines Fehler abgebrochen wurde Der gr ne Pfeil bedeutet dass der Vorg nger nicht nur beendet sondern auch erfolgreich abgeschlossen passed werden muss damit sein Nachfolger ausgef hrt wird Eine kleine Uhr am Pfeil bedeutet dass der nachfolgende Test nur zu einer bestimmten Uhrzeit oder an einem bestimmten Datum ausgef hrt werden soll Dies kann sinnvoll sein wenn l nger dauernde Tests ber Nacht automatisch ablaufen sollen Bei der Ausf hrung von manuellen Tests werden dem Tester die Testschritte nacheinander in einem Fenster angezeigt Zu den Testschritten sind die erwarteten Ergebnisse dokumentiert es liegt nun an dem Tester zu entscheiden ob das tats chliche Verhalten der Software mit dem erwarteten Verhalten bereinstimmt Bei einer Ausf hrung von automatisierten Tests kann zum Beispiel QuickTest Professional vom Quality Center aufgerufen werden Es wird Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 49 auf dem spezifizierten Testrechner gestartet und der Test wird ausgef hrt Nach Abschluss des Tests werden die Ergebnisse im Quality Center angezeigt e TE Runner Test Set lt Test Test gt Test lt 1 Yiew Calendar E P R no Fiter by al Exec Time verify gt No R
134. rden kann TEU Twenty feet Equivalent Unit Bezeichnet einen 20 Fu langen ISO Container Ma einheit f r die Ladekapazit t von Containerschiffen oder Umschlagmenge von Containerh fen Umfuhr Containerumfuhr Bezeichnet die Bewegung eines Containers von einem Stellplatz auf dem Terminal Yard zu einem anderen VC Van Carrier oder auch Straddle Carrier dt Portalhubwagen Fahrzeug mit Hubwerk f r den Transport von Containern auf dem Terminalgel nde Kann je nach Bauart ber eine bestimmte H he an gestapelten Containern hinweg fahren ZAPP Zoll Ausfuhr im Paperless Port EDI basiertes Kommunikationssystem zwischen Zoll Reedern Spediteuren Kaiumschlagsbetrieben u a zur elektronischen Zollausfuhr berwachung im Hamburger Hafen http www zapp hamburg de Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 93 Versicherung ber Selbstst ndigkeit Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Pr fungsordnung nach 824 5 ohne fremde Hilfe selbstst ndig verfasst und nur die angegebenen Hilfsmittel benutzt habe Hamburg 26 M rz 2009 Ort Datum Unterschrift Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 94
135. rung des Tests eingesetzt wird z B gesch ftsprozess basierter Test 3 Testobjekt Art des Testobjekts z B GUI Test 4 Teststufe Die Stufe des verwendeten Vorgehensmodells z B Systemtest 5 Testperson Der Personenkreis der den Test durchf hrt z B Entwicklertest 6 Testumfang z B partieller Regressionstest Volltest vgl Linz2005 S 10 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 14 2 Testgrundlagen In diesem Kapitel werden einige Grundlagen des Softwaretestens n her erl utert Es wird ein berblick ber die gesamte Thematik gegeben damit im sp teren Verlauf der Arbeit die M glichkeit besteht die Tests entsprechend einzuordnen In Kapitel 2 1 wird der Testverlauf begleitend zu einem Vorgehensmodell hier dem V Modell vorgestellt Kapitel 2 2 besch ftigt sich mit verschiedenen Pr fmethoden und deren Klassifizierung w hrend in Kapitel 2 3 speziell auf die Regressionstests eingegangen wird Kapitel 2 4 geht dann n her auf die Testautomatisierung ein die einen zentralen Punkt dieser Arbeit bildet 2 1 Teststufen Das allgemeine V Modell verbindet die Entwicklungsarbeiten mit den dazugeh rigen Testaktivit ten Auf der linken Seite der Modelldarstellung finden sich die verschiedenen Entwicklungsstufen auf der rechten Seite stehen die zugeh rigen Testarbeiten Anforderungs definition E Funktionaler Systemtest
136. rwendetes Dokumentenmanagementsystem zu schreiben sehr komfortabel sein Welche Faktoren in der Praxis von entscheidender Bedeutung sind ist im Einzelfall festzulegen Es bietet sich an eine Tabelle mit notwendigen und w nschenswerten Features zu erstellen und die verf gbaren Tools anhand dieser Tabelle zu pr fen W hrend dieser Evaluation kann sich diese Tabelle durchaus ver ndern da Tools Features enthalten k nnen die man nicht bedacht hat obwohl sie w nschenswert oder sogar notwendig sind vgl Fewster1999 S 260 270 5 2 HP Quality Center Das HP Quality Center ist ein zentrales Qualit tsmanagement Tool mit dem die Aktivit ten im Testprozess abgebildet und alle relevanten Daten verwaltet werden k nnen Die Informationen werden in den Modulen Releases Requirements Business Components Test Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 43 Plan Test Lab und Defects erfasst Die Informationen in diesen Modulen sind miteinander verkn pft so dass der Status des Projektes jederzeit ersichtlich ist Diese bersicht wird durch die M glichkeit diverse Analysen zu erstellen noch verbessert Es k nnen Berichte und Graphen erstellt werden die ber den aktuellen Status oder Verlauf des Projektes Auskunft geben Sie enthalten unter anderem Informationen ber die aktuellen Anforderungen den Verlauf und Stand der Tests die Testfallabdeckung
137. s berpr fen der Maskeninhalte 6 2 Automatisiertes Aufrufen der Funktionen F r den automatischen Aufruf der Funktionen wird HP QuickTest Professional verwendet Hiermit ist es m glich Tastatureingaben an das Exceed Fenster zu schicken Mit Hilfe des Capture and Replay Modus wurde die Eingabe einer Funktion mit Schl ssel aufgezeichnet Die anf ngliche Positionierung des Eingabecursors erfolgt per Mausklick Aufgrund der fehlenden Erkennung von Objekten werden f r diesen Klick nur die Mauskoordinaten erfasst Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 66 Da sich das Eingabefeld f r die Funktion in jeder Maske an der gleichen Stelle befindet entsteht daraus kein Problem f r den verl sslichen Ablauf des Skriptes QuickTest Professional hat diesen VBScript Code erzeugt Coin Fenster in den Vordergrund bringen Window ExceedWindow Activate Cursor per Mausklick in das Funktionsfeld bringen Window ExceedWindow Click 173 498 Funktion eingeben Window ExceedWindow Type 362AZ in das n chste Eingabefeld springen Window ExceedWindow Type micTab Schl ssel eingeben Window ExceedWindow Type tghu9507987 Mit Return Funktion ausf hren Window ExceedWindow Type micReturn Ohne die letzte Zeile sieht das COIN Fenster nach dem Auflauf des Skripts wie folgt aus 101 x Abbildung 6 1 COIN Fenster mit Funktio
138. s Andererseits sind die Kosten pro Testzyklus sehr viel niedriger Die Ausf hrung der Tests erfolgt schneller und verursacht weniger Personalkosten Bei dieser Tabelle handelt es sich um ein einfaches Rechenmodell bei dem einige Aspekte nicht ber cksichtigt wurden Es kann durchaus sein dass die Kosten bei den ersten automatisierten Zyklen h her liegen da eventuell noch Fehler in der Implementierung der Testf lle auftreten Es kann auch sein dass die Automatisierung keinen direkten finanziellen Vorteil erzielt daf r den Test schneller abschlie t und somit ein k rzeres Time to Market erreicht wird Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 30 Eine Metrik die Anzahl der gefundenen Fehler wird bei der Automatisierung nicht betrachtet Manuelle Tests haben in der Praxis die h here Chance Fehler zu entdecken Bei der Automatisierung werden diese Fehler w hrend der Erstellung und der ersten manuellen Ausf hrung der Tests entdeckt Das bedeutet aber nicht dass sich eine Automatisierung nicht lohnt Die Vorteile entstehen unter anderem bei der wiederholten Ausf hrung von Tests zum Beispiel bei Regressionstests vgl Fewster1999 S 203 207 Es ist ratsam mit Metriken den Testprozess zu berwachen Nur so kann festgestellt werden ob neue Techniken effektiver sind als bisherige oder ob eine weitere Optimierung dringend notwendig ist Welche Metrik
139. s Tabulators realisiert werden k nnen so wird aber sichergestellt dass alte Werte die schon im Feld stehen berschrieben werden Wenn kein Wert f r die Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 78 Eingabe in der Data Table hinterlegt ist wird das Feld mit TAB bersprungen Hier werden keine Leerzeichen eingegeben damit keine Standardwerte berschrieben werden Dim Wert wert DataTable DataTable Wert dtLocalSheet dtglobal If wert Then Window ExceedWindow Type mictab else Window ExceedWindow Type wert amp Space datatable Size dtLocalSheet len wert end if Mit diesem Code kann jede Eingabemaske gesteuert werden Die Ablauflogik ist in der Data Table festgelegt Dort m ssen die Eingabefelder in der richtigen Reihenfolge angegeben werden Dieser Code wird f r jede Zeile in der Data Table wiederholt Die Zeilen des globalen Datenblattes der Data Table agieren bei diesem Ablauf als u ere Schleife Jede Zeile stellt einen Containerdatensatz dar der ber die COIN Maske angelegt werden soll Schluessel Laenge Hoehe Typ Tara robe0213100 20 86 dc 2000 robe0219101 40 86 dc 2000 robe0219102 20 96 rf 2000 robe0219103 40 96 rf 2000 Abbildung 6 8 HP QTP Data Table globales Datenblatt 6 6 Testen von Gesch ftsprozessen Das Aufrufen aller vorhandenen COIN Funktionen und Masken ist nicht ausreichend um die
140. s sollten ebenfalls darauf geachtet werden dass die Menge der in der Testsuite gespeicherten Daten nicht zu gro wird Auch hier tritt ein Problem mit der Wartbarkeit auf aber es kommen noch Performanceprobleme hinzu da diese Daten bei der Testausf hrung aus der Datenbank auf die Testrechner kopiert werden m ssen H ufig lassen sich die Datenbest nde verringern wenn bei der Planung mehr Zeit darauf verwendet wird zu identifizieren welche Daten tats chlich ben tigt werden Die Daten sollten nach M glichkeit in einem flexiblen Format gespeichert werden Es ist nicht immer ratsam alle Testdaten so zu speichern dass nur die AUT sie lesen kann Eventuell wird eine nderung vorgenommen die genau dieses Datenformat betrifft Es entsteht ein viel geringerer Wartungsaufwand wenn die Testdaten in einem flexiblen Format vorliegen Die einzelnen Testf lle sollten so kurz wie m glich gehalten werden Oft ist man versucht lange Tests zu konstruieren da sie automatisch ablaufen und der Computer sich daran nicht st rt Aber automatisierte Tests sind Software und m ssen genau wie andere Programme getestet werden Wurde ein langer Test fehlerhaft implementiert und f hrt dies bei seiner Ausf hrung zu einem Fehler ist der Aufwand diesen Fehler zu beheben wesentlich gr er als bei kleineren Testabl ufen Solche langen Tests k nnen auch durch Abh ngigkeiten zwischen mehreren Tests entstehen Dies ist der Fall wenn das Ergebnis des einen Tests di
141. sche Vorteile vgl Liggesmeyer2002 S 187 189 2 4 Anforderungen Das Ziel von Testen ist die berpr fung der Anforderungen an die Software Dies ist gilt sowohl beim manuellen als auch beim automatisierten Testen Man m chte wissen ob die Software die Anforderungen die an sie gestellt werden in einem zufriedenstellenden Ma erf llt Daf r ist es zuerst einmal absolut notwendig dass diese Anforderungen ausreichend detailliert definiert und dokumentiert sind Bei einem automatisierten Test m ssen die Anforderungen noch detaillierter und sorgf ltiger dokumentiert sein da von einem Programm die Richtigkeit berpr ft werden soll Ein Tester kann bei einer ungenauen Spezifikation immer noch entscheiden ob das Ergebnis nun richtig oder falsch ist Wobei diese Entscheidung allerdings nicht zwangsl ufig korrekt sein muss Beim Erfassen der Anforderungen sollte also sehr sorgf ltig vorgegangen werden Hier entstehen die meisten Fehler in einem Projekt Diese Fehler fallen auch selten bei den Tests auf da die Tests genau auf die Erf llung dieser Anforderungen ausgerichtet sind Sind die Anforderungen falsch so sind auch vermeintlich richtige Testergebnisse falsch Die Anforderungen sollten also einem ausf hrlichen Review Prozess unterliegen Dabei sollten folgende Aspekte beachtet werden Mehrdeutigkeiten Da Menschen aus verschiedenen Arbeitsbereichen zusammen vermeiden arbeiten kann jeder ein anderes Verst ndnis f r ein Problem
142. sh auch Versionen f r Tests von Web Applikation und Javaprogrammen und mehr Trotzdem verlangt eine anders geartete AUT auch den Einsatz eines anderen Tools sei es eine andere Squish Version oder ein ganz anderes Programm Das Erstellen der Skripte in Squish erscheint intuitiv durch das Capture and Replay Verfahren Die Verification Points k nnen komfortabel eingepflegt werden und bieten viele M glichkeiten Die Auswahl verschiedener Skriptsprachen JavaScript Tcl Python Perl bietet gen gend Flexibilit t um in den meisten Umgebungen zu funktionieren Es ist nicht n tig eine propriet re Skriptsprache zu erlernen Verschiedene Addons die unter anderem die Integration in das HP Quality Center erm glichen helfen dabei Squish einfach und schnell in die Testabl ufe einzubinden und effektiv zu nutzen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 63 5 7 Ergebnis der Toolauswahl Die Auswahlkriterien aus dem Kapitel 5 1 2 Auswahlkriterien werden von den drei Tools folgenderma en erf llt Froglogic Squish Im o Beschreibung Erf llt 1 Integration in Quality Center ist mit einem Plug In m glich ia F r QT Anwendungen konzipiert ja 3 Eine andere Version f r die eine weitere Lizenz ben tigt wird Kann m glicherweise Windows Objekte erkennen ai 4 Es werden g ngige Skriptsprachen wie JavaScript verwende
143. showSortindicator false a O allColumnsShowFocustrue an tie sed Search O selectionMode 0 Beet First Name Last Name Address E Mail Add D muttiselection false estj O columns 4 testdat Change O drag utoScroll true 4 verifice O contentsY 0 YP FirstName LastName Address E Mail O contentsx 0 ared Sascha B O contentsHeight 16 testeat O contents width 269 scripts O visibleHeight 140 TS d O visiblewidth 498 sous O hScrollBarMode 0 JToday O ScrollBarMode 0 O resizePolicy 1 O frameRect x 0 y O midLinewidth 0 CO margin 0 O linewidth 1 O frameShadow 48 O frameShape 6 O contentsRect x 1 y M frameWwinth 1 Abbildung 5 11 Squish Adressbuch Beispiel Es besteht auch die M glichkeit ohne Unterst tzung des Spy Verification Points zu erstellen M chte man zum Beispiel sicherstellen dass eine bestimmte Datei erzeugt wurde reicht im Skript zur berpr fung die Zeile test verify OFile Exists Name aus Hier kann man alle M glichkeiten die die jeweilige Skriptsprache bietet verwenden Nach der Ausf hrung des Testskripts werden im Log Fenster im unteren Teil der Squish GUI die Ergebnisse angezeigt Dort wird f r jeden Verification Point angezeigt ob er erfolgreich berpr ft werden konnte oder nicht Auch die Abweichungen von den erwarteten Werten werden hier angezeigt Neben der Verifikation ber die Eigenschaften der Steuerelemente bietet Squish auch eine berpr fung anhand
144. sige SQL Statements zu erzeugen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 84 Ein L sungsansatz w re also die Erzeugung der Daten wie in Kap 6 5 2 Erzeugung von synthetischen Daten in COIN umzusetzen und weitere Schritte in TOPX mit einer GUI Automatisierung ablaufen zu lassen Diese Aufgabe sollte mit dem Tool Squish von Froglogic erfolgen vgl Kap 5 6 Froglogic Squish Der so erreichte Vorteil w re dass in den Testfallbeschreibungen dokumentiert werden w rde welche Container f r den entsprechenden Test verwendet werden m ssen Dies spart zum einen die Zeit f r das Suchen der Datens tze ein zum anderen wird auch sichergestellt dass der Test tats chlich mit den Daten ausgef hrt wird die alle Kriterien erf llen die f r eine korrekte Testausf hrung n tig sind Die Erzeugung der synthetischen Daten k nnte auch manuell ausgef hrt werden dabei besteht aber die Gefahr dass bei der Eingabe Fehler gemacht werden Ein Ursache k nnen auch hier Erm dungserscheinungen sein wenn eine gro e Anzahl an Datens tzen manuell eingegeben werden muss Da diese Daten f r jeden Testdurchlauf ben tigt werden handelt es sich um eine wiederkehrende T tigkeit Es sind alle Kriterien erf llt die eine Automatisierung rechtfertigen Nicht alle Daten die f r die Tests ben tigt werden sind Containerdaten Diese werden aber mit Abstand am h ufig
145. spezialisierten Ingenieurleistungen In Deutschland werden ca 4 500 Mitarbeiter besch ftigt vgl Eurogate2008 1 Der Container Terminal Hamburg CTH liegt in Hamburg Waltershof Dort befinden sich zurzeit sechs Gro Schiffsliegepl tze mit 21 Containerbr cken 2007 wurden hier 2 9 Millionen TEU umgeschlagen vgl Eurogate2008 2 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 7 Abbildung 1 1 Eurogate Container Terminal Hamburg Eurogate2007 S 1 Die Eurogate IT Services GmbH EG ITS bietet IT Dienstleistungen f r den Containerumschlag sowie f r cargomodale und intermodale Logistik an Das Unternehmen ist f r die gesamte IT von Eurogate verantwortlich Dieses Aufgabenfeld umfasst die Bereitstellung der Infrastruktur mit ca 200 Servern auf denen verschiedene Betriebssysteme zum Einsatz kommen das Emailsystem die Desktoprechner und Drucker sowie die Wartung und den Support f r die Systeme Es werden viele verschiedene Softwaresysteme verwaltet weiterentwickelt und in Projektarbeiten erg nzt Hierbei handelt es sich um Programme zur Containerverwaltung Koordination der operativen Abl ufe auf dem Yard ERP Systeme SAP Port Security E Business und einige andere Systeme Damit diese Systeme mit allen wichtigen Daten versorgt werden bietet EG ITS EDI Schnittstellen Electronic Data Interchange f r Kunden Reeder und Beh rden an Au er
146. st geeignet Hier wird das Augenmerk auf die Kontrollstrukturen gelegt Auftretende Kontrollflussanomalien k nnen Spr nge aus Schleifen oder Programmst cke mit mehreren Ausg ngen sein Hierbei muss es sich nicht um Fehlerzust nde handeln sie stehen aber im Widerspruch zu den Grunds tzen der strukturierten Programmierung vgl Linz2005 S 90 2 2 2 2 Dynamische Pr ftechniken Die dynamischen Pr ftechniken sind dadurch charakterisiert dass die zu testende Software ausgef hrt und mit konkreten Eingabewerten Testdaten versehen wird Die dynamischen Pr ftechniken k nnen in der realen Betriebsumgebung zum Einsatz kommen Allerdings Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 21 bringen sie keinen Beweis f r die Korrektheit da es sich meistens um Stichprobenverfahren handelt Ein Test mit allen Eingabem glichkeiten ein ersch pfender Test ist aufgrund der hohen Komplexit t von Programmen nicht praktikabel Trotzdem kann man mit dynamischen Pr ftechniken sinnvoll pr fen Ob eine Funktion korrekt oder nicht korrekt ausgef hrt wird Kann im Grunde nur f r die verwendeten Testdaten mit Sicherheit gesagt werden Man muss also auf die Korrektheit anderer nicht getesteter F lle schlie en Somit ist die Wahl der Testf lle ausgesprochen wichtig Man sollte darauf achten dass diese repr sentativ fehlersensitiv redundanzarm und konomisch si
147. sten ben tigt Deshalb w rde das Erstellen von synthetischen Containerdaten schnell zu positiven Effekten f hren Das reine Erzeugen der Daten kann anschlie end dazu ausgebaut werden im Test h ufig verwendete Testszenarien zu erzeugen Dies k nnen Szenarien sein die in der Praxis oft vorkommen oder die eher ungew hnlich sind und h ufig zu Fehlern f hren Besonders wichtig w ren die Szenarien mit denen die Funktionalit ten gepr ft werden die f r das Hauptgesch ft von Eurogate wichtig sind Diese Szenarien lassen sich aus den Testdokumentationen ableiten Als n chstes sollte die schrittweise Automatisierung der Regressionstests die das Hauptgesch ft von Eurogate absichern folgen Hier sollte eine genaue Analyse erfolgen welche Tests sich mit m glichst wenig Aufwand automatisieren lassen Mit diesen Tests sollte begonnen werden um Erfahrungen zu sammeln wie erfolgreich die Automatisierung ist Mit diesen ersten Tests muss eine generelle Vorgehensweise f r die Automatisierung festgelegt werden Nach M glichkeit sollten dabei Standards entwickelt werden Diese Standards k nnen recht umfassend sein So sollte festgelegt werden wie die Testf lle und Testergebnisse dokumentiert werden aber auch die Art und Weise wie Tests automatisiert werden Hier kann unter anderem ein Coding Style f r die Skripte festgelegt werden oder bestimmte Arten der berpr fung Somit wird sichergestellt dass gewonnene Erfahrungen auch einen positiven E
148. stleisters Mitarbeitern aus den Fachbereichen bei Eurogate und Mitarbeiten von Eurogate ITS durchgef hrt Diese Mitarbeiter werden f r die Testausf hrung von ihren eigentlichen Aufgaben freigestellt Die Ausf hrung der Tests f r ein neues Release kann bis zu 3 Wochen oder l nger dauern Die Mitarbeiter f hren diese Tests in dieser Zeit entweder an 2 oder 3 Tagen pro Woche oder in Vollzeit aus Die Tests werden anhand der im HP Quality Center dokumentierten Testschritte manuell ausgef hrt Die Ergebnisse werden ebenfalls im HP Quality Center hinterlegt Es gibt keine Unterst tzung durch automatisierte Prozesse Als Testdaten werden f r gew hnlich Produktionsdaten genommen Dies f hrt h ufig dazu dass zu dem jeweiligen Testszenario passende Datens tze zuerst im System gesucht werden m ssen Eventuell m ssen diese Daten zuerst von Hand angelegt werden Besonders wenn sehr viele oder sehr spezielle Daten ben tigt werden f hrt dies zu erheblichen Verz gerungen 7 2 Zielzustand Das Hauptziel ist dass alle Tests ohne den externen Dienstleister ausgef hrt werden S mtliche Testaktivit ten sollen von Eurogate ITS erledigt werden F r den Test bedeutet Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 82 dies dass er mit weniger Personal ausgef hrt werden soll ohne dass dies eine Verl ngerung der Testausf hrung oder eine Verringerung der Qualit t z
149. swahlkriterien nme nl 43 32 SHP OQuahty Center nee een 43 5 2 1 Releases nassen una SS RERE 44 22 LE We EE 45 5 2 3 Business Components EE 47 Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 5 2 4 Test DEE 48 5 2 5 Test Lab a EE a EE N E E EE 48 5 2 6 Defects nn ee lee ine ee 50 5 2 7 ZUsammenfassung scn Han e a a a lie 51 5 3 Auswahl der Automatisierungstools sssesssssseessesesseetsseessresseesseeesseeesseesseesseessees 52 5 4 HP Quicktest Professional 54 5 4 1 Skripterstellung eea ea sa 54 5 4 2 Verifikation der Ergebnisse asien hen 55 5 4 3 Datensettiebener Test A lee 57 5 4 4 RTE E essen 57 5 5 Redstone EE EE 58 5 5 1 Skripterstellung srira nrnna an Ea 58 5 5 2 Skipt prac Eege 58 5 5 3 Bilderkennuns deed 59 5 5 4 Texterkennung usunesuedsseenunchaunkbuisuebe E 59 5 5 5 Z sammentass ung eg on o a ee E Ea E E 60 3 0 Eroelos e Squish E 61 5 6 1 EE 61 5 6 2 Veritikation der Ergebnisse udn ee 61 5 6 3 Ka Tue 63 5 7 Ergebnis der E TEE 64 6 Automatisierung der Tests f r die COIN Mieraton en 66 6 1 Testkonzeptl see es Ei 66 6 2 _ Automatisiertes Aufrufen der Funktonen nenn 66 6 3 Automatisiertes berpr fen der Maskeninhalte s sessesississeirsereeersrissirssrrsererrrerrss 70 6 3 1 Erstellung von Referenzdaten ansehen Eeer 71 6 3 2 Vergleich mit EE EH 72 6 3 3 Analyse der Testergebnisse uuueieuesdeineiikuenn ni ala 74
150. t ia 5 Es kann auf Datenbanksysteme zugegriffen werden ja EEE Lasttests k nnen ausgef hrt werden ja 7 L uft unter Solaris und l sst sich per Host Emulation von Windows aus bedienen ja 8 ca 2 400 EUR ja HP QuickTest Professional Im o Beschreibung Erf llt Integration in Quality Center ist m glich ja Keine Erkennung von QT Objekten nein F r Windows Anwendungen konzipiert ja 4 Visual Basic Script ist eine g ngige und einfach zu erlernende Skriptsprache ja 5 Es kann auf Datenbanksysteme zugegriffen werden ja Lg Lasttests k nnen nicht ausgef hrt werden nein L uft unter Windows ja Blo 3 000 EUR ja Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 64 Redstonesoftware Eggplant ID Beschreibung Erf llt Integration in Quality Center ist nicht m glich iq Erkennung von QT Objekten durch Bilderkennung ja Erkennung von Windows Objekten durch Bilderkennung ja Eigene Skriptsprache Sense Talk Intuitiv ja Datenbankzugriff ist in Planung nein L Lasttests k nnen nicht ausgef hrt werden nein Ben tigt Mac OS kann per VNC von Windows bedient werden Gate 8 ca 3 750 EUR ja Der Wunsch alle Tests mit einem Tool ausf hren zu k nnen ist nur mit Eggplant zu realisieren Leider ist die Implementation der Tests durch die Bilderkennung eher umst ndlich auch wenn dadurch die Abh ngigkeit von der Objekterkennung umgangen wird
151. te die zur Automatisierung ben tigt werden aufzeichnen Man markiert man den repr sentativen Bildausschnitt zum Beispiel einen Button auf den man einen Mausklick ausf hren will Nun wird dieser Bildausschnitt mit einem passenden Namen in dem Projekt abgespeichert und ist Eggplant somit bekannt ber die Eggplant Men leiste in dem VNC Client kann man einen Mausklick auf das markierte Objekt ausf hren Dabei wird im Skript folgende Zeile erzeugt click Objektname Bei einer erneuten Ausf hrung des Skripts wird dieses Element nun anhand des Bildes wiedergefunden auch wenn es sich an einer anderen Position im Bild befindet Die Skripte sind somit robust gegen ber Positions nderungen von Objekten 5 5 2 Skriptsprache Als Skriptsprache wird das von Redstone Software selbst entwickelte Sense Talk verwendet Bei Sense Talk wird Wert darauf gelegt dass die Skriptsprache schnell erlernbar ist Daf r sollte die Syntax intuitiv sein und h ufig verwendete Funktionalit ten beherrschen Sense Talk ist eine interpretierte objektorientierte Highlevel Sprache deren Syntax sich stark an der englischen Sprache orientiert So sind solche Konstrukte m glich put five is less than two times three Put ist der Sense Talk Befehl f r eine Bildschirmausgabe Somit erzeugt die obenstehende Zeile die Ausgabe true Nat rlich m ssen Zahlen nicht ausgeschrieben werden dieses Beispiel soll nur verdeutlichen wie stark der Bezug zur gew
152. tehen Weitere Kriterien betreffen den Anbieter des Tools W hrend einer Evaluationsphase sollte darauf geachtet werden wie gut der Kontakt zum Anbieter ist und wie schnell und pr zise Supportanfragen bearbeitet werden Der Anbieter m chte mit seinem Produkt Geld verdienen Wenn das Tool gekauft wurde also der Anbieter sein Geld bekommen hat ist es nicht sehr wahrscheinlich dass sich der Kontakt und Support verbessert Wichtig ist auch die Liste der Referenzkunden Wenn man zum Beispiel einer der ersten K ufer des Tools ist gibt es wenig Erfahrungswerte die bei der Implementierung helfen Bei weit verbreiteten Tools kann man unter anderem viele Ratschl ge in Fachforen z B www sgaforums com erhalten Ein weiterer Punkt ist die Bereitschaft des Toolanbieters sein Produkt weiter zu entwickeln oder gegebenenfalls kundenspezifische Verbesserungen vorzunehmen Bei dem Tool sollte darauf geachtet werden dass die Einarbeitungszeit so kurz wie m glich ist Es sollte also gut zug nglich sein und eine umfangreiche Hilfe besitzen Hier k nnen auch Kosten f r Schulungen eingespart werden Au erdem sollte das Tool stabil und zuverl ssig funktionieren Wenn l ngere Testabl ufe automatisiert werden und diese unbeaufsichtigt ablaufen w re es sehr hinderlich wenn das Tool dabei abst rzt Die Integrationsm glichkeiten mit anderen Tools kann ein wichtiger Aspekt sein Zum Beispiel kann die M glichkeit Testergebnisse direkt in ein bereits ve
153. ten Hilfe ZBUAUBRSBPAA S DIS 66 70 74 78 63 6 n 7 7 1 65 69 73 k chiffs ID Schiffs 1D 0141 0153 m 2 67 0273 HUMEN 04 5605 el Service FE 17 6721 YM UT 89 6990 Eu JETA 24 02 2009 18 00 00 Von m Marke 35 58 7260 LAPPL 91 9298 CMA C p Charakteristika j ven CSCL PUSA L nge 337 Bays _39 Art NON_ 40 Richtung B_ LE HAYRE XIN BEIJING LONG BEACH pura Bunuunsnunueuusag os 7o77 03 07 11 15 19 23 27 3 35 39 43 47 51 55 59 63 L AGATE amp O1 05 09 13 17 21 25 29 33 37 4 45 49 53 57 61 L BELGI L DENMA L EUROS L GERMA L HONGK L INDIA RGE L IBELA CSCL PUSAN XIN LOS ANGELES XIN SHANGHAI XIN HONG KONG CSCL ZEEBRUGGE LE HAVRE XIN BEUING LONG BEACH L IWONA z al Neu Sichern Schiff ffnen L schen Aktualisieren 41 E r Aktuell Management Abbildung 7 1 TOPX mit ge ffneter Schiffsansicht Um einen Testfall durchzuf hren wird momentan sehr viel Zeit darauf verwendet passende Daten f r den Testfall zu
154. terscheidung ist dass bei den statischen Tests die zu testende Software nicht zur Ausf hrung gebracht wird im Gegensatz zu den dynamischen Pr ftechniken 2 2 2 1 Statische Pr ftechniken Diese Pr ftechniken werden auch als verifizierende oder analysierende Techniken bezeichnet Charakteristisch hierbei ist dass die Software nicht ausgef hrt wird und dass keine Testf lle generiert werden F r die Analysen ist prinzipiell keine Unterst tzung durch Rechner erforderlich Eine vollst ndige Aussage ber die Korrektheit oder Zuverl ssigkeit kann mit statischen Pr fungen nicht erzeugt werden vgl Liggesmeyer2002 S 40 Zu den statischen Pr ftechniken z hlt die Datenflussanalyse Die Beurteilung der Korrektheit erfolgt aufgrund der Erkennung von Datenflussanomalien vgl Linz2005 S 88 Eine Datenflussanomalie ist beispielsweise ein Zugriff auf eine Variable die vorher nicht initialisiert wurde Da in der objektorientierten Programmierung sehr viel mit Datenzugriffen zum Beispiel bei Klassen mit vielen Attributen gearbeitet wird ist die Datenflussanalyse als Modultest hier sehr geeignet In der Praxis findet sie allerdings kaum Verwendung Die Tests sind recht aufwendig und ohne entsprechende Tools kaum durchf hrbar aber genau diese sind eher selten vgl Liggesmeyer2002 S 170 Eine weitere statische Pr ftechnik die hier kurz vorgestellt werden soll ist die Kontrollflussanalyse Auch diese Technik ist eher f r den Modulte
155. tion 17x 1700 vgl Fewster1999 S 204 Der aktuelle Prozess kostet 10 000 im Jahr und deckt 70 der vorhandenen Fehler auf DDP Defect Detection Percentage In dieser Beispielrechnung sind 1000 Fehler in der Software enthalten Die Kosten diese Fehler zu beheben liegen in der Testphase bei 100 und nach dem Release bei 1000 Das Verh ltnis der Kosten zwischen der Testphase und der Nach Release Phase ist als durchaus realistisch anzusehen Der Wert f r das ROI variiert nach Anzahl der Fehler und der DDP Eine entsprechende Beispielrechnung f r die Einf hrung eines automatisierten Testprozesses kann folgenderma en aussehen manueller Test automatischer Test Kosten f r die Testfallerstellung 6 000 6 000 Toolkosten 5 000 Kosten Implementierung autom Tests 11 000 Gesamtkosten Automatisierung 16 000 Kosten f r einen Testzyklus 5 000 1 000 Anzahl der Zyklen pro Release 3 3 Testkosten pro Release 21 000 9 000 Einsparungen pro Release 12 000 Releases pro Jahr 4 4 Einsparungen pro Jahr 48 000 Gewinn Einsparungen Investition pro Jahr 32 000 ROI Einsparung Investition 200 vgl Fewster1999 S 205 Es wird deutlich dass die Einf hrung der Automatisierung zun chst Kosten verursacht Diese Kosten bestehen sowohl aus Softwarekosten f r die Tools als auch aus Implementierungskosten f r die automatisierten Test
156. ts und Klassentests gibt es gro e Unterschiede Bei prozeduralen Modulen wird Wert darauf gelegt die Schnittstellen zu testen und m glichst viele logische Verzweigungen abzudecken Mit der Gr e der Module steigt die Komplexit t der Ablauflogik und somit w chst auch die Anzahl der m glichen Pfade vom Eingang des Moduls bis zum Ausgang Oft werden diese Module so gro und die Schnittstellen so komplex dass ein angemessener Modultest gar nicht durchf hrbar ist vgl Sneed2002 S 159 160 Bei Klassentests sieht die Problematik anders aus Hier findet man eher kleine Schnittstellen und kleinere Methoden mit einer weniger komplexen Ablauflogik Allerdings finden viele Aufrufe fremder Methoden auch aus anderen Klassen statt Es gibt Abh ngigkeiten zwischen Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 16 den Klassen die auch durch Vererbung entstehen Somit wird es schwer die Klassen isoliert zu testen was aber eine Anforderung des Komponententests ist vgl Sneed2002 S 160 162 Probleme beim Testen von Klassen entstehen aus den eigentlichen Vorteilen der objektorientierten Programmierung Vererbung Polymorphie berladen von Parametern und Wiederverwendung fremder Klassen vgl Sneed2002 S 164 Zusammenfassend l sst sich sagen dass die H rden beim Modultest in der Komplexit t der Module liegen w hrend beim Klassentest die externen A
157. txt In diesem Beispiel also 362AZ_Container Nr txt 6 3 2 Vergleich mit Referenzdaten Nachdem f r alle dokumentierten Funktionen Referenzdaten im Altsystem erzeugt wurden sollen nun die Ausgaben des Neusystems anhand dieser Daten verifiziert werden Da zum Zeitpunkt der Entwicklung des Komparators das Neusystem noch nicht zur Verf gung stand wurden zum berpr fen der Tests die Referenzdaten mit den Ausgaben des Altsystems verglichen Es wurde also das Programm mit sich selbst berpr ft Dabei war zu erwarten dass keine Abweichungen auftreten Im n chsten Schritt wurden die Referenzdaten nachtr glich manipuliert um zu zeigen dass der Komparator diese Ver nderungen zuverl ssig aufdeckt Die Maskeninhalte des Altsystems werden mit der gleichen Funktion wie die Referenzdaten aufbereitet Der Vergleich ist einfach zu implementieren da nur 2 Strings zeichenweise miteinander verglichen werden m ssen Wichtig f r die Effizienz des Tests ist eine bersichtlich gestaltete Auswertung der Ergebnisse Am Ende eines Testdurchlaufs zeigt QuickTest Professional die Ergebnisse im Reporter an Den Status der einzelnen Testschritte Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 72 und die angezeigten Informationen k nnen auch per Quellcode gesetzt werden Dies ist dann notwendig wenn nicht die von QuickTest Professional bereit gestellten Checkpoints verw
158. uf der Abbildung ist der Keyword View zu sehen In diesem k nnen die einzelnen Testschritte per Mausklick erstellt werden und werden entsprechend grafisch dargestellt Dieser Modus richtet sich an die Anwender mit wenig Programmiererfahrung Im Expert View wird direkt mit VBScript gearbeitet In beiden Ansichten k nnen die gleichen Ergebnisse erzielt werden Welche bevorzugt wird h ngt von der Anwendung ab die getestet werden soll au erdem vom Erfahrungshorizont sowie den Pr ferenzen des Anwenders Dies ist das Skript zu der in 5 8 dargestellten Action Browser Book a Flight Mercury Page Book a Flight Mercury WebEdit passFirst0 Set hans Browser Book a Flight Mercury Page Book a Flight Mercury WebEdit passLast0 Set meier Browser Book a Flight Mercury Page Book a Flight Mercury WebList creditCard Select Diners Club Browser Book a Flight Mercury Page Book a Flight Mercury WebEdit creditnumber Set 12346578 Browser Book a Flight Mercury Page Book a Flight Mercury WebList cc_exp_dt_mn Select O1 Browser Book a Flight Mercury Page Book a Flight Mercury WebList cc_exp_dt_yr Select 2009 Browser Book a Flight Mercury Page Book a Flight Mercury Image buyFlights Click 5 4 2 Verifikation der Ergebnisse Bei der Testautomatisierung ist es nicht nur wichtig dass die Tests automatisch ausgef hrt werden es ist auch unerl sslich dass
159. un 06 01 2009 11 51 32 Description Open calender by clicking the link Expected Actual The calender is displayed Abbildung 5 6 HP Quality Center Test Lab manuelle Testausf hrung Es besteht auch die M glichkeit Test Sets aus manuellen und automatisierten Tests zu kombinieren So k nnen eventuell vorbereitende Schritte f r einen Test automatisiert werden Hierbei kann es sich z B um das Anlegen von bestimmten Datens tzen handeln Der eigentliche Test ben tigt diesen bestimmten Datensatz kann aber aus irgendwelchen Gr nden nicht automatisiert werden So wird dem Tester aber zumindest das Anlegen der Testdaten abgenommen Ein anderes Beispiel f r eine Kombination aus manuellem und automatisiertem Test w re das berpr fen eines Ausdrucks auf Papier Hier muss eine manuelle Pr fung erfolgen 5 2 6 Defects Im Defects Modul werden alle aufgedeckten Fehler der Software dokumentiert Die Fehler k nnen mit der Testausf hrung verlinkt werden in der er aufgetreten ist Da dieser Test Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 50 wiederum mit den entsprechenden Requirements verlinkt ist kann eine Auswertung dar ber gemacht werden welches Requirement aufgrund eines bestimmten Fehlers nicht erf llt wird Fehler k nnen au erdem mit anderen Fehlern mit Anforderungen oder Testf llen verlinkt werden BER aart rlslp als
160. unktionen durchgef hrt werden k nnen 7 MakeReference ohne Container Nr Reederei Nr at_Reederei Nr Kunden Nr F 1 0 tghu9507987 034 034 2 E IR DE EB 6 Er 8 EE 10 GEES ie a h Global A Login A Function E HH Data Table hActive Screen H Information Abbildung 6 4 QuickTest Professional Data Table Global Mit dieser Konfiguration wird jede Funktion die eine Containernummer ben tigt mit der Nummer tghu9507987 aufgerufen und jede Funktion die eine Reedereinummer als Schl ssel erwartet mit 034 Es gibt Funktionen die verschiedene Schl sseltypen akzeptieren Damit von der Funktion erkannt werden kann um welchen Typ es sich handelt werden diese manchmal mit Pr fixen versehen Dies ist hier an dem Schl ssel at_Reeederei Nr zu erkennen F r jeden Tupel aus Funktion und Schl sseltypen gibt es einen Eintrag im Datenblatt Function also auch einen Testfall pro Tupel Auf die Bedeutung der Spalte MakeReference wird im folgenden Kapitel eingegangen Das VBSkript muss nun wie folgt angepasst werden If DataTable enable dtLocalSheet 1 Then enable kennzeichnet ob dieser Testfall tats chlich ausgef hrt werden soll Coin Fenster in den Vordergrund bringen Window ExceedWindow Activate Cursor per Mausklick in das Funktionsfeld bringen Window ExceedWindow Click 173 498 Funktion ausf hren Window ExceedWindow Type DataTable Funktion dtLocalSheet
161. unterschiedliche betriebliche Projekte abgedruckt Wie zum Beispiel in Fewster1999 Auch in dieser Arbeit werden zwei recht unterschiedliche Projekte aus der Praxis bearbeitet Die grunds tzliche Aufgabenstellung dieser Arbeit bei Eurogate ITS ist die Analyse der aktuellen Projekte in Hinblick auf konkrete M glichkeiten der Unterst tzung von Softwaretests mit automatisierten Tests oder sogar eine vollst ndige Automatisierung Diese Arbeit entstand w hrend der im Juli 2008 neu eingerichtete Bereich Testmanagement seine Arbeit aufnahm Ziel dieses Bereiches ist es die bisher extern durchgef hrten Softwaretests im Hause selbst zu organisieren Zwei Projekte die auch in dieser Arbeit vorgestellt und behandelt werden haben hier die h chste Priorit t Bei dem einen Projekt handelt es sich um eine 1 1 Migration eines COBOL Programms das zum ersten Mal 1983 in Betrieb genommen wurde Dieses Programm soll durch eine Codekonvertierung auf ein moderneres COBOL gebracht werden und auf einem Oracle Datenbanksystem aufsetzen Die Zielsetzung des Tests ist zu zeigen ob das System nach der Konvertierung immer noch die gleichen Anforderungen erf llt Das zweite Projekt hat das weiter oben angesprochene TOPX zum Thema F r TOPX werden weiterhin Patches und Releases entwickelt die getestet werden m ssen Diese Tests werden von dem Bereich Testmanagement geleitet und weiterhin von dem externen Dienstleister unterst tzt der aber auf lange
162. ur Folge hat Um das zu erreichen m ssen die manuellen Tests so gut wie m glich durch eine Automatisierung ersetzt oder unterst tzt werden Als Vison kann man sicherlich einen vollst ndig automatisierten Regressionstest nennen der die Funktionsf higkeit s mtlicher Gesch ftsprozesse sicherstellt Dazu ist nicht nur eine Automatisierung der Abl ufe in TOPX notwendig sondern auch in COIN Es m ssen also Tests ausgef hrt werden die mindestens zwei Programme bedienen und auch noch mit zwei verschiedenen Automatisierungstools ausgef hrt werden m ssen Durch entsprechende Funktionalit ten im HP Quality Center ist diese Anforderung zumindest technisch durchf hrbar Leider ist hierf r ein nicht unerheblicher Implementierungsaufwand n tig Deshalb ist es sinnvoll zuerst zu analysieren welche Aufgaben mit weniger Aufwand automatisiert werden k nnen und trotzdem entscheidende Verbesserungen bewirken 7 3 Skizzierung einer m glichen Umsetzung Eine m gliche Aufgabe die mit automatischen Abl ufen erledigt werden kann ist die Testvorbereitung Hierbei handelt es sich um das Erzeugen von Testdaten und Testszenarien die Durchf hrung von Tests und die automatische berpr fung von Ausgaben der getesteten Software mit den erwarteten Ausgaben vgl Kap 3 Testautomatisierung F r die Einf hrung von automatischen Tests ist es sinnvoll mit einem kleinen Projekt zu beginnen um Erfahrungen zu sammeln Leider gibt es bei Eurogate ITS kein kl
163. von Screenshots Es gibt unterschiedliche M glichkeiten die Skripte robust zu machen Das hei t dass die Skripte nicht durch unrelevante Abweichungen einen Fehlerzustand melden Wenn bei einem Test eines FTP Clients die Netzwerkverbindung etwas langsam ist und in einem Fenster nicht sofort alle erwarteten Dateien angezeigt werden k nnte dies dazu f hren dass ein Fehlerzustand gemeldet wird obwohl wenige Sekunden sp ter vielleicht alle Dateien ordnungsgem angezeigt werden Hier hat man die M glichkeit ein WaitFor Statement in Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science 62 das Skript einzubauen Dieses Statement kann verwendet werden um darauf zu warten dass eine bestimmte Anzahl an Elementen in einer Liste angezeigt werden in diesem Beispiel also die Anzahl der Dateien in der Browserliste Ein weiteres Problem f r die Robustheit eines Skriptes k nnen Anzeigen mit dem aktuellem Datum oder der Uhrzeit sein da diese garantiert von der Anzeige bei der Erstellung des Skriptes abweichen werden Im Skript k nnen solche Pr fungen mit Hilfe von Wildcards also oder Ir verbessert werden 5 6 3 Zusammenfassung Zum Testen von Anwendungen die auf dem QT Toolkit von Trolltech basieren scheint Squish die erste Wahl zu sein Das bedeutet auf der anderen Seite nat rlich dass man mit Squish nur QT Anwendungen testen kann Es gibt von Squi

Download Pdf Manuals

image

Related Search

Related Contents

2003年3月発行 (PDF/544KB) - JICA Research Institute  Todo lo que tienes que saber para empezar.    MANUAL DE INSTRUCCIONES    D-Link DWA-160 User Manual  Jabra GN5025  Leisure Season PBS4224 Use and Care Manual  here  Avaya one-X Deskphone H.323 9608 and 9611G User Guide  

Copyright © All rights reserved.
Failed to retrieve file