testen Übersicht

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011

Seite 1

TestenÜbersicht

Datei: TestenVorlesung.ppt

Inhalt: Testkonzept/-plan Testarten, -stufen und -phasen Testmethoden für black box testing Testmethoden für white box testing

Kontrollflussbasiert Datenflussbasiert

Testszenarien und Testfälle Unittest Integrationstest Testabschlusskriterien Fehlermanagement


Seite 2

TestenTestkonzept/-plan

• Im Testkonzept (häufig auch bezeichnet als Testplan) werden zuerst die geplanten Testarten (auch bezeichnet als Teststufen bzw. Testphasen) festgelegt (s. nächste Seite).

• Dabei wird für jede Testart folgendes festgelegt:• Ziel• Zuständigkeit (für Koordination, Durchführung und Abnahme)• Zeitraum der Durchführung• Testmethode• Aufwandsabschätzung• Testumgebung (incl. Tool):

• Treiber für benötigte Testdaten• Treiber für erforderliche Aufrufmodule• Simulation der aufgerufenen Module


Seite 3

TestenTestarten/-phasen/-stufen

Testart häufig bezeichnet als Ziel

Unittest Komponententest, Modultest, Produkttest

Sicherstellung der Funktionsfähigkeit von Schnittstellen und Systemfunktionen

Technischer Integrationstest

delivery acceptance test Sicherstellen, daß die entwickelte Komponente technisch ablauffähig ist

Anwendungstest application integration test Sicherstellung der Funktionsfähigkeit des Gesamtsystems

Integrationstest business integration test Sicherstellung der Durchgängigkeit von Prozessen unter Einbindung der angrenzenden Systeme, d.h. Sicherstellung der fachlichen Integration

Rollentest Sicherstellung der Funktionsfähigkeit der mit den Rollen verbundenen Berechtigungsprüfungen

Performancetest (Systemtest), Volumentest Frühzeitiges Feststellen von Performance-Problemen auf Basis von Echtdaten

Regressionstest Upgradetest Sicherstellung des Produktivbetriebs bei Einspielen von neuen Releases

Recoverytest Backuptest Sicherstellung des korrekten Neuaufsetzens nach einem Systemstillstand

Inbetriebnahmetest Sicherstellung der Funktionsfähigkeit der wichtigsten Schnittstellenanbindungen

Systemtest Installationskontrolltest, operations readyness test

Sicherstellen der IT-technischen Integration, d.h. u.a. dass die Anwendung weiterhin den Betriebsanforderungen entspricht.


Seite 4

TestenTestmethoden

Black Box Testing (funktionsorientiertes Testen)

• Spezifikation des Testobjekts als Ausgangspunkt der Testdatenermittlung• Testdaten werden in Klassen eingeteilt, bei jedem Repräsentant einer Klasse verhält sich das Testobjekt gleich• Qualität der Testdaten hängt ab von der Aussagekraft der Spezifikation• Es kann nicht ermittelt werden, ob das Programm mehr tut als es soll (Computerkriminalität)

White Box Testing (strukturorientiertes Testen)

• Programmtext als Ausgangspunkt der Testdatenermittlung• möglichst viele Programmabläufe werden ausgeführt• unterschiedliche Überdeckungen werden angestrebt (C0, C1, …)• Programme können getestet werden, für die keine Spezifikation vorliegt• vergessene Teile der Spezifikation können nicht gefunden werden• es ist nicht erkennbar, ob die getesteten Anweisungen im Betrieb überhaupt ausgeführt werden


Seite 5

TestenBlack Box Testing: Testziele

Mögliche Testziele (einzeln oder in Kombination):

• Funktionsüberdeckung: jede spezifizierte Funktion mindestens einmal aktiviert

• Ausgabeüberdeckung: jede spezifizierte Ausgabe mindestens einmal erzeugt

• Ausnahmeüberdeckung: jede spezifizierte Ausnahme- bzw. Fehlersituation mindestens einmal erzeugt

