Qualitätssicherung – Software Tests

Qualitätssicherung – Software Tests

Allgemeine Erläuterungen

Softwarefehler entstehen zum einen durch menschliche Fehler, zum anderen aber auch bei veränderten Umgebungsbedingungen, wenn sich Entwicklungsumgebung und die Eigenschaften des Produktivsystems in seinen grundlegenden Eigenschaften voneinander unterscheiden. Mit dem Ziel eine Aussage über die Einsatztauglichkeit der Software zu formulieren, werden Tests zum Aufdecken von Fehlern und Feststellen, ob die Anforderungen an die Software erfüllt sind, durchgeführt.

Tests sollten im Idealfall noch bevor der erste Programmcode geschrieben wurde definiert werden und während der Entwicklung regelmäßig zu festgelegten Zeitpunkten durchgeführt werden. Durch diese Methode wird zum einen versucht, Fehler noch vor ihrer Entstehung zu vermeiden sowie im Fehlerfall deren Wirkung frühzeitig vorzubeugen und somit die Qualität der Software zu sichern. Zum anderen erzeugt dieses Vorgehen Vertrauen in die Funktionsfähigkeit der Anwendung und ihrer Praxistauglichkeit.

Bei Durchführung der Software Tests wird die Anwendung zum einen auf ihre Funktionalität hin untersucht. D.h. es wird den Fragen nachgegangen, ob alle geforderten Funktionen vorhanden sind und diese korrekt ausgeführt werden. Für jede Funktion muss mindestens ein Testfall definiert werden. Dabei werden häufig Verarbeitungsfehler, fehlende Funktionen und Fehlverhalten bei Grenzwerten festgestellt.

Des Weiteren finden Robustheitstests statt, wobei die Software auf ihre Unanfälligkeit bei Fehleingaben überprüft wird. Dies geschieht anhand von Negativtests (falsche bzw. unzulässige Eingabewerte). Die dadurch produzierten Falscheingaben können sich auf weitere Orte im Verarbeitungsfluss der Anwendung auswirken und dort Fehler und Abstürze verursachen.

Testprozess

Die Bearbeitung eines Testprozesses lässt sich in der Regel in verschiedene Phasen einteilen. Die dabei durchgeführten Testaktivitäten müssen nicht nacheinander abgearbeitet werden und können sich zeitlich überlappen:

  • Planung und Steuerung
  • Testanalyse und Testdesign
    • Review der Testbasis
    • Identifizierung der Testanforderungen und der benötigten Testdaten
    • Testentwurf/Testfalldesign
    • Testbarkeit der Anforderungen
    • Organisation der benötigten Testumgebung
    • Testinfrastruktur und ggf. Testwerkzeuge
  • Testrealisierung und Testdurchführung
  • Testauswertung und Bericht
  • Testabschluss

Testfall

Anforderungen

Um einen Testfall konkret formulieren zu können, ist es hilfreich sich an bestimmten Grundanforderungen zu orientieren. Zum einen sollte geprüft werden, ob die geforderten Eigenschaften durch die vorhandenen Funktionen umgesetzt sind und sich diese für die vorgesehene Verwendung eignen. Des Weiteren muss gewährleistet sein, dass diese Funktionen korrekt ablaufen und ein fehlerfreies Zusammenspiel mit der Systemumgebung gegeben ist. Darüber hinaus ist es wichtig zu kontrollieren, ob Normen und Vorschriften eingehalten wurden, die eventuell durch Gesetze und Bestimmungen erforderlich sind sowie dass Daten bzw. Programme vor Zugriffen oder Verlust geschützt sind.

 

Testfallentwurfsverfahren

 

White-Box-Verfahren

Beim White-Box-Verfahren werden Tests mit Kenntnissen über die innere Funktionsweise des zu testenden Systems entwickelt. Dabei werden auf Basis der Programmstruktur und des Codes auch nur diese Aspekte betrachtet.

Black-Box-Verfahren

Die Programmstruktur spielt bei der Erstellung von Tests nach dem Black-Box-Verfahren keine Rolle oder ist unbekannt. Die Testfälle werden nur aus den Spezifikationen bzw. den Anforderungen  heraus abgeleitet. Dabei steht die Funktionalität im Mittelpunkt der Betrachtung.

Folgende Entwurfstechniken finden typischerweise beim Black-Box-Verfahren Anwendung:

Äquivalenzklassenbildung

Bei der Äquivalenzklassenbildung werden die Definitionsbereiche der Werte betrachtet. Dabei werden Werte für die ein identisches Verhalten erwartet wird zu einer Äquivalenzklasse zusammengefasst. Bei der Testdurchführung wird nur ein Repräsentant der Äquivalenzklasse verwendet, da für diesen ein identisches Verhalten aller zugehörigen Werte erwartet wird. Es werden Klassen für gültige und ungültige Eingabewerte sowie für Werte mit Sonderbehandlung gebildet.

