1x1 Des Testens

1x1 des Testens
1x1 des Testens

Frank Listing MicroConsult GmbH
Inhalt
Allgemeines Requirementanalyse und Test Testplanung und Testspezifikation Statische Prfung Dynamischer Test Testauswertung Testkosten
MicroConsult - MicroElectronics Consulting & Training GmbH
Allgemeines
Allgemeines
Was ist Test?
Eingaben
ausfhren
messen
Ausgaben
vergleichen
Sollwerte
Was sind Qualittsmerkmale?
Eingaben
ausfhren
messen
Ausgaben
vergleichen
Sollwerte
Qualittsmerkmale von Software
Qualittsmerkmal
Funktionalitt Zuverlssigkeit Benutzbarkeit Effizienz nderbarkeit bertragbarkeit
Qualitts-Teilmerkmal
Angemessenheit, Richtigkeit, Interoperabilitt, Ordnungsmigkeit, Sicherheit Reife, Fehlertoleranz, Wiederherstellbarkeit Verstndlichkeit, Erlernbarkeit, Bedienbarkeit Zeitverhalten, Verbrauchsverhalten Analysierbarkeit, Modifizierbarkeit, Stabilitt, Prfbarkeit Anpassbarkeit, Installierbarkeit, Konformitt, Austauschbarkeit
Nach DIN 66272, Oktober 1994 (ISO/IEC 9126 : 1991)
Qualittsmerkmale von Autos
Spritverbrauch? Tragfhigkeit? Hchstgeschwindigkeit?
Kombination von Qualittsmerkmalen
Was halten Sie von dem Versuch, einen Formel 1 Rennwagen zum Containertransport als 3-Liter Auto zu bauen?
Was halten Sie von dem Versuch, eine sehr speichereffiziente Software mit sehr hoher Zuverlssigkeit und sehr guter Anpassbarkeit mit grafischer, konfigurierbarer Bedienoberflche zu realisieren?
Kombination von Qualittsmerkmalen
Was halten Sie von dem Versuch, einen Formel 1 Rennwagen zum Containertransport als 3-Liter Auto zu bauen?
Was halten Sie von dem Versuch, eine sehr speichereffiziente Software mit sehr hoher Zuverlssigkeit und sehr guter Anpassbarkeit mit grafischer, konfigurierbarer Bedienoberflche zu realisieren?
Qualittsmerkmale von Software
Qualittsmerkmal
Funktionalitt Zuverlssigkeit Benutzbarkeit Effizienz nderbarkeit
Qualitts-Teilmerkmal
Angemessenheit, Richtigkeit, Interoperabilitt, Ordnungsmigkeit, Sicherheit Reife, Fehlertoleranz, Wiederherstellbarkeit Verstndlichkeit, Erlernbarkeit, Bedienbarkeit Analysierbarkeit, Modifizierbarkeit, Stabilitt, Prfbarkeit Zeitverhalten, Verbrauchsverhalten
bertragbarkeit
Nach DIN 66272, Oktober 1994 (ISO/IEC 9126 : 1991)
al im ax M
6 us a 4
Anpassbarkeit, Installierbarkeit, Konformitt, Austauschbarkeit
Qualittsmerkmale und Testen
Softwarespezifikation Analyse
Design
Implementieren
Test
Qualittsmerkmale
Prfen und Testen
Softwarespezifikation
Analyse
Design
Prfungen und Tests

