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.
A. Engel. Wiley Series in Systems Engineering and Management Wiley, 1 edition, (2010)Wertvoll wegen den verschiedenen Black-Box-Testing Methoden für komplexe Systeme..
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)
A. Memon, I. Banerjee, and A. Nagarajan. Automated Software Engineering, 2003. Proceedings. 18th IEEE International Conference on, page 164-173. (October 2003)
P. Santos-Neto, R. Resende, and C. Pádua. SAC '07: Proceedings of the 2007 ACM symposium on Applied computing, page 1409--1415. New York, NY, USA, ACM, (2007)
A. Pretschner, and J. Philipps. Model-Based Testing of Reactive Systems, volume 3472 of Lecture Notes in Computer Science, page 281-291. Springer, (2004)
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..
A. Carniello, M. Jino, and 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..
R. Ferguson, and B. Korel. ACM Trans. Softw. Eng. Methodol., 5 (1):
63--86(1996)ST: Vorgehensweise:
Die Idee dieses Ansatzes ist es eine Sequenz von Knoten im Kontrollflussgraphen zu finden, die zu einer Ausführung eines bestimmten Knoten führt.
Eignung:
Dieser Ansatz ist zwar zunächst in den codebasierten Bereich einzuordnen, aber es spricht auf den ersten Blick nichts dagegen, die Idee auf Kontrollflussgraphen zu übertragen, die auf einer höheren Abstraktion sind (wie z.B. bei dem Systemtest). Abzudeckende Elemente wären dann z.B. Kanten im Aktivitätsdigramm..
M. Soffa, A. Mathur, and N. Gupta. ASE '00: Proceedings of the 15th IEEE international conference on Automated software engineering, page 219. Washington, DC, USA, IEEE Computer Society, (2000)ST: Zusammenfassung:
In diesem Paper liegt der Fokus auf der automatischen Testdatengenerierung. Die Testdaten werden so generiert, dass ein gewünschtes Element im Programm durch einen Pfad abgedeckt wird, d.h. es werden die Testdaten werden so generiert, dass dieser Pfad ausgeführt werden kann. Das Programm liegt als Flussgraph vor. Elemente die abgedeckt werden können sind z.B. Kanten, Statements, oder auch aus dem datenflussorientierten Testen defs-uses Paare. Der vorgeschlagene Algorithmus sucht nun Testdaten um genau dieses Element abzudecken. Dabei wird der Flussgraph auf einen Erreichbarkeitspfad reduziert, der die Erreichbarkeit für das gewünschte Element darstellt. Mit Hilfe der Bedingungen, die an den Entscheidungspunkten stehen, können bei Zahlenwerten Ungleichungen aufgestellt werden. Wenn diese nicht lösbar sind, können auch nicht erreichbare Pfade gefunden werden.
Eignung:
Das Beispiel im Paper ist ein White-Box Ansatz, da der Flussgraph sehr quellcodenah ist. Außerdem wird das Beispiel nur mit numerischen Werten durchgeführt, bei denen die Suche mit Ungleichungssystemen einleuchtet. Im Paper wird allerdings erwähnt, dass der Algorithmus auch auf nicht-numerische Werte, die für unsere Zwecke auch auftreten, angewendet werden kann. Der Ansatz ist deswegen als interessant einzuschätzen, da es denkbar ist, ihn auch auf Flussdiagramme (z.B. Aktivitätsdiagramme) auf einer höheren Ebene anzuwenden. Man könnte z.B. genau die Kanten abdecken wollen, die variabel sind, also für eine Applikation neu hinzukommen. Eine andere Idee ist, den Algorithmus so anzupassen, dass er variable Kanten und die Belegungsmöglichkeiten des OVM mit berücksichtigt. (Ähnlich wie bei den Modelcheckingansätzen von Kim)..
B. Hasling, H. Goetz, and K. Beetz. Software Testing, Verification, and Validation, 2008 1st International Conference on, (April 2008)ST: Vorgehensweise:
In diesem Paper wird eine Testtechnik für den Systemtest beschrieben, die von Siemens im medizinischen Bereich angewendet wurde. Aus einem Use Case Modell, dessen Szenarien durch Aktivitätsdiagramme und Sequenzdiagramme beschrieben werden und Äquivalenzklassen für die erforderlichen Testdaten, können Testfälle generiert werden. Dazu wird das Tool TDE/UML benutzt, welche in vorhergehenden Ansätzen entwickelt wurde. Neu an dieser Technik zu den vorher entwickelten Techniken ist die Verbindung des Requirements-Prozesses mit dem Testprozess durch die Benutzung von Use-Cases, die schon im RE erstellt werden.
Eignung:
Vom Prinzip her ist die Vorgehensweise vergleichbar mit der Idee in ScenTEDTDG, da auf den gleichen Modellen gearbeitet wird und Äquivalenzklassen für die Testdatengewinnung herangezogen werden. Variabilität fehlt, da es ein Einzelsystemansatz ist..
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..
P. Samuel, and A. Joseph. Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, ACIS International Conference on, (2008)ST: Vorgehensweise: Es wurden vier Arten von Abhängigkeiten identifiziert die zwischen Nachrichten in einem Sequenzdiagramm bestehen können. Aus einem UML 2.0 Sequenzdiagramm wird ein Graph generiert, der diese Abhängigkeiten darstellt. Daraus werden dann Test-Sequenzen abgeleitet.
Eignung: Es werden zwar Testfälle generiert, aber es wird nicht festgelegt woher die Testdaten kommen..
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..
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.”.
A. Bertolino, A. Fantechi, S. Gnesi, and G. Lami. Software Product Lines - Research Issues in Engineering and Management, chapter 11, Springer-Verlag, (2006)
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)
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.
P. Liggesmeyer. Spektrum Akademischer Verlag, (2002)MR: Wertvoll ist die Klassifikation und Beschreibung der SW-Prüftechniken unterteilt u.a. in funktionsorientierte (spezifikationsbasierte) und strukturierte (codebasierte)..
S. Pickin, C. Jard, Y. Traon, T. Jéron, J. Jézéquel, and A. Guennec. FORTE, page 97-113. (2002)MR: Mittels UMLAUT wird die UML-Spezifikation in ein IOLTS überführt und durch das Testsynthesis-Tool TGV werden Testfälle abgeleitet.
Auf diesem Ansatz baut auch der Ansatz von Nebut im SPL-Umfeld Nebut2002Nebut2003Nebut2006..
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)..
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)