Myra B. Cohen Matthew B. Dwyer Jiangfan Shi

New York, NY, USA

ROSATEA '06: Proceedings of the ISSTA 2006 workshop on Role of software architecture for testing and analysis 53–63 2006 http://portal.acm.org/citation.cfm?id=1147249.1147257&coll=Portal&dl=GUIDE&CFID=65839091&CFTOKEN=21681387 ACM MR: "Unsere" 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. 1-59593-459-6 Jean Hartmann Marlon Vieira Axel Ruder Birgit Geppert and Charles Krueger and Jenny Li

Boston, MA

Proceedings of the International Workshop on Software Product Line Testing (SPLiT 2004) 58–65 2004 August ST:Basiert auf UML-Aktivitätsdiagrammen Entwicklung eines Tools auf Basis von Rational-Rose. Für die Testdatengewinnung wird eine Ä-Klassenanalyse durchgeführt. Wichtig sind daher die Bedingungen an der Verzweigungspunkten im Aktivitätsdiagramm, da die Auswahl des Testfalls von diesen abhängt. Nutzer wählt Produkt aus und das Tool generiert für ein produkt Testfälle Fazit: Es werden zwar Testfälle mit Testdaten für die Produkte einer Produktlinie automatisch generiert, aber es findet keine Trennung zwischen Domain- und Application Engineering statt. Es ist kein Wiederverwendungsansatz erkennbar. Außerdem arbeitet das Tool auf Basis anderer kommerzieller Tools (Rose). MR: Die Ä-Klassenanalyse wird nach der Category-Partition-Methode durchgeführt, d.h. dass die die Testdaten (mit erwarteten Ausgaben) teilweise manuell erstellt werden müssen. John D. McGregor 2001 CMU/SEI-2001-TR-022 MR: beschäftigt sich eher mit den organisatorischen Aspekten Satish Mishra Roman Redziejowski Ludwik Czaja and Holger Schlingloff CS&P 2006 - Concurrency, Specification and Programming 2006 http://www2.informatik.hu-berlin.de/~hs/Aktivitaeten/2006_CSP/ 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.

Klaus Pohl Andreas Metzger

New York, NY, USA

78–81 2006 Commun. ACM 49 12 http://portal.acm.org/citation.cfm?id=1183236.1183271&coll=Portal&dl=GUIDE&CFID=76494643&CFTOKEN=68898243 ACM

Sacha Reis Andreas Metzger Klaus Pohl FASE 321-335 2007 DBLP:conf/fase/2007 Andreas Reuys 2006 http://www.amazon.de/gp/redirect.html%3FASIN=383251435X%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/383251435X%253FSubscriptionId=13CT5CVB80YFWJEPWS02 Logos Berlin 383251435X Vanessa Stricker 2005 Projektseminar; Lehrstuhl Software Systems Engineering; Professor Dr. Klaus Pohl; SS 2005

Antti Tevanlinna Juha Taina Raine Kauppinen

New York, NY, USA

12–12 2004 SIGSOFT Softw. Eng. Notes 29 2 http://portal.acm.org/citation.cfm?id=979766 ACM MR: ein guter Überblick über SPL-Testing bis 2004

Engin Uzuncaova Daniel Garcia Sarfraz Khurshid Don S. Batory Ivica Crnkovic and Antonia Bertolino

New York, NY, USA

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 525–528 2007 http://doi.acm.org/10.1145/1287624.1287701 ACM 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. 978-1-59593-811-4