Implementieren
Qualittsmerkmale
Testziele und Qualittsmerkmale
Qualittsmerkmale
Implementierung und Testen
Softwarespezifikation Analyse Analyse
Testspezifikation Testplan
Design Unittest
Implementieren
Komponententest
Testziele
Systemtest Testende-Kriterium
V-Modell als ursprngliche Basis
Anforderungsanalyse
Abnahmetest
Analyse
Systemtest
Design Implementierung
Komponententest/Integrationstest Unit-Test
Das V-Modell dient als Referenzmodell fr das Testen. Heute wird vor allem fr Realtime-Systeme kein reines V-Modell verwendet. Realtime-Systeme bentigen meist Optimierungsphasen. Somit wird das V n-mal durchlaufen. Das heit, SWEntwicklung wird heute erfolgreich iterativ in Inkrementen betrieben. Fr die Entwicklung einer Teststrategie ist das V-Modell auch heute noch voll gltig. Jeder Phase der Entwicklung wird eine Phase des Test gegenbergestellt. Auf der linken Seite des V bewegt sich der SW-Entwickler von oben nach unten. Auf der rechten Seite bewegt sich der Tester von unten nach oben.
Wer macht was?
Anforderungsanalyst
Softwarespezifikation
SW-Entwickler
Tester
Analyse
Analyse
Testspezifikation Testplan
Design Unittest
Implementieren
Komponententest
Testziele
Systemtest Test-Endekriterium
Personen bernehmen Rollen in einem Entwicklungsprozess. An eine Rolle sind Aufgaben gebunden. Eine Person kann mehrere Rollen in einem Projekt bernehmen. Rollen knnen einander ausschlieen. (Optimal wre SW-Entwickler und Tester sind verschiedene Personen)
Analysiert die Aufgabe (Lastenheft) und Anforderungsanalyst erstellt daraus eine Anforderungsspezifikation. Entwickelt aus der Anforderungsspezifikation eine Architektur, ein Designmodell und schreibt den Code.
SW-Entwickler
Tester
Entwickelt aus der Anforderungsspezifikation Testflle, bestimmt die vorzunehmenden Prfungen, fhrt, dokumentiert und wertet die Tests aus.
Schlagworte
Ausfhrende Der Entwickler

(first party)
Kollegen Andere Abteilung

(first party)
Auftraggeber (second party) Unabhngige Dritte (third party)
Wertigkeit
(first party)
Ttigkeiten prfen evaluieren testen analysieren validieren verifizieren berprfen zertifizieren nachweisen
test test
assess
Prfen Technischer Vorgang, der aus dem Bestimmen eines oder mehrerer Merkmale eines bestimmten Erzeugnisses, Verfahrens oder einer Dienstleistung besteht und gem einer vorgeschriebenen Verfahrensweise durchzufhren ist. (EN 45 020 : 1993, 12.1). Evaluieren Analysieren und bewerten eines Sachverhalts. Testen Ein Programm wird ausgefhrt, um Fehler zu finden. Analysieren Verstehen und Erfassen der Sachverhalte einer Aufgabenstellung, sowie die Entscheidung ber die Durchfhrbarkeit und die Erfolgsaussichten eines knftigen Projektes. Validieren Tut das System das Richtige? Ein Fachmann/frau prft die Spezifikation oder das gesamte System Verifizieren Tut das System das richtig? Prfen gegen die Spezifikation. berprfen Prfen der Prfung. Wurde der Test richtig durchgefhrt? Zertifizieren Besttigung der Einhaltung bestimmter Verfahren durch einen unabhngigen Dritten. Nachweisen Beweisen eines Sachverhaltes (z.B. Programm erfllt die Anforderungen).
Validieren Verifizieren (am Beispiel eines Eigenheimes)
Die Validation untersucht die Frage: Wird das richtige Haus gebaut?
Die Verifikation untersucht die Frage: Wird das Haus richtig gebaut?
Gehrt von M. Mllerburg, GMD
Requirementanalyse und Test
Requirementanalyse und Test
Darstellung von Requirements
Requirements (Anforderungen) mssen existieren!

mndlich schriftlich modellbasiert (typisch) (empfohlen) (die Zukunft)
Mndliche Requirements
mssen fr den Test analysiert werden erfordern eine ausfhrlichere Testspezifikation!
Anforderungsanalyse
Eingaben
System
Ausgaben
Anforderungsspezifikation Grenzen des Systems Funktionale Anforderungen Nichtfunktionale Anforderungen

