The article illustrates a formal method of deriving functional test cases from use cases, including how to create a use case, derive all scenarios, and create reasonable test cases, as well as use IBM® Rational® RequisitePro for traceability from use cases to scenarios and test cases.
R. Ferguson, и B. Korel. ACM Trans. Softw. Eng. Methodol., 5 (1):
63--86(1996)ST: Vorgehensweise:
Die Idee dieses Ansatzes ist es eine Sequenz von Knoten im Kontrollflussgraphen zu finden, die zu einer Ausführung eines bestimmten Knoten führt.
Eignung:
Dieser Ansatz ist zwar zunächst in den codebasierten Bereich einzuordnen, aber es spricht auf den ersten Blick nichts dagegen, die Idee auf Kontrollflussgraphen zu übertragen, die auf einer höheren Abstraktion sind (wie z.B. bei dem Systemtest). Abzudeckende Elemente wären dann z.B. Kanten im Aktivitätsdigramm..
M. Soffa, A. Mathur, и N. Gupta. ASE '00: Proceedings of the 15th IEEE international conference on Automated software engineering, стр. 219. Washington, DC, USA, IEEE Computer Society, (2000)ST: Zusammenfassung:
In diesem Paper liegt der Fokus auf der automatischen Testdatengenerierung. Die Testdaten werden so generiert, dass ein gewünschtes Element im Programm durch einen Pfad abgedeckt wird, d.h. es werden die Testdaten werden so generiert, dass dieser Pfad ausgeführt werden kann. Das Programm liegt als Flussgraph vor. Elemente die abgedeckt werden können sind z.B. Kanten, Statements, oder auch aus dem datenflussorientierten Testen defs-uses Paare. Der vorgeschlagene Algorithmus sucht nun Testdaten um genau dieses Element abzudecken. Dabei wird der Flussgraph auf einen Erreichbarkeitspfad reduziert, der die Erreichbarkeit für das gewünschte Element darstellt. Mit Hilfe der Bedingungen, die an den Entscheidungspunkten stehen, können bei Zahlenwerten Ungleichungen aufgestellt werden. Wenn diese nicht lösbar sind, können auch nicht erreichbare Pfade gefunden werden.
Eignung:
Das Beispiel im Paper ist ein White-Box Ansatz, da der Flussgraph sehr quellcodenah ist. Außerdem wird das Beispiel nur mit numerischen Werten durchgeführt, bei denen die Suche mit Ungleichungssystemen einleuchtet. Im Paper wird allerdings erwähnt, dass der Algorithmus auch auf nicht-numerische Werte, die für unsere Zwecke auch auftreten, angewendet werden kann. Der Ansatz ist deswegen als interessant einzuschätzen, da es denkbar ist, ihn auch auf Flussdiagramme (z.B. Aktivitätsdiagramme) auf einer höheren Ebene anzuwenden. Man könnte z.B. genau die Kanten abdecken wollen, die variabel sind, also für eine Applikation neu hinzukommen. Eine andere Idee ist, den Algorithmus so anzupassen, dass er variable Kanten und die Belegungsmöglichkeiten des OVM mit berücksichtigt. (Ähnlich wie bei den Modelcheckingansätzen von Kim)..
S. Edwards. Software Testing, Verification and Reliability, 10 (4):
249--262(января 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. Rapps, и E. Weyuker. ICSE '82: Proceedings of the 6th international conference on Software engineering, стр. 272--278. Los Alamitos, CA, USA, IEEE Computer Society Press, (1982)
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..
E. Uzuncaova, D. Garcia, S. Khurshid, и D. Batory. ESEC-FSE '07: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, стр. 525--528. New York, NY, USA, ACM, (2007)ST: Die Spezifikation der Produktlinie liegt in einer formalen Beschreibung vor (LTL)
Es wird ein Modelchecking-Verfahren durchgefuehrt um zu beweisen, dass die Spezifikation gilt.
Fazit: Keine explizite Ableitung von Testdaten, die Spezifikation muss formal vorliegen.
MR: Anhand von formalen Alloy-Spezifikationen von Invarianten und Constraints kann der Alloy Analyzer (SAT solver) automatisch alle passenden Testdaten generieren.
Nachteile: Die erwarteten Ergebnisse werden nicht betrachtet (oder?). Die Spezifikation wird als Annotationen in den Code eingebracht (hier als moderner Ansatz angesehen ähnlich JML). An der Wiederverwendung wird erst gearbeitet..
J. Offutt, и A. Abdurazik. UML'99 - The Unified Modeling Language. Beyond the Standard. Second International Conference, Fort Collins, CO, USA, October 28-30. 1999, Proceedings, 1723, стр. 416--429. Springer, (1999)MR: Die 'Transition Table' aus UML-Statechart-Werkzeugen wird eingelesen und entsprechend definierten Coverage-Criteria werden daraus Testfälle generiert. Ein weiterer Algo. kümmert sich um die Test Data indem die Werte generiert werden, die zum erreichen von bestimmten Zuständen notwendig sind.
Es gibt keine konkrete Aussage über erwartete Testergebnisse. Den Algorithmen kann man aber vorsichtig ableiten, dass mit Test Data auch die erwarteten Ergebnisse gemeint sind..
Z. Stephenson, Y. Zhan, J. Clark, и J. McDermid. Proceedings of the International Workshop on Software Product Line Testing (SPLiT 2004), стр. 13--18. Boston, MA, (августа 2004)ST:Fokus liegt auf Test der Variablen Artefakte, es soll gezeigt werden dass das richtige Produkt abgeleitet wurde. Test der Korrekten Bindung.
Testdaten-Generierung um zu zeigen, dass der Output sich für zwei unterschiedliche Varianten unterscheidet. Output wird dann gegen die Anforderungen der verschiedenen Varianten getestet, so kann festgestellt werden, ob die richtige Variante gebunden wurde.
Technik erfordert lauffähiges Produkt.
Entwicklung eines Tools, welches für zwei Sourceocde-Artefakte, die sich durch Variabilität unterscheiden, Testdaten generiert.
Fazit: eher für die Überprüfung geeignet ob Varianten korrekt gebunden wurden. Kein Wiederverwendungsansatz für Testdaten, keine explizite Trennung der Testdatenermittlung für Domain / Application Engineering..