Die Einordnung des Automatiktests in den gesamten Komplex des Softwaretests und dessen Gebrauch im CTB-Projekt inklusive der aktuellen Problematik

Transkript

1 / 18 Seminarvortrag im Studiengang Scientific Programming von Martin Noy am Die Einordnung des Automatiktests in den gesamten Komplex des Softwaretests und dessen Gebrauch im CTB-Projekt inklusive der aktuellen Problematik

2 Inhaltsübersicht 2 / 18 Einleitung Das Unternehmen INFORM GmbH Das CTB-Projekt Softwaretest Der Automatiktest Eigenschaften Im CTB-Projekt Testframework ivalidator Die Problemdarstellung Problembeschreibung Die Problemlösung Lösungsansatz weiteres Vorgehen

3 Einleitung Das Unternehmen INFORM GmbH 3 / 18 Das Unternehmen INFORM GmbH: mittelständisches Software-Unternehmen in Aachen 1969 gegründet spezialisiert auf Software mit intelligenter Optimierungslogik zur Produktivitätssteigerung zu den Kunden zählen unter anderem: Flughäfen Containerterminals die Industrie Finanzwesen

4 Einleitung Das CTB-Projekt 4 / 18 Das CTB-Projekt: CTB Containerterminal Burchardkai größte Anlage für Containerumschläge im Hamburger Seehafen TERMINALSTAR zur Steuerung und Optimierung von Geschäftsprozessen in maritimen Terminals zum Beispiel der Transport von Containern vom LKW auf das Schiff 24/7 Software Entwicklungszeit von über 100-Mannjahren

5 Einleitung Das CTB-Projekt 5 / 18 Einleitung Der Automatiktest Die Problemdarstellung Die Problemlösung

6 Einleitung Das CTB-Projekt Die Anforderungen des CTB: 6 / 18 fortlaufende Weiterentwicklung der Software mit regelmäßigen Lieferungen ständige Lieferbereitschaft schnelle Reaktionszeit bei Problemen Der Softwareentwicklungsprozess: Entwicklungsphase Testphase agile Projektdurchführung iterative Vorgehensweise

7 Einleitung Softwaretest Komponententest: Test von einzelnen Softwarekomponenten Ein/Ausgabe-Test Integrationstest: Test des Zusammenspiels der Softwarekomponenten Überprüfung der Schnittstellen Im CTB-Projekt abgedeckt durch: Entwicklertest Automatiktest vom Automatiktestteam 7 / 18 Systemtest: Test des komplett integrierten Systems Überprüfung aus der Sicht des Kunden Abnahmetest: durch den Kunden durchgeführt manueller Test durch Systemtester Kundentest

8 Der Automatiktest Eigenschaften 8 / 18 Eigenschaften: Softwareframework automatisierte Testsequenzen aus manuellen Tests läuft regelmäßig ständige Überprüfung der Software Test aller Schnittstellen Fehler leicht reproduzierbar bietet die Möglichkeit für einen Lasttest

9 Der Automatiktest Im CTB-Projekt 9 / 18 Der CTB-Automatiktests: im Anschluss an den nächtlichen Bau der Software von allen Zweigen bis zur produktiven Version läuft für alle gebauten Zweige dient zur Sicherstellung der ständigen Lieferbereitschaft besteht aus etwa 1000 automatisierten Tests verwendet das Java-basierte Testframework ivalidator

10 Der Automatiktest ivalidator Framework 10 / 18 Das ivalidator Framework: Java Library Testablaufbeschreibung über XML-Dateien testsuite.xml TestUnits sind in Java implementiert Variablenerstellung Parameter, statisch über XML-Dateien Daten, zur Laufzeit in den Kontext

11 testsuite.xml Der Automatiktest ivalidator Framework test parameter/s flow alias import 11 / 18 Addi.xml

12 Der Automatiktest ivalidator Framework 12 / 18 Java-Methoden: Kontext Addi.xml

13 Die Problemdarstellung Problembeschreibung 13 / 18 Neue Test XML-Datei: wiederverwenden einer definierten Methode keine Kenntnis über die benötigten Parameter und Daten gleiche Problematik bei Umkonfiguration der Testabläufe Problembeschreibung: Abhängigkeiten zwischen einzelnen Java-Methoden auf Grund der Kontext-Daten sind nicht erkennbar sind niemandem bekannt führen bei Missachtung zu schwer nachvollziehbaren Fehlern sind manuell mit absehbaren Aufwand nicht herausfindbar Try and Error nicht praktikabel

14 Die Problemlösung - Lösungsansatz 14 / 18 Systematisches Erfassen und Dokumentieren der Abhängigkeiten: Parameterdateien werden zur Laufzeit gespeichert (Instrumentierung) die verwendeten Parameter und Daten jeder aufgerufenen Methode werden in drei Gruppen eingeteilt: Parameter durch XML-Datei erstellt Daten aus dem Kontext gelesen Daten in den Kontext geschrieben 12:09: createzahl2() DATA_OUT_VALUES: { zahl_2=8 } 12:09: addition() PARAMETER_VALUES: { zahl_1=5 } DATA_IN_VALUES: { zahl_2=8 }

15 Die Problemlösung - Lösungsansatz Analyse der Testabhängigkeiten: 15 / 18 zur Analyse muss man die ca Methodenaufrufe in drei Gruppen gliedern Methoden, die ausschließlich Daten in den Kontext schreiben oder gar nicht mit dem Kontext interagieren Methoden, welche sowohl Daten in den Kontext schreiben als auch auslesen Methoden, die lediglich Daten aus dem Kontext auslesen Auszug aus der Baumstruktur:

16 Die Problemlösung Weiteres Vorgehen 16 / 18 Ziel: Die Möglichkeit bieten, dass keine explizite Beachtung der Kontext-Daten mehr nötig ist die Erstellung der Beschreibungen übersichtlicher ist Angedachter Lösungsweg: die gewonnenen Abhängigkeiten zur Erstellung einer DSL nutzen bestehende XML-Beschreibungen müssen in DSL-Beschreibungen umgewandelt werden können eine DSL-Beschreibung muss in eine XML-Beschreibungen für den ivalidator umgewandelt werden können aus der endgültigen Lösung des Problems könnte eine Bachelorarbeit bestehen

17 Literatur (Auszug) 17 / 18 ivalidator Tutorial Version: HHLA-Homepage Version: Inform-Homepage Version: Software automatisch testen E. Dustin, J. Rashka und J. Paul 2001 Springer-Verlag GmbH und Co Der Systemtest H. M. Snedd, M. Baumgartner, R. Seidl 2009 Carl Hanser Verlag München Basiswissen Softwaretest A. Spillner, T. Linz 2005 dpunkt.verlag GmbH

18 / 18 Vielen Dank für Ihre Aufmerksamkeit! Bestehen noch Fragen?