Die Anforderungsspezifikation beschreibt, was das System zu tun hat und welche Qualitten das System dabei erfllen muss.
Anforderungen und Testflle
Prfungen und Tests

Anforderungen und Testszenarien (1)

Aktoren Sensoren Eingangs- und Ausgangssignale Schnittstellen und Protokolle Anwendungsflle Ablufe (Szenarien) Zustandsautomaten Protokolle
Testvektoren
Testablufe
Testflle
Anforderungen und Testszenarien (2)
externe Qualittsmerkmale Zuverlssigkeit Effizienz ... Zeitanforderungen
interne Qualittsmerkmale nderbarkeit Benutzbarkeit bertragbarkeit ... Gesetzliche Anforderungen
Sollwerte
Vorgaben
Testflle
Prfungen
Testplanung und Testspezifikation
Testplanung und Testspezifikation
Testplan und Testspezifikation
Testplan (Beispiel nach IEEE 829)

Testplan ID Einfhrung Zu testende Komponenten Zu testende Funktionen Nicht zu testende Funktionen Vorgehensweise Pass / Fail Kriterien Produkte - Testttigkeiten - Testumgebung - Zustndigkeiten - Personal - Zeitplan - Risiken und Risikomanagement - Genehmigungen
Testspezifikation (Beispiel nach IEEE 829)

Testspezifikation ID Zu testende Funktionen Identifikation des zu testenden Objektes Auffhrung der Funktionen und der Kombinationen der Funktionen Verlinkung mit der Anforderungs- und der Design-Spezifikation Testverfahren Ausfhrung der Test Auswahl der Testflle Beschreibung der Umgebung fr die Testflle Testskripte und Testflle Tabellarische Beschreibung der Testflle Benennung der Testskripte Pass / Fail Kriterien
Testplan und Testspezifikation
Testplan (Beispiel nach IEEE 829)

Testplan ID Einfhrung Zu testende Komponenten Zu testende Funktionen Nicht zu testende Funktionen Vorgehensweise Pass / Fail Kriterien Produkte - Testttigkeiten - Testumgebung - Zustndigkeiten - Personal - Zeitplan - Risiken und Risikomanagement - Genehmigungen
Testspezifikation (Beispiel nach IEEE 829)

Testspezifikation ID Zu testende Funktionen Identifikation des zu testenden Objektes Auffhrung der Funktionen und der Kombinationen der Funktionen Verlinkung mit der Anforderungs- und der Design-Spezifikation Testverfahren Ausfhrung der Test Auswahl der Testflle Beschreibung der Umgebung fr die Testflle Testskripte und Testflle Tabellarische Beschreibung der Testflle Benennung der Testskripte Pass / Fail Kriterien
n n de te vo rden! oll we ns s stpla hrieben Te rsc des te opie nen un K ckte Perso ru ged hen Eine twortlic n vera
Teststrategie
Die Teststrategie legt die Konzepte zur Findung aussagekrftiger Testflle fest und schrnkt die Menge der Testflle ein. Entwicklung der Strategie anhand der Qualittsmerkmale der Komponenten der Risiken
Frh mit den Tests im Entwicklungsprozess beginnen, um Fehler so frh wie mglich zu beseitigen.
Teststrategie und Qualittsmerkmale
Funktionalitt Wichtigkeit Source-Code Unit-Test Komponententest Systemtest Abnahmetest 40% + + ++ ++ ++
Zuverlssigkeit 30%
Benutzbarkeit 10%
Effizienz 10% ++ +
bertragbarkeit 10%
+ ++ ++ + ++
Funktionalitt Wichtigkeit Komponente A Komponente B Komponente C 40% + ++ +
Zuverlssigkeit 30% +
Benutzbarkeit 10%
Effizienz 10% ++
bertragbarkeit 10%
++ ++
+ +
Qualittsmerkmale lassen sich den Projektphasen zuordnen. Diese mssen aus der Anforderungsspezifikation entnommen oder eingefordert werden. Ein Gewichtung ist unumgnglich. Hier ist der Tester gefordert. Den Projektphasen kann nun das Qualittsmerkmal zugeordnet werden.
Teststrategie und Qualittsmerkmale
Funktionalitt Wichtigkeit Source-Code Unit-Test Komponententest Systemtest Abnahmetest 40% + +
Zuverlssigkeit 30%
Benutzbarkeit 10%
Effizienz
bertragbarkeit 10%
s litt Qua ++
++
++
P und ale m + k mer

