Einen vollständigen Test durchzuführen bedeutet folgendes:
Der Tester verifiziert alle möglichen Eingaben zusammen mit allen möglichen Ausgaben für alle Konfigurationsmöglichkeiten (z.B. Spracheinstellungen, Layout-Einstellungen, ein- oder ausgeschaltete Plugins, etc.) eines Programmes.
Als Beispiel dient eine Variante des oft zitierten Dreiecksprogramm aus dem Buch von Myers (Glenford Myers: ‚The Art of Software Testing‘, John Wiley & Sons, 1979):
Ein Programm akzeptiert die Eingabe dreier ganzer Zahlen und interpretiert diese als Seitenlängen eines Dreiecks. Die Programmausgaben sind entweder eine Fehlermeldung oder die Art des Dreiecks unterschieden nach ‚allgemein‘, ‚gleichschenklig‘ oder ‚gleichseitig‘.
Als weitere Einschränkung gelte, dass das Programm nur Eingaben vom Typ ‚unsigned short‘ mit einem Zahlbereich von 0 bis 65535 akzeptiert.
Betrachten wir zunächst die Tests aller möglichen gültigen Eingabeformate (d.h. keine Buchstaben, keine Sonderzeichen, keine zu kleinen oder zu großen Zahlen, keine falsche Anzahl an Eingaben, usw.). Schätzen Sie wieviel Testfälle benötigt würden – die Antwort finden Sie weiter unten (unter Antwort 1)
Angenommen, wir hätten diese tatsächlich erstellt und per Skript oder Unit-Test automatisiert.
Was schätzen Sie, wie lange die automatisierte Testdurchführung läuft, wenn ein einzelner Testfall eine Mikrosekunde (1.0e-6 s, der Millionste Bruchteil einer Sekunde) in der Durchführung benötigt? (Antwort 2 unten)
Dieser Test wäre nicht einmal wirklich vollständig.
Ein vollständiger Test würde neben den gültigen Eingaben eben auch alle möglichen ungültigen Eingaben testen.
Bereits für dieses einfache Programm ist ein vollständiger Test daher (mit unseren derzeitigen technischen Mitteln) nicht realisierbar.
Das Beispielprogramm von Myers lässt sich in gängigen Programmier- oder Skriptsprachen mit 10-20 Codezeilen leicht implementieren. Reale Computerprogramme besitzen mehrere tausend bis hin zu mehreren Millionen Quellcodezeilen und oft mehrere tausend Konfigurationsmöglichkeiten, die den Programmablauf wesentlich beeinflussen.
Kann ein Tester dann Software überhaupt ‚vernünftig‘ testen?
Die Antwort ist ein klares: JA!
Vernünftig meint in diesem Zusammenhang, dass der Tester in der Lage ist, erfolgreich Fehler aufzudecken und nach erfolgtem Test eine auf Fakten basierende, nachvollziehbare Einschätzung von verbleibenden Risiken abzugeben. (Was er nicht kann, ist die Fehlerfreiheit zu garantieren.)
Dazu sind systematische und erfahrungsbasierte Testentwurfsverfahren entwickelt worden.
Der systematische Testentwurf beginnt damit, das erwartete Verhalten des Systems im Guten, wie im Schlechten (z.B. bei Fehlbedienungen, Stress, usw.) zu modellieren. Aus den erstellten Modellen (ja – Plural, ein Modell reicht meist nicht aus alle wichtigen Aspekte eines Systems zu testen) werden repräsentative Testfälle abgeleitet, anhand derer das tatsächliche Systemverhalten mit den Erwartungen des Testers aus dem Modell abgeglichen wird.
Systematische (Blackbox-, Whitebox- und erfahrungsbasierte Verfahren) sind in Büchern und in Standards wie der ISO/IEC/IEEE 29119-4 ausführlich beschrieben. Andere Standards wie die IEC 61508-3 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems) oder die ISO 26262 enthalten Richtlinien und Vorgaben zum Einsatz der Verfahren.
Antwort 1 (Markieren Sie die Zeile mit dem Cursor zum Lesen): Sie benötigen 65536³, das sind mehr als 2,8 Billionen Testfälle.
Antwort 2 (Markieren Sie die Zeile mit dem Cursor zum Lesen): Mehr als 8,9 Jahre. Benötigt der Durchlauf eines einzigen Testfalls statt einer Mikro- eine Millisekunde (eine Tausendstel Sekunde), würde die Testdurchführung mehr als 8.900 Jahre dauern.