Beispiel:

Ein Programm verlangt die Eingabe eines Gewichtes in kg. Es wird immer auf eine Nachkommastelle gerundet. Eingaben unter 0,5 werden zu 0. Zulässig wären alle Zahlen größer oder gleich 0, unzulässig alle negativen Zahlen und nicht numerische Eingabe. Es ergeben sich folgende Äquivalenzklassen:

Gültige Äquivalenzklasse:               x >= 0
1. ungültige Äquivalenzklasse:          x < 0
2. ungültige Äquivalenzklasse:          x - nicht numerisch

 

Abschließend wird für jede Äquivalenzklasse ein Repräsentant gewählt und das erwartete Ergebnis festgelegt:

Variable Äquivalenzklasse Repräsentant
Gewicht AK1: x >= 0 1
AK2: x <= 0 -1
AK3: x nicht numerisch Vier

Tabelle 1 Beispiel Äquivalenzklassenbildung

 

Für die Qualität der Testfälle ist die Genauigkeit der Zerlegung in Äquivalenzklassen von enormer Wichtigkeit. Nicht erkannte Äquivalenzklassen können zu nicht erkannten Fehlerwirkungen führen. Für die Auswahl der optimalen Repräsentanten gilt es typische Werte, Problemwerte oder Grenzwerte zu finden.

Um die Gefahr der Fehlermaskierung zu vermeiden, dürfen die Repräsentanten ungültiger Äquivalenzklassen nicht mit Repräsentanten anderer ungültiger Äquivalenzklassen kombiniert werden. Diese sollten nur mit Äquivalenzklassen anderer Klassen mit gleichen Werten kombinierbar sein.

Mit Hilfe der Äquivalenzklassenbildung lassen sich systematische Testfälle erstellen, die auf Basis der Spezifikation gut die funktionalen Anforderungen an die Software erfassen, aber auch Fehler in Anforderungen aufdecken können. Des Weiteren ermöglicht sie die Anzahl der benötigten Testfälle zu reduzieren.

 

Grenzwertanalyse

Durch die Grenzwertanalyse wird die Äquivalenzklassenbildung mit einer Vorschrift zur Repräsentantenauswahl erweitert um Randbereiche intensiver zu testen, da sich bei diesen oft Fehlerwirkungen häufen. Um eine Grenzwertanalyse anwenden zu können, müssen sich für die zu untersuchende Äquivalenzklasse Grenzen für einen gültigen Wertebereich identifizieren lassen können.

 

Grenzwertbestimmung

Ist eine Äquivalenzklasse als einzelner numerischer Wert definiert, werden jeweils angrenzende Randwerte herangezogen:

Beispiel:          Äquivalenzklasse x=5 => Repräsentanten 4,5,6
Entscheidungstabellentest

Bei der Äquivalenzklassenbildung und Grenzwertanalyse werden die Eingabebedingungen isoliert betrachtet und die Abhängigkeiten der Eingabedaten nicht berücksichtigt. Sollen alle Kombinationen verwendet werden, kann es schnell zu einer Testfallexplosion kommen. Mit einem Ursache-Wirkungs-Graph und einer daraus abgeleiteten Entscheidungstabelle wird eine große Anzahl der möglichen Kombinationen systematisch reduziert.

Beispiel:

Regel 1 Regel 2
Bedingung 1 j j
Bedingung 2 n
Bedingung 3 n n
Aktion 1 x
Aktion 2 x
Aktion 3 x x

Tabelle 2 Beispiel Entscheidungstabellentest

 

Grenzwerte lassen sich durch Entscheidungstabellen schwer untersuchen, sodass eine Kombination von Entscheidungstabellen-Testfällen mit Testfällen aus Grenzwertanalyse notwendig ist.

Konstellationen von Eingaben, die mit anderen Verfahren nicht gefunden werden, können so systematisch ermittelt und Testfälle sowie Testendekriterien einfach hergeleitet werden. Bei der Berücksichtigung vieler Ursachen entstehen jedoch auch komplexe, umfangreiche Resultate, sodass sich diese Methode hauptsächlich für Projekte mit in kleine Teile aufteilbare Spezifikation als sinnvoll erweist.

Zustandsbezogenes Testen

Bei zustandsbezogenem Testen werden verschiedene Zustände, die ein Objekt während der Ausführung einnehmen kann in Zustandsmodellen abgebildet.

Bei den bisher vorgestellten Verfahren werden nur Ein-/Ausgabeverhalten laut Spezifikation berücksichtigt. Die verschiedenen Zustände des Testobjektes bleiben außer Betracht (z.B. Höhe der Einnahmen in einer Kasse).

