24. Treffen der GI-FG TAV - Test, Analyse und Verifikation von Software

am 4. und 5. Mai 2006 in Bad Honnef
Themen und Informationen

Letzte Änderung: 27. April 2006 M. Winter

 

Warum stürzt mein Programm ab? Automatisches Bestimmen von Fehlerursachen

Andreas Zeller
Lehrstuhl für Softwaretechnik an der Universität des Saarlandes, Saarbrücken

Jeder Programmierer kennt die Situation: Ein Programm läuft nicht so, wie es soll. Um den Fehler zu beheben, muss man zunächst die Fehlerursachen eingrenzen. Diese Fehlersuche ist nach wie vor eine händische Tätigkeit, abhängig von der Intuition und der Hartnäckigkeit des Programmierers.

In diesem Vortrag stelle ich Techniken vor, die die Fehlersuche weitgehend automatisieren. Basierend auf einem automatischen Test lassen sich externe Fehlerursachen wie Eingaben, Code-Unterschiede oder Threads automatisch isolieren und vereinfachen. Weiter fortgeschrittene Techniken bestimmen sogar vollautomatisch die Ursache-Wirkungs-Kette des Fehlers: "Erst hatte Variable v_1 den Wert x_1, deswegen wurde v_2 zu x_2, also wurde v_3 zu x_3 ... und deshalb kam es zum Fehler." Fallstudien an echten Programmen mit echten Fehlern, von Mozilla bis zum GNU-Compiler, demonstrieren die Praxistauglichkeit der vorgestellten Verfahren. Wer es selbst ausprobieren möchte: Unsere Plug-Ins für Eclipse bieten automatische Fehlersuche für jedermann.

Andreas Zeller ist Professor für Softwaretechnik an der Universität des Saarlandes, Saarbrücken. Sein Buch "Why Programs Fail - A Guide to Systematic Debugging" ist im Oktober 2005 bei Morgan Kaufmann und dpunkt.verlag erschienen.

[Kurzpapier]

 

Reengineering for Testability

Harry Sneed
ANECON GmbH, Wien, Universities of Regensburg and Passau

tbd

[Kurzpapier]

 

Dynamische Deadlock-Suche in nebenläufigen funktionalen Programmen

Frank Huch
Institut für Informatik, Universität Kiel

Nebenläufige Systemen k¨onnen neue, bei sequentiellen Systemen nicht auftretende Fehler enthalten, wie z.B. Deadlocks, Lifelocks oder die Nichteinhaltung von wechselseitigem Ausschluss. Im Gegensatz zu klassischen Fehlern sequentieller Programme hängen diese Fehler vom Prozess-Scheduling ab und treten möglicherweise nur in bestimmten Systemläufen auf.

Zum Finden von Fehlern werden in der Regel Debugger verwendet, welche den Programmablauf visualisieren und so ein besseres Verständnis der Fehlersituation ermöglichen sollen. Wir haben einen Debugger f¨ur Concurrent Haskell (eine nebenl¨aufige Erweiterung der Programmiersprache Haskell) entwickelt. Dieser ermöglicht es nebenläufige Haskell-Programme auszuführen und manuell unterschiedliche Prozess-Schedules auf Fehler zu überprüfen. Ein Nachteil dieses Ansatzes ist, dass sich ein System beispielsweise kurz vor eine Deadlock befinden kann, der Benutzer aber ein falsches Scheduling wählt und so den Programmfehler nicht findet.

Unsere Lösung für dieses Problem ist ein Debugger, der (alle) möglichen Schedules bis zu einer vorgegebenen Tiefe simuliert und im Fehlerfall den Benutzer in den Fehler leiten kann. Im Concurrent Haskell Debugger wird das nebenläufige System im Hintergrund ausgeführt und zusätzlich visualisiert. Zur Implementierung der Deadlock-Suche müssen wir es ermöglichen, dass durchgeführte Concurrent Haskell Aktionen rückgängig gemacht werden und so ein alter Systemzustand wieder hergestellt wird. Somit können wir das Durchsuchen der Folgezustände mittels Backtracking implementieren und Deadlocks automatisch finden.

[Kurzpapier]

 

Werkzeugunterstütztes Architektur- und Qualitätsmonitoring - Ansätze und praktische Erfahrungen

