Oracle (Softwaretest)

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Ein Oracle bezeichnet einen Mechanismus zum Softwaretest, insbesondere in den Bereichen Computing und Softwaretechnik, der als Nachweis für das Bestehen oder Nichtbestehen eines Tests (System Under Test, SUT) verwendet wird.[1] Testen bedeutet in diesem Zusammenhang, ein System zu stimulieren und seine Reaktion zu beobachten. Stimulus und Reaktion haben beide Werte, die übereinstimmen können, z. B. wenn der Stimuluswert und die Reaktion beide reell sind.[2] Die Herausforderung, für ein System das entsprechende gewünschte, korrekte Ergebnis von einem potentiell falschen Ergebnis zu unterscheiden, wird als Oracle Problem bezeichnet.[2][3]

Der Begriff (Test-)Oracle geht dabei zurück auf William E. Howden.[4] Weitergehende Aspekte wurden insbesondere von Elaine Elaine Weyuker beschrieben.[5]

In der Wissenschaft wird zwischen verschiedenen Kategorien von Oracle unterschieden.[3]

Spezifische Oracle

[Bearbeiten | Quelltext bearbeiten]

Diese Oracle werden typischerweise für formalisierte Ansätze der Software-Modellierung und Erstellung von Software-Codes verwendet. Eine Spezifikation definiert das Oracle für einen bestimmten Anwendungsbereich. Eine Spezifikationssprache bezeichnet dabei eine Notation zur Definition eines spezifischen Oracle, das beurteilen soll, ob das Verhalten eines Systems mit einer formalen Spezifikation[6] übereinstimmt.[2][7] Für Test nach formalen Spezifikationen haben sich bestimmte Methoden durchgesetzt: Modellbasiertes Testen,[8] Transitionssysteme Assertionen, Designs by contract (DbC), oder algebraische Spezifikationen. Modellbasierte Sprachen definieren Modelle und eine Syntax, die das gewünschte Verhalten in Bezug auf seine Auswirkungen auf das Modell definiert. Transitionssysteme befassen sich mit der Modellierung der Reaktion eines Systems auf Stimuli, die in diesem speziellen Formalismus als Übergänge (Transition) bezeichnet werden. Assertionen und Designs by Contracts sind Fragmente einer Spezifikationssprache, die mit Anweisungen der Implementierungssprache verschachtelt sind und zur Laufzeit überprüft werden. Algebraische Spezifikationen definieren Gleichungen über die Operationen eines Programms die gelten, wenn das Programm korrekt ist. Herausforderung bei der Erstellung von spezifischen Oracle ist zunächst das Fehlen einer formalen Spezifikation, die bei anderen Kategorien bereits vorliegen.[2] Zudem setzen Modelle mit formaler Spezifikation zwingend auf Abstraktion. Dies impliziert regelmäßig Ungenauigkeiten bspw. infolge von undurchführbaren Verhalten.[9] Letztlich bedarf die Modellausgabe einer Interpretation, um sie mit der konkreten Programmausgabe gleichzusetzen.

Abgeleitete Oracle

[Bearbeiten | Quelltext bearbeiten]

Ein abgeleitetes Oracle unterscheidet zwischen korrektem und inkorrektem Verhalten, indem es auf Heuristiken setzt.[10] Dazu werden bekannte Informationen verwendet, die aus Artefakten des Systems wie Dokumentation, Ergebnisse der Systemausführung und Merkmale von Versionen des zu testenden Systems abgeleitet werden.[3]

Darunter fällt etwa das Pseudo-Oracle,[3] welches nach der Definition von Weyuker[11] ein eigenständiges Programm darstellt, das dieselbe Eingabe wie das zu testende Programm oder System verarbeiten kann. Somit können die Ausgaben verglichen werden, um festzustellen, ob es ein zu untersuchendes Problem gibt.

Ein partielles Oracle[3] ist eine Kombination aus einem spezifizischen Oracle (s. o.) und einem abgeleiteten Oracle. Es spezifiziert wichtige (aber nicht sämtliche) Eigenschaften des zu testenden Systems. Beim metamorphen Testen werden beispielsweise solche Eigenschaften, die sogenannten metamorphen Relationen, über mehrere Ausführungen des Systems hinweg ausgewertet.

Implizierte Oracle

[Bearbeiten | Quelltext bearbeiten]

