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.
J. Warmer, und A. Kleppe. Addison Wesley, 2. A. Edition, (2003)MR: Referenz für OCL
Wertvoll: Es wird gezeigt wie mit OCL Modelle gebaut werden.
MDA eher nur am Rande erklärt
Wichtigster Satz (Kapitel 3.2):
The use of OCL strongly relies on the types (classes, datatypes, and so on) defined in a UML class diagram. This diagram should be build first..
G. Xu, Z. Yang, H. Huang, Q. Chen, L. Chen, und 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..