Abgesehen von ganz einfachen Softwareanwendungen ist es im Allgemeinen unmöglich, alle Eingabekombinationen zu testen,
die für ein Softwaresystem logisch durchführbar sind. Die Auswahl einer passenden Teilmenge bietet die größten Chancen,
die meisten Fehler zu finden, und ist eine lohnenswerte und wichtige Aufgabe von Testern.
Tests, die auf der Analyse von Äquivalenzklassen (Synonyme: Äquivalenzpartitionierung, Domänenanalyse)
basieren, sind eine Form von Blackbox-Testanalyse, bei der versucht wird, die Gesamtanzahl potenzieller Tests auf ein
Minimum von Tests zu reduzieren, die so viele Fehler wie möglich aufdecken [MYE79]. Sie ist
eine Methode, die die Eingaben und Ausgaben in eine begrenzte Anzahl von Äquivalenzklassen einteilt, die die Auswahl eines repräsentativen Testwerts für
jedes Klasse ermöglichen. Der Test, der sich aus dem repräsentativen Wert für eine Klasse ergibt, ist "äquivalent" zu
den anderen Werten in derselben Klasse. Wenn in einem Test des repräsentativen Wertes keine Fehler gefunden werden,
wird davon ausgegangen, dass auch alle anderen "äquivalenten" Werte keine Fehler aufweisen.
Die Stärke von Äquivalenzklassen liegt in ihrer Fähigkeit, den Tester mit Hilfe einer Stichprobenstrategie anzuleiten,
um die kombinatorische Explosion potenziell erforderlicher Tests einzugrenzen. Die Technik ist eine logische Basis für
die Auswahl einer Gruppe von Tests aus den insgesamt möglichen. Im Folgenden sind verschiedene Kategorien von
Problembereichen für eine Vielzahl von Tests aufgeführt, die von der Berücksichtigung von Äquivalenzklassen profitieren
können:
-
Kombinationen unabhängiger Variablen
-
Abhängige Variablen basierend auf einer hierarchischen Beziehung
-
Abhängige Variablen basierend auf einer zeitlich begrenzten Beziehung
-
Gruppierte Beziehungen basierend auf gekennzeichneten Exemplaren
-
Komplexe Beziehungen, die modelliert werden können
Es gibt verschiedene Strategien und Techniken, die bei der Partitionierung von Äquivalenzklassen angewendet werden
können. Hier sind einige Beispiele:
Die Theorie von Äquivalenzpartitionierung wurde von Glenford Myers [MYE79]
entwickelt und versucht, die Gesamtanzahl der erforderlichen Testfälle zu reduzieren, indem die Eingabebedingungen in
eine finite Anzahl von Äquivalenzklassen eingeteilt werden. Es wird zwischen zwei Typen von Äquivalenzklassen
unterschieden: Die Gruppe gültiger Eingaben für das Programm wird als gültige Äquivalenzklasse betrachtet, und
alle anderen Eingaben werden der ungültigen Äquivalenzklasse zugeordnet.
Im Folgenden finden Sie verschiedene Richtlinien für die Identifizierung von Äquivalenzklassen:
-
Wenn eine Eingabebedingung einen Bereich von Werten angibt (z. B. Programm "akzeptiert Werte zwischen 10 und 100"),
dann ist eine gültige Äquivalenzklasse (zwischen 10 und 100). Außerdem werden zwei ungültige Äquivalenzklassen
identifiziert (kleiner als 10 und größer als 100).
-
Wenn eine Eingabebedingung eine Gruppe von Werten angibt (z. B. "Stoff kann viele Farben haben: ROT, WEISS,
SCHWARZ, GRÜN, BRAUN"), werden eine gültige Äquivalenzklasse (die gültigen Werte) und eine ungültige
Äquivalenzklassen identifiziert. Jeder Wert der gültigen Äquivalenzklasse muss für sich behandelt werden.
-
Wenn die Eingabebedingung als "muss"-Situation beschrieben wird (z. B. "die Eingabezeichenfolge muss Großbuchstaben
enthalten"), werden eine gültige Äquivalenzklasse (Großbuchstaben) und eine ungültige Äquivalenzklasse (alle
Eingaben außer Großbuchstabe) identifiziert.
-
Alles, was "lange" vor Abschluss der Aufgabe fertig gestellt wurde, ist eine Äquivalenzklasse. Alles, was in einem
kurzen Zeitraum vor Beendigung des Programms fertig gestellt wurde, ist eine weitere Klasse. Alles, was fertig
gestellt wurde, bevor das Programm eine andere Operation startet, ist eine weitere Klasse.
-
Wenn für ein Programm angegeben wird, dass es mit einer Hauptspeichergröße von 64 MB bis 256 MB arbeiten kann, dann
ist dieser Größenbereich eine Äquivalenzklasse. Jede andere Hauptspeichergröße, die größer ist als 256 MB oder
kleiner als 64 MB, kann akzeptiert werden.
-
Die Partitionierung von Ausgabeereignissen basieren auf den Eingaben des Programms. Auch wenn unterschiedliche
Eingabeäquivalenzklassen dasselbe Ausgabeereignis haben können, müssen Sie die Eingabeäquivalenzklassen trotzdem
für sich behandeln.
In jeder Äquivalenzklassen haben die Grenzbedingungen in der Regel eine höhere Erfolgsquote beim Auffinden von Fehlern
als andere Bedingungen. Grenzbedingungen sind die Werte, die knapp über oder unter den Grenzen bzw. "Kanten" jeder
Äquivalenzklasse liegen.
Tests, die sich aus Grenzbedingungen ergeben, verwenden Werte, die auf dem Minimum (min), knapp über dem Minimum
(min+), knapp unter dem Maximum (max-) und auf dem Maximum (max) des zu testenden Wertebereichs liegen. Beim Testen von
Grenzwerten wählen Tester einige wenige Testfälle für jede Äquivalenzklasse aus. Für den relativ kleinen Auszug von
Tests ist die Wahrscheinlichkeit, einen Fehler zu finden, hoch. Der Tester muss damit nicht mehr die ganze Masse von
Fällen in einer Äquivalenzklasse von Werten untersuchen, die voraussichtlich keine großartig unterschiedlichen
Ergebnisse liefern.
Empfehlungen für die Auswahl von Grenzwerten:
-
Wenn die gültige Bedingungen für eine Gleitkommavariable
-1.0 bis 1.0 ist, testen Sie
-1.0 , 1.0 , -1.001 und 1.001 .
-
Wenn der gültige Eingabebereich für einen Integer
10 bis 100 ist, testen Sie
9 , 10 , 100 , 101 .
-
Wenn ein Programm einen Großbuchstaben erwartet, testen Sie die Grenzen A und Z. Testen Sie auch
@ und
[ , da im ASCII-Code das Zeichen @ direkt vor A und [ direkt hinter Z steht.
-
Wenn die Eingabe oder Ausgabe eines Programms eine geordnete Menge ist, achten Sie auf das erste und letzte Element
der Menge.
-
Wenn die Summe der Eingaben eine spezielle Zahl (
n ) sein muss, testen Sie das Programm mit Werten, die
in der Summe n-1 , n oder n+1 ergeben.
-
Wenn ein Programm eine Liste akzeptiert, testen Sie die Werte in der Liste. Alle anderen Werte sind ungültig.
-
Wenn Sie aus einer Datei lesen oder in eine Datei schreiben, prüfen Sie das erste und das letzte Zeichen in der
Datei.
-
Die kleinste Werteinheit von Geld ist ein Cent oder ein Äquivalent. Wenn das Programm einen bestimmten Bereich
akzeptiert (a bis b), testen Sie a
-0,01 und b +0,01 .
-
Für eine Variable mit mehreren Bereichen, ist jeder Bereich eine Äquivalenzklasse. Wenn die Teilbereiche sich nicht
überlappen, testen Sie die Werte auf den Grenzen, oberhalb der oberen Grenze und unterhalb der unteren Grenze.
Nachdem ein erfahrener Tester die beiden vorherigen Strategien für Grenzanalyse angewendet hat, stellt er fest, dass es
für das Programm noch Fälle mit "Sonderwerten" gibt, die ebenfalls ergiebige Quellen für die Entdeckung von
Softwarefehlern darstellen. Hier sind einige Beispiele:
-
Bei Ganzzahltypen sollte die Null immer getestet werden, wenn sie in der gültigen Äquivalenzklasse liegt.
-
Beim Testen von Zeitwerten (Stunde, Minute und Sekunde) sollten 59 und 0 als obere und untere Grenzwerte für jedes
Feld getestet werden, unabhängig davon, welche Einschränkungen für die Eingabevariable gelten. Das heißt, außer den
Grenzwerten der Eingabe sollten -1, 0, 59 und 60 immer Bestandteil eines Testfalls sein.
-
Beim Testen von Datumswerten (Jahr, Monat und Tag) sollten mehrere Testfälle untersucht werden, z. B. die Anzahl
der Tage in einem Monat, die Anzahl der Tage im Februar eines Schaltjahres und die Anzahl der Tage in einem
Nicht-Schaltjahr.
Ostrand und Balcer [16] haben eine Partitionierungsmethode entwickelt, die Tester bei der
Analyse der Systemspezifikation sowie beim Schreiben und Verwalten von Testscripts unterstützt. Anders als herkömmliche
Strategien, die sich meistens auf den Code konzentrieren, basiert ihre Methode auch auf den Spezifikations- und
Designinformationen.
Der Hauptvorteil dieser Methode ist ihre Fähigkeit, Fehler aufzudecken, bevor der Code geschrieben wird, da die
Eingabequelle die Spezifikation ist und sich die Tests aus der Analyse dieser Spezifikation ergeben. Fehler in den
Spezifikationen werden in einem frühen Stadium entdeckt, häufig vor ihrer Implementierung im Code.
Die Strategie für die Methode "Kategoriepartitionierung" wird im Folgenden erläutert:
-
Analysieren Sie die Spezifikation. Zerlegen Sie die Systemfunktionalität in funktionale Einheiten, die unabhängig
von Spezifikation und Implementierung getestet werden können.
Gehen Sie danach wie folgt vor:
-
Identifizieren Sie die Parameter und Umgebungsbedingungen, die sich auf die Ausführung der Funktion
auswirken. Parameter sind die Eingaben der Funktionseinheit. Umgebungsbedingungen sind die Systemzustände,
die sich auf die Ausführung der Funktionseinheit auswirken.
-
Identifizieren Sie die Merkmale der Parameter und der Umgebungsbedingungen.
-
Klassifizieren Sie die Merkmale in Kategorien, die sich auf das Verhalten des Systems auswirken.
In diesem Stadium werden mehrdeutige, widersprüchliche und fehlende Beschreibungen von Verhalten
gefunden.
-
Partitionieren Sie die Kategorien in Auswahlmöglichkeiten: Auswahlmöglichkeiten sind die möglichen Situationen, die
eintreten können, aber nicht erwartet sind. Sie stellen innerhalb einer Kategorie denselben Typ von Informationen
dar.
-
Bestimmen Sie die Beziehungen und Bedingungen zwischen den Auswahlmöglichkeiten. Die Auswahlmöglichkeiten in
verschiedenen Kategorien beeinflussen einander, was auch Einfluss auf die Erstellung der Testsuite haben kann. Es
werden Bedingungen hinzugefügt, um den Widerspruch zwischen Auswahlmöglichkeiten unterschiedlicher Parameter und
Umgebungen zu beseitigen.
-
Entwerfen Sie Testfälle für die Kategorien, Auswahlmöglichkeiten und Bedingungen. Wenn eine Auswahlmöglichkeit
Fehler bewirkt, kombinieren Sie sie nicht mit anderen, um den Testfall zu erstellen. Wenn eine Auswahlmöglichkeit
durch einen einzelnen Test "angemessen" untersucht werden kann, ist sie entweder die repräsentative
Auswahlmöglichkeit oder ein Sonderwert.
-
Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
-
White L. J. and Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software
Engineering, Vol. SE-6, No. 3, 1980.
-
Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on
Software Engineering, 8-4, 1992.
-
Steven J. Zeil, Faten H. Afifi and Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction
on Software Engineering and Methodology, 1-4, 1992.
-
BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering
and Methodology, 3-3, 1994.
-
Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
-
Martin R. Woodward and Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal
triangle, ACM Press New York, NY, 2000.
-
Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software
Engineering, 71-16, 2000.
-
Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New
York, 2002.
-
Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special
Interest Group on Software Engineering, 18-5, 1993.
-
Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM
Special Interest Group on Software Engineering, 1981.
-
Lori A. Clarke, Johnette Hassell, and Debra J Richardson, A system to generate test data and symbolically execute
programs, IEEE Transaction on Software Engineering, SE-2, 1976.
-
Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons,
Inc., 1995.
-
Steven J. Zeil, Faten H. Afifi and Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM
Transaction on Software Engineering and Methodology, 1-4, 1992.
-
William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
-
Thomas J. Ostrand and Marc J. Balcer, The Category-Partition method
for specifying and generating functional tests, Communications of ACM 31, 1988.
-
Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.
|