Browse Prior Art Database

Pfadklassen-Testfallgenerierung durch symbolische Interpreter

IP.com Disclosure Number: IPCOM000127898D
Original Publication Date: 2005-Oct-10
Included in the Prior Art Database: 2005-Oct-10
Document File: 3 page(s) / 73K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Die Tests der Softwareentwicklung koennen in drei wesentliche Phasen eingeteilt werden: In den Modultest, den Integrationstest und den Systemtest. Bei der Testfallsuche soll in jeder Phase ein anderer Fokus im Vordergrund stehen. Alle Phasen haben das grundlegende Problem gemein, die passenden Testfaelle zu finden. So wird beim Systemtest die Sicht des Anwenders, beim Integrationstest der Fokus auf den Datenfluss zwischen den Modulen und beim Modultest die Kenntnis der Implementierung zu Grunde gelegt. Mit Kenntnis der Implementierung ist hier u.a. das Wissen ueber Datenstrukturen und die einzelnen Codezeilen zu verstehen. Diese Kenntnis wird auch als „White-Box“-Sicht bezeichnet, im Gegensatz zur „Black-Box“-Sicht, die die reine Aussensicht kennzeichnet, d.h. ohne Kenntnis der Internas. Um mit diesen Kenntnissen die passenden Modultest-Testfaelle zu finden, bestehen verschiedene Verfahren (z.B. Pfadanalyse, Boundary-Check, Coverage-Analyse). Alle Verfahren weisen jedoch einige wesentliche Probleme auf: 1. Es ist ein enormer Aufwand noetig, um die entsprechenden Funktionen manuell vollstaendig zu analysieren und passende Testfaelle zu formulieren. 2. Durch die teilweise sehr monotonen Arbeitsschritte erfordert es eine hohe Disziplin, um die Analyse nicht nur vollstaendig, sondern auch fehlerfrei zu erarbeiten. 3. Ausser fuer die Coverage-Analyse gibt es keine automatisierten Loesungen/Tools dafuer, denn die Analyse der Quelltexte ist sehr aufwaendig zu implementieren und die Informationen, die aus einem einzelnen Quelltext herauszulesen ist, sind nicht vollstaendig. Es fehlt die Lokalitaet. Es werden haeufig viele bis alle Quelltexte eines Softwareprojektes benoetigt, um alle Datentypen und Strukturen zu kennen. 4. Eine reine statische Analyse kann keine vollstaendige Loesung finden. So sind beispielsweise die Abbruchkriterien fuer Schleifen nicht immer ermittelbar und somit ist es nicht moeglich, hier eine vollstaendige Loesung anzugeben.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 3

S

Pfadklassen-Testfallgenerierung durch symbolische Interpreter

Idee: Michael Denzlein, DE-Fuerth; Thomas Grzenkowski, DE-Fuerth

Die Tests der Softwareentwicklung koennen in drei wesentliche Phasen eingeteilt werden: In den Modultest, den Integrationstest und den Systemtest. Bei der Testfallsuche soll in jeder Phase ein anderer Fokus im Vordergrund stehen. Alle Phasen haben das grundlegende Problem gemein, die passenden Testfaelle zu finden. So wird beim Systemtest die Sicht des Anwenders, beim Integrationstest der Fokus auf den Datenfluss zwischen den Modulen und beim Modultest die Kenntnis der Implementierung zu Grunde gelegt. Mit Kenntnis der Implementierung ist hier u.a. das Wissen ueber Datenstrukturen und die einzelnen Codezeilen zu verstehen. Diese Kenntnis wird auch als "White-Box"-Sicht bezeichnet, im Gegensatz zur "Black-Box"-Sicht, die die reine Aussensicht kennzeichnet, d.h. ohne Kenntnis der Internas. Um mit diesen Kenntnissen die passenden Modultest- Testfaelle zu finden, bestehen verschiedene Verfahren (z.B. Pfadanalyse, Boundary-Check, Coverage-Analyse).

Alle Verfahren weisen jedoch einige wesentliche Probleme auf:

1. Es ist ein enormer Aufwand noetig, um die entsprechenden Funktionen manuell vollstaendig zu analysieren und passende Testfaelle zu formulieren.

2. Durch die teilweise sehr monotonen Arbeitsschritte erfordert es eine hohe Disziplin, um die Analyse nicht nur vollstaendig, sondern auch fehlerfrei zu erarbeiten.

3. Ausser fuer die Coverage-Analyse gibt es keine automatisierten Loesungen/Tools dafuer, denn die Analyse der Quelltexte ist sehr aufwaendig zu implementieren und die Informationen, die aus einem einzelnen Quelltext herauszulesen ist, sind nicht vollstaendig. Es fehlt die Lokalitaet. Es werden haeufig viele bis alle Quelltexte eines Softwareprojektes benoetigt, um alle Datentypen und Strukturen zu kennen.

4. Eine reine statische Analyse kann keine vollstaendige Loesung finden. So sind beispielsweise die Abbruchkriterien fuer Schleifen nicht immer ermittelbar und somit ist es nicht moeglich, hier eine vollstaendige Loesung anzugeben.

Fuer die Loesung der genannten Probleme sind zwei wesentliche Schritte (A und B) noetig:

(A) Es wird nicht der Quelltext direkt analysiert, sondern das durch einen Compiler erzeugte Ergebnis (Maschinencode oder Pseudomaschinencode).

Um aus lesbarem Quelltext den auf einem konkreten Prozessor ablauffaehigen Maschinencode zu erzeugen, gibt es zwei Moeglichkeiten: Entweder wird aus dem Quelltext direkt Maschinencode erzeugt oder Pseudomaschinencode fuer einen abstrakten Prozessor. Der Pseudomaschinecode wird dann erst kurz vor der Ausfuehrung in den eigentlichen Maschinencode des eingesetzten Prozessors uebersetzt. Alternativ kann der Pseudomaschinencode auch interpretiert werden. Aufgrund des zusaetzlichen Schrittes wird zwar auf der Zielplattfom eine sogenannte Runtime noetig, aber man ist dafuer plattformunabhaengig (unabhaengig vom eingesetzten Prozessor und Betriebs...