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.
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.
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.
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.
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)
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..
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..
A. Bertolino, A. Fantechi, S. Gnesi, and G. Lami. Software Product Lines - Research Issues in Engineering and Management, chapter 11, Springer-Verlag, (2006)
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. 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. 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.
P. Murthy, P. Anitha, M. Mahesh, and R. Subramanyan. SCESM '06: Proceedings of the 2006 international workshop on Scenarios and state machines: models, algorithms, and tools, page 75--82. New York, NY, USA, ACM, (2006)
J. Hartmann, C. Imoberdorf, and M. Meisinger. ISSTA '00: Proceedings of the 2000 ACM SIGSOFT international symposium on Software testing and analysis, page 60--70. New York, NY, USA, ACM, (2000)MR: Es konzentriert sich auf dem Integrationstest. Es gibt aber sehr viele Parallelen zu den späteren Systemtest-Techniken von Hartmann et.al..
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).
S. Mishra. CS&P 2006 - Concurrency, Specification and Programming, (2006)MR: Es wird gezeigt, dass bei SPLs, die mit formalen Spezifikationen (hier CSP-CASL) beschrieben sind, die Testfälle, Testeingaben und erwartete Ergebnisse automatisch generiert werden können.
Die Wiederverwendung der Tests beschränkt sich im Paper auf SPLs von speziellen Art, bei denen die Varianten nur erweitert werden können und somit andere Varianten und den gemeinsamen Teil vollständig involvieren..
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..
P. Ammann, and J. Offutt. Compass'94: 9th Annual Conference on Computer Assurance, page 69--80. Gaithersburg, MD, National Institute of Standards and Technology, (1994)
J. Offutt, and A. Abdurazik. UML'99 - The Unified Modeling Language. Beyond the Standard. Second International Conference, Fort Collins, CO, USA, October 28-30. 1999, Proceedings, 1723, page 416--429. Springer, (1999)MR: Die 'Transition Table' aus UML-Statechart-Werkzeugen wird eingelesen und entsprechend definierten Coverage-Criteria werden daraus Testfälle generiert. Ein weiterer Algo. kümmert sich um die Test Data indem die Werte generiert werden, die zum erreichen von bestimmten Zuständen notwendig sind.
Es gibt keine konkrete Aussage über erwartete Testergebnisse. Den Algorithmen kann man aber vorsichtig ableiten, dass mit Test Data auch die erwarteten Ergebnisse gemeint sind..
M. Chen, X. Qiu, W. Xu, L. Wang, J. Zhao, and 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..
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..
A. Bertolino, E. Marchetti, and 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).
F. Basanieri, A. Bertolino, and E. Marchetti. «UML» 2002 — The Unified Modeling Language, page 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. Future of Software Engineering, 2007. FOSE '07, page 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. Abstract State Machines, page 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..
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..
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..
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..