A. Memon, I. Banerjee, and A. Nagarajan. Automated Software Engineering, 2003. Proceedings. 18th IEEE International Conference on, page 164-173. (October 2003)
P. Santos-Neto, R. Resende, and C. Pádua. SAC '07: Proceedings of the 2007 ACM symposium on Applied computing, page 1409--1415. New York, NY, USA, ACM, (2007)
S. Edwards. Software Testing, Verification and Reliability, 10 (4):
249--262(January 2001)MR: Aus dem Text: Testing 'to contract' is at the heart of specification based testing. Es wird gezeigt wie ein Anzatz von Zweben1992 (der leider nicht auffindbar ist) sich praktisch umsetzen lässt. Dabei spielen die Contracts für die Generierung der Test(ein/aus)gabedaten grundlegende Rolle. Die getesteten Komponenten werden als Flowgraphs dargestellt, womit sie große Analogie zu Aktivitätsdiagrammen besitzen. Obwohl noch Probleme bei der Auswahl der Testdaten (infeasable paths) existieren, wurde gezeigt, dass dieser Ansatz großen Potential besitzt. Für das Experiment wurde Fehlerinjektionsmethoden angewendet (Mutation)..
S. Mishra. CS&P 2006 - Concurrency, Specification and Programming, (2006)MR: Es wird gezeigt, dass bei SPLs, die mit formalen Spezifikationen (hier CSP-CASL) beschrieben sind, die Testfälle, Testeingaben und erwartete Ergebnisse automatisch generiert werden können.
Die Wiederverwendung der Tests beschränkt sich im Paper auf SPLs von speziellen Art, bei denen die Varianten nur erweitert werden können und somit andere Varianten und den gemeinsamen Teil vollständig involvieren..
A. Bertolino. Future of Software Engineering, 2007. FOSE '07, page 85-103. (2007)MR: Das bisher erreichte in Bezug auf Software-Testen wurde gut zusammengetragen. Für IST-SPL sind die Kapitel zu MBT (mit Testorakeln) und automatischen Testen interessant.
Die Notwendigkeit der Kombinierungsmöglichkeiten von verschiedenen Modelltypen (transition-based, pre/post condition-based, scenarion-based) wurde hervorgehoben..
D. Sokenou. TU Berlin, Fakultät für Elektrotechnik und Informatik, (March 2006)MR: Interessant für IST-SPL sind vor allem folgende Kapitel:
5-Testbarkeit von UML-Modellen: alle Diagrammtypen werden auf ihre Eignung für den Test untersucht
10-UML-basierte Testorakel: mit Hilfe von Zustandsdiagrammen und OCL-Constraints
Leider fehlt der Blick auf den Systemtest.
Besonderheit: die eingesetzte aspektorientierte Technik erlaubt die OCL-Constraints in Aspekte umzuwandeln und zur Ladezeit so in den Testcode einweben, dass die getestete Systemimplementierung nicht neu versioniert werden muss.
G. Xu, Z. Yang, H. Huang, Q. Chen, L. Chen, and F. Xu. apsec, (2004)ST: Interessant an diesem Paper ist die die Idee Testorakel mit Aspektorientierter Programmierung mit der Applikation zu verknüpfen. Wie im Paper "Investigating the use of analysis contracts to support fault isolation in object oriented code" untersucht, ist es sinnvoll Testorakel in Form von Zusicherungen in den Code zu schreiben. Diese Zusicherungen werden in Aspekte ausgelagert (separation of concerns). Nachteil: Es muss mit einem Programmiersprachenspezifischen AO-System gearbeitet werden..
A. Bertolino. Abstract State Machines, page 1-21. (2003)MR: Gute Zusammenfassung der Grundlagen über Testen, aber gleichzeitig auch Überblick zum State-Of-The-Art.
Für IST-SPL: Wertvoller Überblick über spezifikationsbasierte Testmethoden und kurz zum Testorakel-Problem..
L. Briand, Y. Labiche, and H. Sun. ISSTA '02: Proceedings of the 2002 ACM SIGSOFT international symposium on Software testing and analysis, page 70--80. New York, NY, USA, ACM, (2002)ST: In diesem Paper wird untersucht, ob extern erstellte Testorakel durch Zusicherungen im Code ersetzt werden können. (vgl. Binder: Built-in Test Oracle, Seite 935)Diese Zusicherungen werden in OCL definiert (Pre-Postconditions, Invarianten) und mit Hilfe eines Tools in Java Code eingebettet. Diese eingebetteten Zusicherungen dienen als Testorakel. Ein Experiment zeigte, dass Durch diese Technik erfolgreich Testorakel in den Code eingebettet werden können und zum andreren die Diagnostizierbarkeit des Codes steigt. Wird eine Zusicherung verletzt, tritt eine Exception haeufig in der Nähe eines Code-Errors auf, so kann der Fehler leichter gefunden werden als bei einem herkömmlichen Orakel..
T. O'Malley, D. Richardson, and L. Dillon. (1996)ST: Aehnliche vorgehensweise wie in "Testing using Log File Analysis: Tools, Methods, and Issues". Die Zustandsautomaten (Orakel) werden jedoch nicht manuell erstellt, sondern aus einer graphischen Repraesentation der LTL automatisch generiert. Die weitere Vorgehensweise ist gleich: Es werden waehrend der Ausfuehrung des Testfalls aufgezeichnete Programm-Traces mit dem Automat verglichen und auf Gueltigkeit überprueft..
J. Andrews, R. Fu, and V. Liu. ASE '02: Proceedings of the 17th IEEE international conference on Automated software engineering, page 275. Washington, DC, USA, IEEE Computer Society, (2002)ST: Nachtrag zum Paper "Testing using Log File Analysis: Tools, Methods, and Issues". Die dort vorgestellte Technik wird dahingehend erweitert, dass der Grad der Abdeckung der Transitionen des Orakels durch die Testfaelle gemessen werden kann. Außerdem können Testfaelle auf Basis des Orakels abgeleitet werden (Ist dass sinnvoll?) und das Testorakel kann automatisch validiert werden..
J. Andrews. ASE '98: Proceedings of the 13th IEEE international conference on Automated software engineering, page 157. Washington, DC, USA, IEEE Computer Society, (1998)ST: Interessantes Paper. Basis sind eine Menge von Zustandsautomaten, die als Testorakel dienen, und Logfiles, die während der Ausführung der Testfaelle Eingaben, Ausgaben, aufgerufene Methoden etc speichern. Nach der Ausführung der Tests werden die Logfiles gegen die Automaten geprueft, d.h. ob es für eine mitgeloggte Methodensequenz einen gültigen Lauf in einem Automaten gibt. Falls nicht, widerspricht das Verhalten des System der Spezifikation.
Die Technik ist automatisiert, die Technik wurde beispielhaft im Unittest und im Systemtest vorgestellt..