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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"Create effective, grounded, timely materials to support the teaching and self-study of software testing, software reliability, and quality-related software metrics."
Die gezeigten Posts sind eventuell nicht akkurat bei Änderungen, die vor Kurzem vorgenommen worden. Wollen Sie jedoch akkurate Posts mit eingeschränkten Sortierungsmöglichkeiten, folgen Sie dem folgenden Link.
?. Lecture Notes in Computer Science Springer, 1 Edition, (2002)MR: eher für den fortgeschrittenen Einsatz von OCL oder sogar für die Forschung rund um OCL.
P. Ammann, und J. Offutt. Compass'94: 9th Annual Conference on Computer Assurance, Seite 69--80. Gaithersburg, MD, National Institute of Standards and Technology, (1994)
J. Andrews. ASE '98: Proceedings of the 13th IEEE international conference on Automated software engineering, Seite 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..
J. Andrews, R. Fu, und V. Liu. ASE '02: Proceedings of the 17th IEEE international conference on Automated software engineering, Seite 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..
M. Balcer, W. Hasling, und T. Ostrand. Symposium on Testing, Analysis, and Verification, Seite 210-218. (1989)MR: Formalismen zu der Category-Partition-Methode mittels TSL.
F. Basanieri, A. Bertolino, und E. Marchetti. «UML» 2002 — The Unified Modeling Language, Seite 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, E. Marchetti, und H. Muccini. Electronic Notes in Theoretical Computer Science, (Januar 2005)MR: enthält Overview on Model-based Testing.
Dieser Ansatz erweitert den Cow_Suite-Ansatz indem neben der Sequenzdiagrammen und der UIT-Technik auch noch Zustandsdiagramme als Input für die Ableitung der Testfälle berücksichtigt werden. Es erfolgt mehrfache automatische Synthese der Sequenzdiagramme aus den Zustandsdiagrammen und umgekehrt. Die resultierenden 'augepeppten' Sequenzdiagramme dienen als Input für die UIT-Technik.
Für IST-SPL interessant, wenn Zustandsdiagramme involviert werden sollten..
A. Bertolino. Abstract State Machines, Seite 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..
A. Bertolino. Future of Software Engineering, 2007. FOSE '07, Seite 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..
A. Bertolino, A. Fantechi, S. Gnesi, und G. Lami. Software Product Lines - Research Issues in Engineering and Management, Kapitel 11, Springer-Verlag, (2006)
A. Bertolino, E. Marchetti, und A. Polini. Electronic Notes in Theoretical Computer Science, 82 (6):
44--54(September 2003)MR: vermutlich keine großen Neuerungen im Vergleich zu dem Haupt-Cow_Suite_Paper (Basanieri2002).
A. Braganca, und R. Machado. SPLC '07: Proceedings of the 11th International Software Product Line Conference, Seite 3--12. Washington, DC, USA, IEEE Computer Society, (2007)
L. Briand, Y. Labiche, und H. Sun. ISSTA '02: Proceedings of the 2002 ACM SIGSOFT international symposium on Software testing and analysis, Seite 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..
J. Calame, N. Ioustinova, und J. van de Pol. Electronic Notes in Theoretical Computer Science, (Oktober 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..
A. Carniello, M. Jino, und M. Chaim. Journal of Computer Science & Technology, (2005)ST: Vorgehensweise:
Die Technik arbeitet mit einem Test-kriterium, welches auf Basis der Struktur von Use-Cases entwickelt wird. Die Struktur bildet sich durch Assoziationen, Include- und Extend Beziehungen. Testkriterien sind die Auführung von Use Cases mit allen include und extend Beziehungen, oder die Kombination von extend Beziehungen. Die Rechtfertigung nach dieser Technik vorzugehen liegt darin, das bei dieser Technik mehr Fehler gefunden werden können als bei einem reinen funktionalen Test.
Eignung:
Nach dem Lesen stellte sich heraus, dass keine Flussdiagramme für den Kontrollfluss der Use-Cases verwendet werden sondern nur die Struktur der Use Cases. Daher ist der Ansatz eher ungeeignet..
P. Carpenter. Ada Lett., XIX (3):
23--29(1999)ST: Vorgehensweise: Das Paper ordnet den Vorgang, wie man sicherheitskritische Anforderungen verifizieren kann, in einen Software Life-Cycle ein. Use-Cases werden mit Parametern für Daten versehen. Die Eingabedaten werden mit Hilfe eines Tools generiert per üblicher Ä-Klassenanalyse.
Eignung: Es ist nichts über die Testgüte zu finden (Abdeckungskriterium etc.). Außerdem wird kein Testmodell o.ä. erwähnt, welches alternative Ausführungspfade des Use Cases repräsentiert..
M. Chen, X. Qiu, W. Xu, L. Wang, J. Zhao, und 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..
T. Chen, S. Tang, P. Poon, und T. Tse. QSIC '05: Proceedings of the Fifth International Conference on Quality Software, Seite 55--63. Washington, DC, USA, IEEE Computer Society, (2005)
M. Cohen, M. Dwyer, und J. Shi. ROSATEA '06: Proceedings of the ISSTA 2006 workshop on Role of software architecture for testing and analysis, Seite 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..