Worum geht's?


Testen von Software und das sicherstellen von korrekter Software in Bezug auf den Anforderungen und Anwendungsfällen. Um dieses Ziel zu erreichen, möchte man nicht zu wenig, aber auch nicht zu viel Testen. Zu viel Tests würden das Testbudged strapazieren, zu wenige könnten die Qualität der Software reduzieren.
Deshalb werden beim Testen von Methoden generell zwei Verfahren angewendet, um die Testdatenmenge zu reduzieren.</p>

  1. Äquivalenzklassen auf den Inputdefinitionsbereichen werden gebildet.
    Bsp.: Eingabefeld Hausnummer wird aufgeteilt in gültige Eingaben den Integerwerten größer 0, den ungültigen kleiner gleich 0 und den restlichen ungültigen Eingabemöglichkeiten.
  2. </p>
  3. Um nicht alle Äquivalenzklassen-Kombinationen bei mehreren Inputparametern testen zu müssen wird auf die Pairwise-Methode zurückgegriffen. Es werden dabei nur alle Eingabeparameter paarweise kombiniert anstelle des Kreuzproduktes.


Anwendungsfall


Bei einer neu programmierten Anwendung soll ein Systemtest durchgeführt werden, wobei mehrere spezifizierte Anwendungsfälle durchgeprüft werden sollen; beispielsweise das Suchen nach einer Zugverbindung Berlin - Hamburg.</p>

Problem


Bei Tests auf Anwendungsfallebene bleiben trotz Äquivalenzklassenbildung und Anwendung der Pairwise-Methode für die Kombinationen sehr viele verschiedene Testfälle übrig, da oftmals sehr viele Eingabeparameter für den Benutzer existieren (beispielsweise schon bei der Suche einer Zugverbindung). Die Frage ist, ob diese zum einen sinnvoll sind und zum anderen ob sie für eine ausreichende Testabdeckung notwendig sind.</p>

Führt man das geschilderte Vorgehen in der Praxis aus, fallen zwei Dinge auf:

  1. Da die Äquivalenzklassen auch Fehlerfälle widerspiegeln, kann es passieren, dass nachdem man die verschiedenen Inputvariablen mit der Pairwise-Methode kombiniert hat, keine Kombination den "Standardfall" wiedergibt; d. h. alle Kombinationen enthalten Eingabedaten, die zwangsläufig einen Fehlerfall überprüfen.
  2. Wenn man einen Systemtest durchführt sind meist viel mehr Eingabeparameter zu berücksichtigen als dies bei Methoden mit oftmals verhältnismäßig wenig Eingabeparametern der Fall ist. Folglich entstehen trotz den vorgeschlagenen Maßnahmen sehr viele Testkombinationsfälle.

Lösung


Eine Lösung könnte das bilden von logischen Eingabeeinheiten sein, sodass nicht mehr alle Eingabefelder per se paarweise kombiniert werden, sondern nur noch die logischen Einheiten. Ein Verfahren, dass ich selbst praktisch angewendet habe, kann folgendermaßen skizziert werden:</p>

  1. Schritt: Bildung von Äquivalenzklassen auf Definitionsbereich der Eingabevariablen:
    Eingabevariablendefinitionsbereich → Aequivalenzklassen; Bsp.:
    a1 ∈ $$\mathbb{N}$$ → aA1 = { Mf = { intMin, .. ,0 }, Np = {1, .. , 43 }, Of = {44, .. , maxInt}}
    a2 .. an → aA2, .. , aAn
  2. </p>
  3. Schritt: Bildung von logischen Einheiten auf den verschiedenen Eingabevariablen:
    Eingabevariablen → logische Einheit; Bsp.:
    a1, a2, .. , an → b1 = {a1, a3, a4} und b2 = {a2, a5} usw.
  4. </p>
  5. Clustering der Äquivalenzklassen pro logische Einheit
    Äquivalenzklassen pro logische Einheit → aggregierte Äquivalenzklassen pro logische Einheit
    bA1 = {aA1, aA3, aA4} ⇔ {Mf, Np, Of, ...} → BA1 = {P, F1, F2}
    Wobei p Pass und f Fail bedeuteut.


Beispiel: Man hat eine Eingabemaske zu einer Person; (1) Dann kann man zu jedem Eingabefeld eine Äquivalenzklasse bilden. (2) Anschließend aggregiert man die Felder (z.B. Heimadressfelder, Arbeitsadressfelder, Angaben zur Krankenkasse usw.) und (3) abschließend kombiniert man die Äquivalenzklassen der aggregierten Felder.</p>

Ergebnis: logische Einheiten mit aggrebierten Äquivalenzklassen.

In den von mir eingesetzten Fällen reduzieren sich die Eingabetestfälle erheblich. Zudem entstehen auch beim paarweisen kombinieren weiterhin Standardtestfälle. Über die Testqualität kann ich nur eine Annahme treffen. Ich würde aber behaupten, dass diese nicht signifikant sinkt, denn:

  1. die logischen Einheiten bilden meist auch Subsysteme ab und diese sollten vorab von Subsystemtests getestet werden. Die Integration wird aber weiterhin durch die Kombinationen der logischen Einheiten getestet.
  2. weiterhin werden Randfälle betrachtet und die Kombination daraus getestet. Auf einer logischen Ebene handelt es sich also um Äquivalenzklassen bei den Aggregationen.


Falls ihr anderer Meinung seid, lasst es mich wissen. Ansonsten viel Erfolg beim Softwaretesten!