http://www.bibsonomy.org/burst/user/ist_spl/lineBibSonomy BuRST Feed for /user/ist_spl/line2008-09-05T07:30:50+02:00http://www.bibsonomy.org/bibtex/2b64fd7f3e0bf3df7ff2a9a8b8d545167/ist_splist_spl2008-09-03T10:02:06+02:00SSE systemtest product line ScenTED <span style="color:#555555;">Andreas <a href="http://www.bibsonomy.org/author/Reuys">Reuys</a> und Erik <a href="http://www.bibsonomy.org/author/Kamsties">Kamsties</a> und Klaus <a href="http://www.bibsonomy.org/author/Pohl">Pohl</a> und Sacha <a href="http://www.bibsonomy.org/author/Reis">Reis</a> </span><em>Inform., Forsch. Entwickl.</em><em>20(1-2):33-44</em>(<em>2005</em>)Wed Sep 03 10:02:06 CEST 2008Inform., Forsch. Entwickl.1-233-44Szenario-basierter Systemtest von Software-Produktfamilien202005SSE systemtest product line ScenTED Software product line testinghttp://www.bibsonomy.org/bibtex/2d98a11b8a2cfb061f5eeea8f84b44ff3/ist_splist_spl2008-09-03T10:00:11+02:00ScenTED line SSE product testing <span style="color:#555555;">Klaus <a href="http://www.bibsonomy.org/author/Pohl">Pohl</a> und Andreas <a href="http://www.bibsonomy.org/author/Metzger">Metzger</a> </span><em>Commun. ACM</em><em>49(12):78--81</em>(<em>2006</em>)Wed Sep 03 10:00:11 CEST 2008New York, NY, USACommun. ACM1278--81Software product line testing492006ScenTED line SSE product testing Exploring principles and potential solutions.http://www.bibsonomy.org/bibtex/26f2567a20bd96c5368c6e878bf8fd01e/ist_splist_spl2008-09-03T09:08:29+02:00PLUC line testing category-partition product systemtest PLUTO Use-Cases <span style="color:#555555;">Antonia <a href="http://www.bibsonomy.org/author/Bertolino">Bertolino</a> und Stefania <a href="http://www.bibsonomy.org/author/Gnesi">Gnesi</a> </span><em>PFE, </em><em>Seite181-197. </em>(<em>2003</em>) <em>MR: Besch&amp;#228;ftigt sich mit dem Systemtest. Variabilit&amp;#228;t der PL auch in Testartefakten ber&amp;#252;cksichtigt, aber keine systematische Wiederverwendun<span class="info">...<span>MR: Besch&#228;ftigt sich mit dem Systemtest. Variabilit&#228;t der PL auch in Testartefakten ber&#252;cksichtigt, aber keine systematische Wiederverwendung von Testeingaben und erwarteten Ergebnissen. Testableitung teilweise manuell. Nicht modellbasiert.</span></span> . </em>Wed Sep 03 09:08:29 CEST 2008PFEDBLP:conf/pfe/2003MR: Beschäftigt sich mit dem Systemtest. Variabilität der PL auch in Testartefakten berücksichtigt, aber keine systematische Wiederverwendung von Testeingaben und erwarteten Ergebnissen. Testableitung teilweise manuell. Nicht modellbasiert.181-197PLUTO: A Test Methodology for Product Families2003PLUC line testing category-partition product systemtest PLUTO Use-Cases The testing stage for a product belonging to a family is a crucial and expensive part of development. Yet the derivation of test cases for product families has so far received little attention. We focus here on test planning, that is the most critical part of testing. We outline a simple methodology we are developing for this purpose, called PLUTO, relying on the early requirements specification expressed as Use Cases. We also overview the related literature.http://www.bibsonomy.org/bibtex/23bfe504598091728c40915f10395bf23/ist_splist_spl2008-09-03T08:49:03+02:00product systemtest testing ScenTED SSE line <span style="color:#555555;">Andreas <a href="http://www.bibsonomy.org/author/Reuys">Reuys</a> und Erik <a href="http://www.bibsonomy.org/author/Kamsties">Kamsties</a> und Klaus <a href="http://www.bibsonomy.org/author/Pohl">Pohl</a> und Sacha <a href="http://www.bibsonomy.org/author/Reis">Reis</a> </span><em>CAiSE, </em><em>Seite519-534. </em>(<em>2005</em>)Wed Sep 03 08:49:03 CEST 2008CAiSEDBLP:conf/caise/2005519-534Model-Based System Testing of Software Product Families2005product systemtest testing ScenTED SSE line http://www.bibsonomy.org/bibtex/205f49f607ea295f48e61eb2d61b7fbc1/ist_splist_spl2008-09-02T14:30:48+02:00product line variability SSE OVM <span style="color:#555555;">Klaus <a href="http://www.bibsonomy.org/author/Pohl">Pohl</a> und Andreas <a href="http://www.bibsonomy.org/author/Metzger">Metzger</a> </span><em>Software Engineering, </em><em>Seite28-41. </em>(<em>2008</em>)Tue Sep 02 14:30:48 CEST 2008Software EngineeringDBLP:conf/se/200828-41Variabilit{\"a}tsmanagement in Software-Produktlinien2008product line variability SSE OVM Die Software-Produktlinienentwicklung erlaubt die Entwicklung ähnlicher Software-Systeme zu geringen Kosten, in kurzer Zeit und zudem mit steigender Qualität. Zahlreiche Erfahrungen aus der Industrie belegen diese Vorteile der Produktlinienentwicklung gegenüber der Entwicklung von Einzel-Software-Systemen. Der Schlüssel für die Software-Produktlinienentwicklung ist die Unterscheidung zwischen zwei Entwicklungsprozessen („Entwicklung für Wiederverwendung“ und „Entwicklung unter Wiederverwendung“) sowie der systematische Umgang mit den Unterschieden (der Variabilität) sowie den Gemeinsamkeiten der Produkte einer Produktlinie. In diesem Beitrag diskutieren wir die Notwendigkeit der expliziten Dokumentation der Produktlinienvariabilität und stellen Ansätze zur expliziten Dokumentation von Produktlinienvariabilität in unterschiedlichen Entwicklungsmodellen vor (z.B. UML-Diagramme oder Feature-Modelle). Darauf aufbauend erläutern wir den Vorteil der Dokumentation der Variabilität in dedizierten Modellen und stellen als eine mögliche Form dieser Variabilitätsmodellierung den in Essen entwickelten Ansatz zur Orthogonalen Variabilitätsmodellierung (OVM) vor. Die Vorteile des OVM-Ansatzes, insbesondere bezüglich der Handhabung von Variabilität in verschiedenen Entwicklungsartefakten, illustrieren wir anhand von Beispielen. Automating Mappings between Use Case Diagrams and Feature Models for Software Product Lineshttp://www.bibsonomy.org/bibtex/2fa8b293e480a80239c6dd7aec83886c7/ist_splist_spl2008-08-27T15:05:25+02:00Use-Cases model OCL diagrams transformation QVT line UML product feature <span style="color:#555555;">Alexandre <a href="http://www.bibsonomy.org/author/Braganca">Braganca</a> und Ricardo J. <a href="http://www.bibsonomy.org/author/Machado">Machado</a> </span><em>SPLC '07: Proceedings of the 11th International Software Product Line Conference, </em><em>Seite3--12. </em><em>Washington, DC, USA, </em><em>IEEE Computer Society, </em>(<em>2007</em>)Wed Aug 27 15:05:25 CEST 2008Washington, DC, USASPLC '07: Proceedings of the 11th International Software Product Line Conference3--12Automating Mappings between Use Case Diagrams and Feature Models for Software Product Lines2007Use-Cases model OCL diagrams transformation QVT line UML product feature Features have been widely used by the product line community to model variability. They represent the common and variable characteristics of the members of a product line. They are very well suited for the configuration of product line members. Outside the product line community, use cases are also widely used to model the functionality of systems at a similar level of abstraction but from a user perspective. Significant work has been done by several authors regarding the possible relationship between these two perspectives of a system. Nonetheless, this has been done in an informal way. In this paper we explore the relationships between these two perspectives and describe a possible approach to automate the transformation from UML use case to feature models.ScienceDirect - Journal of Systems and Software : Evolution support mechanisms for software product line process Feature-based Meta-process Product Software Transient Use architecture case development evolution line model modeling object oriented process product Keywords: Software product line process evolution; Software development process; Product line architecture; Transient process; Meta-process; Feature-based object oriented model; Use case modelinghttp://www.bibsonomy.org/bibtex/217c14994dcc3ed0a33a7479154a2a063/ist_splist_spl2008-08-14T10:30:20+02:00product line process development Use-Cases modeling <span style="color:#555555;">Samuel A. <a href="http://www.bibsonomy.org/author/Ajila">Ajila</a> und Ali B. <a href="http://www.bibsonomy.org/author/Kaba">Kaba</a> </span><em>Journal of Systems and Software</em><em>81(10):1784--1801</em><em>#oct#2008. </em>Thu Aug 14 10:30:20 CEST 2008Selected papers from the 30th Annual International Computer Software and Applications Conference (COMPSAC), Chicago, September 7-21, 2006Journal of Systems and Software#oct#101784--1801Evolution support mechanisms for software product line process812008product line process development Use-Cases modeling Software product family process evolution needs specific support for incremental change. Product line process evolution involves in addition to identifying new requirements the building of a meta-process describing the migration from the old process to the new one. This paper presents basic mechanisms to support software product line process evolution. These mechanisms share four strategies - change identification, change impact, change propagation, and change validation. It also examines three kinds of evolution processes - architecture, product line, and product. In addition, change management mechanisms are identified. Specifically we propose support mechanisms for static local entity evolution and complex entity evolution including transient evolution process. An evolution model prototype based on dependency relationships structure of the various product line artifacts is developed.MR: Gewissermaßen ein Teil der Diss von Andreas Reuys und der ScenTED-Methode.http://www.bibsonomy.org/bibtex/277be542bac60389552ee830a4671476b/ist_splist_spl2008-07-23T17:28:26+02:00diagrams scenario-based testing ScenTED product coverage activity ddgraph MBT branch UML FTPS line <span style="color:#555555;">Thomas <a href="http://www.bibsonomy.org/author/Rinke">Rinke</a> </span>(<em>2004</em>)Wed Jul 23 17:28:26 CEST 2008Ableitung von Domänen-Testfall-Szenarien aus Domänen-Aktivitätsdiagrammen unter Gewährleistung der Zweigabdeckung Diplomarbeit2004diagrams scenario-based testing ScenTED product coverage activity ddgraph MBT branch UML FTPS line DBLP Record 'journals/sosym/HalmansP03'http://www.bibsonomy.org/bibtex/2c37414fb6a915ce97fd08495ccf0fe48/ist_splist_spl2008-07-23T12:22:05+02:00variability UML requirements Use-Cases line engineering product <span style="color:#555555;">G&#252;nter <a href="http://www.bibsonomy.org/author/Halmans">Halmans</a> und Klaus <a href="http://www.bibsonomy.org/author/Pohl">Pohl</a> </span><em>Software and System Modeling</em><em>2(1):15-36</em>(<em>2003</em>)Wed Jul 23 12:22:05 CEST 2008Software and System Modeling115-36Communicating the Variability of a Software-Product Family to Customers22003variability UML requirements Use-Cases line engineering product Variability is a central concept in software product family development. Variability empowers constructive reuse and facilitates the derivation of different, customer specific products from the product family. If many customer specific requirements can be realised by exploiting the product family variability, the reuse achieved is obviously high. If not, the reuse is low. It is thus important that the variability of the product family is adequately considered when eliciting requirements from the customer. In this paper we sketch the challenges for requirements engineering for product family applications. More precisely we elaborate on the need to communicate the variability of the product family to the customer.We differentiate between variability aspects which are essential for the customer and aspects which are more related to the technical realisation and need thus not be communicated to the customer. Motivated by the successful usage of use cases in single product development we propose use cases as communication medium for the product family variability.We discuss and illustrate which customer relevant variability aspects can be represented with use cases, and for which aspects use cases are not suitable. Moreover we propose extensions to use case diagrams to support an intuitive representation of customer relevant variability aspects.MR: Der Entwickelte Prototyp wurde auch in der Diss von Andreas Reuys (TransUse) beschrieben.http://www.bibsonomy.org/bibtex/247b2991613f919ed3cdd461442a2c2c6/ist_splist_spl2008-07-23T12:20:01+02:00testing ScenTED line UML diagrams product Use-Cases activity <span style="color:#555555;">Dirk <a href="http://www.bibsonomy.org/author/Högemann">H&#246;gemann</a> </span>(<em>2005</em>)Wed Jul 23 12:20:01 CEST 2008EssenErstellung von Aktivitätsdiagrammen aus Domänen Use Cases zum Testen von ProduktfamilienBachelorarbeit2005testing ScenTED line UML diagrams product Use-Cases activity http://www.bibsonomy.org/bibtex/25572f6d31c4837e5884c395b61dfa3c4/ist_splist_spl2008-07-23T11:44:25+02:00line product diagrams variability testing UML activity Use-Cases ScenTED <span style="color:#555555;">Dirk <a href="http://www.bibsonomy.org/author/Högemann">H&#246;gemann</a> </span><em>Universit&#228;t Duisburg-Essen, </em>(<em>2004</em>) <em>Projektseminararbeit . </em>Wed Jul 23 11:44:25 CEST 2008Universität Duisburg-EssenProjektseminararbeitPattern-Identification for the derivation of V-Activity Diagrams from Domain Use Cases2004line product diagrams variability testing UML activity Use-Cases ScenTED MR: Einer der Grundsteine für die Diss von Andreas Reyus.http://www.bibsonomy.org/bibtex/26d3b132574891802906b2f5896efbd0c/ist_splist_spl2008-07-23T11:17:59+02:00product Use-Cases line activity scenarios testing diagrams test UML ScenTED <span style="color:#555555;">Andreas <a href="http://www.bibsonomy.org/author/Reuys">Reuys</a> und Sacha <a href="http://www.bibsonomy.org/author/Reis">Reis</a> und Erik <a href="http://www.bibsonomy.org/author/Kamsties">Kamsties</a> und Klaus <a href="http://www.bibsonomy.org/author/Pohl">Pohl</a> </span><em>Erfurt, </em>(<em>2003</em>) <em>Proceedings of the PLEES&#8217;03 International Workshop on Product Line Engineering: The Early Steps: Planning, Modeling, and Managing . </em>Wed Jul 23 11:17:59 CEST 2008ErfurtProceedings of the PLEES’03 International Workshop on Product Line Engineering: The Early Steps: Planning, Modeling, and ManagingDerivation of Domain Test Scenarios from Activity Diagrams2003product Use-Cases line activity scenarios testing diagrams test UML ScenTED Requirements are often reported as not suitable for testing, because they are, for instance, incomplete. We argue in this paper for early steps in requirements engineering to ensure the testability of requirements in the context of product families. This paper describes the early derivation of test scenarios from use cases represented as activity diagrams. Use cases are often supplemented with activity diagrams if the control structure of the use case includes loops or branches. The use of activity diagrams allows defining a coverage criterion to ensure a particular degree of completeness of the test scenarios. The approach described in this paper is intended for use cases at the domain engineering level. It is discussed how variability in these use cases can be captured in activity diagrams, and, most important, how to address variability while deriving test scenarios so that a particular degree of completeness is reached. For this purpose, we adapt the existing branch coverage criterion to the needs of product families and provide an operational procedure that helps in deriving a set of test scenarios that fulfills our extended coverage criterion. Eventually, the derivation of test scenarios gives an early feedback to the requirements engineer when performed from the tester’s perspective. This increases the requirements quality.http://www.bibsonomy.org/bibtex/2637eeb497465541bb566aefabf5db130/ist_splist_spl2008-07-21T16:53:26+02:00activity line diagrams product UML defs-uses ScenTED testing <span style="color:#555555;">Vanessa <a href="http://www.bibsonomy.org/author/Stricker">Stricker</a> </span>(<em>2006</em>)Mon Jul 21 16:53:26 CEST 2008Datenflussbasierte Identifikation erneut auszuführender Applikationstestfälle in der Produktlinienentwicklung Bachelorarbeit2006activity line diagrams product UML defs-uses ScenTED testing MR: Die Arbeit beinhaltet eine Übersicht über Regressions-, Impact-Analysis und Delta-Techniken. Die Auswirkungen der Variabilität werden betrachtet. Und Einfluesse die aus der Ablauflogik (Aktivitätsdiagramme, Sequenzdiagramme) und den Datenabhängigkeiten sich ableiten werden analysiert. Gute Idee: Aktivitätsdiagramme mit angehängten Informationen zu Datenaustausch... Wertvoll: Literaturverweise (auch auf die SSE-Eigenen Arbeiten)http://www.bibsonomy.org/bibtex/28d7c9e3717b02928dc7c69641e5f0769/ist_splist_spl2008-07-18T14:39:38+02:00application testing activity reuse UML diagrams product ScenTED dependencies data OVM line variability <span style="color:#555555;">Vanessa <a href="http://www.bibsonomy.org/author/Stricker">Stricker</a> </span>(<em>2005</em>) <em>Projektseminar; Lehrstuhl Software Systems Engineering; Professor Dr. Klaus Pohl; SS 2005 . </em>Fri Jul 18 14:39:38 CEST 2008Projektseminar; Lehrstuhl Software Systems Engineering; Professor Dr. Klaus Pohl; SS 2005Anforderungen an ein Modell zur Selektion erneut auszuführender Applikationstetsartefakte2005application testing activity reuse UML diagrams product ScenTED dependencies data OVM line variability http://www.bibsonomy.org/bibtex/28c1f5039205271120bfaf2c223064af8/ist_splist_spl2008-07-08T13:58:56+02:00scenario integration reuse generation automated product line variability testing ScenTED <span style="color:#555555;">Sacha <a href="http://www.bibsonomy.org/author/Reis">Reis</a> und Andreas <a href="http://www.bibsonomy.org/author/Metzger">Metzger</a> und Klaus <a href="http://www.bibsonomy.org/author/Pohl">Pohl</a> </span><em>FASE, </em><em>Seite321-335. </em>(<em>2007</em>)Tue Jul 08 13:58:56 CEST 2008FASEDBLP:conf/fase/2007321-335Integration Testing in Software Product Line Engineering: A Model-Based Technique2007scenario integration reuse generation automated product line variability testing ScenTED The development process in software product line engineering is divided into domain engineering and application engineering. As a consequence of this division, tests should be performed in both processes. However, existing testing techniques for single systems cannot be applied during domain engineering, because of the variability in the domain artifacts. Existing software product line test techniques only cover unit and system tests. Our contribution is a model-based, automated integration test technique that can be applied during domain engineering. For generating integration test case scenarios, the technique abstracts from variability and assumes that placeholders are created for variability. The generated scenarios cover all interactions between the integrated components, which are specified in a test model. Additionally, the technique reduces the effort for creating placeholders by minimizing the number of placeholders within the integration test case scenarios. We have experimentally measured the performance of the technique and the potential reduction of placeholders.MR: Die Referenzarbeit für auf ScenTED basierende Forschung.http://www.bibsonomy.org/bibtex/24336a1857dfafb495786b25d49c7600f/ist_splist_spl2008-07-07T14:16:03+02:00testing product requirements line scenario ScenTED software based <span style="color:#555555;">Andreas <a href="http://www.bibsonomy.org/author/Reuys">Reuys</a> </span>(<em>2006</em>)Mon Jul 07 14:16:03 CEST 2008Anforderungsbasierte Ableitung von Systemtestfall-Szenarien in der Software-Produktlinien-Entwicklung2006testing product requirements line scenario ScenTED software based Kurzbeschreibung Ziel der Einführung von Software-Produktlinien in einer industriellen Software-Entwicklung ist die Reduzierung der Entwicklungszeit und u2013kosten bei gleichzeitiger Steigerung der Qualität gegenüber der Einzelsystem-Entwicklung. Neben konstruktiven Entwicklungsphasen müssen in der Produktlinien-Entwicklung Maßnahmen zur Qualitätssicherung durchgeführt werden. Der Systemtest ist Bestandteil der analytischen Qualitätssicherungsmaßnahmen. Eine Aufgabe des Systemtests ist die Überprüfung der richtigen Umsetzung der funktionalen Anforderungen eines Systems. Dazu werden System-Testfälle aus den spezifizierten funktionalen Anforderungen abgeleitet. Die Anwendung existierender Test-Techniken, -Methoden und -Verfahren aus der Einzelsystem-Entwicklung ist durch die Konzepte der Produktlinien-Entwicklung, der Trennung von Domänen- und Applikations-Entwicklung sowie Variabilität, problematisch. Es ist ein effizientes Verfahren entwickelt worden, das den Systemtest in der Software-Produktlinien-Entwicklung unterstützt. An das Verfahren wurden die folgenden Anforderungen gestellt: Um einen geringen Aufwand bei dem Systemtest zu haben, soll die Wiederverwendung von Testfällen unterstützt werden. Die Wiederverwendung kann nur erfolgen, wenn die Nachvollziehbarkeit zwischen Anforderungen und Testfällen aufgezeichnet wurde. Durch wiederverwendete Anforderungen in Applikationen der Produktlinie können die wiederzuverwendenden Testfälle ermittelt werden. Zusätzlich soll eine frühe Validierung während des Domänen-Tests unterstützt werden, um Fehler frühzeitig zu ermitteln. Die Umsetzung der Anforderungen erfolgt im ScenTED-Verfahren (Scenario-based TEst case Derivarion) durch die folgenden Kernideen: - Erstellung von Testfällen mit Variabilität im Domänen-Test: Es wurden unterschiedliche Strategien zum Test in der Produktlinien-Entwicklung beurteilt. Es wurde eine Strategie umgesetzt, in der Testfälle für Gemeinsamkeiten und für die Varianten der Produktlinie ermittelt werden. Die Testfälle mit Variabilität enthalten die Ausprägungen der Varianten und können deshalb mit geringen Anpassungen beim Testen von Applikationen der Produktlinie verwendet werden. - Ableitung der Testfälle aus Domänen-Use-Cases und Szenarien: Die Ableitung der Testfälle erfolgt aus den Anforderungen. Die Anforderungen liegen als Domänen-Use-Cases und dazu gehörigen Szenarien vor. Diese Typen von Anforderungen sind eine gute Grundlage zur Ermittlung der Testfälle, da sie Abläufe beschreiben, die einem Systemtest sehr ähnlich sind. - Umsetzung eines Modell-basierten Vorgehens: Modell-basierte Vorgehen sind in der Einzelsystem-Entwicklung bekannt. Sie haben einige Vorteile, wie z.B. nachvollziehbare Mengen von Testfällen und Überprüfung der Anforderungen durch die Erstellung des Test-Modells. Als Test-Modell wurde ein Aktivitätsmodell verwendet, welches um Variabilität erweitert wurde. Zur Unterstützung des ScenTED-Vorgehens sind zwei Prototypen implementiert worden. Der erste Prototyp realisiert die Erstellung eines Test-Modells für den Domänen-Test. Der zweite Prototyp nimmt dieses Test-Modell als Eingabe, um daraus Testfall-Szenarien im Domänen-Test zu ermitteln. Das Verfahren wurde in zwei Fallstudien angewendet. Zum einen wurde eine imaginäre Produktlinie getestet. Zum anderen wurde das ScenTED-Verfahren erfolgreich in einer Kooperation mit der Firma Siemens AG in einer realen Entwicklung genutzt, um den Systemtest einer Software-Produktlinie zu unterstützen. Es ist einmal eine kleine Menge von Testfall-Szenarien ermittelt worden. Diese Testfall-Szenarien wurden zum Test von drei Applikationen der Produktlinie herangezogen. Die Testfälle wurden systematisch wiederverwendet, was den Aufwand zur Ermittlung der Testfälle reduzieren soll. Product family testinghttp://www.bibsonomy.org/bibtex/2823e900bcd466d99b6d9aedff92da714/ist_splist_spl2008-07-03T18:55:21+02:00product line testing <span style="color:#555555;">Antti <a href="http://www.bibsonomy.org/author/Tevanlinna">Tevanlinna</a> und Juha <a href="http://www.bibsonomy.org/author/Taina">Taina</a> und Raine <a href="http://www.bibsonomy.org/author/Kauppinen">Kauppinen</a> </span><em>SIGSOFT Softw. Eng. Notes</em><em>29(2):12--12</em>(<em>2004</em>) <em>MR: ein guter &#220;berblick &#252;ber SPL-Testing bis 2004 . </em>Thu Jul 03 18:55:21 CEST 2008New York, NY, USASIGSOFT Softw. Eng. NotesMR: ein guter Überblick über SPL-Testing bis 2004212--12Product family testing: a survey292004product line testing In this paper we discuss the current state of product family testing. Testing, unlike other areas of software development, has received only little attention in this context despite the problems directly rising from scale, reuse and variability. We present the current approaches to product family testing methodology and processes. We also evaluate the current state-of-the-art in product family testing and highlight problems that need to be addressed in the future.http://www.bibsonomy.org/bibtex/2aec593ff707ee5e036253d36633a414e/ist_splist_spl2008-07-03T18:25:42+02:00product testing line <span style="color:#555555;">John D. <a href="http://www.bibsonomy.org/author/McGregor">McGregor</a> </span><em>CMU/SEI-2001-TR-022. </em>(<em>2001</em>)Thu Jul 03 18:25:42 CEST 2008MR: beschäftigt sich eher mit den organisatorischen AspektenCMU/SEI-2001-TR-022Testing a Software Product Line2001product testing line A suitably organized and executed test process can contribute to the success of a product line organization. Testing is used to identify defects during construction and to assure that completed products possess the qualities specified for the products. Test-related activities are organized into a test process that is designed to take advantage of the economies of scope and scale that are present in a product line organization. These activities are sequenced and scheduled so that a test activity occurs immediately following the construction activity whose output the test is intended to validate. This report expands on the testing practice area described by Clements and Northrop. Test-related activities that can be used to form the test process for a product line organization are described. Product line organizations face unique challenges in testing. This report describes techniques and activities for meeting those challenges.Computer Science Bibliography Collectionhttp://www.bibsonomy.org/bibtex/242adeda1515608dae46ba044035d5904/ist_splist_spl2008-07-02T09:11:19+02:00line product TDE/UML diagrams TSL UML activity systemtest category-partition Use-Cases <span style="color:#555555;">Jean <a href="http://www.bibsonomy.org/author/Hartmann">Hartmann</a> und Marlon <a href="http://www.bibsonomy.org/author/Vieira">Vieira</a> und Axel <a href="http://www.bibsonomy.org/author/Ruder">Ruder</a> </span><em>Proceedings of the International Workshop on Software Product Line Testing (SPLiT 2004), </em><em>Seite58--65. </em><em>Boston, MA, </em><em>August2004. </em><em>ST:Basiert auf UML-Aktivit&amp;#228;tsdiagrammen Entwicklung eines Tools auf Basis von Rational-Rose. F&amp;#252;r die Testdatengewinnung wird eine &amp;#196;-Klassena<span class="info">...<span>ST:Basiert auf UML-Aktivit&#228;tsdiagrammen Entwicklung eines Tools auf Basis von Rational-Rose. F&#252;r die Testdatengewinnung wird eine &#196;-Klassenanalyse durchgef&#252;hrt. Wichtig sind daher die Bedingungen an der Verzweigungspunkten im Aktivit&#228;tsdiagramm, da die Auswahl des Testfalls von diesen abh&#228;ngt. Nutzer w&#228;hlt Produkt aus und das Tool generiert f&#252;r ein produkt Testf&#228;lle Fazit: Es werden zwar Testf&#228;lle mit Testdaten f&#252;r die Produkte einer Produktlinie automatisch generiert, aber es findet keine Trennung zwischen Domain- und Application Engineering statt. Es ist kein Wiederverwendungsansatz erkennbar. Au&#223;erdem arbeitet das Tool auf Basis anderer kommerzieller Tools (Rose). MR: Die &#196;-Klassenanalyse wird nach der Category-Partition-Methode durchgef&#252;hrt, d.h. dass die die Testdaten (mit erwarteten Ausgaben) teilweise manuell erstellt werden m&#252;ssen.</span></span> . </em>Wed Jul 02 09:11:19 CEST 2008Boston, MAProceedings of the International Workshop on Software Product Line Testing ({SPL}i{T} 2004)AugustST: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.58--65A {UML}-based Approach for Validating Product Lines2004line product TDE/UML diagrams TSL UML activity systemtest category-partition Use-Cases The Unified Modeling Language (UML) is gaining wide acceptance in industry as the new de facto visual modeling language and as such it is being used within Siemens to model large, complex new product lines. As a result, we are extending our existing UML-based approaches to component and system validation to address the needs of product line validation. In this paper, we will focus on describing the extensions made to our system testing approach in which Activity Diagrams that form the basis for the test specification are annotated with variation points and conformance tests are then automatically generated to validate each product variant. We are also implementing these extensions as part of our Test Development Environment for UML (TDE/UML) automated test generation technology, which is currently integrated with the IBM/Rational Rose UML modeling tool and coupled with test execution tools, such as a graphical capture/replay tool. This paper provides an outline of our existing UML-based approach to system validation, but focuses on how we supplement the existing UML diagrams with information concerning the variation points for product-line validation.http://www.bibsonomy.org/bibtex/2d75bfa54d7c45c6a6ffba04b75938005/ist_splist_spl2008-06-27T15:45:53+02:00line testing automated CSP product algebraic specification-based oracle software specification testdata <span style="color:#555555;">Satish <a href="http://www.bibsonomy.org/author/Mishra">Mishra</a> </span><em>CS&amp;P 2006 - Concurrency, Specification and Programming, </em>(<em>2006</em>) <em>MR: Es wird gezeigt, dass bei SPLs, die mit formalen Spezifikationen (hier CSP-CASL) beschrieben sind, die Testf&amp;#228;lle, Testeingaben und erwartete Ergeb<span class="info">...<span>MR: Es wird gezeigt, dass bei SPLs, die mit formalen Spezifikationen (hier CSP-CASL) beschrieben sind, die Testf&#228;lle, Testeingaben und erwartete Ergebnisse automatisch generiert werden k&#246;nnen. Die Wiederverwendung der Tests beschr&#228;nkt sich im Paper auf SPLs von speziellen Art, bei denen die Varianten nur erweitert werden k&#246;nnen und somit andere Varianten und den gemeinsamen Teil vollst&#228;ndig involvieren.</span></span> . </em>Fri Jun 27 15:45:53 CEST 2008 CS&P 2006 - Concurrency, Specification and ProgrammingMR: 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.Specification Based Software Product Line Testing: A Case Study2006line testing automated CSP product algebraic specification-based oracle software specification testdata In this paper, we describe an approach of software product line testing which is based on formal specifications of the desired properties. In a software product line, common behaviours are maintained at subsequent levels of the product development. Commonalities among products arise from the reuse of parts of the software. It is unclear, however, in which way test cases for one product can be reused for subsequent enhancements. In this paper we approach this problem by specification based testing. We start the software quality assurance process by formally specifying the system in the process algebraic specification language CSP-CASL [1] for the description of system properties. After that we establish an enhancement relation between specifications in a software product line development. This enhancement relation conceptually forms the basis of reusability of test suites among different implementations in a product line development.