4. Testentwurfsverfahren Flashcards

1
Q

Testentwicklungsverfahren

A
  1. Testanalyse
  2. Testentwurf
  3. Testimplementierung
  4. Testausführungsplan
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Testbedingung

A

Während der Testanalyse werden die dem Test zugrunde liegenden Dokumente analysiert, um festzustellen, was getestet werden muss, d.h. die Testbedingungen festzulegen.

Eine Testbedingung ist definiert als eine Einheit oder ein Ereignis, z.B.

  • eine Funktion,
  • eine Transaktion,
  • ein Qualitätsmerkmal oder
  • ein strukturelles Element,

das durch einen oder mehrere Testfälle verifiziert werden kann.

Indem Testbedingungen auf Spezifikationen und Anforderungen zurückgeführt werden, erlauben sie sowohl eine effektive Auswirkungsanalyse (impact analysis) bei geänderten Anforderungen als auch die Bestimmung einer Anforderungsüberdeckung, bezogen auf eine bestimmte Menge von Tests.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Testentwurf

A

Während des Testentwurfs werden die Testfälle und Testdaten definiert und dokumentiert.

Ein Testfall besteht aus

  • einer Menge von Eingabewerten
  • den für die Ausführung notwendigen Vorbedingungen,
  • der Menge der vorausgesagten Ergebnisse und
  • den erwarteten Nachbedingungen,

definiert mit dem Ziel, ein oder mehrere Testziele oder Testbedingungen abzudecken.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

IEEE Standard 829-1998

A

Der IEEE Standard 829-1998 (‘Standard for Software Test Documentation’) beschreibt die Inhalte von Testentwurfsspezifikationen (inkl.Testbedingungen) und Testfallspezifikationen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Erwartete Ergebnisse

A

Erwartete Ergebnisse sollten im Rahmen der Spezifikation eines Testfalls ermittelt werden, und Ausgaben, Änderungen von Daten und Zuständen sowie alle anderen Folgen des Tests enthalten.

Falls die erwarteten Ergebnisse nicht definiert wurden, könnte ein plausibles, aber fehlerhaftes Ergebnis fälschlicherweise als richtig angesehen werden.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Testimplementierung

A

Während der Testimplementierung werden die Testfälle entwickelt, implementiert, priorisiert und in einer Testablaufspezifikation (Drehbuch oder Testskript) zusammengefasst (IEEE STD 829-1998).

Das Testdrehbuch legt die Reihenfolge der Aktionen für die Ausführung eines Tests fest.

Wenn Tests unter Verwendung eines Testausführungswerkzeugs durchgeführt werden, ist die Reihenfolge der Aktionen in einem Testskript festgelegt (in einem automatisierten Testszenario).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Testausführungsplan

A

Die verschiedenen manuellen und automatisierten Testskripte werden anschließend in einem Testausführungsplan zusammengestellt, der die Reihenfolge festlegt, in der die verschiedenen Testszenarios (und gegebenenfalls die automatisierten Testskripte) ausgeführt werden.

Der Testausführungsplan berücksichtigt Faktoren wie

  • Regressionstests,
  • Priorisierung und
  • logische Abhängigkeiten.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Testentwurfsverfahren

A

Das Ziel von Testentwurfsverfahren ist es,

  • Testbedingungen,
  • Testfälle und
  • Testdaten

zu ermitteln.

Ein klassischer Ansatz unterscheidet Testentwurfsverfahren in Black-Box- oder White-Box-Verfahren.

Dieser Lehrplan bezeichnet spezifikationsorientierte Testentwurfsverfahren als Black-Box-Verfahren, und strukturbasierte Testentwurfsverfahren als White-Box-Verfahren. Zusätzlich werden die erfahrungsbasierten Testentwurfsverfahren abgedeckt.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Black-Box-Verfahren

A

Black-Box-Verfahren (die auch spezifikationsorientierte Verfahren genannt werden) stellen einen Weg dar, Testbedingungen, Testfälle oder Testdaten für eine Komponente oder ein System aufgrund der Analyse der zugrunde liegenden Dokumentation der Testbasis abzuleiten und auszuwählen.

Diesumfasst funktionales und nicht-funktionales Testen.

Black-Box-Testverfahren verwenden per Definition keine Informationen über die interne Struktur der Komponente oder des Systems, welches zu testen
ist.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

White-Box-Verfahren

A

White-Box-Verfahren (auch strukturelle oder strukturbasierte Verfahren) stützen sich auf eine Analyse der Struktur einer Komponente oder eines Systems.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Gemeinsame Merkmale der

spezifikationsorientierten Testentwurfsverfahren

A
  • Modelle, ob formal oder nicht formal, werden zur Spezifikation des zu lösenden Problems, der Software oder ihrer Komponente herangezogen.
  • Testfälle können systematisch von diesen Modellen abgeleitet werden.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Gemeinsame Merkmale