Ein implizites Oracle stützt sich auf implizite Informationen und Annahmen.[3] So wird anhand von bekannten Informationen auf unbekannte Informationen geschlossen (Heuristik). So kann etwa aus einem technischen Vorfall auf ein unerwünschtes Verhaltensmuster geschlossen werden, das dem System inhärent anhaftet. Umgekehrt kann konkret nach unerwünschten Verhaltensmuster gesucht werden (negatives Testen). Eine Möglichkeit dafür ist das Fuzzing.

Für implizierte Oracle bestehen generelle Einschränkungen, da sie lediglich auf Annahmen und Schlussfolgerungen beruhen. Aufgrund dieser Abhängigkeiten sind sie daher anfällig für falsch positive Ergebnisse.

Menschliche Oracle

[Bearbeiten | Quelltext bearbeiten]

Wenn spezifische, abgeleitete oder implizite Oracle aus technischen Gründen nicht anwendbar sind, sind menschliche Eingaben zur Bestimmung erforderlich.[12] Diese können als quantitative und qualitative Ansätze beschrieben werden.[3] Ein quantitativer Ansatz zielt darauf ab, die richtige Menge an Informationen über ein zu prüfendes System (z. B. Testergebnisse) zu sammeln, um Entscheidungen über die Eignung für einen bestimmten Zweck oder die Freigabe der Software treffen zu können. Ein qualitativer Ansatz zielt darauf ab, die Eignung der eingegebenen Testdaten und den Kontext der Ausgabe des getesteten Systems zu ermitteln. Ein Beispiel ist die Verwendung realistischer und repräsentativer Testdaten und die Interpretation der Ergebnisse (sofern sie realistisch sind). Dabei kann man sich von heuristischen Ansätzen leiten lassen, wie z. B. Bauchgefühl, Faustregeln, Checklisten und Erfahrung, um die spezifische Kombination für das zu testende Programm/System anzupassen.

Oracle basieren in der Regel auf Spezifikationen und Dokumentation.[13] Eine formale Spezifikation, die als Input für den modellbasierten Entwurf und modellbasiertes Testen verwendet wird, ist ein Beispiel für ein spezifisches Oracle. Das modellbasierte Oracle verwendet dasselbe Modell, um das Systemverhalten zu generieren und zu verifizieren.[14] Eine Dokumentation, bei der es sich nicht um eine vollständige Spezifikation des Produkts handelt, wie z. B. ein Benutzer- oder Installationshandbuch oder eine Aufzeichnung der Leistungsmerkmale oder Mindestanforderungen an den Rechner für die Software, wäre typischerweise ein abgeleitetes Oracle. Ein Konsistenz-Oracle ist ebenfalls ein abgeleitetes Oracle und vergleicht die Ergebnisse einer Testausführung mit denen einer anderen auf Übereinstimmung.[15]

Zum Testen eines Softwareprogramm kann ein Oracle genutzt werden, welches als ein zweites Programm einen anderen Algorithmus verwendet, um denselben mathematischen Ausdruck auszuwerten wie das zu testende Programm. Hierbei handelt es sich um ein Beispiel für ein Pseudo-Oracle in Form eines abgeleiteten Oracle.[11]

Bei der Google-Suche mangelt es dem Nutzer an einem Oracle, mit dem überprüft werden kann, ob die Anzahl der gefundenen Ergebnisse korrekt ist. In diesem Fall kann eine metamorphe Beziehung[16] so definiert werden, dass eine nachfolgende eingeschränkte Suche weniger Ergebnisse liefert. Hierbei handelt es sich um ein Beispiel für ein partielles Oracle, i.e. eine Mischung aus einem spezifischen und einem abgeleiteten Oracle.

Ein statistisches Oracle verwendet probabilistische Merkmale,[17] z. B. bei der Bildanalyse, bei der ein Bereich von Gewissheit und Ungewissheit bestimmt wird, damit das Oracle eine potentielle Übereinstimmung feststellen kann. Dies wäre ein Beispiel für einen quantitativen Ansatz bei einem menschlichen Oracle.

