In früheren Blogbeiträgen haben wir darüber gesprochen, wie man einen Aspekt der Testherausforderung aufschlüsselt, nämlich den Umgang mit mehreren Eingaben als geplantes Experiment, bei dem wir uns zunächst auf jeweils eine Eingabe konzentrieren können. In einem späteren Blogbeitrag wurden die grundlegenden Prinzipien faktorieller Effekte in geplanten Experimenten erneut behandelt. Jetzt werden wir diese Ideen kombinieren und besprechen, was wir bei der Gestaltung eines zu Testzwecken zu verwendenden Experiments beachten sollten.
Kehren wir zur Beta-Verteilung zurück und überlegen wir nun, ob wir die Variation der Eingaben der Beta-Verteilung testen möchten, wobei wir uns auf q, Alpha und Beta konzentrieren.
Angenommen, wir wählen für jeden dieser Inputs drei Werte (niedrig/mittel/hoch). Man könnte sich vorstellen, alle 27 (3x3x3) möglichen Kombinationen auszuprobieren. Aber würde das auch funktionieren, wenn wir 10 Inputs hätten? 20? 100? Irgendwann wird klar, dass wir eine andere Strategie brauchen. Wir haben zwar eine Möglichkeit, dies bei typischen Versuchsplanungsproblemen zu handhaben, aber funktioniert dieser Ansatz auch beim Testen von Software? Unter Berücksichtigung, dass wir Fehler finden wollen und diese in den Ecken und an den Rändern lauern , formulieren wir dies so um, dass unser Ziel darin besteht, Inputkombinationen zu finden, die einen Fehler verursachen (d. h., wir beobachten nicht das erwartete Ergebnis).
Was ist mit den Grenzen?
Ihnen ist vielleicht aufgefallen, dass ich die Grenzen scheinbar ignoriere. Hier kann der OFAT-Ansatz von Nutzen sein. Im Idealfall haben wir unsere Grenzen für jeden unserer Inputs bereits überprüft (und alle Probleme behoben), bevor wir beim Testen an diesen Punkt gelangen. Wie wir später feststellen werden, können wir jedoch Grenzen berücksichtigen, wenn wir unsere Inputs variieren.
Über OFAT hinausgehen
In einem faktoriellen Design beziehen sich die grundlegenden Prinzipien der faktoriellen Effekte auf wichtige/signifikante Effekte. Für Softwaretests formulieren wir die grundlegenden Prinzipien jedoch in Form von „fehlerverursachenden Kombinationen“ neu:
Kombinationshierarchie : i) Kombinationen mit weniger Eingaben führen eher zum Fehler als solche mit mehr Eingaben. ii) Kombinationen der gleichen Reihenfolge sind mit gleicher Wahrscheinlichkeit wichtig.
Kombinations-Spärlichkeit : Die Anzahl der fehlerverursachenden Kombinationen wird gering sein.
Kombinationsvererbung : Eine Kombination führt mit höherer Wahrscheinlichkeit zu einem Fehler, wenn mindestens einer der an der Interaktion beteiligten übergeordneten Faktoren bekanntermaßen eher zum Fehler führt.
Warum müssen wir überhaupt eine Unterscheidung treffen?
Einer der Hauptunterschiede beim Testen besteht darin, dass unsere Antwort einfach ein Bestehen/Nichtbestehen ist – weichen wir von unserem erwarteten Ergebnis ab oder nicht? Darüber hinaus gehen wir normalerweise von einem deterministischen Ergebnis aus. Das heißt, wenn wir dieselben Eingaben verwenden, erhalten wir dieselben Ergebnisse (kein Fehler). Während ein Tester Fehler finden möchte, hoffen wir, dass diese Fehler letztendlich behoben werden. Wir versuchen nicht, ein Modell anzupassen, Auswirkungen zu finden oder eine Antwort zu optimieren. Tatsächlich ist die Aufgabe, eine Kombination aufzuspüren, die einen Fehler verursacht hat, die dem Modellierungskonzept am nächsten kommt. Dies wird als Fehlerlokalisierungsproblem bezeichnet und hat seine eigenen einzigartigen Herausforderungen.
Sind diese Prinzipien für das Testen überhaupt sinnvoll?
Es stellt sich heraus, dass es empirische Beweise dafür gibt, dass die Kombinationshierarchie gilt (siehe Kuhn et al., 2004). Andererseits ist Kombinationssparsität möglicherweise nicht immer eine vernünftige Annahme. Wenn ein System keinerlei Tests auf Interaktionen oder sogar Tests einzelner Eingaben unterzogen wurde, kann es in einer Testsuite zu vielen Fehlern kommen (insbesondere bevor Fehler behoben werden). Dies hängt auch mit dem Prinzip der Kombinationsvererbung zusammen – wenn eine einzelne Eingabe einen Fehler verursacht, führt jede Kombination, an der diese Eingabe beteiligt ist, zu einem Fehler.
Wenn diese Annahmen also vernünftig sind, was macht dann eine gute Testreihe aus? Bleiben Sie dran bei unseren nächsten Blogeinträgen.
Kuhn, DR, Wallace, DR und Gallo, AM, 2004. Interaktionen von Softwarefehlern und Auswirkungen auf Softwaretests.IEEE-Transaktionen zur Softwareentwicklung, 30(6), S. 418-421.