der strukturbasierten Testentwurfsverfahren

A
  • Informationen über den Aufbau der Software werden für die Ableitung von Testfällen verwendet, beispielsweise der Code und Informationen des Detailentwurfs (detailed design).
  • Der Überdeckungsgrad der Software kann für vorhandene Testfälle gemessen werden.
  • Weitere Testfälle können zur Erhöhung des Überdeckungsgrads systematisch abgeleitet werden.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Gemeinsame Merkmale

der erfahrungsbasierten Testentwurfsverfahren

A
  • Das Wissen und die Erfahrung von Menschen wird zur Ableitung der Testfälle genutzt.
  • Das Wissen von Testern, Entwicklern, Anwendern und Betroffenen über die Software, ihre Verwendung und ihre Umgebung ist eine Informationsquelle.
  • Das Wissen über wahrscheinliche Fehlerzustände und ihre Verteilung ist eine weitere Informationsquelle.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Spezifikationsorientierte

oder

Black-Box Verfahren

A
  1. Äquivalenzklassenbildung
  2. Grenzwertanalyse
  3. Entscheidungstabellentest
  4. Zustandsbasierter Test
  5. Anwendungsfallbasierter Test
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Äquivalenzklassenbildung

A

Bei der Äquivalenzklassenbildung werden Eingabewerte(gültige und ungültige) für die Software oder das System in Gruppen eingeteilt, bei denen man von einem ähnlichen Verhalten ausgeht, so dass es wahrscheinlich ist, dass sie auf dieselbe Weise verarbeitet werden.

  • Ausgabewerte,
  • interne Werte,
  • Benutzereingaben
  • zeitbezogene Werte (d.h. vor oder nach einem Ereignis) und
  • für Schnittstellenparameter(d.h. integrierte Komponenten, die beim Integrationstest getestet werden)

Äquivalenzklassenbildung kann in allen Teststufen angewandt werden.

Das Ziel ist, durch Bildung von Äquivalenzklassen eine hohe Fehlerentdeckungswahrscheinlichkeit bei minimaler Anzahl von Testfällen zu erreichen.

Äquivalenzklassenbildung kann eingesetzt werden, um Überdeckungsziele in Bezug auf Eingabe oder Ausgabewerte zu erreichen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Grenzwertanalyse

A

Da das Verhalten an der Grenze jeder Äquivalenzklasse mit einer höheren Wahrscheinlichkeit fehlerhaft ist als das Verhalten innerhalb der Klasse, sind solche Grenzen ein Bereich, in dem Testen wahrscheinlich
Fehlerzustände aufdecken wird.

Der größte und der kleinste Wert einer Klasse sind deren
Grenzwerte. Beim Entwurf von Testfällen wird ein Test für jeden
Grenzwert(gültige und ungültige) gewählt.

Grenzwertanalyse kann in allen Teststufen angewandt werden.

Sie ist vergleichsweise einfach anzuwenden und das Potenzial, Fehlerzustände aufzudecken, ist hoch.

Detaillierte Spezifikationen sind bei
der Bestimmung der interessanten Grenzen hilfreich.

17
Q

Entscheidungstabllentest

Wofür?

A

Entscheidungstabellen sind eine gute Möglichkeit, um Systemanforderungen zu erfassen, die logische Bedingungen enthalten und um den internen Systementwurf zu dokumentieren.

Sie können zur Erfassung komplexer, von einem System umzusetzenden Regeln in Geschäftsprozessen verwendet werden.

Beim Erstellen einer Entscheidungstabelle wird die Spezifikation analysiert, und die Bedingungen und Aktionen des Systems werden ermittelt.

18
Q

Entscheidungstabellentest

Wie?

A

Die Entscheidungstabelle enthält die auslösenden Bedingungen, oft Kombinationen von „wahr“ und „falsch“ für alle Eingabebedingungen und die daraus resultierenden Aktionen für jede Kombination der Bedingungen.

Jede Spalte der Tabelle entspricht einer Regel im Geschäftsprozess, die eine eindeutige Kombination der Bedingungen definiert, die wiederum
die Ausführung der mit dieser Regel verbundenen Aktionen nach sich zieht.

Der üblicherweise bei Entscheidungstabellentest verwendete Standardüberdeckungsgrad besagt, dass wenigstens ein Testfall
pro Spalte in der Tabelle benötigt wird, was in der Regel die Abdeckung aller Kombinationen der auslösenden Bedingungen umfasst.

19
Q

Entscheidungstabellentest

Stärk

A

Die Stärke des Entscheidungstabellentests ist, dass er Kombinationen von Bedingungen ableitet, die andernfalls beim Test möglicherweise nicht ausgeführt worden wären.

