Was ist Softwaretesten?
Wenn Sie mich, als ich vor über einem Jahrzehnt bei JMP anfing, gefragt hätten, was Softwaretests sind, hätte ich meine bevorzugte Websuche verwendet (oder heutzutage einen AI LLM-Assistenten) und die Antwort wäre ungefähr so gewesen: Beim Softwaretests geht es darum, eine Softwareanwendung oder ein Produkt zu bewerten, um sicherzustellen, dass es wie vorgesehen funktioniert und die Benutzeranforderungen erfüllt.
Durch viele Diskussionen mit meinem Kollegen Joseph Morgan habe ich jedoch eine Definition aus der Softwareentwicklung übernommen, die Glenford Myers [1] prägnant formuliert hat:
„Beim Testen handelt es sich um den Vorgang, ein Programm auszuführen, um Fehler zu finden.“
Ist diese Definition so anders? Ich würde sagen, ja. Obwohl Myers et al. [1] eine großartige Diskussion darüber führen, besteht für die meisten Menschen ein psychologischer Unterschied zwischen der Bitte, zu prüfen, ob etwas funktioniert, und dem Versuch, es kaputt zu machen. Wenn man Myers' Definition anwendet, hat ein Testingenieur sein Ziel – Fehler zu finden. Dies sorgt nicht nur für Struktur, sondern durch das frühzeitige und sorgfältige Auffinden und Beheben dieser Fehler (oder Bugs, wie wir sie nennen) entsteht Software, die wie vorgesehen funktioniert und die Benutzeranforderungen erfüllt.
Wo sind die Fehler?
Wenn Sie mir noch folgen und mit der Definition von Testen vertraut sind, stellt sich natürlich die Frage, wo man überhaupt mit den Versuchen beginnen kann, die Software zu beschädigen. Dazu können wir uns an Boris Beizer [2] wenden:
„Käfer lauern in Ecken und versammeln sich an Grenzen.“
Lassen Sie uns dies in zwei Teile aufteilen. Dabei behandeln wir eine Eingabe als eine Art Daten oder Informationen, die Sie einer Software geben, um eine Reaktion zu erhalten oder mit diesen Informationen etwas zu tun.
Fehler häufen sich an Grenzen : Dies unterstreicht, dass Fehler häufig an den Grenzen dessen zu finden sind, was das System verarbeiten soll. Wenn eine Funktion beispielsweise Eingaben zwischen 0 und 1 akzeptieren soll, sollten wir sowohl die Grenzen (0 und 1) als auch die Bereiche direkt außerhalb dieser Grenzen testen.
Fehler lauern in Ecken : Dies deutet darauf hin, dass sich Fehler häufig in den Teilen eines Systems verstecken, die mehr als eine Eingabe erfordern. Das heißt, ähnlich wie bei Interaktionen werden wir keinen Fehler finden, wenn wir diese Kombinationen nicht testen.
Wie geht es jetzt weiter?
In den kommenden Wochen werden Sie von meinen Kollegen und mir über verschiedene Themen im Zusammenhang mit Validierung (bauen wir das richtige Produkt?) und Testen (Fehler finden, sicherstellen, dass die Software funktioniert) hören. Besonders interessant finde ich, dass es eine enge Verbindung zwischen Testen und Versuchsdesign gibt (ein weiteres Thema, über das ich gerne spreche).
Egal, ob Sie Ihre eigenen Anwendungen erstellen, vor Ihrer eigenen Testherausforderung stehen oder sich einfach nur allgemein für dieses Thema interessieren, ich hoffe, Sie lesen weiter. Gibt es Themen, die Sie gerne behandelt sehen würden? Lassen Sie es uns in den Kommentaren wissen!
Und da ein Blog ohne ein Bild nicht vollständig erscheint, hier ein Bild des ersten „Computerfehlers“, wie etwa von einem Teil eines Teams an der Harvard University im Jahr 1947, zu dem auch Grace Hopper gehörte.
Mit freundlicher Genehmigung des Naval Surface Warfare Center, Dahlgren, VA., 1988., Erster Computerfehler, 1945 , als gemeinfrei gekennzeichnet, weitere Einzelheiten auf Wikimedia Commons
Referenzen.
- G. Myers, C. Sandler und T. Badgett, The Art of Software Testing, 3. Auflage , New Jersey, John Wiley & Sons, Inc, 2011.
- B. Beizer, Software-Testtechniken , Van Nostrand Reinhold Reihe Elektrotechnik/Informatik und Ingenieurwesen, 1983
Hallo @Ryan_Lekivetz !
Vielen Dank für diese sehr nette Einführung, ich kann es kaum erwarten, mehr über die Verwendung von Covering Arrays oder anderen Methoden zur Fehlerlokalisierung zum Testen von Software zu erfahren.
