Richtlinie: Analyse von Äquivalenzklassen
Die Analyse von Äquivalenzklassen ist eine Technik, um die Anzahl der Testfälle zu minimieren. Diese Richtlinie beschreibt diese Technik und wie sie verwendet wird.
Beziehungen
Hauptbeschreibung

Einführung

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:

  1. Kombinationen unabhängiger Variablen
  2. Abhängige Variablen basierend auf einer hierarchischen Beziehung
  3. Abhängige Variablen basierend auf einer zeitlich begrenzten Beziehung
  4. Gruppierte Beziehungen basierend auf gekennzeichneten Exemplaren
  5. Komplexe Beziehungen, die modelliert werden können

Strategien

Es gibt verschiedene Strategien und Techniken, die bei der Partitionierung von Äquivalenzklassen angewendet werden können. Hier sind einige Beispiele:

Partitionierung von Äquivalenzklassen

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:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Analyse von Grenzwerten

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:

  1. 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.
  2. Wenn der gültige Eingabebereich für einen Integer 10 bis 100 ist, testen Sie 9, 10, 100, 101.
  3. 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.
  4. Wenn die Eingabe oder Ausgabe eines Programms eine geordnete Menge ist, achten Sie auf das erste und letzte Element der Menge.
  5. 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.
  6. Wenn ein Programm eine Liste akzeptiert, testen Sie die Werte in der Liste. Alle anderen Werte sind ungültig.
  7. Wenn Sie aus einer Datei lesen oder in eine Datei schreiben, prüfen Sie das erste und das letzte Zeichen in der Datei.
  8. 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.
  9. 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.

Sonderwerte

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:

  1. Bei Ganzzahltypen sollte die Null immer getestet werden, wenn sie in der gültigen Äquivalenzklasse liegt.
  2. 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.
  3. 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.

Methode der "Kategoriepartitionierung"

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:

  1. 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:

    1. 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.
    2. Identifizieren Sie die Merkmale der Parameter und der Umgebungsbedingungen.
    3. 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.

  2. 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.

  3. 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.

  4. 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.

Weitere Informationsquellen und Referenzen

  1. Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
  2. 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.
  3. Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on Software Engineering, 8-4, 1992.
  4. 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.
  5. BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering and Methodology, 3-3, 1994.
  6. Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
  7. 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.
  8. Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software Engineering, 71-16, 2000.
  9. Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New York, 2002.
  10. Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special Interest Group on Software Engineering, 18-5, 1993.
  11. Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM Special Interest Group on Software Engineering, 1981.
  12. 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.
  13. Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons, Inc., 1995.
  14. 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.
  15. William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
  16. Thomas J. Ostrand and Marc J. Balcer, The Category-Partition method for specifying and generating functional tests, Communications of ACM 31, 1988.
  17. Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.