Walter Bischofberger
Software-Tomography GmbH, Dammstrasse 19, 6301 Zug
Tel. +41 (0)41 711 77 72
wb@software-tomography.com

Durch Quelltextanalyse lassen sich heute eine Vielzahl von Qualitätsaspekten prüfen, wie z.B. die Übereinstimmung von Quelltext und Architektur, das Einhalten von Komponentenschnittstellen, das Vorkommen von Code-Duplikaten oder die handwerkliche Qualität des Quelltexts. High-end Quelltextanalysewerkzeuge liefern Analyseergebnisse auf verschiedenen Abstraktionsebenen, so dass Manager, Architekten und Entwickler sowohl bei in-house Entwicklung als auch in Outsourcing-Szenarien mit kleinem Zeitaufwand Zugriff auf die für sie relevanten Informationen haben. Dieser Beitrag fokussiert, basierend auf etlichen Jahren praktischer Erfahrung mit dem Sotographen, auf zwei Aspekte des Architektur- und Qualitätsmonitorings:

  • Was soll gemessen werden?
  • Wie werden die gewonnen Informationen aggregiert, präsentiert und im Entwicklungsprozess verwendet?

Bezüglich der Frage nach der Art der zu messenden Aspekte und der Interpretation der Messresultate können in der Praxis hauptsächlich zwei Ansätze beobachtet werden:

  • Der statistische Ansatz konzentriert sich darauf, die Qualität eines Softwaresystem, z.B. bezüglich Wartbarkeit und Effizienz, zu bewerten. Dabei ist es häufig auch ein Ziel die Qualität verschiedener Softwaresystem vergleichbar zu machen. Diese Ansätze basieren typischerweise auf der relativen Häufigkeit des Überschreitens von Grenzwerten und auf der Aggregation der Messwerte basierend auf hierarchischen Qualitätsmodellen.
  • Der regelbasierte Ansatz versucht die Qualität eines Softwaresystems zu verbessern in dem zentrale Regeln auf Architektur, Design- und Implementationsebene überwacht und Verletzungen frühstmöglich behoben werden.

Bei der Präsentation von automatisch gesammelten Qualitätsinformationen geht es darum unterschiedliche Kundengruppen zu bedienen. Ein kontinuierliches Monitoring muss mit minimalem wöchentlichen Aufwand möglich sein, da es sonst im Wust "dringendenderer" Aufgaben untergeht. Für detaillierte Qualitätsanalysen werden hingegen möglichst viele Informationen benötigt, die dann möglichst effizient gefiltert und im Kontext verschiedenster Informationen interpretiert werden sollen. Die in beiden Fällen gewonnenen Informationen müssen dann je nach Kundengruppe (Manager, Architekten und Entwickler) unterschiedlich aufbereitet werden.

[Kurzpapier]

 

Automatische Erzeugung von Testfällen

Herbert Kuchen
Universität Münster

Beim Glass-Box-Testen ist es nicht einfach, eine systematische Überdeckung des zu testenden Codes durch Testfälle zu erreichen. Wir stellen ein Werkzeug vor, das dem Benutzer diese Aufgabe abnimmt. Basierend auf einer symbolischen Java Virtual Machine wird der Code systematisch durchlaufen. Beim Durchlaufen von Verzweigungen ergibt sich hierbei ein System von Constraints. Aus einer Lösung dieses Systems kann ein Repräsentant einer Klasse von Testfällen mit äquivalentem Kontrollfluss generiert werden. Die Respräsentanten sind minimal bezogen auf die Größe der Testeingaben.

[Kurzpapier]

 

Standardisierung der technischen Qualitätssicherung im J2EE-Umfeld der Dresdner Bank

Michael Meurer (1), Daniel Simon (2)
(1) Dresdner Bank AG, (2) SQS AG

Tbd

[Kurzpapier]

 

TestBench meets TestFrame®: State of the Art Testdesign

Dierk Engelhardt, Tilo Linz
Imbus AG, Möhrendorf

TBD

[Folien]

 

TestBench meets TestFrame®: State of the Art Testautomation

Anton Schlatter
LogicaCMG
Main Airport Center (MAC)
Unterschweinstiege 10
D-60549 Frankfurt am Main
T: +49 (0)69 26499-0
www.logicacmg.com/de

TBD

