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.
"Create effective, grounded, timely materials to support the teaching and self-study of software testing, software reliability, and quality-related software metrics."
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.
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.
This site offers access to selected papers on software testing. The main focus lies on papers related to functional and evolutionary testing as well as their automation. Most of the papers are available in pdf-format or are linked to the original source.
Furthermore, this site offers a free download of the Classification-Tree Editor CTE/XL.
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.
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.
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.
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.
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.
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.
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.
L. Briand, Y. Labiche, and H. Sun. ISSTA '02: Proceedings of the 2002 ACM SIGSOFT international symposium on Software testing and analysis, page 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..
S. Vegas, and V. Basili. Empirical Software Engineering, 10 (4):
437-466(2005)MR: Versucht die Antwort auf die Frage zu erleichtern: Wie soll indentifiziert werden, welches Testkriteria passen am besten zu meinem Testselektionsproblem?
Bei IST-SPL könnte es zur Begründung des eingesetzten Überdeckungskriteriums herangezogen werden..
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..
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..
J. Andrews. ASE '98: Proceedings of the 13th IEEE international conference on Automated software engineering, page 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..
A. Rajan, M. Whalen, and M. Heimdahl. ICSE '08: Proceedings of the 30th international conference on Software engineering, page 161--170. New York, NY, USA, ACM, (2008)MR: nuetzlich fuer IST-SPL nur wegen der Referenzen auf eingesetzte Techniken zur ' Test Case Generation using model checkers '..
L. Tan, O. Sokolsky, and I. Lee. IRI, page 493--498. IEEE Systems, Man, and Cybernetics Society, (2004)ST: Anforderungen werden in LTL spezifiziert.Es wird eine Metrik definiert, die eine Aussage ueber die Abdeckung der spezifizierten Eingenschaften durch eine Testsuite macht. Durch ein Abdeckungskriterium wird eine Testsuite mit endlichen Testfaellen definiert, die die spezifizierten Eigenschaften testet..
D. Peters, and D. Parnas. IEEE Transactions on Software Engineering, 24 (3):
161--173(1998)ST: Spezifikation einer SW-Einheit (im Paper Methoden) wird formal beschrieben. Tool leitet automatisch Orakel ab.
Grenzen werden bei dynamische Datenstrukturen erreicht da sie schwer beschreibbar sind.
Die formale Spezifikation erscheint in den Beispielen sehr aufwendig..
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..
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..
Z. Stephenson, Y. Zhan, J. Clark, and J. McDermid. Proceedings of the International Workshop on Software Product Line Testing (SPLiT 2004), page 13--18. Boston, MA, (August 2004)ST:Fokus liegt auf Test der Variablen Artefakte, es soll gezeigt werden dass das richtige Produkt abgeleitet wurde. Test der Korrekten Bindung.
Testdaten-Generierung um zu zeigen, dass der Output sich für zwei unterschiedliche Varianten unterscheidet. Output wird dann gegen die Anforderungen der verschiedenen Varianten getestet, so kann festgestellt werden, ob die richtige Variante gebunden wurde.
Technik erfordert lauffähiges Produkt.
Entwicklung eines Tools, welches für zwei Sourceocde-Artefakte, die sich durch Variabilität unterscheiden, Testdaten generiert.
Fazit: eher für die Überprüfung geeignet ob Varianten korrekt gebunden wurden. Kein Wiederverwendungsansatz für Testdaten, keine explizite Trennung der Testdatenermittlung für Domain / Application Engineering..