Ein heuristisches Oracle liefert repräsentative oder annähernde Ergebnisse für eine Klasse von Testeingaben.[18] Dies wäre ein Beispiel für einen qualitativen Ansatz bei einem menschlichen Oracle.

  • Robert V. Binder: Oracles. In: Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison-Wesley, 2000.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. Cem Kaner: A Course in Black Box Software Testing (Memento des Originals vom 7. August 2020 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.testingeducation.org, 2004.
  2. a b c d Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, Shin Yoo: The Oracle Problem in Software Testing: A Survey. In: IEEE Transactions on Software Engineering. Band 41, Nr. 5, 1. Mai 2015, ISSN 0098-5589, S. 507–525, doi:10.1109/TSE.2014.2372785 (ieee.org [abgerufen am 15. November 2021]).
  3. a b c d e f g Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, Shin Yoo: The Oracle Problem in Software Testing: A Survey. In: IEEE Transactions on Software Engineering. Band 41, Nr. 5, November 2014, S. 507–525, doi:10.1109/TSE.2014.2372785 (ucl.ac.uk [PDF]).
  4. W. E. Howden: Theoretical and Empirical Studies of Program Testing. In: IEEE Transactions on Software Engineering. Band 4, Nr. 4, Juli 1978, S. 293–298, doi:10.1109/TSE.1978.231514.
  5. Elaine J. Weyuker: The Oracle Assumption of Program Testing. In: Proceedings of the 13th International Conference on System Sciences (ICSS), Honolulu, HI, January 1980. S. 44–49.
  6. E. Börger: High Level System Design and Analysis Using Abstract State Machines. Hrsg.: D. Hutter, W. Stephan, P. Traverso, M. Ullman (= Lecture Notes in Computer Science. Band 1641). 1999, ISBN 3-540-66462-9, S. 1–43, doi:10.1007/3-540-48257-1_1.
  7. D. K. Peters: Using test oracles generated from program documentation. In: IEEE Transactions on Software Engineering. Band 24, Nr. 3, März 1998, S. 161–173, doi:10.1109/32.667877.
  8. Mark Utting, Alexander Pretschner, Bruno Legeard: A taxonomy of model-based testing approaches. In: Software Testing, Verification and Reliability. Band 22, Nr. 5, 2012, ISSN 1099-1689, S. 297–312, doi:10.1002/stvr.456 (edu.au [PDF]).
  9. Pascale Le Gall, Agnès Arnould: Formal specifications and test: Correctness and oracle. In: Recent Trends in Data Type Specification. Band 1130. Springer, Berlin/ Heidelberg 1996, ISBN 3-540-61629-2, S. 342–358, doi:10.1007/3-540-61629-2_52 (springer.com [abgerufen am 16. November 2021]).
  10. Tao Wu, Le Huang, Liang Zhe, Xiaoning Zhang, Canrong Zhang: A Supervised Learning-Driven Heuristic for Solving the Facility Location and Production Planning Problem. In: European Journal of Operational Research. 15. November 2021, ISSN 0377-2217, doi:10.1016/j.ejor.2021.11.020 (sciencedirect.com [abgerufen am 16. November 2021]).
  11. a b E. J. Weyuker: On Testing Non-Testable Programs. In: The Computer Journal. Band 25, Nr. 4, November 1982, S. 465–470, doi:10.1093/comjnl/25.4.465.
  12. Paul Ammann, Jeff Offutt: Introduction to Software Testing. Cambridge University Press, 2008, ISBN 978-0-521-88038-1.
  13. Dennis K. Peters, David L. Parnas: Generating a Test Oracle from Program Documentation. In: Proceedings of the 1994 International Symposium on Software Testing and Analysis. International Symposium on Software Testing and Analysis (ISSTA); ACM Press, S. 58–65 (mun.ca [PDF]).
  14. Harry Robinson: Finite State Model-Based Testing on a Shoestring. STAR West 1999.
  15. Douglas Hoffman: Analysis of a Taxonomy for Test Oracles. (Memento des Originals vom 10. März 2012 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.softwarequalitymethods.com In: Quality Week. 1998.
  16. Z. Q. Zhou, S. Zhang, M. Hagenbuchner, T. H. Tse, F.-C. Kuo, T. Y. Chen: Automated functional testing of online search services. In: Software Testing, Verification and Reliability. Band 22, Nr. 4, 2012, S. 221–243, doi:10.1002/stvr.437.
  17. Johannes Mayer, Ralph Guderlei: Test Oracles Using Statistical Methods. First International Workshop on Software Quality. In: Proceedings of the First International Workshop on Software Quality, Lecture Notes in Informatics. Springer, 2004, S. 179–189 (englisch, uni-ulm.de [PDF]).
  18. Douglas Hoffman: Heuristic Test Oracles. (Memento des Originals vom 14. März 2016 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.softwarequalitymethods.com In: Software Testing & Quality Engineering Magazine. 1999.