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.
"Create effective, grounded, timely materials to support the teaching and self-study of software testing, software reliability, and quality-related software metrics."
Software developers frequently encounter failures that occur only as the result of an interaction between two components. Failure triggering fault interactionsTesters often use pairwise testing – all pairs of parameter values – to detect such interactions. Combinatorial testing beyond pairwise is rarely used because good algorithms for higher strength combinations (e.g., 4-way or more) have not been available, but empirical evidence shows that some errors are triggered only by the interaction of three, four, or more parameters (see graph). These results have important implications for testing. If all faults in a system can be triggered by a combination of n or fewer parameters, then testing all n-way combinations of parameters can provide high confidence that nearly all faults have been discovered. We are producing methods and tools to generate tests for all n-way combinations of parameter values, using improved combinatorial testing algorithms for constructing covering arrays, and automated generation of test oracles using model checking.
In contrast to manual selection of input value boundaries, we present an approach to derive them automatically from OCL expressions of UML state machines and UML class diagrams. We statically analyze the interdependence of OCL expressions within the system model and transform the model into a transition tree and investigate the tree's paths. The corresponding test suite is focused on detecting errors that result from differences between constraints in the model and constraints in the system under test.
The Dresden OCL Toolkit is all about the Object Constraint Language (OCL). OCL is part of the well-known Unified Modelling Language (UML). It extends the UML's graphical notation with the possiblity of adding more formally defined textual constraints on method invocations and on class structures as a whole. Many aspects of a model that cannot be expressed adequately with the graphical notation alone find their representation in OCL constraints.
So, where does the Dresden OCL Toolset come into play? As its name indicates it is not some standalone solution. Instead, many of these tools are meant to be used as a library, integrated into other tools, but there exist also some standalone tools in the Toolkit.
This document contains some pointers to information on Formal Methods, useful for mathematically describing and reasoning about computer-based systems, available around the world on the World Wide Web (WWW). Formal methods are a fault avoidance technique that help in the reduction of errors introduced into a system, particularly at the earlier stages of design. They complement fault removal techniques like testing.
This article discusses various uses of OCL (Object Constraint Language) for both developers and testers. IT also enumerates the many advantages of the language, which is part of the UML specification.
NuSMV is a symbolic model checker
NuSMV is a reimplementation and extension of SMV, the first model checker based on BDDs. NuSMV has been designed to be an open architecture for model checking, which can be reliably used for the verification of industrial designs, as a core for custom verification tools, as a testbed for formal verification techniques, and applied to other research areas.
NuSMV2, combines BDD-based model checking component that exploits the CUDD library developed by Fabio Somenzi at Colorado University and SAT-based model checking component that includes an RBC-based Bounded Model Checker, connected to the SIM SAT library developed by the University of Genova.
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.
Opensourcetesting.org aims to boost the profile of open source testing tools within the testing industry, principally by providing users with an easy to use gateway to information on the wide range of open source testing tools available.
Uni-DUE: *E-Books, Safari Books online*
Eine große Sammlung elektronischer Volltexte von neu erschienenen deutschsprachigen Büchern aus den Verlagen Springer, Teubner, Vieweg, Gabler und Verlag für Sozialwissenschaften steht unter dem Link Datenbanken-E-Books zur Verfügung. Ausserdem wurde das Angebot der Safari Books online von 200 auf 300 Slots und in der Anzahl der parallelen Nutzer erweitert.
Seminar "Spezifikationsbasierter Softwaretest"
Prof. Dr. H. Schlingloff, Lehre
In der Veranstaltung wird die Frage behandelt, wie Testfälle aus Spezifikationen abgeleitet werden können. Ein besonderer Schwerpunkt ist dabei der modellbasierte Test eingebetteter Systeme, z.B. im Automotive Software Engineering.
E. Uzuncaova, D. Garcia, S. Khurshid, and 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, page 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. 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..
A. Neto, R. Subramanyan, M. Vieira, and G. Travassos. WEASELTech '07: Proceedings of the 1st ACM international workshop on Empirical assessment of software engineering languages and technologies, page 31--36. New York, NY, USA, ACM, (2007)
J. Hartmann, M. Vieira, and A. Ruder. Proceedings of the International Workshop on Software Product Line Testing (SPLiT 2004), page 58--65. Boston, MA, (August 2004)
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..
N. Raza, A. Nadeem, and M. Iqbal. Quality Software, 2007. QSIC '07. Seventh International Conference on, (October 2007)ST: Vorgehensweise: Aus diesen Diagrammen sollen Testpfade für den Systemtest generiert werden. Die Diagramme sind mit Pre- und Postconditions durch OCL versehen. Aus diesen Diagrammen wird ein Zustandsautomat generiert. Nun können Abdeckungskriterien wie Zustandsüberdeckung oder Transitionsüberdeckung angewendet werden um Testpfade abzuleiten.
Eignung: Es können Testpfade für den Systemtest abgeleitet werden aber wie die Testdaten systematisch abgeleitet werden bleibt offen..
B. Korel, and A. Al-Yami. icse, (1996)ST: Testdaten werden mit Hilfe der Assertions automatisch abgeleitet. Das Ziel ist es Testdaten abzuleiten die die Assertion verletzen. Mit dieser Vorgehensweise werden mehr Fehler gefunden als mit herkömmlichen Methoden..
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)
M. Balcer, W. Hasling, and T. Ostrand. Symposium on Testing, Analysis, and Verification, page 210-218. (1989)MR: Formalismen zu der Category-Partition-Methode mittels TSL.
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..
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)ST: Vorgehensweise: Erst wird eine große Menge von zufälligen Testfällen generiert. Das Programm wird mit diesen Testfällen ausgeführt und man erhält die entsprechenden Ausführungspfade. Diese werden mit den Aktivitätsdiagrammen verglichen auf Basis des Abdeckungskriteriums. Man wählt die übereinstimmenden Ausführungspfade aus und erhält so eine reduzierte Menge von Testfällen die das Abdeckungskriterium erfüllt. So kann auch die Konsistenz des Programms mit dem Aktivitätsdiagramm geprüft werden.
Eignung: Man findet keine Hinweise darauf, woher die Testdaten für die zufällig erzeugten Testfälle kommen. Für diesen Schritt wird auf ein Paper verwiesen, welches zufällige Testfälle für den Unittest erzeugt, siehe „A Tool for Random Generation of Unit Tests for Java Classes.”.
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. Braganca, and R. Machado. SPLC '07: Proceedings of the 11th International Software Product Line Conference, page 3--12. Washington, DC, USA, IEEE Computer Society, (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)..
H. Gross. Springer, 1 edition, (2004)MR: am meisten interessant ist der Kapitel: Model-Based Testing with UML und dadrin der Abschnitt über das Testen mit Aktivitätsdiagrammen (in Bezug auf ScenTED).
M. Cohen, M. Dwyer, and J. Shi. ROSATEA '06: Proceedings of the ISSTA 2006 workshop on Role of software architecture for testing and analysis, page 53--63. New York, NY, USA, ACM, (2006)MR: Ünsere" OVM-Notation wird auf ein relationales Modell abgebildet, um damit Abdeckungskriterien für das Testen von SPL definieren zu können. Mit diesen Kriterien kann die Information gesammelt werden für sogenanntes 'cumulative variability coverage' mit dem gezielt die Testaufwände für neue Produkte der SPL festgelegt werden können. Das Ganze wird durch combinatorial interaction testing ermöglicht. Diese Technik (aus Einzelsystemen bekannt) reduziert die hohe Anzahl von möglichen Kombinationen von Input-Variablen auf wenige Repräsentanten.
Bei IST-SPL könnte man überlegen, diese Technik als Ergänzung einer anderen einzuführen, um höhere Abdeckungsraten zu erreichen.
Der Nachteil ist jedoch immer noch, dass hierbei keine Orakel erstellt werden. Hierfür verweisen die Spezialisten von Combinatorial Testing auf Model Checking beispielsweise..
S. Rapps, and E. Weyuker. ICSE '82: Proceedings of the 6th international conference on Software engineering, page 272--278. Los Alamitos, CA, USA, IEEE Computer Society Press, (1982)
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.
T. Kishi, and N. Noda. Proceedings of the International Workshop on Software Product Line Testing (SPLiT 2004), page 19--26. Boston, MA, (August 2004)ST: Das zu testende System und die mit dem System in Interaktion stehende Umgebung werden als Zustandsautomat modelliert.
Testdaten ergeben sich aus den Transitionen.
Es werden Modelchecking Techniken angewendet um Invarianten zu prüfen..
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..