• Attributüberdeckung: alle geforderten Attribute (soweit technisch möglich) getestet

• insbesondere Erreichung der spezifizierten Leistungsanforderungen– unter normalen Bedingungen– unter möglichst ungünstigen Bedingungen (Belastungstest)


Seite 6

TestenBlack Box Testing: Verfahren

Problem der Testfall-Auswahl: die gewählten Testziele mit möglichst wenig und möglichst guten Testfällen umsetzen

Klassische Techniken:• Äquivalenzklassenbildung: Gleichartige Eingabedaten werden zu Klassen zusammengefasst

und aus jeder Klasse wird ein Repräsentant getestet• Grenzwertanalyse: An den Grenzen zulässiger Datenbereiche treten erfahrungsgemäß häufig

Fehler auf; Testfälle für solche Grenzfälle auswählen• Ursache-Wirkungsgraphen: systematischen Bestimmung von Eingabedaten, die ein

gewünschtes Ergebnis bewirken• Statistisches Testen (random testing): Eingabedaten werden zufällig ausgewählt; die gezielte

Testfall-Auswahl wird durch eine große Zahl von Testfällen ersetzt; Problem: Auswahl der Eingabedaten muss der tatsächlichen Verteilung der Eingabedaten im produktiven Betrieb der Software entsprechen

• Fehler raten (error guessing): Intuitive Testfallauswahl aufgrund von Erfahrung; ergänzt andere Methoden zur Testfallbestimmung; Qualität stark von Erfahrung und Intuition der Tester abhängig


Seite 7

TestenBlack Box Testing: Übung

Gegeben sei ein Programm, das folgende Spezifikation erfüllen soll:

Das Programm fordert zur Eingabe von drei nicht negativen reellen Zahlen auf und liest die eingegebenen Werte; es interpretiert die eingegebenen Zahlen als Strecken a, b und c und untersucht, ob die drei Strecken ein Dreieck bilden, und klassifiziert gültige Dreiecke.

Das Programm liefert folgende Ausgaben:• kein Dreieck wenn a+b <= c oder a+c <= b oder b+c <= a• gleichseitiges Dreieck, wenn a=b=c• gleichschenkliges Dreieck, wenn a=b oder b=c oder a=c• unregelmäßiges Dreieck sonst

Das Programm zeichnet ferner alle gültigen Dreiecke winkeltreu und skaliert in einem Fenster der Größe 10x14 cm auf maximal darstellbare Größe. Die Seite c liegt unten parallel zur Horizontalen. Alle Eckpunkte haben einen Minimalabstand von 0,5 cm vom Fensterrand.

Das Programm liefert eine Fehlermeldung, wenn andere Daten als drei nicht negative reelle Zahlen eingegeben werden. Anschließend wird mit einer neuen Eingabeaufforderung versucht, gültige Werte einzulesen.


Seite 8

TestenBlack Box Testing: Übung

Welche 4 Funktionen sind bei einer vollständigen Funktionsüberdeckung zu prüfen?

Für eine vollständige Ausgaben- und Ausnahmeüberdeckung sind die notw. Äquivalenzklassen definiert worden; legen Sie für jede (Sub-)klasse einen Repräsentanten fest:

• Ausgabenüberdeckung:– kein Dreieck mit 3 Subklassen– gleichseitiges Dreieck– gleichschenkliges Dreieck mit 3 Subklassen– unregelmäßiges Dreieck mit 9 Subklassen

• Ausnahmeüberdeckung– ungültige Eingabe mit 3 Subklassen

Legen Sie für jeden Grenzfall einer Grenzwertanalyse einen Testwert fest (insg. 7 Grenzfälle): • kein Dreieck mit 4 Werten• Sehr flaches Dreieck mit 2 Werten• Sehr steiles Dreieck


Seite 9

TestenWhite Box Testing: Verfahren

Kontrollflussbasierter Test