Er kann in allen Situationen angewandt werden, in denen die Abläufe der Software von mehreren logischen Entscheidungen abhängen.

20
Q

Zustandsbasierter Test

A

Ein System kann in Abhängigkeit von aktuellen Gegebenheiten oder von seiner Vorgeschichte (seinem Zustand) unterschiedliche Reaktionen zeigen.

In diesem Fall kann dieser Aspekt des Systems mit einem Zustandsdiagramm dargestellt werden. Es ermöglicht dem Tester, die Software darzustellen in Bezug auf

  • ihre Zustände,
  • Übergänge zwischen den Zuständen,
  • Eingaben oder
  • Ereignisse, die die Zustandsübergänge (transitions) auslösen, und
  • Aktionen, die aus den Übergängen folgen können.

–> können ungültige Übergänge aufzeigen

Die Zustände des Systems oder Testobjekts sind einzeln unterscheidbar, eindeutig identifizierbar und endlich in ihrer Anzahl.

21
Q

Anwendungsfallbasierter Test

A

Tests können aus Anwendungsfällen (use cases) abgeleitet werden.

Ein Anwendungsfall beschreibt die Interaktionen zwischen den Akteuren (Anwender oder Systeme), die ein aus Sicht des Anwenders oder Kunden gewünschtes und wahrnehmbares Ergebnis zur Folge haben.

Anwendungsfälle können auf einer abstrakten Ebene (fachlicher Anwendungsvorfall, technologiefrei, Geschäftsprozessebene) oder auf einer Systemebene (Systemanwendungsfall auf Ebene der Systemfunktionalität) beschrieben werden.

Jeder Anwendungsfall hat Vorbedingungen, die erfüllt sein müssen, damit der Anwendungsfall erfolgreich durchgeführt werden kann.

Jeder Anwendungsfall endet mit Nachbedingungen, den beobachtbaren Ergebnissen und dem Endzustand des Systems, wenn der Anwendungsfall vollständig abgewickelt wurde.

Ein Anwendungsfall hat üblicherweise ein Hauptszenario (das wahrscheinlichste Szenario) und alternative Szenarien.

22
Q

Anwendungsfallbasierter Test

Stärken

A

Anwendungsfälle beschreiben die „Prozessabläufe” durch das System auf Grundlage seiner voraussichtlich tatsächlichen Verwendung.

–> Praxiseinsatzes des Systems Fehlerzustände in den Prozessabläufen aufdecken.

  • -> Abnahmetests mit Kunden-/Anwenderbeteiligung
  • -> Fehlerzustände im Umfeld der Integration aufdecken

Das Entwerfen von Testfällen auf Basis von Anwendungsfällen kann mit anderen spezifikationsorientierten Testentwurfsverfahren
kombiniert werden.

23
Q

Strukturbasierter Test

oder White-Box-Verfahren

Strukturebenen

A
  • Komponentenebene: Die Struktur der Softwarekomponente, d.h. Anweisungen, Entscheidungen, Zweige oder sogar einzelne Pfade
  • Integrationsebene: Die Struktur kann ein Aufrufgraph sein (ein Diagramm, das zeigt, welche Module andere Module aufrufen)
  • Systemebene: Die Struktur kann die Menüstruktur sein, Geschäftsprozesse oder die Struktur einer Webseite

Ziel: Codeüberdeckung

24
Q

Strukturbasierter Test

oder White-Box-Verfahren

Anweisungstest

A

Im Komponententest steht Anweisungsüberdeckung für die Messung des prozentualen Anteils von allen Anweisungen einer Komponente, welche durch eine Testsuite ausgeführt wurden.

Das Anweisungstestverfahren leitet Testfälle so ab, dass bestimmte Anweisungen ausgeführt werden, in der Regel mit dem Ziel die Anweisungsüberdeckung zu erhöhen.

25
Q

Strukturbasierter Test

oder White-Box-Verfahren

Anweisungsüberdeckung

A

Anweisungsüberdeckung ist bestimmt durch die Anzahl ausführbarer Anweisungen, die durch entworfene oder ausgeführte Testfälle überdeckt sind, dividiert durch die Anzahl aller ausführbaren Anweisungen des Programmcodes im Test.

26
Q

Strukturbasierter Test

oder White-Box-Verfahren

Entscheidungstest

A

Beim Entscheidungstestverfahren werden Testfälle abgeleitet, um spezifische Entscheidungen zu durchlaufen.

Zweige nehmen ihren Anfang in Entscheidungspunkten des Programmcodes und zeigen die Übertragung der Steuerung zu verschiedenen Stellen im Code.

Der Entscheidungstest ist eine Form des kontrollflussbasierten Tests, da er einem speziellen Kontrollfluss durch die Entscheidungspunkte folgt.

27
Q

Strukturbasierter Test

