5. Dynamische QS: Testen

• testende Verfahren, SW-Test, Test

• Programmcode ausgeführt, konkrete Eingabewerte übergeben und das Verhalten bzw. das erzeugte Ergebnis bewertet

  • diagnostische Maßnahmen

  
  

1. entwicklungsbegleitend

2. Ab dem ersten SW-Artefakt

3. Komponententest, Integrationstest, Systemtest, Abnahmetest

4. QZ und aktuelle Teststufe

• Handlungsanweisung

• Mindestens:

  • Vorbedingungen,

    die vor Prüfschritt sichergestellt werden müssen;

  • Testdaten bzw. Testaktionen,

    die während des Prüfschrittes eingegeben bzw. durchgeführt werden;

  • Nachbedingungen,

    deren Erfüllung nach Prüfschritt geprüft wird

  • beschreibende Daten zum Testfall,

    wie Name, ID, betreffende Komponente, Funktion oder Eigenschaft, die geprüft wird, Anwendungsfall oder Name des Erstellers.

    (Zum Zweck der Dokumentation, Reproduzierbarkeit, Nachvollziehbarkeit)

• Anhand der Art und Weise, wie Testfälle erzeugt werden

  • Black-Box-Test

  • White-Box-Test

1. Definition:

   Testverfahren, bei dem Testfälle ausschließlich auf Basis der Anforderungen und Spezifikationen erstellt werden, ohne Kenntnis der internen Struktur oder des Codes.

2. Merkmale:

   • Keine Kenntnis des Programmiercodes nötig

   • Testet das Verhalten des Systems aus Anwendersicht

1. Beispiele für Methoden:

• Äquivalenzklassenbildung

• Grenzwertanalyse

• Use-Case-Tests

1. Prüfung aller in der Spezifikation geforderten Funktionen und Eigenschaften zu einem System oder einer Systemkomponente

2. Fokus auf Eingaben und erwartete Ausgaben -> Was ist das Ergebnis?

3. 1. Tester liest und interpretiert die Spezifikation.

   2. Erstellt anhand Interpretation Testfälle und führt diese aus

   3. Beurteilung Testergebnisse

4. Zusammenspiel verschiedener Systemkomponenten, da der Fokus auf Erfüllung der geforderten Funktionen liegt

   —> Einsatz Integrations-, System- und Abnahmetests

5. anwendernah

6. Spezifikation

   • Auf Basis der Spezifikation wird

     • der Grad der Testabdeckung bestimmt;

     • der Testfall erstellt

     • Testergebnisse beurteilt

Definition: Testverfahren, bei dem Testfälle basierend auf der internen Struktur, dem Aufbau und dem Quellcode des Systems erstellt werden.

Merkmale:

• Fokus auf die Überprüfung von Kontrollflüssen, Pfaden und Bedingungen

• Kenntnis des Codes erforderlich

• Testet interne Logik und Struktur

Beispiele für Methoden:

• Pfadüberdeckung

• Anweisungsüberdeckung

• Bedingungsüberdeckung

1. möglichst große Ab­deckung der im Programmcode implementierten Anweisungen und Kontrollstrukturen (wie if, while, for, switch),

2. 1. Teil des Programmcodes implementieren

   2. Analyse Codestruktur

   3. Auf dieser Basis werden dann Testfälle formuliert (möglichst große Abdeckung)

   4. Nach der Ausführung werden die Ergebnisse ausgewertet und bei Bedarf der Programmcode angepasst, bevor erneut getestet wird.

   —> selbe Person

3. begleitend zur Implementierung und bei Komponenten- und Integrationstests

• Dies ist das Maß wie vollständig die Menge von Testfällen das System testet.

• Der konkrete Messwert ist abhängig von der Art des Tests und der gewählten Technik der Testfallerstellung.

• keine vollständige (nicht möglich), sondern eine kostenoptimale Qualitätssicherung

• Stichproben

• unendliche viele Eingabewerte —> unendlich viele Zustände

• Korrektheit

• Auswahl geeigneter Testfälle und Testdaten, damit mit möglichst wenig Aufwand möglichst hohe Testabdeckung erreicht werden kann.

• aus den fachlichen Anwendungsfällen

  • Use-Case-Diagramme

  • mindestens ein Testfall zu jedem Anwendungsfall

  • mit Aktivitätsdiagrammen

• Wertbeitrag:

  Wie hoch ist der Beitrag dieser Funktion zur Wertschöpfungskette?

• Nutzungshäufigkeit:

  Wie viele Nutzer greifen wie häufig auf die Funktion zu?

• Schadenspotential:

  Welcher Schaden kann durch nicht identifizierte Fehler in der Funktion entstehen?

• Typische Fehler:

  Welche Funktionen bergen häufig Fehler in der Umsetzung? Wo sind die typischen Schwachstellen bei vergleichbaren Alt- oder Konkurrenzsystemen?

• Geforderte Testabdeckung:

  Welcher Grad der Testabdeckung ist für die fachliche Ebene tatsächlich gefordert?

• Funktionen

• Anweisungsüberdeckung

  Jede Funktion wird mindestens 1 x aufgerufen.

• Zweigüberdeckung

  Jeder Kontrollflusspfeil wird mindestens 1 x durchlaufen.

• Bedingungsüberdeckung

  Jede Bedingung wird mindestens 1 x zu WAHR und 1 x zu FALSCH ausgewertet.

