Test von Use Case basierten Produkt Linien mit dem PLUTO Ansatz - Seminar Software-Qualit atssicherung bei Prof. Dr. Gregor Engels betreut von ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Test von Use Case basierten Produkt Linien mit
dem PLUTO Ansatz
Frederik Eichler, mail@frederik-eichler.de
1. August 2008
Universität Paderborn
Seminar Software-Qualitätssicherung bei
Prof. Dr. Gregor Engels
betreut von Andreas Wübbeke
iZusammenfassung
Produktlinien werden in der Industrie eingesetzt um bei steigender Produktviel-
falt gleichzeitig Kosten zu sparen, indem ähnliche Produkte zu einer Linie zusam-
mengefasst werden. Beim Test dieser Produkte müssen neben den Gemeinsamkei-
ten einer Produktlinie, auch die Unterschiede berücksichtigt und in die Testfälle
aufgenommen werden. PLUTO [4] stellt hierbei einen Ansatz dar, bei System-
und Abnahmetests auch die Unterschiede innerhalb einer Produktlinie abzude-
cken. Im Zuge der Arbeit wird der Begriff der Produktlinie eingeführt und die Idee
des Tests von Produktlinien mit Use Cases und dem PLUTO Ansatz erläutert,
sowie ein Ausblick auf zukünftige Herausforderungen in diesem Forschungsbereich
gegeben.
Inhaltsverzeichnis
1 Einführung 1
2 Produktlinien 2
2.1 Varianten und Variationspunkte . . . . . . . . . . . . . . . . . . . . 2
2.2 Product Line Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Variationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Einordnung im Entwicklungsprozess . . . . . . . . . . . . . . . . . . 6
3 PLUTO 7
3.1 Kategorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Instanzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Ausblick 10
4.1 PLUTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Produktlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ii1 Einführung
Als US-Amerikanische Automobilhersteller in den Jahren 1980 bis 1991 auf eine
“best platform strategie” umstellten [5], erhöhten sie damit ihren Umsatz um 35%.
Diese Strategie basierte auf der Prämisse, dass durch die Nutzung einer gemeinsa-
men Basis oder auch Plattform die Produktion der Fahrzeuge vergünstigt werden
kann.
Zwar bedeutete dies für die Automobilhersteller ein höheres Anfangsinvestment
für das Entwickeln einer Plattform, im Gegenzug aber auch, dass dem Verbraucher
besser an seine Wünsche angepasste Fahrzeuge angeboten werden konnten.
Diese Flexibilität ist laut Pohl et. al [5] die Vorraussetzung für “mass customisa-
tion” und bietet für diese Arbeit als Begriff der Variabilät eine wichtige Grundlage.
Überträgt man diesen Begriff der Platform von der Automobilindustrie in die
Softwareentwicklung, so ergibt sich laut Meyer & Lehnerd [7] folgende Definition
einer Software Plattform:
A software platform is a set of software subsystems and interfaces that
form a common structure from which a set of derivative products can
be efficiently developed and produced
Wie bereits im obigen Beispiel angedeutet, bringt der Einsatz einer Plattform
allerdings nicht nur erhöhte Flexibilität, sondern auch Kosten um eine neue Platt-
form oder Produktlinie zu etablieren mit sich. In diesem Zusammenhang stellt sich
auch die Frage wie die Qualität der einzelnen Produkte einer Produktlinie mit re-
lativ geringem Aufwand, etwa durch genau definierte Tests, sichergestellt werden
können. Neben Produktlinie ist auch der Begriff der Produktfamilie [4] geläufig
und wird hier synonym verwendet.
Im Folgenden soll der Begriff der Produktlinie genauer erklärt und darauf ein-
gegangen werden, wie Produkte einer solchen Linie auf Korrektheit getestet wer-
den können. Dazu soll der PLUTO Ansatz genauer erklärt werden, der mit einer
semi-formalen Notation die Abdeckung des Tests aller Varianten, die in einer Pro-
duktlinie entstehen können, sicher stellen soll. Einzelne Vorgänge werden dabei in
natürlicher Sprache beschrieben.
12 Produktlinien
Eine Produktlinie umfasst nach [6] mit einander verwandte Produkte und setzt
sich aus einer Sammlung von Elementen, die alle Produkte einer Linie gemeinsam
haben ( mandatory elements ), sowie variablen Elemente ( variation points ), an
denen sich die Produkte unterscheiden, zusammen.
Vorteile einer Produktlinie sind nach Pohl et al. [5] unter anderem die erhöhte
Qualität des Produkts durch den Einsatz von Artefakten in mehreren Produk-
ten und außerdem die kürzeren Entwicklungszyklen, also die Zeit bis ein Produkt
Marktreife erlangt. Zudem ist es aufgrund der Vergleichbarkeit der Produkte einer
Linie einfacher Kostenabschätzungen für neue Produkte zu geben. Zuletzt erhält
auch der Kunde einen direkten Vorteil, nämlich ein an seine Bedürfnisse angepass-
tes Produkt zu einem annehmbaren Preis.
Wie bereits dargelegt liegen die Nachteile einer Produktlinie unter anderem in
den Investments, die zum Aufbau einer Produktlinie notwendig sind, so dass die
Amortisationszeit eines einzelnen Produktes innerhalb der Produktlinien zunächst
entsprechend länger als die eines einzelnen Produktes ist.
Besonders das Testen einer Produktlinie stellt hier eine Herausforderung dar,
da die erreichte Flexibilität für jedes Produkt unterschiedliche Ausprägungen und
Produktmerkmale bedeutet und diese alle einzeln beim Test berücksichtigt wer-
den müssen. Die Prämisse der Flexibilität wird im PLUTO Ansatz durch die so
genannte Variabilität sicher gestellt, was im Folgenden weiter erläutert werden soll.
Hauptvorraussetzung um den Einsatz einer Produktlinie möglich zu machen
ist, dass die Domäne - also der Anwendungsbereich - aus der die Produktlinie
entstammt eindeutig definiert ist. Ist die Domäne zu weit gefasst, das heißt die
Produkte einer Linie haben nur wenig Gemeinsamkeiten, wird der Einsatz zu
aufwändig und die Anzahl an Varianten zu groß, beziehungsweise der Nutzen durch
die Wiederverwendbarkeit schwindet.
2.1 Varianten und Variationspunkte
Um den Begriff Variante definieren zu können, müssen zunächst der Begriff Variati-
onspunkt erklärt werden. Hierunter verstehen Böckle et al. [1] die Stelle an der die
Auswahl einer oder mehrerer Varianten möglich ist. Eine Variante beschreibt dann
die “konkrete Ausprägung in Bezug auf einen oder mehrere Variationspunkte”.
Für die Variabilität ergeben sich laut [1] verschiedene Beziehungen, im Folgen-
den und im Zusammenhang mit PLUTO in 2.2.3 erläutert werden:
Optionale Beziehungen, etwa die sprachliche Unterstützung von Sehbehinderten
2Ausprägung Beispiel
Features Zahlung per Kreditkarte
Ablauf Reihenfolge des Bestellvorgangs
Datenumfang Benötigte Datenbasis für den Bestellvorgang
Datenformat Anzahl der Dezimalstellen beim Rechnungsbetrag
Systemzugang Zugang zum System etwa über das Internet, Telefon
Benutzerschnittstelle sprachlich, textuelle, mediale Führung
Systemschnittstelle Customer Relationship Management, Warenwirtschaft,
Legacy Systems
Qualität Ansprüche an Sicherheit, Performanz, Vefügbarkeit, etc.
Tabelle 1: Ausprägungen von Variabilität in Produktlinien
in der Softwareumgebung erlauben es Features in einem Produkt der Linie zu
verwenden und in anderen zu vernachlässigen. Alternative Beziehungen bedeuten
die Pflicht eine von mehreren Variationen fest zu wählen, etwa die Entscheidung
auf 2 Dezimalstellen zu runden.
Pflichtbeziehungen müssen in jedem Produkt der Linie auftauchen und Aus-
schlussbeziehung erlauben zu definieren, dass ein genau spezifiziertes Feature unter
genau definierten Bedingungen nicht auftreten darf. So lässt sich zum Beispiel dar-
stellen, dass der Tempomat in einem Auto gesetzliche Höchstbestimmungen nicht
überschreiten darf.
Zudem kann die Beziehung zwischen Varianten durch sog. Constraints, wie in [1]
erläutert, beschrieben werden. Requires-Beziehungen erzwingen das Vorhandensein
einer Variante A, bevor eine Variante B erlaubt wird. Ausschluss-Beziehungen (
excludes ) schließen genau dieses gemeinsame Auftreten aus.
Ausprägungen von Variabilität
Variabilität kann in verschiedenen Ausprägungen [1] ( Tabelle 1 ) in einer
Produktlinie auftreten. So können sich zum Beispiel die Features ( z.B. mögliche
Zahlweisen in einem Online Shop ) eines Produktes unterscheiden. Auch im Ablauf,
also zeitlich, kann es Abweichungen unter den Produkten geben. So mag bei einem
Online Shop etwa die Angabe der Adresse vor oder nach der Zahlungsart kommen.
Die beschriebenen Ausprägungen können nun weitere Variationen ( Tabelle 1)
bedingen, die sich etwa im benötigten Datenumfang bei der Kreditkartenzahlung
wiederspiegeln.
3Schlüssel Wert
Goal Play a game on a [V0] Mobile Phone and record score
Scope The [V0] Mobile Phone
Level Summary
Precondition The [V0] Mobile Phone is on
Trigger Function GAMES has been selected from the main menu
Primary Actor The Mobile Phone user
Secondary Actors The [V0] Mobile Phone, The Mobile Phone Company
Tabelle 2: Beschreibung des Use Cases
2.2 Product Line Use Cases
Der in dieser Arbeit dargestellte Ansatz zum Testen von Produktlinien basiert
auf der Nutzung sog. Product Line Use Cases ( PLUC ), welche in semi-formaler
Notation die Abläufe innerhalb der Software wiederspiegeln und zusätzlich die
verschiedenen Ausprägungen von Produkten innerhalb der Produktlinie abbilden.
Zur Veranschaulichung wird hier ein Beispiel-Use Case, wie in [4] eingeführt
vorgestellt. Um die Komplexität des Beispiels zu reduzieren, wird das Use Ca-
se im Folgenden in drei Teilen erklärt. Variationspunkte sind hierbei in eckigen
Klammern ( [VX ] ) dargestellt.
Beim Beispiel handelt es sich um eine Produktlinie eines Mobiltelefonanbie-
ters, der drei Modelle mit unterschiedlichen Ausstattungsmerkmalen, wie etwa der
Möglichkeit Spiele zu spielen, anbietet. Des weiteren unterscheiden sich die Pro-
dukte in der Möglichkeit das Internet zu nutzen.
2.2.1 Beschreibung
Der erste Abschnitt dieses Product Line Uses Cases, dargestellt durch Tabelle 2
enthält Informationen über den Zweck des Use Cases sowie welche Bedingungen
und Aktoren mitwirken. Hier wird zwischen primary actor und secondary actor
unterschieden. Letzterer interagiert zwar mit dem System, kann aber nicht den
Use Case auslösen.
An dieser Stelle wird bereits die Variabilität eingeführt, indem auf den Variati-
onspunkt [V0] ( Art des Mobiltelefons ) Bezug genommen wird.
42.2.2 Ablauf
Der zweite Teil des PLUC beschreibt den Ablauf des Use Cases als main success
scenario, sowie mögliche Erweiterungen. Hier unterscheidet sich das PLUC nicht
von gewöhnlichen Use Cases 1 .
• 1. The system displays the list of the [V1] available games
• 2. The user selects a game
• 3. The user selects the difficulty level
• 4. The user starts the game and plays it until completion
• 5. The user records the score achieved [V 2 ] and sends the score to Club
XXX via WAP
Erweiterungen beschreiben welche zusätzlichen Use Cases oder Aktionen durch
den Benutzer ausgelöst werden können. In diesem Beispiel wird berücksichtigt, dass
während des Spielens ein Anruf über das Mobiltelefon angenommen werden kann.
• 1a. No game is available:
• 1a1. return to main menu
• 3a. The user starts the game and plays i t until an incoming call arrives. See
CallAnswer.
2.2.3 Variationen
Im Gegensatz zur Ablaufbeschreibung ( 2.2.2 ) , die mögliche Handlungsvarianten
für den Benutzer bietet, stellt die folgende Liste Variationen innerhalb der Pro-
duktlinie dar. Somit kommt ihr essentielle Bedeutung für die Ableitung von Tests
für ein spezifisches Produkt zu. Hier kommen auch die unter 2.1 beschriebenen
Abhängigkeiten zum Einsatz.
Hier mögliche Variationen sind die Nutzung unterschiedlicher Mobiltelefone (
requires Beziehung aus 2.1 ),
welche das Spielen von unterschiedlichen Spielen erlauben ( alternative Bezie-
hung aus 2.1 ).
1
Alistair Cockburn: Use Case Fundamentals - http://alistair.cockburn.us/index.php/Use case fundamentals
5• Model 0
• Model 1
• Model 2
i f V 0 = 0 then
d i s p l a y msg ”no game a v a i l a b l e ”
e l s e i f V0=1 then
Snake I I o r Space Impact
e l s e i f V0=2 then
Snake I I o r Space Impact o r Bumper .
Zudem ist es möglich, falls die Variante V0 den Wert 2 hat ein optionales Feature
zu nutzen. Dies wird im PLUC durch das Schlüsselwort when ausgedrückt. Ein
Beispiel hierfür findet sich auch in Abschnitt 3.1.
V2: Optional
when V0=2 then
enable club option
2.3 Einordnung im Entwicklungsprozess
Will man die Verwendung von PLUC und PLUTO im Entwicklungsprozess ein-
ordnen, so ergibt sich für das V-Modell die Abbildung 1. Wie in der Grafik zu
sehen ist, stehen sich PLUC und PLUTO im V-Modell direkt auf den obers-
ten zwei Ebenen gegenüber. Diese frühe Einordnung im Entwicklungsprozess wird
leicht verständlich wenn man sich die Struktur der in Abschnitt 2.2 beschriebenen
PLUC ansieht. Hier werden allgemeine Vorgänge und Produktmerkmale beschrie-
ben und keine Entscheidungen über die zu benutzende Softwarearchitektur oder
Programmstruktur gefällt.
Aufgrund der Natur der PLUC ist hier festzustellen, dass PLUTO - welches aus
PLUCs abgeleitet wird - nur für die Tests in der höheren Abstraktionsebene, also
bei System- und Abnahmetests zum Einsatz kommt.
6PLUC PLUTO
Anforderungsanalyse Abnahme-Test / Nutzung
System-Architektur System-Integration
System-Entwurf Integrations-Tests
Software-Architektur Unit-Tests
Software-Entwurf
Abbildung 1: PLUC und Pluto im V-Modell
3 PLUTO
Grundlage für den PLUTO Ansatz zum Test von Produktlinien bietet die Ca-
tegory Partion Methode ( kurz: CP ) [Ostrand et al., 1988]. CP basiert darauf,
funktionale Einheiten für mögliche Tests zu identifizieren und für jede Testeinheit
eine Kategorisierung festzulegen und weiter in choices, also Auswahlmöglichkeiten
aufzuteilen.
Im Folgenden wird dieser Ansatz exemplarisch dargestellt und der Einsatz von
CP verdeutlicht.
3.1 Kategorisierung
Um mit Hilfe von Category Partition zu einer Kategorisierung zu gelangen wird
hier das Beispiel der drei Mobiltelefone aus 2.2 bemüht. Folglich gelangt [3] zu
folgenden Kategorien, welche die Variationspunkt in dieser Produktlinie darstellen:
• Mobile Phone Model
7• Games
• Difficulty Level
• Scenarios
• Club
Mit dieser Liste von zu berücksichtigenden Kategorien kann eine Anzahl der
choices abgeleitet werden, die in der PLUC Gameplay Test Specification ( Abb. 2
) notiert wird.
Um die Verfügbarkeit ( siehe 2.1 ) einer choice innerhalb der Kategorie auszu-
drücken, wird im Folgenden mit dem [IF ..] Selektor markiert. Kategorien werden
bei PLUTO auch als Tags bezeichnet, da sie im Verlauf des Ansatzes mit Werten
belegt ( 3.2 ) und somit Testfälle abgeleitet werden.
Abbildung 2: PLUC Gameplay Test Specification
Wie in Abbildung 2 dargestellt, sind nicht alle choices für alle Mobiltelefone
verfügbar. Games sind für das Modell 0 gar nicht verfügbar und alle Spiele, sind
nur mit dem Modell 2 abrufbar. Ein Beispiel für eine optionale Kategorie findet
sich unter [V2] Club, welches nur bei P2 genutzt werden kann, welches über eine
Internetverbindung verfügt. Dies wird hier durch den IF Selektor ausgedrückt,
welcher direkt an der betroffenen choice steht.
83.2 Instanzierung
Abbildung 3: PL Test List
Um zu einer möglichen Liste von Testanweisung für spätere Testfälle2 zu gelan-
gen werden die Variablen, wie etwa die Property P0 mit Werten belegt und alle
gültigen Kombinationen unter dieser Bedingung aufgelistet. Resultat ist die PL
Test list, die exemplarisch in 3 nachzuvollziehen ist.
2
“[..] the precise specification of a test input, a sequence of events and the expected output.”
[2]
94 Ausblick
[3] schließen ihr Paper mit der Aussage, dass schon viel im Bereich der Anforde-
rungsdefinition von Produktlinien getan sei, aber nur wenig beim wirklichen Test
und der Implementierung. Im folgenden sollen die Herausforderungen vom Tes-
ten von Produktlinien mit PLUTO im speziellen und von Produktlinien allgemein
herausgestellt werden.
4.1 PLUTO
[2] beschreibt einen Testfall allgemein als präzise Spezifikation von Testinput,
einer Sequenz von Ereignissen und der Angabe von erwarteten Ausgaben. Eine
der Herausforderungen beim Testen mit PLUTO ergibt sich daher aus dem Fehlen
von Testbegleitenden Daten. Nimmt man sich als Beispiel die drei Mobiltelefone (
2.2 ), so könnten diese um einen Testfall ausführen zu können PIN-Nummern oder
Passwörter benötigen um die richtige Ausgangsposition oder pre-condition für den
Test herzustellen.
Des weiteren ist es möglich das die Überprüfung ob der Testfall ein Erfolg war,
nicht sofort für den Tester offensichtlich ist, sondern von bestimmten Nachbedin-
gungen oder post-conditions abhängt. Dies könnte ein bestimmter Systemzustand
sein oder auch das Format der beim Model 2 an den Internetserver überlieferten
Daten sein. All diese Bedingungen und Daten könnten auch in einem begleitenden
Dokument festgehalten werden, wenn im Zusammenhang mit Produktlinien die
Variabilität nicht eine bedeutende Rolle spielen würde. Je nach gewählter choice
mag das Resultat der Testdaten anders aussehen und müsste sich also auch in
einem begleitenden Dokument wiederspiegeln.
Hier stellt sich die Frage ob es günstiger ist jedes mal, wenn ein Test ausgeführt
wird die gewünschten post-conditions erneut anhand der gegebenen Variabilität zu
definieren oder den PLUTO Ansatz so zu erweitern, dass Testdaten automatisch
aus der Variabilität errechnet werden können.
Um diese Frage zu beantworten ist es notwendig beide Möglichkeiten genauer zu
definieren und dann ihren Aufwand detaillierter im Bezug auf Anzahl der Varia-
tionspunkte und choices zu untersuchen. Dies soll jedoch nicht Bestandteil dieser
Arbeit sein.
Eine weitere Herausforderung im Test von Produktlinien mit PLUTO ergibt
sich, durch die steigende Komplexität der Testfälle bei ebenfalls steigender An-
zahl von Beziehungen ( 2.1 ) zwischen den Varianten. Vergleicht man etwa die
Repräsentation des optionalen Tag [V2] Club in der Testspezifikation ( Abb. 2 )
10mit einer vergleichbaren Darstellung, etwa als Featurediagramm3 ( Abb. 4 ) ließe
sich in direkt durch die Notation des nicht ausgefüllten Kreises am Club Knoten
erkennen, dass alle folgenden choices optional sind. Liest man die Testspezifikation
( Abb. 2 ), ist allerdings eine Untersuchung aller choices auf den Selektor, hier IF,
notwendig um auf die optionale Eigenschaft des Tags zu schließen. Der ausgefüllte
Winkel ( * 2 ) für die Club Option in Abb. 4 drückt hierbei implizit aus, dass
WAP entweder an oder ausgeschaltet sein muss.
Mobile Phone Legende
mandatory feature
optional feature
*1 alternative features
Model Club * 2 features mit logischer
oder Beziehung
*1
*2
WAP WAP
0 1 2
on off
Abbildung 4: Feature Diagramm über Modell und Internetkonnektivität
4.2 Produktlinien
Im Hinblick auf Herausforderungen und Forschungsgebiete bei Produktlinien all-
gemein ergeben sich laut [5] folgende Überlegungen.
Im Bereich der Forschung wäre vor allem eine genauere Untersuchung der Va-
riabilität auf den verschiedenen Teststufen ( siehe 1 ) wünschenswert, sowie die
Frage zu klären welche Aspekte auf den unterschiedlichen Stufen zur, in der An-
forderungsdefinition aufgestellten Variabilität, hinzukommen.
Auch die Einführung von MDD ( model-driven development ) in die Softwa-
reentwicklung von Produktlinien sehen [5] als Herausforderung für zukünftige
Forschungen.
3
www.info.fundp.ac.beỹbo/docs/splc04/foda-semantics.pdf
11Aus Projektsicht ergeben sich Herausforderungen durch die ständige Änderung
von Anforderungen an Softwareprodukte innerhalb einer Produktlinie und deren
Auswirkungen auf die Variabilität und somit auch die Testfälle.
Ein weiterer Punkt, den auch [3] in ihrem Schlusswort andeuten, ist die feh-
lende Tool-Unterstützung beim Test und der Implementierung der Produkte. Hier
wären fertige Werkzeuge von Vorteil, die den Ablauf automatisieren oder zumin-
dest vereinfachen können.
Des weiteren wäre es wünschenswert sich beim Testen näher an Standards wie
dem CMMI 4 zu halten um die Qualitätsanforderungen einer Produktlinie genauer
definieren und einhalten zu können. Aus wirtschaftlicher Sicht ergibt sich außer-
dem der Wunsch in Zukunft genauer das Return on Investment ( kurz: ROI )
eines bestimmten Features / einer Variabilität einschätzen zu können um so zum
Beispiel die Profabilität einer Erweiterung der Produktlinie um weitere Produkte
abschätzen zu können.
4
http://www.sei.cmu.edu/cmmi/general/index.html
12Literatur
[1] Pohl Schmid Böckle, Knauper. Software-produktlinien: Methoden, einführung
und praxis. Dpunkt Verlag, 2004. 2, 3
[2] Bertolino et al. Product line use cases: Scenario-based specification and testing
of requirements. http://fmt.isti.cnr.it/WEBPAPER/Ch11.pdf. 9, 10
[3] Bertolino et al. Use case-based testing of product lines. ACM, 2003. 7, 10, 12
[4] Bertolino et al. Pluto: A test methodology for product families.
http://fmt.isti.cnr.it/WEBPAPER/23-BertGnesi.pdf, 2004. ii, 1, 4
[5] Klaus Pohl et al. Software product line engineering. Springer Verlag, 1993. 1,
2, 11
[6] A. van der Hoek H. Muccini. Towards testing product line architectures.
http://www.henrymuccini.com/Research/Tacos03/Tacos03C R.pdf, 2003. 2
[7] Alvin P. Lehnerd Marc H. Meyer. The power of product platforms. Free Press,
1997. 1
13Sie können auch lesen
