BibSonomy publications for /user/ist_spl/line+testingFri Sep 05 09:49:50 CEST 2008FASEDBLP:conf/fase/2007321-335Integration Testing in Software Product Line Engineering: A Model-Based Technique2007ScenTED variability generation testing reuse line integration automated scenario product SSE 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.Wed Sep 03 10:00:11 CEST 2008New York, NY, USACommun. ACM1278--81Software product line testing492006testing product line ScenTED SSE Exploring principles and potential solutions.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 Families2003Use-Cases testing product line PLUTO category-partition systemtest PLUC 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.Wed Sep 03 08:49:03 CEST 2008CAiSEDBLP:conf/caise/2005519-534Model-Based System Testing of Software Product Families2005line SSE testing systemtest product ScenTED Wed Jul 23 17:28:26 CEST 2008Ableitung von Domänen-Testfall-Szenarien aus Domänen-Aktivitätsdiagrammen unter Gewährleistung der Zweigabdeckung Diplomarbeit2004testing FTPS MBT branch coverage UML activity diagrams scenario-based product line ddgraph ScenTED Wed Jul 23 12:20:01 CEST 2008EssenErstellung von Aktivitätsdiagrammen aus Domänen Use Cases zum Testen von ProduktfamilienBachelorarbeit2005diagrams Use-Cases UML line activity testing ScenTED product Wed Jul 23 11:44:25 CEST 2008Universität Duisburg-EssenProjektseminararbeitPattern-Identification for the derivation of V-Activity Diagrams from Domain Use Cases2004product diagrams variability line Use-Cases UML ScenTED activity testing 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 Diagrams2003UML testing product line diagrams activity test scenarios Use-Cases 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.Mon Jul 21 16:53:26 CEST 2008Datenflussbasierte Identifikation erneut auszuführender Applikationstestfälle in der Produktlinienentwicklung Bachelorarbeit2006ScenTED line activity product diagrams UML defs-uses testing 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 Applikationstetsartefakte2005testing diagrams dependencies ScenTED activity application variability product OVM line UML data reuse Mon Jul 07 14:16:03 CEST 2008Anforderungsbasierte Ableitung von Systemtestfall-Szenarien in der Software-Produktlinien-Entwicklung2006requirements based scenario ScenTED product line testing software 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. 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 survey292004line testing product 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.Thu Jul 03 18:25:42 CEST 2008MR: beschäftigt sich eher mit den organisatorischen AspektenCMU/SEI-2001-TR-022Testing a Software Product Line2001testing line product 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.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 Study2006testdata software oracle specification product testing specification-based CSP line automated algebraic 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.Fri Jun 27 14:53:10 CEST 2008New York, NY, USAESEC-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 engineeringST: 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. 525--528A specification-based approach to testing software product lines2007specification-based generation GenVoca AHEAD testdata Alloy line testing product This paper presents a specification-based approach for sys- tematic testing of products from a software product line. Our approach uses specifications given as formulas in Alloy, a first-order logic based on relations. Alloy formulas can be checked for satisfiability using the Alloy Analyzer. The fully automatic analyzer, given an Alloy formula and a scope, i.e., a bound on the universe of discourse, searches for an in- stance, i.e., a valuation to the relations in the formula such that it evaluates to true. The analyzer translates an Alloy formula (for the given scope) to a propositional formula and finds an instance using an off-the-shelf SAT solver. The use of an enumerating solver enables systematic test generation. We have developed a prototype based on the AHEAD theory. The prototype uses the recently developed Kodkod model finding engine of the Alloy Analyzer. We illustrate our approach using a data structure product line.Tue Jun 10 11:24:04 CEST 2008New York, NY, USAROSATEA '06: Proceedings of the ISSTA 2006 workshop on Role of software architecture for testing and analysisMR: "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.53--63Coverage and adequacy in software product line testing2006OVM testing combinatorial product line Software product line modeling has received a great deal of attention for its potential in fostering reuse of software artifacts across development phases. Research on the testing phase, has focused on identifying the potential for reuse of test cases across product line instances. While this offers potential reductions in test development effort for a given product line instance, it does not focus on and leverage the fundamental abstraction that is inherent in software product lines - variability.In this paper, we illustrate how rich software product line modeling notations can be mapped onto an underlying relational model that captures variability in the feasible product line instances. This relational model serves as the semantic basis for defining a family of coverage criteria for testing of a product line. These criteria make it possible to accumulate test coverage information for the product line itself over the course of multiple product line instance development efforts. Cumulative coverage, in turn, enables targeted testing efforts for new product line instances. We describe how combinatorial interaction testing methods can be applied to define test configurations that achieve a desired level of coverage and identify challenges to scaling such methods to large, complex software product lines. Tue Jun 10 10:56:43 CEST 2008Electr. Notes Theor. Comput. Sci.6Towards Testing Product Line Architectures822003software line testing product Wed Jun 04 11:47:41 CEST 2008Software Product Lines - Research Issues in Engineering and ManagementMR: Bei dem beschriebenen Ansatz ist es notwendig die Testdaten manuell einzufügen für die Testgenerierung und Simulation. Im Artikel wird trotzdem von der Generierung der konkreten Testfälle gesprochen, die konkreten Daten werden aber ausgeblendet! Ansatz baut auf Use Cases als Anforderungen auf, die mit UML-Sequenzdiagrammen (als Systemscenarios) erweitert sind und als Eingabe gedacht sind. Aus diesen werden automatisch Testszenarien abgeleitet. Nützliche Ideen: - OCL zur Beschreibung von Pre- und Postbedingungen für die Testszenarios. - Test Synthesis zur Effizienzsteigerung bei der Ableitung der Testfälle. - Verwandschaft zu ScenTED wurde skizziert. Usefulness for IST-SPL (-/0/+/++/+++): ++ (Verwandschaft zu ScenTED) 447--477System Testing of Product Lines: From Requirements to Test Cases2006requirements cases TGV product UML system OCL LTS testing use line Thu May 29 12:09:38 CEST 2008PFEMR: Sammlung von interessanten Papers zu IST-SPL.Lecture Notes in Computer ScienceSoftware Product-Family Engineering, 5th International Workshop, PFE 2003, Siena, Italy, November 4-6, 2003, Revised Papers30142004line testing product Mon May 26 19:09:21 CEST 2008Software Product Lines - Research Issues in Engineering and Management11MR: Ein Ansatz zum Testen von Produktlinien. Es basiert nicht auf einem Testmodell, sondern auf einer strukturierten Testspezifikation die Variabilität beinhaltet. Die Testfälle werden für jede Applikation ermittelt basierend auf dieser Spezifikation. Somit gibt es keine Trennung von Domain- und Application-Engineering zur Wiederverwendung von Tests und Testdaten. Diese Technik zur Ableitung der Testszenarien wird PLUTO genannt und basiert auf der Category-Partition (CP) Methode. Diese Methode wird auf die hier auch vorgestellten PLUCs = Product Line Use Cases angewendet. Category Partioning ist ein dynamisches Blackbox-Test-Verfahren und basiert auf der Idee, die Testdaten in Kategorien zu unterteilen. Zuerst werden die Parameter der zu testenden Methode identifiziert. Im Anschluss werden die für den Test relevanten Aspekte aufgestellt. Auf diese Weise haben wir unsere Menge von möglichen Eingabedaten in Kategorien aufgeteilt. Es fällt uns nun leichter mögliche Eingabedaten für unseren Test zu finden, da wir nun jede Kategorie einzeln betrachten können und so schneller zu unseren Choices (den Teilmengen möglicher Eingabewerte einer bestimmten Kategorie) kommen. Weil der Ansatz auf Requirements basiert, die zwar strukturiert sind, aber in natürlicher Sprache verfasst sind, ist es ein halb-automatischer, halb-manueller Ansatz. Für IST-SPL wäre zu überlegen, ob die Category-Partition, oder die diese Methode erweiternde Klassifikationsbaummethode auf ScenTED zu übertragen wäre um die Testdaten und ergebnisse zu bestimmen. Z.B. wäre es möglich die Aktivitätsdiagramme mittels OCL zu erweitern und dann daraus mittels der Klassifikationsbaummethode automatisch Testdaten ableiten???425--445Product Line Use Cases: Scenario-Based Specification and Testing of Requirements2006specification scenario-based cases use product PLUC testing line requirements PLUTO