Joseph Morgan hat sich bereits ausführlich mit der Idee von Unit-Tests in JMP befasst. Einige hervorragende Lektüren:
Der Einfachheit halber verwende ich in diesem Blog die Terminologie von Whittaker (2000), um Unit-Tests zu definieren.
Unit-Test: Eingabedomäne
Unter dem Begriff „Unit-Test“ versteht man das Testen einzelner Softwarekomponenten oder einer Sammlung von Komponenten. Tester definieren den Eingabebereich für die betreffenden Units und ignorieren den Rest des Systems.
Konzentrieren wir uns auf den zweiten Teil, in dem Tester den Eingabebereich definieren. Was ist, wenn wir eine Funktion haben, die wir testen möchten, die einzelnen Argumente aber als Einheiten behandeln möchten?
Nehmen Sie beispielsweise die Beta-Verteilungsfunktion von JSL (Screenshot aus dem Scripting Index). Die Beta-Verteilungsfunktion wird verwendet, um Zufallsvariablen zu modellieren, die zwischen 0 und 1 liegen und häufig in der Bayesschen Statistik verwendet werden.
Wir könnten Alpha und Beta auf etwa 0,5 festlegen und eine Reihe verschiedener Werte von q testen.
alpha = 0.5;
beta = 0.5;
Beta Distribution( 0.5, alpha, beta );
Beta Distribution( -1, alpha, beta );
Beta Distribution( 0, alpha, beta );
Nun ist die Bestimmung dessen, was wir für jeden Funktionsaufruf der Beta-Verteilungsfunktion erwarten, ein eigener Blogbeitrag (bekannt als Orakelproblem). Vorausgesetzt wir wissen jedoch, was wir erwarten (in diesem Fall 0,5, ein fehlender Wert und 0), können wir q testen. Jeder der Inputs kann auf diese Weise einzeln überprüft werden, beispielsweise Alpha, Beta und sogar Theta und Sigma.
One-Factor-at-a-Time-Tests (OFAT)
Was bedeutet es, wenn wir uns auf ein Argument gleichzeitig konzentrieren? Indem wir die anderen Argumente auf einen festen (z. B. den Standard-)Wert setzen und den Wert eines Arguments ändern, klingt das nach einem Test über OFAT.
Bei der Einführung in (typische) geplante Experimente diskutieren wir die Fallstricke von OFAT. Insbesondere wird von OFAT abgeraten, da Ressourcen ineffizient sind und Interaktionen fehlen. Wir können sehen, dass dieser Testansatz dieselben Probleme hat. Wenn wir jedoch Software testen, können wir diese Testfälle später wiederverwenden, sodass das Erstellen dieser Tests und das Bestimmen der erwarteten Ergebnisse nicht unbedingt eine Verschwendung von Testressourcen ist. Wenn wir ein Problem finden (d. h. das Ergebnis entspricht nicht den Erwartungen), wissen wir, welche Eingabe geändert wurde, die das Problem verursacht hat. Dies ist besonders nützlich, wenn es als Teil eines Anwendungsentwicklungsprozesses durchgeführt wird, bei dem diese Tests regelmäßig ausgeführt werden können (auch dies ist ein Thema für ein zukünftiges Blog).
Wie geht es jetzt weiter?
Wenn Sie diesen Blog lesen und sich fragen, warum wir nicht mehr als eine Eingabe gleichzeitig ändern, seien Sie versichert, das tun wir. Tatsächlich werden zukünftige Blogs die Behandlung dieser Testherausforderung als Versuchsplanungsproblem diskutieren. Bleiben Sie dran!
Whittaker, JA, 2000. Was ist Softwaretesten? Und warum ist es so schwer? IEEE Software , 17 (1), S. 70-79.