• C0-Überdeckung, Anweisungsüberdeckung, statement coverage (alle Knoten)• C1-Überdeckung, Zweigüberdeckung, branch coverage (alle Zweige)• CGI, Grenze-Inneres Test• C∞-Überdeckung, Pfadüberdeckung, path coverage (alle Pfade)

Test der Bedingungen

Datenflussbasierter Test

• C2-Überdeckung, Bedingungsüberdeckung (alle Bedingungen, auch Teile davon)• Mehrfachbedingungsüberdeckung (alle Kombinationen der Teilbedingungen)

• Überdeckungsgrad bzgl. der Datenverwendung (Def/Uses-Verfahren):• (zustandsverändernde) Wertzuweisung: z.B. r=0• (zustandserhaltende) Benutzung in Ausdrücken: z.B. f(r)• (zustandserhaltende) Benutzung in Entscheidungen: z.B. r>0


Seite 10

Testen White Box Testing: C0-Überdeckung

Kontrollfußgraph vom ggT (Bsp.:ggT(4,8)=4, ggT(5,8)=1, ggT(15,35)=5)

9-11

12

13

1

2-3

4-6

7

8

1. public int ggt(int m, int n) {

2. int r;

3. if (n > m) {

4. r = m;

5. m = n;

6. n = r

}

7. r = m % n;

8. while (r != 0) {

9. m = n;

10. n = r;

11. r = m % n; }

12. return n;

13. }

1,2-3,4-6,7, 8,9-11,8,12,13

Ein Testfall für die 100%ige C0-Überdeckung:

Der Pfad

wird nicht getestet, weil in diesem Pfad keine Anweisung enthalten ist

2-3,7


Seite 11


Mit den Testdaten x=5 und y=0 wird zwar die C0-Überdeckung erfüllt, jedoch wird der Fehler im falschen Programm nicht gefunden, denn die Sollwerte x=25 und y=30 werden in beiden Fällen erreicht.

Beispiel für nicht gefundenen Fehler bei der C0-Überdeckung:


Seite 12


9-11

12

13

1

2-3

4-6

7

8

1,2-3,4-6,7, 8,9-11,8,12,13

Zwei Testfälle für die 100%ige C1-Überdeckung:

1,2-3,7,8,12,13 neu

Jedoch:• Schleifen werden nicht ausreichend getestet.• Komplexe Bedingungen werden nicht getestet.• Kombinationen von Zweigen werden nicht getestet.

9-11

12

13

1

2-3

4-6

7

8


Seite 13


Mit den Testdaten x=5 und y=0 (Ergebnis: x=25, y=30) wird der eine Test durchgeführt, mit x=-1 und y=0 (Ergebnis: x=-1, y4) der zweite Test.

Der Fehler wird im Gegensatz zur C0-Überdeckung gefunden.

Beispiel für gefundenen Fehler bei der C1-Überdeckung:


Seite 14

Testen White Box Testing: CGI-Überdeckung

Die CGI-Überdeckung (Grenze-Inneres) bezieht sich nur auf Schleifenanweisungen und fordert, dass jede Schleife in mindestens einem Testfall• gar nicht (gilt nur bei abweisenden

Schleifen, while, for nur wenn Abbruchbedingung bei

erstmaliger Auswertung wahr)• genau einmal und• mehr als einmal ausgeführt wird.

9-11

12

13

1

2-3

4-6

7

8

1,2-3,7,8,12,13

3 Testfälle für die CGI-Überdeckung:

1,2-3,4-6,7, 8,9-11,8,12,13

1,2-3,4-6,7, 8,9-11,8,9-11,8,12,13


Seite 15

Testen White Box Testing: Bedingungsüberdeckung

Die C2-Überdeckung (Bedingungsüberdeckung) berücksichtigt komplexe/zusammengesetzte Bedingungen, indem sie fordert, alle Teilbedingungen zu variieren. Jedoch ist nicht gefordert, dass unterschiedliche Wahrheitswerte bei der Auswertung der gesamten Bedingung berücksichtigt werden. Somit ist die Anweisungs- bzw. Zweigüberdeckung stärker, da manche Zweige bei der C2-Überdeckung nicht getestet werden.

