ObjectGen is a tool for generating test objectives from use cases. ValueGen is a tool for generating operational variables and combination of values from use cases. Although ValueGen needs the artefacts generated by ObjectGen, both tools are independent.
Software testing is important activity in Software Development Life Cycle. To cut down cost of manual testing and to increase reliability of it, researchers and practitioners have tried to automate it. One of the important activity in testing environment is automatic test case generation - description of a test, independent of the way a given software system is designed. This paper presents a survey on automatic test case generation techniques that are found in the current literature. Problems in usage of certain techniques are identified. Areas that needed future research are presented.
UCTSystem is a prototype tool designed to perform automatic test generation from UML requirements. It uses UML use cases enhenced with contracts (i.e. precondition and postconditions) to build an execution model allowing all valid sequences of use cases. Using this execution model and several test criteria, it generates test objectives as sequence of use cases to exerce. It includes both criteria for functional testing and a criterion for robusness testing. Those test objectives are then mapped into test cases using test templates.
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)
R. Ferguson, and 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, and N. Gupta. ASE '00: Proceedings of the 15th IEEE international conference on Automated software engineering, page 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(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)..
C. Nebut, F. Fleurey, Y. Traon, and J. Jézéquel. ISSRE '03: Proceedings of the 14th International Symposium on Software Reliability Engineering, page 85. Washington, DC, USA, IEEE Computer Society, (2003)
P. Fröhlich, and J. Link. ECOOP '00: Proceedings of the 14th European Conference on Object-Oriented Programming, page 472--492. London, UK, Springer-Verlag, (2000)
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..
M. Chen, X. Qiu, W. Xu, L. Wang, J. Zhao, and X. Li. The Computer Journal, (2007)MR: Der Ansatz ist ein Gray-Box-Ansatz, obwohl es auf Modellen basiert, muss das Programm selbst auch ausgeführt werden um bestimmte Eingaben für das Verfahren zu liefern.
Die Generierung von Testdaten ist kaum automatisiert.
Für IST-SPL interessant wegen den Formalismen für Aktivitätsdiagramme..
F. Basanieri, A. Bertolino, and E. Marchetti. «UML» 2002 — The Unified Modeling Language, page 275--303. (2002)MR: Cow_Suite ist ein Ansatz einer Technik und Toolprototyp für den Systemtest und Integrationstest und besteht aus zwei Teilen:
- UIT (Use Interaction Test) als Testableitungsmethode
- Cowtest (Cost Weighted Test Strategy) für Testpriorisierung und -selektion.
Mit Cowtest wird entschieden welche Testfälle ausgeführt werden sollen, durch setzen von Gewichten in die von der Spez. abgeleitete Graphstrukturen (Testauswahlkriterium) und unterstützt auch die Planung des Testprozesses.
UIT nutzt diese Information bei der Testfallableitung basierend auf der Category-Partition-Methode, also teils manuell (Interaction mit dem User).
Das Besondere ist, dass die forliegende Anforderungs- und Designspezifikation in Form von UML-Use-Case-Diagrammen und -Sequenzdiagrammen ohne weiteren Ausbau (also so wie sie ist) als Input für die Technik dienen kann.
Ein für IST-SPL wichtiger Ansatz: es wäre möglich ähnliche Strategie (CP) bereits für die Aktivitätsdiagramme anzuwenden, wobei deren Produktlinieneigenschaften berücksichtigt werden müssten..
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..
C. Mingsong, Q. Xiaokang, and L. Xuandong. AST '06: Proceedings of the 2006 international workshop on Automation of software test, page 2--8. New York, NY, USA, ACM, (2006)