Letzte Änderung: 27. April 2006 M. Winter
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] [Folien]
ANECON GmbH, Wien, Universities of Regensburg and Passau
tbd
[Kurzpapier] [Folien]
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] [Folien]
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:
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:
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] [Folien]
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] [Folien]
(1) Dresdner Bank AG, (2) SQS AG
Tbd
[Kurzpapier] [Folien]
Dierk Engelhardt, Tilo Linz
Imbus AG, Möhrendorf
TBD
[Kurzpapier] [Folien]
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
[Kurzpapier] [Folien]
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.:
tbd
Der Arbeitskreis Testmanagement wurde im März 1995 gegründet und dient in erster Linie dem Erfahrungsaustausch der Teilnehmer über folgende Themenbereiche:
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.
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@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 )
http://www.systematic-testing.de/tav
Tagungsort und Unterbringung
Anmeldung bitte bis 15. April
2006 per Web-Formular
Hotels
Siehe Bad Honnef
tbd
Mitte Februar 2007
Themenvorschläge werden wie immer auf dem kommenden Treffen gesammelt.
|
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. |