Testfall1: A=2, B=1, C=4


Die Testfälle überdecken zwar alle Variationen der Teilbedingungen, jedoch wird der Pfad c nicht getestet.


Seite 16


Bei der Testfallermittlung sollte man sowohl die C2-Überdeckung (Bedingungsüberdeckung) als auch die Zweigüberdeckung berücksichtigen (s. auch Beispiel vorige Folie):

Testfall1: A=2, B=0, C=4 Pfad a-c-e

Testfall2: A=1, B=1, C=1 Pfad a-b-d

Mit diesen Testfällen werden zwar alle Zweige überdeckt, jedoch nicht alle Zweigkombinationen.

Um das zu zeigen, benötigt man eine äquivalente Umformung des Kontrollflussgraphen:


Seite 17



A>1

A=2

C:=C/A

C:=C+1

true

true

false

false

B=0true

false

C>1

false

true


Zwei Zweige fehlen:

Lösung:

Mehrfachbedingungsüberdeckung (C3-Ü.)

Die C3-Überdeckung ist dann erfüllt, wenn jede Kombination der Wahrheitswerte aller Teilbedingungen in Testfällen ausgeführt wird.


Seite 18

TestenWhite Box Testing

Datenflussbasiertes Testen (Def/Uses-Verfahren)

• Getestet werden Interaktion zwischen Anweisungen, die einer Variablen einen Wert zuwei-

sen (definieren), und Anweisungen, die diesen Variablenwert benutzen (referenzieren):• Wertzuweisung (Definition, definitional use, def)• Berechnungsreferenz (Benutzung in Ausdrücken, computational use, c-use)• Entscheidungsreferenz (Benutzung in Bedingungen, predicative use, p-use)

r = m % n

r = op1(m,n)

while (r != 0)

if (r == 0)

c-use(m,n)

p-use(r)

def(r)

• verschiedene Test-/Überdeckungskriterien (Metriken):• Alle Definitionen: Das Resultat einer Zuweisung

(Definition) wird wenigstens einmal

benutzt (c-use oder p-use)• Alle DR-Interaktionen: jedes Paar

(def/ref) auf irgendeinem Weg ausführen• Alle Referenzen: p-uses und c-uses• ….


Seite 19

TestenVerfahren zum White Box Testing

Kontrollflussgraph mit Datenflussannotation:

1. public int ggt

(int m, int n) {

2. int r;

3. if (n > m) {

4. r = m;

5. m = n;

6. n = r

}

7. r = m % n;

8. while (r != 0) {

9. m = n;

10. n = r;

11. r = m % n; }

12. return n;

13. }

8

2

3

4

6

7

9

10

11

12

5

1 def(m,n)

def(r)

p-use(m,n)

def(r), c-use(m)

def(m), c-use(n)

def(n), c-use(r)

def(r), c-use(m,n)

p-use(r)

def(m), c-use(n)

def(n), c-use(r)

def(r), c-use(m,n)

c-use(n)

Bsp. für DR-Interaktionen:

(1, m, 4, r, 6):

m wird in 1 definiert, in 4 referenziert, r wird in 4 definiert und in 6 referenziert; damit hängt 6 von 1 ab.

(1, m, 7, r, 10):

…..

Teste die Wegstücke:

(1, 2, 3, 4, 5, 6) und

(1, 2, 3, 7, 8, 9, 10)


Seite 20

TestenVerfahren zum White Box Testing

Testverfahren Leistungsfähigkeit BewertungC0, (statement coverage)

Anweisungsüberdeckung

Niedrig

Entdeckt knapp 1/5 der Fehler

Entdeckt dead code

Mit and. Verfahren kombinieren

C1, (branch coverage)

Zweigüberdeckung

Entdeckt ca. 1/3 aller Fehler und 80% der Kontrollflussfehler

