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.
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.
T. Chen, S. Tang, P. Poon, and T. Tse. QSIC '05: Proceedings of the Fifth International Conference on Quality Software, page 55--63. Washington, DC, USA, IEEE Computer Society, (2005)
J. Edvardsson. (1999)ST: In diesem Paper wird ein Überblick gegeben wie Testdaten automatisch generiert werden können. An einem Beispiel wird die Vorgehensweise erläutert, wie Testdaten autoamtisch abgeleitet werden können; es eignet sich gut um die Grundlagen zu verstehen. Es werden weiterhin unterschiede zwischen zielorientierter, zufälliger, und pfadorientierter Testdatenableitung aufgezeigt..
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)
A. Reuys, S. Reis, E. Kamsties, and K. Pohl. Erfurt, (2003)Proceedings of the PLEES’03 International Workshop on Product Line Engineering: The Early Steps: Planning, Modeling, and Managing.
M. Friske, and H. Schlingloff. Tagungsband Dagstuhl-Workshop MBEES: Model Based Engineering of Embedded Systems, 2005-01, TU Braunschweig, (January 2005)
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..
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..
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)
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..
J. Calame, N. Ioustinova, and J. van de Pol. Electronic Notes in Theoretical Computer Science, (October 2007)MR: Stark formalisiertes und mathematisch ergründetes Werk.
Basierend auf der Spezifikation des IUT (gegeben in LTS) wird der Lösungsraum durch data abstraction eingeengt (mittels µCRL). Mittels enumerativ tools (wie TGV) werden dann abstrakte Testfälle generiert. Die konkreten Daten (Ein und Ausgaben!) werden mittels constraint-solving techniques (mittels Prolog) ermittelt.
Future Work soll ermöglichen UML-Spezifikationen als Eingabe zu erlauben und die Testfälle sollen in TTCN-3 generiert werden!
Spätestens dann wird dieser Ansatz für IST-SPL sehr interessant..