Als Hilfsmittel zur Testfallerstellung dient ein Übergangsbaum. Dabei werden alle Zustände und mögliche Übergangsfunktionen in Baum-Form dargestellt. Der Anfangszustand ist die Wurzel des Baumes. Jeder Zustand der nach dem Ausgangszustand folgen kann wird zu einem neuen Knoten und mit dem Vorgängerknoten über eine Kante verbunden. Dieses Vorgehen wird solange für alle Folgezustände fortgesetzt, bis der Zustand des Knotens ein Endzustand ist oder bereits im Baum dargestellt wird. Jeder Weg von der Wurzel zu einem Blatt ist dabei ein Testfall.

Anwendungsfallbasierter Test

Bei der anwendungsfallbasierten Entwurfstechnik werden Testfälle von den verschiedenen Anwendungsfällen (Use Cases) des Testobjektes abgeleitet. Dabei werden eine Interaktion und das gewünschte Resultat eines Anwenders mit dem System dargestellt.

Beispiel:          „Einem Benutzer sollte es möglich sein, eine Datei anhand eines Dateinamens zu finden.“

Jeder Anwendungsfall beschreibt eine Aufgabe, die mit dem System bearbeitet werden soll. Um einen Anwendungsfall zu definieren bedarf es der Beschreibung der Vorbedingungen, die zur erfolgreichen Durchführung erfüllt sein müssen, des zu erwartenden Ergebnisses, der Eingabedaten und der resultierenden Nachbedingungen. So lässt sich aus jedem Anwendungsfall ein Testfall generieren.

Anwendungsfallbasierte Tests eignen sich für Abnahmetests, jedoch ist dabei eine Herleitung zusätzlicher Testfälle über die dargestellten Anwendungsfälle hinaus nicht möglich, sodass sie mit weiteren Testfallentwurfsverfahren ergänzt werden sollten.

Priorisierung

Eine Priorisierung bezweckt eine Testreihenfolge festzulegen, damit hochpriore Testfälle zuerst abgearbeitet werden können, um schwerwiegende Fehler frühzeitig aufzudecken. Des Weiteren lassen sich so beschränkte Testressourcen besser verteilen und organisieren.

In der Regel sollte die Priorisierung so erfolgen, dass bei einer (vorzeitigen) Beendigung der Tests zu einem beliebigen Zeitpunkt das bis dahin bestmögliche Ergebnis erreicht wird, z.B. bei Budgetknappheit oder Zeitdruck.

Die Prioritätskriterien werden vom Testmanager im Testplan festgelegt und orientieren sich an folgenden Einteilungseigenschaften:

  • Nutzungshäufigkeit einer Funktion
  • Fehlerrisiko (Fehlerschwere und Eintrittswahrscheinlichkeit)
  • Wahrnehmung der Fehlerwirkung durch den Anwender
  • Priorität der Anforderungen
  • Qualitätsmerkmale (nicht funktionale Anforderungen)
  • Auswirkungen auf System
  • Komplexität der zu testenden Komponente
  • Projektrisiko

Testplan

Bei der Testplanerstellung gilt es zu beachten, dass der Testplan bestimmte inhaltliche Anforderungen erfüllt:

  • Allgemeine Erläuterungen zum Projekt und relevanten Informationsquellen
  • Zu testendes System und Testobjekte
  • Zu testende Qualitätsmerkmale
  • Nicht zu testende Qualitätsmerkmale
  • Teststrategie (einzusetzende Testverfahren und deren Reihenfolge)
  • Testendekriterien
  • Abbruchkriterien und Wiederaufnahmekriterien
  • Dokumentation (Vorgaben für die zu erzeugenden Dokumente)
  • Testaufgaben (Zerlegung der Teststrategie in einzelne Aktivitäten)
  • Testumgebung (Anforderungen an Testumgebung)
  • Zuständigkeiten (Personelle Zuständigkeiten der einzelnen Testphasen)
  • Mitarbeiterprofile (Höhe des personellen Aufwandes, evtl. Schulungen)
  • Zeitplan (Grober Zeitplan auf Meilensteinebene)
  • Risiken (Faktoren, die die planmäßige Erreichung der Testziele einschränken)

Testreports

Mit Hilfe eines Testreports lassen sich Aussagen über Testaktivitäten, Testergebnisse, Testfortschritt und die Qualität des Produkts formulieren. Sie beinhalten Informationen zu erfolgten Tests und deren Fortschritt sowie die Anzahl der erfolgreichen und fehlgeschlagenen Tests.

Aus diesen Ergebnissen heraus sind bestehende Risiken erkennbar und es lässt sich die eventuelle  Notwendigkeit von weiteren Tests ableiten.

 

Keine Kommentare


Antwort hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.