[Folien]

 

TAV-Arbeitskreis: Test Objektorientierter Programme (TOOP)

Das Ziel des seit Oktober 1995 bestehenden Arbeitskreises ist der Erfahrungsaustausch über Probleme und Lösungen beim Test (und Review) von objektorientierter und komponentbasierter Software in Industrie und Forschung.

Themenschwerpunkte im Arbeitskreis sind u.a.:

  • Testbarkeit, Entwurf für Testbarkeit
  • Reviews
  • Test von Bibliotheken, Frameworks, Multi-Plattform Applikationen (CORBA...)
  • Techniken für den Integrationstest von OO-Software
  • Testmetriken und Testwerkzeuge
  • OO-Testplan mit Methoden- und Werkzeugempfehlungen

tbd

 

TAV-Arbeitskreis: Testmanagement

Der Arbeitskreis Testmanagement wurde im März 1995 gegründet und dient in erster Linie dem Erfahrungsaustausch der Teilnehmer über folgende Themenbereiche:

  • Organisation von Testprozessen
  • Methodische Unterstützung
  • Einbettung in allgemeine QS-Aufgaben
  • Rollen und Aufgaben im Testprozess
  • Abgrenzung des Begriffs Testmanagement

Weitere Informationen zum Arbeitskreis Testmanagement finden Sie unter: www.caseconsult.com/tavtm

Alle Interessenten sind herzlich eingeladen, in unsere Diskussion einzusteigen. Eine Anmeldung zur Teilnahme an der Arbeitskreissitzung ist nicht erforderlich.

 

TAV-Arbeitskreis: Berufsbilder und Ausbildung im QS-Bereich

Das Ziel des Arbeitskreises "Berufsbild Software-Tester" ist es, eine einheitliche und für alle Beteiligten nachvollziehbare Ausbildung für den Software-Tester zu unterstützen, um die Qualität der Qualifikation sicherzustellen und damit auch insgesamt die Qualität der Software-Entwicklung zu verbessern.

Zur Zeit hat der AK  7 Kernmitglieder und weitere Interessierte. Ein Positionspapier  "Empfehlungen für das Berufsbild, die Ausbildung und die Qualifikationsstufen des Software- Tester" ist in den letzten Monaten erarbeitet worden und im Nov. 2004 in Petrasch, R. (Hrsg.): Schriften zum Software-Qualitätsmanagement. Analytische und konstruktive Qualitätssicherung in Theorie und Praxis. Reihe: Software-Qualitätsmanagement: Theorie & Praxis (herausgegeben von R. Petrasch), Band 3. Logos Verlag Berlin" erschienen.

Mitglieder des Arbeitskreises arbeiten aktiv bzw. gestalten eine einheitliche Zertifizierung von QM-Personal im Testbereich im nationalen und  europäischen bzw. internationalen Rahmen mit.  Entsprechende Seminare werden dazu von bekannten Trainingsanbietern angeboten den (siehe z.B. das Infoportal der IMBUS AG, die IMBUS-Seminarangebote und die SQS - Seminare).

Auch im Rahmen der TAV 22 wird die Möglichkeit angeboten (siehe Zeitplan) die Prüfung zum Certified Tester zu absolvieren.

Sprecher des Arbeitskreises ist Horst Pohlmann ( Horst.Pohlmann(at)german-testing-board.info ). Die HomePage des Arbeitskreises ist aktuell unter der folgenden URL erreichbar: www.softwarequality.de/Projects/GI/Tester/tester.html 

(Gespiegelt auf dem GI-Web-Server unter http://giserver.gi-ev.de/fachbereiche/softwaretechnik/tav/bb/st/index.htm )

 

Anmeldung und weitere Informationen zum Treffen

Tagungsort und Unterbringung

Physikzentrum Bad Honnef

Anmeldung bitte bis 15. April 2006 per Web-Formular

 

Hotels

Siehe Bad Honnef

 

Nächstes Treffen

tbd

Mitte Februar 2007

Themenvorschläge werden wie immer auf dem kommenden Treffen gesammelt.

 

Abendveranstaltung

Das "Social Event" findet ab 18:00 Uhr im Physikzentrum als Buffett statt.

Ab 20:00 Uhr ist Gelegenheit, einige Werkzeuge in der Tool-Demo anzusehen.