oder White-Box-Verfahren

Entscheidungsüberdeckung

A

Die Entscheidungsüberdeckung, die mit dem Zweigtest verwandt ist, ist die Messung des prozentualen Anteils eines Entscheidungsergebnisses (z.B. „wahr“ und „falsch“ bei einer IF-Anweisung), welche durch eine Testsuite ausgeführt wurden.

Die Entscheidungsüberdeckung ist bestimmt durch die Anzahl aller Entscheidungsausgänge, die durch entworfene oder ausgeführte Testfälle überdeckt sind, dividiert durch die Anzahl aller Entscheidungsausgänge
des Programmcodes im Test.

Entscheidungsüberdeckung ist stärker als Anweisungsüberdeckung:
100% Entscheidungsüberdeckung schließt 100% Anweisungsüberdeckung ein, aber nicht umgekehrt.

28
Q

Andere strukturbasierte Verfahren

A

Über Entscheidungsüberdeckung hinaus gibt es stärkere strukturelle Überdeckungsgrade, beispielsweise Bedingungsüberdeckung und Mehrfachbedingungsüberdeckung.

Das Konzept der Überdeckungsgrade kann auch auf andere Teststufen übertragen werden. Beispielsweise wird auf der Integrationsebene der prozentuale Anteil von Modulen, Komponenten oder Klassen, die durch eine Testsuite ausgeführt wurden, als Modul-, Komponenten- oder Klassenüberdeckung bezeichnet.

Werkzeugunterstützung ist beim strukturbasierten Test von Code sehr hilfreich.

29
Q

Erfahrungsbasierte Verfahren

A

Erfahrungsbasiertes Testen bezeichnet Tests, die durch das Können und die Intuition des Testers und aus seiner Erfahrung mit ähnlichen Applikationen und Technologien abgeleitet werden.

Wenn es zur Unterstützung systematischer Verfahren eingesetzt wird, kann dieses Verfahren zur Ermittlung spezieller Tests nützlich sein, die von formalen Verfahren nicht leicht erfasst werden, insbesondere wenn erfahrungsbasiertes Testen nach den formaleren Ansätzen eingesetzt wird.

Abhängig von der Erfahrung des Testers kann die Wirksamkeit dieses Verfahrens sehr stark variieren.

30
Q

Erfahrungsbasierte Verfahren

Error guessing

A

Ein weit verbreitetes erfahrungsbasiertes Testverfahren ist die intuitive Testfallermittlung (error guessing). Gewöhnlich sehen Tester Fehler auf Grund ihrer Erfahrung voraus.

Eine strukturierte Herangehensweise an das Verfahren der intuitiven Testfallermittlung ist es, eine Liste möglicher Fehlerzustände
zu erstellen, und dann Testfälle zu entwerfen, die auf diese Fehlerzustände abzielen.

Dieser systematische Ansatz wird Fehlerangriff (fault attack) genannt. Die Liste der Fehlerzustände und Fehlerwirkungen kann erstellt werden auf der Basis von

  • Erfahrungen,
  • verfügbaren Daten über Fehlerzustände und Fehlerwirkungen
  • und von Allgemeinwissen darüber, warum Software sich falsch verhalten kann.
31
Q

Erfahrungsbasierte Verfahren

Exploratives Testen

A

Exploratives Testen ist gleichzeitiger

  • Testentwurf,
  • Testdurchführung,
  • Testprotokollierung und
  • Lernen,

auf Grundlage einer Test-Charta, der die Testziele zu entnehmen sind.

Es wird innerhalb festgelegter Zeitfenster durchgeführt.

Es ist ein Ansatz, der sich besonders gut eignet, wenn es nur wenige oder ungeeignete Spezifikationen gibt, unter hohem Zeitdruck, oder um andere, formalere Testverfahren zu unterstützen oder zu ergänzen.

Es kann auch zur Überprüfung des Testprozesses dienen und helfen sicherzustellen, dass die schwerwiegendsten Fehlerzustände gefunden werden.

32
Q

Auswahl von Testverfahren

A

Faktoren

  1. Art des Systems
  2. regulatorischen Anforderungen
  3. Kunden- oder Vertragsanforderungen
  4. Risikostufe
  5. Risikotyp
  6. Testziel
  7. verfügbarer Dokumentation
  8. Wissen der Tester
  9. Zeit und Geld
  10. Softwareentwicklungsmodell
  11. Anwendungsfallmodelle
  12. frühere Erfahrungen mit gefundenen Fehlerzustandsarten

Beim Erstellen von Testfällen benutzen Tester gewöhnlich eine Kombination von Testverfahren einschließlich prozessgetriebener, regelbasierter und datengetriebener (data-driven) Verfahren, um eine angemessene Überdeckung des Objekts im Test zu gewährleisten.

33
Q
A