DAS minimale Testkriterium

C2,

Bedingungsüberdeckung

Niedrig Umfasst i.Allg. nicht die C0- und C1-Überdeckung, da Bedingungen evtl. in Anweisungen neu berechnet werden

Mehrfach-Bedingungs-überdeckung

Hoch Umfasst Zweigüberdeckung

Aufwand wächst stark

CGI,

Grenze-Inneres Test

Mittel Zielt auf komplexe Schleifen

Nur als Ergänzung

C∞, (path coverage)

Pfadüberdeckung

Sehr hoch

Entdeckt ca. 2/3 aller Fehler

In den meisten Fällen nicht praktikabel

Datenflusstest Mittel bis hoch

All c-uses deckt 1/2 aller Fehler auf

All p-uses deckt 1/3 aller Fehler auf

All defs deckt 1/4 aller Fehler auf

Zielt auf Variablen-Verwendung

C-uses findet viele Berechnungsfehler


Seite 21

TestenTestszenarien und Testfälle

Für jede der geplanten Testarten werden die Testszenarien (o. a. Testumfänge) in Form einer Liste von Testfällen festgelegt.

Für jeden Testfall gibt es dann eine Testanweisung und ein Testprotokoll, die häufig in einem(!) Formular zusammengefasst sind. Die Beschreibung eines Testfalls beinhaltet somit folgendes:

• Beschreibung des Testfalls und der dazugehörigen Testschritte incl. Testbedingungen und Testdaten• Name des Erstellers der Testanweisung• Name des Freigebenden der Testanweisung• Name des Testers• Name des Abnehmenden• Die zu testende Eigenschaft (Korrektheit, Bedienoberfläche, Performance, …)• Erwartetes Ergebnis• Tatsächliches Ergebnis (diese Information liegt natürlich erst nach der Testdurchführung vor)


Seite 22

TestenUnittest

• typgerechte Verwendung aller Datenobjekte (ungewollte Konvertierungen)• Objektverwendungsnachweise (Cross reference list, Aufrufhierarchie/-graph)• Datenflussanalyse von Programmobjekten (Variablen, Konstanten):

• Objekte werden vor ihrer Definition verwendet• Objekte werden mehrfach überschrieben, ohne vorher verwendet worden zu sein• Objekte werden definiert, ohne danach verwendet zu werden• “nur-lesbare” Objekte werden überschrieben: z.B. Prüfung durch den ANSI-C-Compiler bei Verwendung des Schlüsselworts CONST: char *strcpy (char *ziel, const char *quelle);

(der Speicherbereich quelle darf von der Funktion nicht verändert werden).

• Statisch unerreichbare Programmsequenzen (z.B. fehlendes GOTO bei vorh. Sprungmarken)• Hinweise auf krasse Programmierfehler (z.B. nicht terminierende Schleife)• Prüfung von Programmierkonventionen und Qualitätsstandards (z.B. Namensgebung, Schachtelungstiefe, Komplexität)


Seite 23

TestenUnittest (Komplexität, Überdeckung)

Komplexität: metric of McCabe: Cyclomatic Number is the maximum number of independent paths in a flowgraph

v(G) = e - n + 2p

v(G) - Cyclomatic Number of the flowgraph Ge - number of edges in Gn - number of nodes in Gp - number of connected components (if you have subprograms, p=1 in a single program)

1

43

2

5

...

...

IF a>b

THEN IF b>c

THEN p(a,b)

ELSE p(b,c);

Print(a,b,c);

v(G) = 8 - 7 + 2*1 = 3

Statement coverage:

1-2-3-5 und 1-2-4-5

Branch coverage:

1-5 (additional)

Überdeckung:


Seite 24

TestenIntegrationstest

