<rdf:RDF xmlns:community="http://www.bibsonomy.org/ontologies/2008/05/community#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:admin="http://webns.net/mvcb/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:cc="http://web.resource.org/cc/" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:swrc="http://swrc.ontoware.org/ontology#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:base="http://www.bibsonomy.org/user/ist_spl/product+software+testing"><owl:Ontology rdf:about=""><rdfs:comment>BibSonomy publications for /user/ist_spl/product+software+testing</rdfs:comment><owl:imports rdf:resource="http://swrc.ontoware.org/ontology/portal"/></owl:Ontology><rdf:Description rdf:about="http://www.bibsonomy.org/bibtex/24336a1857dfafb495786b25d49c7600f/ist_spl"><owl:sameAs rdf:resource="http://www.bibsonomy.org/uri/bibtex/24336a1857dfafb495786b25d49c7600f/ist_spl"/><rdf:type rdf:resource="http://swrc.ontoware.org/ontology#PhDThesis"/><owl:sameAs rdf:resource="http://www.amazon.de/gp/redirect.html%3FASIN=383251435X%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/383251435X%253FSubscriptionId=13CT5CVB80YFWJEPWS02"/><swrc:date>Mon Jul 07 14:16:03 CEST 2008</swrc:date><swrc:publisher><swrc:Organization swrc:name="Logos Berlin"/></swrc:publisher><swrc:title>Anforderungsbasierte Ableitung von Systemtestfall-Szenarien in der Software-Produktlinien-Entwicklung</swrc:title><swrc:year>2006</swrc:year><swrc:keywords>line software product scenario requirements ScenTED testing based </swrc:keywords><swrc:abstract>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. </swrc:abstract><swrc:hasExtraField><swrc:Field swrc:value="9783832514358" swrc:key="ean"/></swrc:hasExtraField><swrc:hasExtraField><swrc:Field swrc:value="383251435X" swrc:key="asin"/></swrc:hasExtraField><swrc:hasExtraField><swrc:Field swrc:value="383251435X" swrc:key="isbn"/></swrc:hasExtraField><swrc:author><rdf:Seq><rdf:_1><swrc:Person swrc:name="Andreas Reuys"/></rdf:_1></rdf:Seq></swrc:author></rdf:Description><rdf:Description rdf:about="http://www.bibsonomy.org/bibtex/2d75bfa54d7c45c6a6ffba04b75938005/ist_spl"><owl:sameAs rdf:resource="http://www.bibsonomy.org/uri/bibtex/2d75bfa54d7c45c6a6ffba04b75938005/ist_spl"/><rdf:type rdf:resource="http://swrc.ontoware.org/ontology#InProceedings"/><owl:sameAs rdf:resource="http://www2.informatik.hu-berlin.de/~hs/Aktivitaeten/2006_CSP/"/><swrc:date>Fri Jun 27 15:45:53 CEST 2008</swrc:date><swrc:booktitle> CS&amp;P 2006 - Concurrency, Specification and Programming</swrc:booktitle><swrc:note>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.</swrc:note><swrc:title>Specification Based Software Product Line Testing: A Case Study</swrc:title><swrc:year>2006</swrc:year><swrc:keywords>specification CSP testdata line software product algebraic testing oracle specification-based automated </swrc:keywords><swrc:abstract>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.</swrc:abstract><swrc:author><rdf:Seq><rdf:_1><swrc:Person swrc:name="Satish Mishra"/></rdf:_1></rdf:Seq></swrc:author><swrc:editor><rdf:Seq><rdf:_1><swrc:Person swrc:name="Roman Redziejowski Ludwik Czaja"/></rdf:_1><rdf:_2><swrc:Person swrc:name="Holger Schlingloff"/></rdf:_2></rdf:Seq></swrc:editor></rdf:Description><rdf:Description rdf:about="http://www.bibsonomy.org/bibtex/2f289279eaa2256f1237ebcc3c6e2bcd9/ist_spl"><owl:sameAs rdf:resource="http://www.bibsonomy.org/uri/bibtex/2f289279eaa2256f1237ebcc3c6e2bcd9/ist_spl"/><rdf:type rdf:resource="http://swrc.ontoware.org/ontology#Article"/><owl:sameAs rdf:resource="http://www.henrymuccini.com/Research/Tacos03.htm"/><swrc:date>Tue Jun 10 10:56:43 CEST 2008</swrc:date><swrc:journal>Electr. Notes Theor. Comput. Sci.</swrc:journal><swrc:number>6</swrc:number><swrc:title>Towards Testing Product Line Architectures</swrc:title><swrc:volume>82</swrc:volume><swrc:year>2003</swrc:year><swrc:keywords>testing product software line </swrc:keywords><swrc:hasExtraField><swrc:Field swrc:value="http://www1.elsevier.com/gej-ng/31/29/23/133/50/show/Products/notes/index.htt\#011" swrc:key="ee"/></swrc:hasExtraField><swrc:hasExtraField><swrc:Field swrc:value="DBLP, http://dblp.uni-trier.de" swrc:key="bibsource"/></swrc:hasExtraField><swrc:author><rdf:Seq><rdf:_1><swrc:Person swrc:name="Henry Muccini"/></rdf:_1><rdf:_2><swrc:Person swrc:name="Andr{\&#039;e} van der Hoek"/></rdf:_2></rdf:Seq></swrc:author></rdf:Description></rdf:RDF>