Systematisches Testen von Software - Software

Systematisches Testen von Software
Gliederung
I Motivation
- Vorstellung
- Begriffseingrenzung
- Der Vorgang des Testens
II Testmethodik
-
Whitebox-und Blackbox- Tests
Funktions- und Modultests
GUI- und Capture-Replay-Testtools
Testsprachen
Modellbasierte Tests
III Testorganisation
- Testplanung
- Testdurchführung
- Testdokumentation
1.7.2003
ViSEK-Forum
Seite 2 / 66
SVT – Synthese, Validierung und Test
bei Fraunhofer FIRST
Thema: Softwarequalität und Qualitätssoftware
• Spezifikationsbasierte Testerzeugung und
Testdurchführung
• Korrektheitsanalyse eingebetteter Systeme
• Generative Softwareproduktion mit
Compilertechnologien
1.7.2003
ViSEK-Forum
Seite 3 / 66
Projekte
• Quasar – Qualitätssicherung und
Anforderungsanalyse
- Automatische Testfallerzeugung aus UML-StateCharts
• Sicherheitszertifizierung in der Bahntechnik
- Test eines fehlertoleranten Stellwerkscomputers für das
ETCS durch softwareinduzierte Fehlerinjektion
• TTCN3-basiertes Lasttestsystem
- Testadapter für GSM, GPRS und SS7 Einheiten im gesamten
Netz eines europäischen Mobilfunkunternehmens
• Qualitätssicherung eines großen
Informationssystems
- GUI-Tests, Massentestdatenerzeugung und Prozessanalyse
für eine Sachbearbeitungs-Datenbank
1.7.2003
ViSEK-Forum
Seite 4 / 66
Unsere Leistungen für Sie
• Qualitätssicherung von Software und
Systemen
• Modellierung, Simulation und Validierung
von Entwürfen und Lösungen
• Implementierung, Analyse und Test
maßgeschneiderter sicherer Komponenten
• Entwicklung, Anpassung und Integration
von Softwarewerkzeugen
• Seminare und Schulungen über neue
Softwareentwicklungsmethoden
1.7.2003
ViSEK-Forum
Seite 5 / 66
I Motivation
Software-Erstellungskosten
Sicherheit
Formale Methoden
Softwarekrise
Kundenmehrwert
Modellbasierung
1.7.2003
ViSEK-Forum
Seite 6 / 66
1.7.2003
ViSEK-Forum
Seite 7 / 66
anderes Beispiel: Automobil
40-80 eingebettete Steuergeräte („Software auf Rädern“)
80 K Lines of Code für einen Airbag
Rückrufaktionen mit Millionenkosten (2002: 127 Rückrufaktionen in
Deutschland, davon ca. 15% Softwarefehler; Tendenz steigend)
1.7.2003
ViSEK-Forum
Seite 8 / 66
NIST Studie zu den Kosten von Softwarefehlern (Juni 2002)
WASHINGTON -- Software bugs are costing the
U.S. economy an estimated $59.5 billion each
year, with more than half of the cost borne by
end users and the remainder by developers and
vendors, according to a new federal study.
Improvements in testing could reduce this cost
by about a third, or $22.5 billion, but it won't
eliminate all software errors, the study said. Of
the total $59.5 billion cost, users incurred 64%
of the cost and developers 36%.
1.7.2003
ViSEK-Forum
Seite 9 / 66
Kosten der QS bei der Systementwicklung
regulär
Installation
10%
sicherheitskritisch
Definition
10%
Entwurf
10%
Test
40%
Implementierung
30%
Installation
5%
Definition
Entwurf
5% 5%
Implementierung
10%
Test
75%
1.7.2003
ViSEK-Forum
Seite 10 / 66
Begriffseingrenzung
Experimentieren = Ausführen einzelner Versuche zur
Erlangung einer neuen Erkenntnis
Probieren = experimentelles Feststellen der
Qualität eines Objekts
Testen = systematisches Probieren
nach verschiedenen Qualitätskriterien
Prüfen = Testen einer Serie gleichartiger Objekte
1.7.2003
ViSEK-Forum
Seite 11 / 66
Abgrenzung
Validation:
Verifikation:
Ist es die richtige Software?
Die Software ist richtig!
Test:
Ist die Software richtig?
Debugging:
Warum ist die Software
nicht richtig?
1.7.2003
ViSEK-Forum
Seite 12 / 66
Testziel
Qualität = Übereinstimmung mit den Anforderungen
z.B.: Funktionalität, Zweckdienlichkeit,
Robustheit, Zuverlässigkeit, Sicherheit,
Effizienz, Benutzbarkeit, Geschwindigkeit, ...
Î verschiedene Testmethoden
Î Formulierung von überprüfbaren Anforderungen
1.7.2003
ViSEK-Forum
Seite 13 / 66
Quantifizierung der Anforderungen
- nicht: „akzeptable Antwortzeiten sind wichtig“
- sondern: „Antwortzeit höchstens 5 Sekunden,
in 80% der Fälle kleiner als 3 Sekunden“
Kategorisierung der Anforderungen
- (unerläßlich / wichtig / erwünscht / irrelevant /
unerwünscht)
1.7.2003
ViSEK-Forum
Seite 14 / 66
Notwendigkeit der Formalisierung
Natürliche Sprache ist mehrdeutig!
Beispiel:
„alle 30 Sekunden sollen die Werte der
Sensoren abgelesen werden; wenn die
Standardabweichung 0,25 überschreitet,
soll die Normalisierungsprozedur
ausgeführt werden, anschließend sollen
die Werte an das Analysepaket
weitergegeben werden.“
Akzeptanztest ergibt falsche Analysewerte.
Problem: Komma!
1.7.2003
ViSEK-Forum
Seite 15 / 66
Formale Anforderungsdefinition
(a) Festlegung der Schnittstellen und Ereignisse
(b) Festlegung des reaktiven Verhaltens
(a)
Methoden:
get_data (...)
calc_dev(...)
normalize (...)
set_timer (...)
data_sampling
(b)
data_ackquisition
data from
data_ackquis
start_sig
from timer
x:=calc_dev(data)
j
Signale:
get_data (data)
data: ...
deviation: ...
start_sig: ...
data to
data_sampling
data to
data_analysis
data to
data_analysis
data_ackquisition
data_sampling
data_sampling
normalize(data)
x>0,25
n
1.7.2003
ViSEK-Forum
Seite 16 / 66
Deklarative statt operationaler Beschreibungsformen
(was statt wie)
Alle Werte sollen normalisiert analysiert werden.
Logische Spezifikation der gewünschten Eigenschaften
(formale Grundlage)
For all x exists y: y=normalize(x) and sometime analyzed(y)
Æ Spezifikationsbasierte Tests
1.7.2003
ViSEK-Forum
Seite 17 / 66
Der Vorgang des Testens
• warum
• wer
• wozu
• wie
• was
1.7.2003
ViSEK-Forum
Seite 18 / 66
Warum?
Mangelnde Qualität kostet Geld:
•Benutzerakzeptanz, Kundenverlust
•Fehlerkorrektur- und Folgekosten
•Gewährleistung, Produkthaftung
•Sicherheitsprobleme
1.7.2003
ViSEK-Forum
Seite 19 / 66
Wer?
Interne oder externe Tester
„Bugs“ schleichen sich nicht ein, sie werden gemacht
Niemand kennt das Produkt so genau wie der Entwickler
Motivation des Entwicklers: Debugging und Verifikation
Motivation des Testers:
Fehler identifizieren
1.7.2003
ViSEK-Forum
Seite 20 / 66
Wozu?
Fehlervermeidung statt Fehlererkennung!
Individualverantwortlichkeit
Teamverantwortung
• Diskriminierungen
• Kooperation
• Schuldzuweisungen
• Qualitätsbewußtsein
• verminderte Produktivität
• Produktverbesserung
1.7.2003
ViSEK-Forum
Seite 21 / 66
Globale Fehlerrückverfolgung
Explosion durch Sprengung, weil
Schräglage durch Ruder, weil
vermeintliche Fehlbahn, weil
falsche Lagedaten, weil
Sensorausfall, weil
Übertragungsfehler, weil
Zahlbereichsüberlauf, weil
undokumentierte Anforderung, weil
ungetestetes Ariane4-Bauteil, weil
Termin- und Kostendruck
Handlungsempfehlungen:
...
Fehlerkorrekturmaßnahmen,
klare Aufgabenverteilung,
Software-Redundanz,
Leistungsbedarfsermittlung,
Ausnahmebehandlung,
formale Dokumentation,
vollständige Integrationstests,
QS-getriebene Entwicklung
1.7.2003
ViSEK-Forum
Seite 22 / 66
Wie?
• Konzentration auf Benutzersicht
(Relevante Testfälle, Benutzbarkeitsprobleme)
• Systematische Vorgehensweise
(Testplanung und -dokumentation)
• Einbeziehung aller Komponenten
(auch: Dokumentation, Installationsroutinen usw.)
• Automatisierung wo möglich
1.7.2003
ViSEK-Forum
Seite 23 / 66
Was?
alle während der Softwareentwicklung entstehenden
Artefakte
•
Anforderungen (Use cases)
•
Systementwürfe (Datenformate, Ablauflogik)
•
Funktionen
•
Module
•
System
•
Konfiguration
1.7.2003
ViSEK-Forum
Seite 24 / 66
Faustregeln beim Testen
Je früher ein Fehler gemacht wird, desto mehr wird von ihm
abhängig; je später ein Fehler erkannt wird, desto teurer ist
seine Korrektur.
Es ist normal, dass Menschen Fehler machen. Der erste Gedanke
ist manchmal gut, aber fast nie konsistent. Fehler im Entwurf
müssen schrittweise beseitigt werden.
Schlimmer noch als die schlichten Irrtümer sind
Missverständnisse zwischen Anwender und Entwickler
Ziel: schrittweise begleitende Qualitätssicherung
1.7.2003
ViSEK-Forum
Seite 25 / 66
Gliederung
I Motivation
- Vorstellung
- Begriffseingrenzung
- Der Vorgang des Testens
II Testmethodik
-
Whitebox-und Blackbox- Tests
Funktions- und Modultests
GUI- und Capture-Replay-Testtools
Testsprachen
Modellbasierte Tests
III Testorganisation
- Testplanung
- Testdurchführung
- Testdokumentation
1.7.2003
ViSEK-Forum
Seite 26 / 66
Whitebox- und Blackbox-Test
Codebasierte Tests orientieren sich an der Struktur
des zu testenden Programms
- Äquivalenzklassenbildung, Grenzwertanalyse,
Entscheidungstabellen
- JUnit, Cantata, Tessy, ...
Spezifikationsbasierte Test orientieren sich an der
Beschreibung der Programmeigenschaften
- Capture-Replay: WinRunner, Rational Robot, ...
- Modellbasiert: separate Beschreibung
- Last- und Performanztest
1.7.2003
ViSEK-Forum
Seite 27 / 66
Funktionstests (Unit Tests)
Funktionstests werden üblicherweise vom Entwickler selbst
durchgeführt
Fliessender Übergang zum Debugging
Schnittstellen sind nichtöffentliche Interna im Programmcode
bekannteste Vertreter: JUnit,
Cantata, C-Check
1.7.2003
ViSEK-Forum
Seite 28 / 66
Beispiel: JUnit
Public Domain, Plugin für Eclipse
zu testende Einheiten = einzelne Klassen
public void testAddSameCurrency() {
Schritte:
final Money money1 = new Money(20);
final Money money2 = new Money(30);
Kreieren von Objekten
Aufruf von Methoden
money1.add(money2);
Überprüfen des Ergebnisses
assertEquals(50, money1.getValue());
assertEquals(30, money2.getValue());
}
XP?
1.7.2003
ViSEK-Forum
Seite 29 / 66
Modultests
Big-bang oder inkrementelle Integration
Zwei Arten der Integration: Top-Down und Bottom-up
Implementierung von Stubs
und Treibern
Bottom-up: unterstützt Re-use
Treiber leicht implementierbar
Modul A
Modul B
Modul C
Modul E
Modul D
Modul F
Top-Down: unterstützt Prototyping
Stub-Programmierung aufwändig
1.7.2003
ViSEK-Forum
Seite 30 / 66
Kontrollflussgraphen und Überdeckungen
Überdeckungsmaße:
Prozentsatz der mindestens einmal
durchlaufenen
• Anweisungen
• Zweige
• Bedingungsteile
• Schleifen
• Pfade
1.7.2003
ViSEK-Forum
Seite 31 / 66
Datenorientierte Überdeckungsmaße
Definitionsüberdeckung: für jede definierte Variable wird die
Verwendung von einem Testfall erfasst
Verwendungsüberdeckung: für jede definierte Variable wird
jede mögliche Verwendung von einem Testfall erfasst
Wertebereichsüberdeckung: für jede definierte Variable werden
alle Randwerte von einem Testfall erfasst
1.7.2003
ViSEK-Forum
Seite 32 / 66
GUI und Capture Replay Tools
bekannteste Vertreter: Mercury WinRunner, Rational Robot
(mehr als 50 Tools in http://www.testingfaqs.org/t-gui.htm)
Idee
•
Aufzeichnung von Benutzerinteraktionen
•
Abspielen mit Vergleich auf Änderungen
Erweiterungen
•
GUI-Map
•
Alternativen, Datenüberdeckungen
•
Wiederholungen, Checkpoints
1.7.2003
ViSEK-Forum
Seite 33 / 66
WinRunner Script Sprache
1.7.2003
ViSEK-Forum
Seite 34 / 66
Testdefinitionssprache TTCN-3
Testing and Test Control Notation
- ETSI Standard 2003 (Telekommunikation)
- Sprachliche, tabellarische und graphische Notation
- Variables Datentypkonzept (ASN1, andere)
- Standardisierte Schnittstelle zwischen Komponenten und zum SUT
- Main Test Components und Parallel Test Components
- Verschiedene Arten der Kommunikation
- Templates und Matching
1.7.2003
ViSEK-Forum
Seite 35 / 66
Beispiel
1.7.2003
ViSEK-Forum
Seite 36 / 66
Modellbasierte Tests
Brockhaus: Modell (von lat. modulus)
1.
Vorbild: Aufbau oder Form nach der das
eigentliche Werk geschaffen wird;
gedanklicher Entwurf
2.
Abbild: vereinfachende bildliche oder
mathematische Darstellung von
Strukturen, Funktionsweisen oder
Verlaufsformen; Wiedergabe eines
Gegenstandes in verkleinertem Maßstab
zu Studien- und Versuchszwecken
1.7.2003
ViSEK-Forum
Seite 37 / 66
Modelle beim Testen
Systemmodell
Beschreibung des gewünschten Verhaltens des Systems in der
modellierten Umgebung
Umgebungsmodell
Beschreibung der (physikalischen oder logischen) Umgebung
des zu implementierenden Systems
Beispiel Satellitensteuerung:
- Systemmodell Schaltverhalten
- Umgebungsmodell Solarzellen, Batterie
1.7.2003
ViSEK-Forum
Seite 38 / 66
modellbasierter Entwurf
• durchgängiger, kompatibeler
Entwurfsprozess
• ingenieursgerechte Notation
und Methodik
• Werkzeugunterstützung
1.7.2003
ViSEK-Forum
Grafik: W. Kattanek, IMMS
Seite 39 / 66
StateCharts
von D. Harel 1987 eingeführte Erweiterung von endlichen
Automaten; Strukturierung: Hierarchie und Parallelität
Variablen, Kommunikation per Broadcast
als Statechart Diagrams in UML eingeflossen; vor allem im
Automobilbereich viel verwendet
iLogix-Tools: StateMate, Rhapsody
Generierung von Testfällen aus StateCharts (StateMate ATG,
Conformiq, Quasar)
1.7.2003
ViSEK-Forum
Seite 40 / 66
StateChart-Beispiel
1.7.2003
ViSEK-Forum
Seite 41 / 66
Anderer Formalismus: CSP
Communicating Sequential Processes, Hoare 85
Synchronisation, Komposition, Rekursion, Timeout
operationelle Semantik: Zustandsübergangssystem
Realisierung in FDR2:
Berechnung von Verfeinerungen zwischen Prozessen
1.7.2003
ViSEK-Forum
Seite 42 / 66
Beispiel: Telekommandos im Satelliten
SPEC = ( SWITCHDEV [|{| Tau_nextTC |}|] TCTIM ) ||| TIMCHK
SWITCHDEV = Tau_nextTC -> (
(Com_PYRO_PWR_DEV_ON -> setTimSwt ->
Swt_BS_ON_MAIN_ON -> Swt_PYRO_PRE_MAIN_ON ->
Swt_PYRO_PWR_ON -> resTimSwt -> SWITCHDEV)
|˜| (Com_PYRO_PWR_DEV_OFF -> setTimSwt ->
Swt_PYRO_PWR_MAIN_OFF -> resTimSwt -> SWITCHDEV)
|˜| ... )
TIMCHK = elaTimSwt -> errorSwitchTimer -> TIMCHK
TCTIM = Tau_nextTC -> setTimTick -> elaTimTick -> TCTIM
Erzeugung von Tests aus der Zustandsübergangsrelation
1.7.2003
ViSEK-Forum
Seite 43 / 66
Testgenerierung
Konformanzbegriff
- Implementierung I ist konform zu einer Spezifikation S,
wenn für alle Sequenzen σ von Ein/Ausgaben gilt:
Beobachtungen (I nach σ) ⊆ Beobachtungen (S nach σ)
Testfall:
- deterministisches endliches
Transitionssystem
- Endzustände pass oder fail
- von jedem Zustand eine
Ausgabe- oder beliebige
Eingabemöglichkeit
Testgenerierung durch depth-first-Konstruktion der Sprache
1.7.2003
ViSEK-Forum
Seite 44 / 66
Modellbasierte Überdeckungsbegriffe
Zustandsüberdeckung: jeder Platz / Teilzustand wird von einem
Testfall erfasst
Konfigurationsüberdeckung: jeder erreichbare Globalzustand
(Markierung) wird erfasst
Transitionsüberdeckung: jeder Zustandsübergang wird erfasst
Pfadüberdeckung: jeder Teilpfad einer gewissen Länge / bis zu
einer gewissen Tiefe wird erfasst
1.7.2003
ViSEK-Forum
Seite 45 / 66
Tools für modellbasierte Tests
Kriterien:
unterstützte Modellierungssprachen, Effizienz
Beeinflussbarkeit der Testfallerzeugung
Ausführungsunterstützung
- im Modell,
- für einen virtuellen Prototyp, und
- für ein reales SUT (System Under Test)
1.7.2003
ViSEK-Forum
Seite 46 / 66
verfügbare Tools
Conformiq: Generierung und Ausführung von Testfällen aus
UML StateCharts, Übersetzung nach TTCN3
Agedis: Murphi-Modelle mit Generierungsdirektiven
(Projektionen)
TGV: Lotos und SDL nach TTCN, Telekommunikation
Telelogic Tau: generiert TTCN aus SDL
ASML: Microsoft Abstract State Machine Language für .Net
RT-Tester: RT-CSP und Timed Automata mit verteilter
Ausführung, Zufallsüberdeckungen
UniTesK: Modelle in J@va und C@++ (pre- und postconditions im
Code: „grey box testing“)
1.7.2003
ViSEK-Forum
Seite 47 / 66
Verteilung der Testausführung
1.7.2003
ViSEK-Forum
Seite 48 / 66
... für die Telekommunikation
1. Management
Console (GUI)
7. Test Case
2. Distribution/deployment
Repository
component
MTC
8. Analysis
6. Test Campaign/
Result Repository
Visualization of
Test Hardware
Selection and Configuration
of Modules and
Protocol Stacks,
Testing Strategy
5. Intercomponent Handling: TCI
Online
PTCs
TSS
TSS
3. Test execution
component
4. TRI Adaptation
SUT
1.7.2003
ViSEK-Forum
Seite 49 / 66
Gliederung
I Motivation
- Vorstellung
- Begriffseingrenzung
- Der Vorgang des Testens
II Testmethodik
-
Whitebox-und Blackbox- Tests
Funktions- und Modultests
GUI- und Capture-Replay-Testtools
Testsprachen
Modellbasierte Tests
III Testorganisation
- Testplanung
- Testdurchführung
- Testdokumentation
1.7.2003
ViSEK-Forum
Seite 50 / 66
Testplanung
Erstellung eines detaillierten Dokumentes für folgende Punkte:
•
Testziele (welche Qualitätskriterien sollen eingehalten werden)
•
Teststufen (in welchen Projektphasen sind welche Aktivitäten
auszuführen)
•
Testtypen (welche Tests sollen durchgeführt werden, welche
Werkzeuge)
•
Randbedingungen (Hardware / Softwareumgebung)
•
Rollen und Verantwortlichkeiten
•
Meilensteine und Deliverables
1.7.2003
ViSEK-Forum
Seite 51 / 66
Muster eines Testplanes (1)
1.
1.1
1.2
1.3
1.4
1.5
2.
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.2
Einführung
Zielsetzung
Geltungsbereich
Definitionen und Abkürzungen
Referenzen
Übersicht
Teststrategie
Testtypen
Benutzbarkeitstest
Modultest
Integrationstest auf Komponentenebene
Annahmeprüfung
Systemtest
Abnahme
Test der einzelnen Releases
1.7.2003
ViSEK-Forum
Seite 52 / 66
Muster eines Testplanes (2)
3.
3.1
3.2
3.3
3.4
3.5
4.
5.
5.1
5.2
5.3
5.4
Testtools
Testumgebung
Testmanagement und Fehlerverfolgung
Funktions- und Regressionstest
Last- und Performancetests
Organisation
Rollen
Testumgebungen
Entwicklungsumgebung
Systemtestumgebung
Pre-Productionumgebebung
Produktionsumgebung
1.7.2003
ViSEK-Forum
Seite 53 / 66
Muster eines Testplanes (3)
6
6.1
6.2
6.3
6.4
6.5
7
7.1
7.2
Verantwortungen und Akzeptanzkriterien
Modultest
Integrationstest auf Komponentenebene
Annahmeprüfung
Systemtest
Abnahme
Dokumentation
Testberichte
Fehlerverwaltung
1.7.2003
ViSEK-Forum
Seite 54 / 66
Rolle
Aufgaben
Personen
Testleiter
Koordinierung Testaktivitäten
Zuständigkeit für Ressourcen
Erstellung Managementreports
abschließende Bewertung der Ergebnisse
HXS
Testdesigner
Identifikation, Implementierung der Testfälle
Erstellung des Testplanes
Beurteilung der Effizienz des Testaufwandes
EKM,
RSC
Tester
Durchführung der Tests
Protokollierung u. Bewertung der Ergebnisse
MAF,
EMM,
RSC
Testautomatisierer
Erstellung von Testskripten
Umsetzung der GUI-Map
HXS,
MAF
Testsystemadministrator
Installation und Verwaltung des Testsystems
Datenbankadministration und –management
EKM
1.7.2003
ViSEK-Forum
Seite 55 / 66
1.7.2003
ViSEK-Forum
Seite 56 / 66
Testaufwand
Das Testen erfordert Ressourcen, muss also im Projekt
eingeplant werden!
Testen, Integration und Dokumentation sind oft die letzten
Phasen der Entwicklung.
Testphase als Dispositionsmasse für eine falsche Planung
,,Wann ist endlich das Programm x fertig?“
x ,,Gleich, ich muss nur noch Testen!“
x ,,Gleich, ich muss nur noch einen Fehler bereinigen!“
x ,,Gleich, ich muss nur noch dokumentieren!“
1.7.2003
ViSEK-Forum
Seite 57 / 66
Abschlusskriterien für den Test
Nicht: Wenn Ressourcen oder Zeit erschöpft
Nicht: wenn keine Fehler gefunden werden
Sondern: Wenn vorher festgelegte Qualitätsziele erreicht sind
- Überdeckungsgrad erreicht
- Restfehlerabschätzung zufriedenstellend
- Systemabnahme erfolgreich
1.7.2003
ViSEK-Forum
Seite 58 / 66
Testdurchführung
Viele Werkzeuge zur Unterstützung und zum Management der
Testdurchführung
Integriert in Software-Entwicklungsumgebungen, Planungssoftware,
Requirements-Analyse, Verwaltung von Defekten, Evaluation des
Projektfortschritts usw.
Aufgaben:
- Erzeugung und Verwaltung des Testplanes
- Vernetzung mit Requirements und Modulen
- Erstellung von Testreports und metrischen Evaluationen
- Import und Export von externen Schnittstellen
Beispiele: Mercury Test Director, QACenter, Rational Test Manager
1.7.2003
ViSEK-Forum
Seite 59 / 66
1.7.2003
ViSEK-Forum
Seite 60 / 66
1.7.2003
ViSEK-Forum
Seite 61 / 66
Testdokumentation
Problem: ggf. lange Archivierung der Ergebnisse (z.T. 20 Jahre)
IEEE/ANSI 829 Teil 1: Testdokumente:
- Testplan
- Testspezifikation
- Testskript
- Testfall
IEEE/ANSI 829 Teil 2: Berichtsdokumente:
- Software-Übergabe
- Testprotokoll
- Problemmeldung
- Abschlussbericht
1.7.2003
ViSEK-Forum
Seite 62 / 66
Testdokumentation: Testdokumente
- Testplan
x Inhalt siehe oben
- Testspezifikation Komponenten
x Zu testende Funktionen, Testverfahren
x Testskripte und Testfälle, Pass / Fail Kriterien
- Testskripte
x Testziel, spezielle Anforderungen, Einzelschritte
- Testfall
x Zu testende Funktionen, Eingaben, Ausgaben
x Umgebung, Besonderheiten, Abhängigkeiten
1.7.2003
ViSEK-Forum
Seite 63 / 66
Testdokumentation: Testberichte
- Software-Übergabe
x Inhalt der Lieferung, Übergabepunkt, Zustand
- Testprotokoll
x Beschreibung, durchgeführte Testfälle, Ergebnis, unerwartete
Ereignisse
- Problemmeldung
x Beschreibung, Auswirkungen
- Abschlussbericht
x Abweichungen, Umfang, Bewertung, Maßnahmen
1.7.2003
ViSEK-Forum
Seite 64 / 66
Zusammenfassung
Tips und Tricks zum Softwaretest
Testtools und Test Management Tools
White-box-Test: Trend zur Integration in SW-IDEs
Black-box-Test: Trend zu modellbasierter Entwicklung,
standardisierten Sprachen
Testdurchführung: Trend zu integrierten Desktops für die
Projektverwaltung
1.7.2003
ViSEK-Forum
Seite 65 / 66
Vielen Dank für Ihre Aufmerksamkeit!
1.7.2003
ViSEK-Forum
Seite 66 / 66