• Syntaxprüfung der Schnittstellen (z.B. falsche Anzahl von Parametern oder nicht übereinstimmender Parametertyp), z.B. Prüfung der Argumente/aktuellen Parameter bei einem Funktionsaufruf unter Verwendung des Funktions-Prototypen zur Deklaration der Funktionen durch den ANSI-C-Compiler: float hoch (float zahl, int potenz)• Kopplungskategorisierung nach Myers, sechs Abstufungen für die interne Festigkeit eines Moduls (Cohesion), fünf Abstufungen für die Bindung zu anderen Moduln (Coupling)• Anzeige verdeckter Abhängigkeiten, Beispiel: Zwei Module verwenden (importieren) eine externe Variable, die von einem dritten Modul bereitgestellt wird, d.h. die Kopplung zwischen den beiden benutzenden Moduln ist nicht unmittelbar ersichtlich• Intermodulare Datenflussanalyse, Beispiel: Ein Parameter erhält vor dem Aufruf der Schnittstelle einen Wert und wird in der aufgerufenen Funktion sofort überschrieben, ohne vorher gelesen zu werden• Ausschöpfen der Parameterbereiche: Prüfung der Ausnahmebehandlungen und Grenzfälle (sind häufig in den Simulationen vernachlässigt worden), des Modulverhaltens bei Systemfehlern, der über Modulgrenzen hinweg realisierten Fehlerbehandlungen und der globalen Variablen• Überprüfen der Aufrufreihenfolge: systemweite Überprüfung auf Einhaltung vorgeschriebener Abläufe und Protokollierung der Abläufe einzelner Operationen• Funktionalitätsprüfung (Zusammenwirken von Teilfunktionen)

stat.

dyn.


Seite 25

TestenTestabschlusskriterien

Wenn mit den in der Testvorschrift festgelegten Testdatensätzen keine Fehler mehr gefunden werden• Sinnvolles Kriterium, wenn der Umfang des Prüflings eine systematische Auswahl von Testfällen mit ausreichender Überdeckung ermöglicht• Übliches Kriterium bei der Abnahme

Wenn die Prüfkosten pro entdecktem Fehler eine im voraus festgelegte Grenze überschreiten• Sinnvolles Kriterium für das Beenden des Systemtests• Setzt die Erfassung der Prüfkosten und der Anzahl gefundener Fehler voraus

Wenn während der Ausführung einer im voraus festgelegten Menge von Testfällen keine Fehler auftreten• Beispielsweise im Systemtest mit zufällig bestimmten Testdaten. Die Anzahl der hintereinander fehlerfrei auszuführenden Testfälle bestimmt sich aus der geforderten Zuverlässigkeit

Wenn die vorher festgelegte Obergrenze für die Fehlerdichte unterschritten wird• Muss mit statistischen Methoden bestimmt werden


Seite 26

Fehlerstatus Gesetzt durch Bedeutung

Neu Tester Neue Fehlermeldung (s. nä. Folie) wurde erfasst. Der Tester hat eine aus seiner Sicht sinnvolle Beschreibung und Klassifizierung eingetragen.

Offen Testmanager (TM) TM sichtet die Meldungen, bereitet sie für eine einheitliche Bewertung auf, löscht ggfs. Dubletten und weist die Meldung einem Entwickler zu.

Abgewiesen Testmanager Meldung wird als unberechtigt abgewiesen (kein Defekt im Testobjekt, Änderungswunsch, der nicht berücksichtigt wird).

Analyse Entwickler E. dokumentiert das Ergebnis der Problemanalyse (Ursache, Lösungs-möglichkeiten, geschätzter Korrekturaufwand) in Form von Kommentaren.

Beobachtung Entwickler Das Problem kann nicht nachvollzogen/ausgeschlossen werden. Meldung bleibt unerledigt, bis weitere Informationen/Erkenntnisse vorliegen.

Korrektur Projektmanager Projektmanager entscheidet aufgrund der Analyse, dass die Korrektur er-folgen soll. Der zuständige Entwickler dokumentiert die Art der Korrektur.

Test Entwickler Der zuständige Entwickler behebt das Problem. Die Softwareversion, in der die Korrektur verfügbar ist, wird angegeben.