++ ++ +
10% n ase ktph ++ roje +
++
Funktionalitt Wichtigkeit Komponente A Komponente B Komponente C 40% +
Zuverlssigkeit 30% +
Benutzbarkeit
und ale rkm ++ ++ sme litt ++ + Qua
Effizienz nten one 10% 10% p Kom ++
bertragbarkeit 10%
+ +
Risikobasierte Teststrategie
Optionen des Risikomanagements
Minimierung des Verlustes Vermeiden von Risiken Vermeiden von Gefahren Prventive Risikovermeidung Proaktives Risikomanagement
Reaktion im Schadensfall Bilden von Rcklagen Transfer des Risikos
Kosten- und Versicherung Terminreserven Garantie
Risikobasiertes Testen
Quelle: nach Testing Embedded Software Broekmann/Notenboom S. 82
Testende-Kriterien
Wann ist der Test zu Ende? Testziele

TestendeKriterien TestabbruchKriterien
l Zie nic
err eic ht
ht eic e rr
Zie l
ar hb
Testende
Testabbruch
Strukturierung von Tests
Fokussierung auf den Systemtest

Validieren
Anforderungsanalyse Abnahmetest
Verifizieren/Testen
Analyse
Systemtest
Testspezifikation
Komponententest / Integrationstest Unit-Test
Aufwand fr den Test hlt sich in Grenzen
Finden maskierter Fehler schwierig Qualitt der Komponenten orientiert sich an den Features den Projektes Lokalisierung der Fehler ist fr den Entwickler schwierig
Strukturierung von Tests
Validieren
Anforderungsanalyse Abnahmetest
Testspezifikation
Verifizieren/Testen
Analyse
Systemtest
Modul und Integrationsplan
Komponententest / Integrationstest Unit-Test
Modultestplan Modultestplan Modultestplan Modultestplan
Einfache Lokalisierung der Fehler durch den Entwickler Module werden einzeln getestet
Hherer Dokumentationsaufwand
Statische Prfung
Statische Prfung
Statische Prfung
Statische Prfungen
Statische Prfungen sind Verfahren, die eine Bewertung des Codes vornehmen, ohne ihn auszufhren. Unterschieden werden manuelle Prfungen, wie Fagan Inspektion und Walkthroughs, sowie automatische Prfungen, wie z.B. Compiler, LINT.
Software-Teilprodukte
--- SW Anforderungen --Software Anforderungsspezifikation Software Validierungsplan --- SW Architektur --Software Architekturbeschreibung Testspezifikation Software-ArchitekturIntegration Bedienanleitung Entwicklungswerkzeuge Codier Richtlinie --- SW System --Software Systembeschreibung Testspezifikation Software-SystemIntegration --- SW Module --Software Modul Entwurfs Spezifikation Software Modul Test Spezifikation --- Coding --Form des Source Codes (hndisch, automatisch) Software Modul Test Report Software Code Review Report
--- SW Integration --Software Modul Integration Test Report Software System Integration Test Report Software Architektur Integration Test Report --- SW Operation and Maintenance --Benutzerhandbuch Bedienanleitung Wartungsanleitung --- SW Validation --Validierungsreport --- SW Modification --SW Modifikations-Anleitung SW Modifikations-Anforderung SW Modifikations-Auswirkungsanalyse SW Modifikations-Bericht --- Phasenbergreifende --SW Qualittsplan SW Verifikationsplan Verifikationsbericht Plan zum Nachweis der Qualitt Bericht ber den Qualittsnachweis
Aus unseren akt. Herstellerchecklisten basierend auf 61508-1
Testbar
Inspizierbar
Statische Prfungen
Inspektionen
Finden von 60% bis 90% aller Fehler in der Spezifikation und im Code allein durch Inspektionen. Reduzierung des Problems der "Unersetzbarkeit" von Entwicklern (Verteilung des Wissens auf mehrere Mitarbeiter). Erhhung der Qualitt in einer frhen Phase. Verringerung des Test- und Korrekturaufwandes ("Gesundtesten" ist nicht ntig). Inspektionen sind auf jede Art von Dokument anwendbar.
Dynamische Tests
Dynamische Tests
Dynamische Tests
Dynamische Tests
Der zu testende Code wird ausgefhrt. Dynamische Tests werden unter Bercksichtigung der inneren Struktur (White-Box-Test) bis hin zur Betrachtung als geschlossenes System durchgefhrt (Black-Box-Test).
Dynamische Tests
White-Box-Test
Grundlage ist die innere Struktur des Codes.
Black-Box-Test
Erfolgt ohne Kenntnis der inneren Struktur (Schnittstellentest).
Gray-Box-Test
Kombiniert die Methodik von Black-Box- und White-Box-Tests.
Anweisungsberdeckungstest/ C0-Test
1
ja
a || b || c d
nein
Keine leeren Zweige
2
ja
3
nein
4 e
ja nein nein
g 7 8 9
Tests und Fehleridentifizierungsquote Kontrollflussorientiert Anweisungsberdeckungstest oder C0-Test (18%) Jeder Befehl im Programm muss mindestens einmal ausgefhrt werden. Zweigberdeckungstest (34%) Alle Entscheidungen oder Sprnge werden erfasst (Entwurf entsprechend vieler Testflle ist ntig). Er enthlt den Anweisungsberdeckungstest vollstndig Bedingungsberdeckungstest (ca. 50%) Test aufgrund der Bedingungen von Schleifen und logischen Ausdrcken. Alle Bedingungen, die zum Durchlaufen eines Zweigs fhren knnen, werden getestet. Pfadberdeckungstest (>60%) Ziel ist die Ausfhrung aller unterschiedlichen Pfade des Programms. Datenflussorientiert (Statistiken aus Girgis, Woodware `86) all defs: (24%, keine Kontrollflussfehler) Jede Definition muss in einer Berechnung oder Bedingung benutzt werden all p-uses: (34%, identifiziert sicher Kontrollflussfehler) Jede Kombination aus Variablendefinition und deren prdikative Nutzung mu getestet werden Beinhaltet Zweigberdeckung all c-uses: (48%, identifiziert Berechnungsfehler) Jede Kombination aus Variablendefinition und deren berechnende Benutzung muss getestet werden
Zweigberdeckungstest / C1-Test
1
ja
a || b || c d
nein
Auch leere Zweige werden getestet
2
ja
3
nein
4 e
ja nein nein
g 7 8 9
Erweiterter Zweigberdeckungstest / C1p-Test
Verschiedene Kombinationen
ja
1 a || b || c d
nein
2
ja
3
nein
Test der Schleifen mit Extremwerten
4 e
ja nein nein
g 7 8 9
White-Box-Tests - Testabdeckung
Was bedeutet Testabdeckung?
Durchlauf aller Programmpfade in allen Kombinationen
X X
Test mit allen Datenwerten und deren Kombinationen
Aber nicht alle Werte und Programmpfade fhren zu einem Fehler!
Kontrollflussorientierte Tests betrachten nur den Programmablauf. Daten werden nur indirekt und sehr begrenzt betrachtet. Vollstndiger Test -> unendlich viele Testflle. Datenflussorientierte Tests betrachten die Initialisierung und Nutzung von Daten. Es wird aber nicht auf verschiedene Werte dieser Daten eingegangen. Ein vollstndiger -> unendlich viele Testflle.
Ermittlung von Testvektoren
Funktion mit einem gltigen Definitionsbereich von 1..12: int daysOfMonth(int month); Test mit Zufallszahlen z.B.: -23, 13, 356 Problem: Kein Wert liegt im gltigen Bereich.
Ermittlung von Testvektoren
Funktionale quivalenzklassenbildung
Werte z.B.: -4, 8, 245
ungltige Werte
gltige Werte
ungltige Werte
-4
245
-2
10
12
14
12
13
Grenzwertanalyse
Werte: 0, 1, 12, 13
Klassifikationsbaum-Methode
Grafische Ermittlung von Grenz- und quivalenzklassen Ausprgung als konkrete Ein-/Ausgaben oder Sequenzen
Klasse Wert als Konstante
Testfall
Die CTE-Methode wurde vom Forschungslabor Softwaretechnologie der DaimlerChrysler AG entwickelt.
Testtreiber
Testtreiber
Ein- und Ausgaben
globale Daten
Function under Test Stub

Funktionsaufrufe
Parametrierungen
Aufgaben des Testtreibers Vorbedingungen fr den Ablauf des Tests schaffen Eingangsumgebung globale Variablen statische Variablen in der Testfunktion (Code muss instrumentiert werden) Funktionsparameter Zu testende Funktion ausfhren Nachbedingungen erfassen Ausgangsumgebung globale Variablen statische Variablen in der Testfunktion Funktionsparameter (Pointer, ...) Rckgabewert der Funktion Ausgaben fr die Nachbereitung speichern
Testtreiber und Teststub
Function Under Test

extern int max(int a, int b); int setMaxToPort(int a, int b) { int c; c= max(a, b); return c; } // Noch nicht // vorhanden
Testtreiber
int g_retMax; void main() { int a= 10; int b= 20; int Result; g_retMax= 5;
Teststub
int g_retMax; int max(int a, int b) { return g_retMax; }
Result= setMaxToPort(a, b); printf("%d", Result); }
Regressionstest
Getestete SW Regressionstest
nderung
Ungetestete SW
Nach einer Codenderung darf keine Regression auftreten, d.h., die genderten Anteile mssen weiterhin der Spezifikation gengen. Dies wird durch Regressionstests geprft. nderungen an existierendem Code knnen
korrektiv (Spezifikation verletzt), inkrementell (Spezifikation erweitert), adaptiv (Spezifikation gendert) oder optimierend (Spezifikation unverndert) sein.
Testauswertung
Testauswertung
Reports
Testauswertung
Testergebnisse mssen dokumentiert werden! Fehler mssen dokumentiert werden, um das Wissen um sie verfgbar zu machen und sie zu beheben, nicht um Schuldzuweisungen machen zu knnen.
Testprotokoll Testprotokoll z.B. IEEE 829 Testprotokoll je Test z.B. IEEE 829 z.B. IEEE 829
Problemmeldung n Problemmeldung n Problemmeldung z.B. IEEE 829
Abschlussbericht z.B. IEEE 829
Testkosten
Testkosten
Kosten fr den Test
Werkzeuge und Testumgebung
Testspezifikation Testplanung Testdesign
Kosten fr die Fehlerbeseitigung
Testdurchfhrung Testdokumentation
Fehloptimierung
Fehloptimierung
Gezielte Optimierung
Gezielte Optimierung
Optimierung durch Design for Test
Zusammenfassung
Die Prfung der Software ist ein geplanter Vorgang! Sie orientiert sich an klar definierten Qualittsmerkmalen! Sie setzt klare Anforderungen (Requirements) voraus! Prfen ist allgemein! Nur Ausfhrbares kann getestet werden! Entwicklung und Test gehen Hand in Hand (Design for Test)! Der richtige Mix aus statischer Prfung und dynamischen Tests fhrt zum Erfolg!
Wissen nach Ma fr Embedded Projekte
Training, Coaching, Engineering
AnforderungsAnalyse Analyse Design Implementierung MicroConsult untersttzt Sie bei:
AbnahmeTest System-Test KomponentenTest Unit-Test
HW-/SW-Technologien, Tools, Methoden, Prozess, Team

1x1 Des Testens

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1x1 Des Testens

Enviado por

Direitos autorais:

Formatos disponíveis

1x1 des Testens

1x1 des Testens

MicroConsult - MicroElectronics Consulting & Training GmbH

Was ist Test?

MicroConsult - MicroElectronics Consulting & Training GmbH

Was sind Qualittsmerkmale?

MicroConsult - MicroElectronics Consulting & Training GmbH

Qualittsmerkmale von Software

Nach DIN 66272, Oktober 1994 (ISO/IEC 9126 : 1991)

MicroConsult - MicroElectronics Consulting & Training GmbH

Qualittsmerkmale von Autos

Spritverbrauch? Tragfhigkeit? Hchstgeschwindigkeit?

Spritverbrauch? Tragfhigkeit? Hchstgeschwindigkeit?

Spritverbrauch? Tragfhigkeit? Hchstgeschwindigkeit?

MicroConsult - MicroElectronics Consulting & Training GmbH

Kombination von Qualittsmerkmalen

MicroConsult - MicroElectronics Consulting & Training GmbH

Kombination von Qualittsmerkmalen

MicroConsult - MicroElectronics Consulting & Training GmbH

Qualittsmerkmale von Software

Nach DIN 66272, Oktober 1994 (ISO/IEC 9126 : 1991)

Anpassbarkeit, Installierbarkeit, Konformitt, Austauschbarkeit

MicroConsult - MicroElectronics Consulting & Training GmbH

Qualittsmerkmale und Testen

MicroConsult - MicroElectronics Consulting & Training GmbH

Prfen und Testen

Prfungen und Tests

MicroConsult - MicroElectronics Consulting & Training GmbH

Testziele und Qualittsmerkmale

MicroConsult - MicroElectronics Consulting & Training GmbH

Implementierung und Testen

Softwarespezifikation Analyse Analyse

MicroConsult - MicroElectronics Consulting & Training GmbH

V-Modell als ursprngliche Basis

MicroConsult - MicroElectronics Consulting & Training GmbH

Wer macht was?

MicroConsult - MicroElectronics Consulting & Training GmbH

Ausfhrende Der Entwickler

Kollegen Andere Abteilung

Auftraggeber (second party) Unabhngige Dritte (third party)

MicroConsult - MicroElectronics Consulting & Training GmbH

Validieren Verifizieren (am Beispiel eines Eigenheimes)

MicroConsult - MicroElectronics Consulting & Training GmbH

Gehrt von M. Mllerburg, GMD

Requirementanalyse und Test

Requirementanalyse und Test

Darstellung von Requirements

Requirements (Anforderungen) mssen existieren!

MicroConsult - MicroElectronics Consulting & Training GmbH

Anforderungsspezifikation Grenzen des Systems Funktionale Anforderungen Nichtfunktionale Anforderungen

MicroConsult - MicroElectronics Consulting & Training GmbH

Anforderungen und Testflle

Anforderungsspezifikation Grenzen des Systems Funktionale Anforderungen Nichtfunktionale Anforderungen

Prfungen und Tests

Anforderungen und Testszenarien (1)

Anforderungsspezifikation Grenzen des Systems Funktionale Anforderungen Nichtfunktionale Anforderungen

Anforderungen und Testszenarien (2)

Anforderungsspezifikation Grenzen des Systems Funktionale Anforderungen Nichtfunktionale Anforderungen

externe Qualittsmerkmale Zuverlssigkeit Effizienz ... Zeitanforderungen

interne Qualittsmerkmale nderbarkeit Benutzbarkeit bertragbarkeit ... Gesetzliche Anforderungen

Testplanung und Testspezifikation

Testplanung und Testspezifikation

Testplan und Testspezifikation

Testplan (Beispiel nach IEEE 829)