• Pfadtest

  Jeder mögliche Pfad durch den Use Case wird vollständig („am Stück“) durchlaufen, dabei werden mögliche Schleifen berücksichtigt.

1. Technik zur Auswahl konkreter Testdaten.

   Dabei werden alle möglichen Eingabewerte, die zu einer Funktion gemacht werden können (zu gleichem Systemverhalten führen), in sogenannte Äquivalenzklassen eingeteilt.

2. Nicht alle Eingabewerte testen, sondern nur jeweils ein beliebig ausgewählter Vertreter aus jeder Äquivalenzklasse

   —> weniger Testdaten pro Testfall

3. Grundsätzlich für alle Tests, in denen Daten übergeben oder Funktionen aufgerufen werden

4. Beispiele

   • Eine oder mehrere Bedingungen, die erfüllt werden müssen

   • Festgelegter Wertebereich

   • Anzahl von Elementen einer Menge ( Anzahl der Werte)

   • Auswahl Elemente einer Menge, die jeweils unterschiedlich behandelt werden

5. Testdaten müssen nicht disjunkt sein

1. Äquivalenzklassen für jeden Eingabeparameter der Funktion bzw. jedes GUI-Element der Dialogmaske bestimmt und eindeutig gekennzeichnet.

2. Testfälle erstellen, mit denen alle gültigen Äquivalenzklassen abgedeckt werden

   —> Ziel: möglichst viele Äquvalenzklassen in möglichst wenig Testfälle

3. Testfälle erstellen, mit denen alle ungültigen Äquivalenzklassen abgedeckt werden

   —> Unterschied: pro Testfall nur eine ungültige Äquivalenzklasse

   —> einfachere Identifizierung bei Fehlschlag

4. Erstellen konkreter Eingabedaten auf Basis der ausgewählten Äquivalenzklassen für jeden Testfall

1. Vorteile

   • einfache Technik zur Ermittlung von Testdaten und Testfällen

   • Einsatz für jede technische oder fachliche Funktion, die Eingabedaten erwartet

   • einfache Erstellung der Testfälle als auch eine intuitive Dokumentation aufgrund Tabellen

2. Nachteile

   • Keine Berücksichtigung fachlicher Abhängigkeiten

   • ungeeignet für Komponenten/ Systeme, deren Verhalten von internen Zuständen abhängig ist

1. Technik zur Auswahl von konkreten Eingabedaten

2. Beobachtung, dass Softwarefehler häufig in dem Grenzbereich liegen, der den Übergang von gültigen zu ungültigen Eingabewerten darstellt, d. h. an den Grenzen von Äquivalenzklassen

3. in Kombination mit der Äquivalenzklassenbildung

4. Berücksichtigung gültiger und ungültiger Werte, die an den Grenzen von Äquivalenzklassen liegen.

5. jeweils ein Vertreter der Äquivalenzklasse im mittleren Wertebereich als Testdaten

   —> mehr Testfälle

   —> Einsatz verschiedener Grenzwerte, um Menge der Testfälle niedrig zu halten

1. bei Systemen oder Systemkomponenten eingesetzt, deren Verhalten maßgeblich durch einen internen fachlichen oder technischen Zustand gesteuert

2. - fachlich: Phasen in Lebenszyklen von Geschäftsobjekten (wie: beantragt, angenommen, abgelehnt) oder Prozessen (wie: eröffnet, Gutachten beauftragt, Schaden bewertet, Schaden reguliert)

   - technisch: interne Zustände von Systemkomponenten; Protokollen an technischen Schnittstellen

3. für White-Box-Tests als auch für Black-Box-Tests eingesetzt

4. - Ob definierte Zuständen über die Zustandsübergänge erreicht werden

   —>explizit auch die Nicht-Unterstützung von nicht-vorgesehenen Zustandsübergängen durch das System geprüft.

   
   

1. Erstellen einer Zustandsübergangstabelle

2. Ausfüllen der Tabelle

3. Fehlerzustände in Tabelle eintragen

4. Testfälle aus Tabelle ableiten

1. Vorteile

   - leichte Anwendung —> weit verbreitet

   - Zustandsübergangstabellen: Testfälle leicht ableiten & Testabdeckung veranschaulichen

   
   

   
   

   Nachteile

   • Zustandsübergangstabelle bei zuvielen zu testenden Zuständen schnell unübersichtlich

   • fachliche Funktionen, die ihre Zustände nicht ändern werden vergessen

1. Testdaten, die als Eingabewerte für zu testende Funktionen genutzt werden

2. Beispiele:

   • Test von Benutzeroberflächen mit vielen Eingabeelementen

   • für das Testen des Datenaustausches über technische Schnittstellen

3. Erzeugung zufälliger Werte im Rahemn eines gegebenen Wertebereichs von EIngabeparametern

4. - Grenzen von Wertebereichen mit der Äquivalenz­klassenbildung ermitteln und die Festlegung der konkreten Eingabewerte über Zufallstestdaten erfolgen

   - komplexe Zufallstestdaten auf Grundlage bereits bestehender Testdatensätze

5. Vorteile:

   • generieren vieler verschiedener Testdatensätze mit geringem Aufwand

   • durch automatische Erzeugung durch Testdatengenerator können menschliche Fehler ausgeschlossen werden

6. Nachteile

   • keine Erzeugung realistischer Daten

     —> Auwand Prüfung auf Nutzen individuell zu entscheiden

     —> Häufig Ergänzung, nicht als einzige Technik ausreichend