Erledigt Tester Tester wiederholt im nächstmöglichen Testzyklus den fehleraufdeckenden Test und setzt bei erfolgreicher Fehlerbeseitigung den Endzustand.

Flop Tester Ergibt der Fehlernachtest, dass die Fehlerbeseitigung erfolglos oder ungenügend war, ist eine erneute Analyse notwendig.

TestenFehlermanagement beim Testen


Seite 27

Attribut Bedeutung

Nummer laufende, eindeutige Meldungsnummer

Testobjekt Identifikation der genauen Version des Testobjekts

Plattform Identifikation der HW-/SW-Plattform bzw. der Testumgebung, in der das Problem auftritt

Entdecker Identifikation des Testers (ggf. mit Teststufe), der das Problem meldet

Entwickler Name des für das Testobjekt verantwortlichen Entwicklers oder Teams

Erfassung Datum, ggf. Uhrzeit, an dem das Problem beobachtet wurde

Status (s. vo. Folie) Bearbeitungsfortschritt der Meldung; möglichst mit Kommentar und Datum

Klasse Klassifizierung der Schwere des Problems

Priorität Klassifizierung der Dringlichkeit einer Korrektur

Anforderung Verweis auf die (Kunden-)Anforderung, die wegen der Fehlerwirkung nicht erfüllt oder verletzt ist

Fehlerquelle Soweit feststellbar, die Projektphase, in der die Fehlhandlung begangen wurde (Analyse, Design, Programmierung); nützlich zur Planung prozessverbessernder Maßnahmen

TestenFehlermeldung: Identifikation und Klassifizierung


Seite 28

TestenAnhang: Lösung der Übungsaufgabe von Seite 8

Vollständige Funktionsüberdeckung beinhaltet:

Aktivierung der Funktionen Prüfen, Klassifizieren, Skalieren und Zeichnen

Vollständige Ausgaben- und Ausnahmenüberdeckung benötigen Äquivalenzklassen für

Erzeugen der Ausgaben

• kein Dreieck

• gleichseitiges Dreieck

• gleichschenkliges Dreieck

• unregelmäßiges Dreieck

Erzeugung der Ausnahmesituationen

• ungültige Eingabe


Seite 29


Klasse Subklasse Repräsentant

kein Dreieck b größte Seite 4.25, 2, 1.3

b größte Seite 1.3, 4.25, 2

c größte Seite 2, 1.3, 4.25

gleichseitiges Dreieck 4.2, 4.2, 4.2

gleichschenkliges Dreieck a = b 4.71, 4.71, 2

b = c 3, 5.6, 5.6

a = c 11, 6, 11

unregelmäßiges Dreieck α spitz, β spitz 3, 5, 6

α spitz, β rechtwinklig 3, 5, 4

α spitz, β stumpf 3, 6, 4

β spitz, γ spitz 6, 3, 5

β spitz, γ rechtwinklig 4, 3, 5

β spitz, γ stumpf 4, 3, 6

γ spitz, α spitz 5, 6, 3

γ spitz, α rechtwinklig 5, 4, 3

γ spitz, α stumpf 6, 4, 3

Klasse Subklasse Repräsen-tant

Ungültige Eingabe

Negative Zahlen

2.3, -1.5, 3

Text statt Zahl

2.3, 1.5, xrfk.q

Unvollständige Eingabe

2.3, 1.5


Seite 30


Grenzfall Subklasse Testwert

kein Dreieck a = b = c = 0 0, 0, 0

a = b + c 6, 2, 4

b = a + c 2, 6, 4

c = a + b 2, 4, 6

Sehr flaches Dreieck c = a + b – ε, ε sehr klein 3, 4, 6.999999999999

b = a + c – ε, ε sehr klein 3, 6.999999999999, 4

Sehr steiles Dreieck c klein, a = b sehr groß 107, 107, 5

Grenzwertanalyse

testen Übersicht

Documents