Optimierte Varianten- und Anforderungsabdeckung im Test Anastasia Cmyrev, Ralf Reißing* Daimler AG Hanns-Klemm-Straße 45 71034 Böblingen [email protected]

Hochschule Coburg* Friedrich-Streib-Str. 2 96450 Coburg [email protected]

Abstract: Die in zunehmendem Maße wachsende Anzahl an Fahrzeugvarianten stellt eine große Herausforderung für einen Automobilhersteller dar. Zusätzlich spielen eingebettete E/E-Systeme eine immer wichtigere Rolle in der Realisierung der wettbewerbsfähigen Funktionsvarianten. Der hohe Vernetzungsgrad zwischen den Systemen sowie die hohe Varianz führen zu einer komplexen Kombinatorik und stellen somit höchste Ansprüche an den Entwicklungsprozess. Zur Bewältigung dieser Komplexität bedarf es methodischer Unterstützung. Insbesondere während der Phase der Absicherung ist ein systematisches Vorgehen zur Selektion von testrelevanten Varianten notwendig, um unnötig hohe Kosten- und Zeitaufwände zu vermeiden. Im Beitrag wird hierfür ein Verfahren vorgeschlagen, welches basierend auf einer 100%igen Anforderungsüberdeckung eine minimale Auswahl an Varianten liefert, die abgesichert werden müssen. Zur Erfassung und Verwaltung der Variabilität wird der Ansatz der Produktlinienentwicklung genutzt, bei dem die Gemeinsamkeiten und Unterschiede eines Testobjektes innerhalb eines Merkmalmodells dargestellt und dann auf Anforderungsund Testartefakte gemappt werden. Auf Basis dieser Produktlinieninfrastruktur erfolgt dann die Selektion mittels eines Greedy-Algorithmus. Der folgende Beitrag stellt das Vorgehen detailliert vor und demonstriert das Verfahren anhand eines Fallbeispiels der Daimler AG.

1 Einführung Ein Automobilhersteller steht heutzutage vor der Herausforderung, die steigende Variantenvielfalt der Fahrzeuge während des Entwicklungsprozesses zu bewältigen. Dabei ist der Kundenwunsch nach individueller Gestaltung des Fahrzeugs eine der Hauptursachen für die steigende Anzahl an Produktkonfigurationen. So hat ein Kunde bei der aktuellen Produktlinie der A-Klasse von Mercedes-Benz über 1015 Möglichkeiten die Ausstattungsmerkmale seines Fahrzeugs zu kombinieren. Parallel dazu nimmt die Komplexität der Fahrzeuge stark zu, da ein Großteil der softwarebasierten Innovationen durch hochgradig miteinander vernetzte, elektrisch/elektronische (E/E-)Systeme realisiert wird. Als Folge dessen ergeben sich hohe Ansprüche an die Absicherung der Fahrzeuge bzw. E/E-Systeme. Diese betreffen die enorme Anzahl an Tests, die durchgeführt werden müssten, um eine Produktlinie vollständig zu testen [dCMMdA12]. Da die Anzahl gültiger Produktkonfigurationen, die aus einer Produktlinie abgeleitet werden kann, jedoch expo2417

nentiell mit der Anzahl der möglichen Optionen wächst [ER11], ist das Testen aller Produktkonfigurationen sowohl aus ökonomischer als auch praktischer Sicht nicht realisierbar. Für eine effiziente Absicherung ist somit folgende methodische Unterstützung notwendig: 1. systematische Bestimmung einer Untermenge zu testender Konfigurationen Ctest , 2. Vermeiden von redundanten Testfällen durch Wiederverwendung. Auch für die Erfüllung relevanter Normen und Gesetze sowie die Einhaltung der Qualitätsziele ist eine Variantenstrategie im Testprozess unerlässlich. So fordert bspw. die in Kraft getretene Norm ISO 26262 „Road vehicles - Functional safety“, welche für die Absicherung von sicherheitsrelevanten E/E-Systemen in Kraftfahrzeugen gilt, eine Variantenabdeckung für jedes Testobjekt, erlaubt jedoch gleichzeitig die Selektion einer „sinnvoll zu testenden Untermenge“ [ISO11] (4-8.4.1.4) aufgrund der enormen Anzahl an Konfigurationen. Ein gängiger Ansatz zur Beherrschung der resultierenden Komplexität ist durch die Produktlinienentwicklung gegeben. Diese unterstützt eine organisierte Wiederverwendung von Artefakten im Entwicklungsprozess [BKPS04]. Dafür werden während der Aktivität des Domain Engineerings produktübergreifende Artefakte als sog. Plattform bereitgestellt. Darauf folgend können im Application Engineering die einzelnen Produkte aus der Plattform ausgeleitet werden. Dieser Grundgedanke der Wiederverwendung wird von der Produktlinienentwicklung ebenfalls in der Phase der Absicherung genutzt. Im Hinblick auf die genannten Herausforderungen sowie die bereits gegebenen Ansätze der Produktlinienentwicklung wird im vorliegenden Beitrag ein Verfahren vorgestellt, welches eine systematische Identifikation von Ctest erlaubt. Ctest stellt dabei die kleinstmögliche Menge an Konfigurationen dar, welche für eine 100%ige Abdeckung aller Anforderungen genügt. Die gemeinsame Plattform beinhaltet das Merkmalmodell, mit der dort erfassten Variabilität, sowie Anforderungs- und Testspezifikationen, in denen die Merkmale desselben Merkmalmodells auf die Anforderungen bzw. Testfälle gemappt werden. Auf Basis dieser generischen Spezifikationsdokumente lassen sich beliebige produktspezifische Artefakte ausleiten. Dieser Zusammenhang ist in Abbildung 1 dargestellt. Die Verwendung eines Merkmalmodells erlaubt es für Ctest die entsprechenden Testfälle zu Gemeinsames Merkmalmodell

Domain Engineering

SLH

Testspec Testspec

SLH SLH SLH Produkt x Produkt y Produkt z

Produkt x Produkt y Produkt z

Application Engineering

Abbildung 1: Übersicht über die Produktlinien-Infrastruktur für die Phasen des Spezifizierens von Anforderungen, hier im Systemlastenheft (SLH), sowie von Testfällen, in der Testspezifikation

2418

bestimmen. Mithilfe der dadurch ermöglichten Testfallwiederverwendung können erhebliche Einsparungen der Entwicklungszeit sowie Entwicklungskosten erzielt werden. Im folgenden Kapitel werden die verwandten Arbeiten umfassend behandelt, um einen Überblick über den aktuellen Stand der Technik zu geben. In Kapitel 2, dem Schwerpunkt des Beitrags, wird zunächst ein Beispiel zur Veranschaulichung der nachfolgenden Methodiken vorgestellt. Um einen Überblick über die Produktlinien-Infrastruktur zu verschaffen, werden in Kapitel 3.1 die Modellierung der Variabilität sowie in Kapitel 3.2 deren Mapping auf Entwicklungsartefakte konkretisiert. Davon ausgehend wird in Kapitel 3.3 die Selektionsmethodik des anforderungsbasierten Produktlinientests eingeführt, der Algorithmus skizziert und die Ergebnisse anhand eines Fallbeispiels evaluiert. Abgeschlossen wird der Beitrag mit einer kurzen Zusammenfassung sowie einem Ausblick.

2 Verwandte Arbeiten Die einfachste Methodik für das Testen von Produktlinien ist das Product-by-Product Testen. Dabei wird jedes einzelne Produkt der Produktlinie individuell abgesichert, wodurch die Testaktivitäten allein in der Applikationsentwicklung stattfinden [TTK04, JhQJ08]. Das Verfahren hat hohe Ähnlichkeit zur Einzelsystementwicklung und steht somit im Widerspruch zum eigentlichen Kerngedanken der Produktlinienentwicklung. Der Vorteil des Verfahrens ist jedoch, dass eine hohe Produktqualität garantiert werden kann. Der Ansatz wird bei Nokia zur Entwicklung von mobilen Browsern herangezogen [Jaa02]. Dass das Product-by-Product Testen nur bei sehr kleinen Produktlinien funktionieren kann, wird vom Beitrag bestätigt, in welchem von einer Produktlinie mit vier Produkten berichtet wird. Im Gegensatz dazu versucht der Ansatz des Inkrementellen Testens Testfälle mithilfe von Ideen des Regressionstests wiederzuverwenden. Der Regressionstest wird angewendet, um Testfälle zu ermitteln, welche nach Modifikation eines Testobjektes zu dessen ReVerifikation, erneut durchgeführt werden müssen. Das modifizierte Testobjekt stellt dabei eine Version des ursprünglichen Testobjektes dar. Setzt man Konfigurationen mit Versionen gleich, lässt sich eine Regressionstestmethodik einsetzen, um ausgehend von einer initialen Konfiguration die Testumfänge weiterer Konfigurationen zu identifizieren [TTK04, NCRMG11]. Dies wird von Lity et al. in [LLS+ 12] umgesetzt. Dabei werden mithilfe eines wiederverwendbares Testmodells und den Differenzen zwischen den Produkten die Testumfänge inkrementell bestimmt. Der Vorteil ist hier, dass eine bewährte Methode im neuen Kontext eingesetzt wird. Nicht trivial ist jedoch, die Festlegung des initialen Testobjektes. Darüber hinaus steht bei diesem Ansatz die Testfallwiederverwendung im Vordergrund, die zu testenden Konfigurationen müssen jedoch durch andere Methoden bestimmt werden. Auch der Modellbasierte Produktlinientest macht sich das Prinzip der Wiederverwendung zunutze, denn die in der Domänenentwicklung erstellten Testmodelle werden in der Applikationsentwicklung in angepasster Form wiederverwendet. Der Fokus der Methodik liegt dabei auf der automatisierten Ableitung von Testfällen für die einzelnen Produkte auf Basis 2419

von formalen Spezifikationen. Mit ScenTED wird dies ausgehend von Aktivitätsdiagrammen durchgeführt [RKPR05]. Die Variabilität wird über gekennzeichnete Verzweigungen im Kontrollfluss des Aktivitätsdiagramms dargestellt, während die Testfallableitung im Hinblick auf das Kriterium der Zweigüberdeckung geschieht. Unter Einsatz des Modellbasierten Produktlinientests ist eine hohe Automatisierbarkeit erreichbar, jedoch liegt der Schwerpunkt nicht auf der Selektion der zu testenden Konfigurationen. Weiterhin oft genutzt ist die Methode der Priorisierung, bei welcher durch Analyse entsprechender Kriterien den Konfigurationen eine hohe oder niedrige Test-Dringlichkeit zugeordnet wird. Das am meisten verwendete Kriterium ist dabei die Häufigkeit, mit der ein Produkt verkauft wird bzw. geplant ist zu verkaufen [MD08, Bur10]. So werden in [Man11] Funktionsvarianten der Dr. Ing. h.c. F. Porsche AG nach Verbauhäufigkeit gewichtet. Ebenfalls werden Risiken, die sich aus einer Fehlfunktion des entsprechenden Produktes ergeben könnten, zur Priorisierung herangezogen [Man11, Sch12, Kol03]. Darüber hinaus existieren Ansätze, welche bspw. Kostenmodelle zur Einschätzung des Testaufwandes nutzen [ZZR04] oder Fehlermodelle zur Identifikation der wahrscheinlichsten Fehlerquellen aufstellen [McG08]. Die Schwierigkeit bei diesem Verfahren ergibt sich in der Beschaffung und Bereitstellung der zusätzlichen Informationen sowie dem damit einhergehenden Mehraufwand. Kombinatorische Testverfahren werden eingesetzt, um Fehler dort aufzudecken, wo Interaktionen stattfinden und Informationen bzw. Daten ausgetauscht werden. Das Ziel kann dabei die Abdeckung aller Paare bis beliebiger t-Tupel aller Merkmale sein. Obwohl dabei nur ein Bruchteil an Konfigurationen getestet wird, weisen empirische Untersuchungen einen hohen Grad an Fehleraufdeckung nach. Die Idee wird ebenfalls bei der Klassifikationsbaum-Methode zur Testfallgenerierung verwendet [Gri95]. Die PairwiseMethode wird bspw. von [Ost11] zur Selektion der zu testenden Konfigurationen für den modellbasierten Test eingesetzt, während Cohen [Coh04] ein mathematisches Modell zur variablen Abdeckung von Eingabewerten entwickelt. Der Vorteil der Methodik ist die enorme Komprimierung des zu testenden Konfigurationsraums und einer gleichzeitigen Fehleraufdeckungsrate von über 70% [KWG04, BLKK09, McG01]. Nachteilig ist, dass einzig die Variabilität als Selektionskriterium herangezogen wird. Ein zum vorliegenden Beitrag besonders ähnlicher Ansatz wird in [Sch07] beschrieben und zählt zur Anforderungsbasierten Selektion. Dabei werden die zu testenden Konfigurationen eines Systems basierend auf einer optimierten Abdeckung der Anforderungen sowie der Architekturelemente selektiert. Für diesen Zweck wird die Menge der Architekturelemente, welche in einer Konfiguration C eine Anforderung R realisieren, zu einem locality set LC,R zusammengefasst [Sch06]. Auf Basis der LC,R generiert ein GreedyAlgorithmus eine optimierte Selektion der Konfigurationen. Die Idee ist dabei, dass Anforderungen, welche in zwei verschiedenen Konfigurationen durch dieselbe Menge der Architekturelemente realisiert werden, d.h. ein gemeinsames LC,R besitzen, in nur einer Konfiguration abgesichert werden müssen. Das Verfahren erreicht eine Einsparung von rund 30%, in der Praxis skaliert es jedoch nur schwer für große Testobjekte. Im Gegensatz zum letzten vorgestellten Vorgehen werden im vorliegenden Beitrag für die optimale Selektion nur Anforderungsspezifikationen und keine Architekturelemente herangezogen. Darüber hinaus basiert das Konzept auf einem durchgängigen Varianten2420

management von Anforderungen bis zu den Testfällen, welches in [CNHR12] detailliert behandelt wird. Durch diese Verknüpfung wird eine explizite Testfallwiederverwendung ermöglicht.

3 Selektionsmethodik 3.1 Modellierung der Variabilität Im Rahmen einer erfolgreichen Produktlinienentwicklung ist zunächst die Erfassung und explizite Dokumentation der vorhandenen Variabilität für eine Produktlinie notwendig. Zu diesem Zweck werden sämtliche variable Eigenschaften identifiziert und innerhalb eines Variabilitätsmodells in Form von Variationspunkten hinterlegt. Bei der Daimler AG erfolgt die Dokumentation in einem Merkmalmodell, welches unabhängig von weiteren Artefakten wie Anforderungen oder Testfällen ist. Das Merkmalmodell bietet die Möglichkeit die Variationspunkte, d.h. Merkmale, entsprechend der Konfigurationsmöglichkeiten miteinander in Beziehung zu setzen. Dazu wird jedes Merkmal mit einem Variationstypen attributiert. Ein obligatorisches Merkmal ist in jeder Produktkonfiguration enthalten. Bei einer alternativen Merkmalgruppe ist genau ein Merkmal in jeder Konfiguration enthalten und bei einer oder-Gruppe mindestens eines. Zusätzlich können sog. Constraints den Konfigurationsraum weiter einschränken. Die bidirektionale Exklusion zwischen zwei Merkmalen verbietet sämtliche Produktkonfigurationen, in denen beide Merkmale vorkommen, während die unidirektionale Implikation (mx → my ) nur solche Konfigurationen erlaubt, bei denen mx in Kombination mit my auftritt (wobei Konfigurationen mit my nicht zwingend mx enthalten müssen). Abbildung 2 zeigt ein exemplarisches Merkmalmodell für das System Klimatisierung. Die Produkte des Systems variieren dabei in den Klimamaßnahmen sowie der Tatsache, ob und welche HV-Batterie verbaut ist. obligatorisch alternativ oder Implikation Exklusion

Sitzheizung

Klimatisierung

Bezugsobjekt

Klimamaßnahme Panelheizung

HV-Batterie Merkmalgruppe

Sitzkühlung

HV Groß

HV Klein

Kein HV Merkmalausprägung

Abbildung 2: Merkmalmodell des Beispielsystems Klimatisierung

Neben den Entwicklungsdokumenten wird auch das Merkmalmodell im Anforderungsmanagement-Tool IBM Rational DOORS [DOO] dokumentiert. Da dieses Werkzeug in erster Linie nicht für die Produktlinienentwicklung ausgelegt ist, ist es in der Mächtigkeit der komplexen Beziehungsabbildung zwischen Merkmalen eingeschränkt. Denn das Merkmalmodell in DOORS ist in zwei Ebenen aufgebaut. Die erste Ebene charakterisiert Merkmalgruppen, welche durch obligatorische Merkmale gekennzeichnet werden. Deren Kin2421

der, Merkmalausprägungen, enthalten die eigentlichen variablen Anteile und können entweder alternative oder oder-Gruppen beschreiben.1

3.2 Mapping der Variabilität auf Entwicklungsartefakte Um die im Merkmalmodell definierte Variabilität in den Entwicklungsdokumenten abbilden zu können, werden den Artefakten Merkmale zugeordnet. In einer natürlichsprachlichen Spezifikation geschieht dies dadurch, dass jedem einzelnen Artefakt, also jeder Anforderung oder jedem Testfall, aus einer Liste aller im Merkmalmodell verfügbaren Merkmale die Merkmale explizit zugeordnet werden, für welche es gilt. Tabelle 1 zeigt eine exemplarische Anforderungsspezifikation mit dem Mapping der Merkmale aus dem Merkmalmodell von Abbildung 2 auf die Anforderungen rk .

Anforderungen, rk r1 r2 r3 r4 r5

Merkmalmapping Klimatisierung HV-Batterie (Sitzheizung), (Sitzkühlung) (Sitzkühlung) (Panelheizung) (Sitzheizung), (Sitzkühlung)

(HV Groß), (HV Klein) (Kein HV) (HV Groß) (HV Klein)

Tabelle 1: Beispielhaftes Merkmalmapping auf Anforderungen angelehnt an die Struktur in DOORS

Folglich umfasst eine solche Spezifikation alle Produktspezifikationen der korrespondierenden Produktlinie, welche durch die Selektion der relevanten Merkmale im Bezug auf eine bestimmte Produktkonfiguration ausgeleitet werden können. Dadurch haben die Dokumente einen generischen Charakter und erzielen für die Entwicklungsartefakte einen hohen Grad der Wiederverwendung. Beispielsweise umfasst die Testspezifikation der Produktlinie Klimatisierung alle Testfälle, die für das Testen der verschiedenen Fahrzeugprodukte notwendig sind. Aus dieser können für alle validen Konfigurationen die passenden Testspezifikationen ausgeleitet werden (siehe Abbildung 1). Die Art wie die zugeordneten Merkmale eines Artefaktes zusammenhängen, d.h. die Assoziationslogik, spielt dabei eine wesentliche Rolle. In DOORS werden die Merkmale über Disjunktion (ODER-Operator) und Konjunktion (UND-Operator) verknüpft, sodass die zugeordneten Merkmale für jede Anforderung einen Ausdruck in der konjunktiven Normalform (KNF) annehmen. Dabei werden Merkmalausprägungen, welche einer Anforderung zugeordnet sind, innerhalb einer Spalte mit der Disjunktion und zwischen den Spalten mit der Konjunktion verbunden. Für r5 in Tabelle 1 bedeutet dies, dass die Anforderung für: [(Sitzheizung) ODER (Sitzkühlung)] UND (HV Klein) gilt. r5 ist also für jede Konfiguration gültig, welche entweder [ (Sitzheizung) UND (HV Klein) ] oder [ (Sitzkühlung) 1 Obwohl von DOORS ein Strukturrahmen für die Modellierung der Variabilität vorgegeben ist, sei hier angemerkt, dass jedes Merkmalmodell sich gemäß [OMSM09] vereinheitlichen lässt.

2422

UND (HV Klein) ] enthält. Ist in einem Feld kein expliziter Merkmaleintrag vorhanden, so gelten alle Merkmalausprägungen der entsprechenden Merkmalgruppe.

3.3 Selektion der zu testenden Konfigurationen 3.3.1

Basis der Selektionsmethodik

Die Selektionsmethodik geht von der von DOORS vorgegebenen Assoziationslogik aus. Aufgrund der KNF ist die Einschränkung gegeben, dass in den Anforderungen explizit nur das kartesische Produkt der Merkmalausprägungen aller Merkmalgruppen abgebildet werden kann. Das kartesische Produkt des Systems Klimatisierung, (siehe Abbildung 2), ergibt insgesamt acht valide Konfigurationen ci , welche in Tabelle 2 dargestellt sind. Für jedes Merkmal mj , welches in der Konfiguration enthalten ist, wird der Eintrag 1, für jedes nicht enthaltene Merkmal der Eintrag 0 vorgenommen. Für die Abdeckung der Merkmale durch jeweils eine Konfiguration Fcov (ci ) gilt somit: ( 1 falls mj ∈ Fcov (ci ) cov(ci , mj ) = 0 sonst.

ci c1 c2 c3 c4 c5 c6 c7 c8

cov(ci , m1 ) (m1 =SH) 1 1 1

cov(ci , m2 ) (m2 =PH)

cov(ci , m3 ) (m3 =SK)

cov(ci , m4 ) (m4 =HVgr)

cov(ci , m5 ) (m5 =HVkl)

cov(ci , m6 ) (m6 =kHV)

|Fcov (ci )|

1 1 1

1 0 0 1 0 1 0 0

0 1 0 0 0 0 1 0

0 0 1 0 1 0 0 1

2 2 2 2 2 3 3 3

0 1 1

1 1 1

0

Tabelle 2: Konfigurationsbildung ci gemäß der DOORS-Struktur sowie die Abbildung wie viele Merkmale von jeweils einer Konfiguration abgedeckt werden |Fcov (ci )|.

In einigen Feldern der Tabelle 2 ist keine explizite Angabe gemacht, ob ein Merkmal in der jeweiligen Konfiguration enthalten ist oder nicht. Dies ist bspw. für c2 der Fall, in der das Merkmal (SK) enthalten sein kann oder nicht. Ein ci kann somit eine unvollständige Konfiguration darstellen, in der Entscheidungen noch zu treffen sind. Einige Zuordnungen ergeben sich dagegen implizit über die vom Merkmalmodell vorgegebenen Constraints und sind in Tabelle 2 grau hervorgehoben. So darf c2 das Merkmal (P H) nicht enthalten, da dies von (HV kl) ausgeschlossen ist. (P H) erhält somit in c2 den Eintrag 0. In der letzten Spalte ist mit |Fcov (ci )| zusammengefasst, wie viele Merkmale eine Konfiguration jeweils abdeckt.

2423

Des Weiteren wird für jedes ci bestimmt, welche Anforderungen Rcov (ci ) es abdeckt. Dies ist in Tabelle 3 dargestellt, wobei gilt: ( 1 falls rk ∈ Rcov (ci ) cov(ci , rk ) = 0 sonst. So ist die Anforderung r1 bspw. für c1 , c2 , c6 und c7 gültig. In der letzten Spalte der Tabelle 3 ist die Kardinalität der Menge Rcov (ci ) dargestellt, welche die Anzahl der von der jeweiligen Konfiguration, abgedeckten Anforderungen kennzeichnet. Ausgehend von der vorgestellten Basis erfolgt die Selektion der zu testenden Konfigurationen. ci

cov(ci , r1 )

cov(ci , r2 )

cov(ci , r3 )

cov(ci , r4 )

cov(ci , r5 )

|Rcov (ci )|

c1 c2 c3 c4 c5 c6 c7 c8

1 1 0 0 0 1 1 0

0 0 1 0 1 0 0 1

0 0 0 0 0 1 1 1

0 0 0 1 0 0 0 0

0 1 0 0 0 0 1 0

1 2 1 1 1 2 3 2

Tabelle 3: Abbildung welche Konfigurationen für welche Anforderungen gelten cov(ci , ri ) sowie wie viele Anforderungen von jeweils einer Konfiguration abgedeckt werden |Rcov (ci )|.

3.3.2

Vorgehensweise bei der Selektion

Ausgehend von der beschriebenen Produktlinien-Infrastruktur werden die zu testenden Konfigurationen bestimmt. Da in den Anforderungen direkt abgebildet ist, wo die Gemeinsamkeiten zwischen den Konfigurationen liegen, lässt sich diese Information zugunsten einer Optimierung ausnutzen. Gilt eine Anforderung für mehrere Konfigurationen, ist es irrelevant in welcher Konfiguration sie ausgeführt wird und somit ausreichend diese in einer der Konfigurationen zu berücksichtigen. Diese Idee lässt sich auf alle Anforderungen übertragen, sodass die kleinste Menge an Konfigurationen, welche jedoch alle Anforderungen abdeckt für die Absicherung einer Produktlinie als minimaler Testumfang ausreicht. Das Finden der kleinsten Menge an Konfigurationen, welche alle Anforderungen abdeckt, stellt ein NP-vollständiges Optimierungsproblem dar. Für die Ermittlung der besten Lösung müssen alle Möglichkeiten, d.h. alle Kombinationen von ci ausprobiert werden, was für reale Systeme mit großen Konfigurationsräumen zu aufwändig wäre. Aus diesem Grund ist es sinnvoll, ein schnelles und einfach umsetzbares heuristisches Verfahren, wie einen Greedy-Algorithmus, anzuwenden. Ein Greedy-Algorithmus liefert zwar nicht immer die beste Lösung, da er in lokalen Optima stecken bleiben kann, jedoch ermöglicht er eine Annäherung an das globale Optimum. Der Greedy-Algorithmus wählt bei der Suche schrittweise den Folgezustand, welcher zum Zeitpunkt der Auswahl den größten Nutzen/Gewinn bringt. Der größte Gewinn ist für das 2424

vorliegende Problem durch eine hohe Anforderungsabdeckung gegeben und lässt sich anhand von |Rcov (ci )| bestimmen. Im Beispiel deckt c7 die meisten, nämlich drei Anforderungen ab und würde selektiert werden (dunkelgrau hervorgehoben in Tabelle 3). Vor Ausführung der Greedy-Schleife muss jedoch geprüft werden, ob Anforderungen existieren, welche von ausschließlich einem ci abgedeckt werden. Diese Bedingung wird von r4 erfüllt, denn diesem ist ausschließlich c4 zugeordnet (hellgrau hervorgehoben in Tabelle 3). c4 muss in jedem Fall selektiert werden, wenn eine 100%ige Anforderungsabdeckung erreicht werden soll. Da c4 außer r4 weitere Anforderungen abdecken könnte, ist es sinnvoll, solche ci vorweg zu selektieren. Aufgrund der Tatsache, dass solche Fälle nur zu Beginn der Suche gegeben sein können, wird die Abfrage nur einmal durchgeführt. Algorithmus 1 zeigt den Pseudocode zum Vorgehen. Zu Beginn wird in der sogenannten Initialisierung nach Elementen rmin in der Anforderungsliste „ReqsToCover“ gesucht, welche durch exakt eine Konfiguration abgedeckt werden. Alle Konfigurationen, welche diese Bedingung |Ccov (rmin )| = 1 erfüllen, werden als Csel gespeichert und der Menge der selektierten Konfigurationen „SubsetConfigs“ hinzugefügt. Zusätzlich werden die beiden Listen der Anforderungen und Merkmale aktualisiert, indem die bereits durch Csel abgedeckten Elemente entfernt werden. Algorithmus 1 Greedy Configuration Selection function G REEDY C ONFIG S ELECTION(ReqsToCover, FeatsToCover, Configs) SubsetConfigs ← ∅ ⊲ Phase 1: Initialisierung Rmin = {rmin ∈ ReqsToCover | |C (r )| = 1} cov min S Ccov (rmin ) Csel ← rmin ∈Rmin S Rcov (c) ReqsToCover ← ReqsToCover \ c∈C Ssel FeatsToCover ← FeatsToCover \ Fcov (c) c∈Csel

SubsetConfigs ← SubsetConfigs ∪ Csel

⊲ Phase 2: Greedy-Algorithmus while |ReqsToCover| > 0 OR |FeatsToCover| > 0 do Cmax = {cmax ∈ Configs | ∀d ∈ Configs (|Rcov (cmax )| ≥ |Rcov (d)|)} if |Cmax | = 1 then csel ← cmax ∈ Cmax else Cf max = {cf max ∈ Cmax | ∀d ∈ Cmax (|Fcov (cf max )| ≥ |Fcov (d)|)} csel ← RandomSelect(cr ∈ Cf max ) end if ReqsToCover ← ReqsToCover \Rcov (csel ) FeatsToCover ← FeatsToCover \Fcov (csel ) SubsetConfigs ← SubsetConfigs ∪ csel end while return SubsetConfigs end function

2425

In der darauf folgenden Phase des Greedy-Algorithmus wird nach Konfigurationen Cmax gesucht wird, durch welche die meisten Anforderungen abgedeckt werden. Gibt es mehrere Konfigurationen, welche zu einem maximalen Beitrag der Anforderungsabdeckung führen, wird von denen die Konfiguration mit der größten Merkmalabdeckung Cf max gesucht. Bei mehreren Kandidaten wird von diesen zufällig eine cr ausgewählt und als csel gespeichert. Schließlich wird geprüft, welche Anforderungen und Merkmale csel abdeckt und die Liste der „ReqsToCover“ sowie der „FeatsToCover“ aktualisiert. Zuletzt wird csel der Menge aller selektierten Konfigurationen „SubsetConfigs“ hinzugefügt. Wie bereits in Kapitel 3.3.1 beschrieben, gibt es Konfigurationen ci mit leeren Merkmaleinträgen. D.h. für eine vollständige Konfiguration cv,i ist noch die Entscheidung zu treffen, ob die entsprechenden Merkmale in der Konfiguration enthalten sind oder nicht. Momentan wird davon ausgegangen, dass solche Merkmale in den cv,i nicht vorkommen und somit den Eintrag 0 enthalten. Hier ist jedoch eine weitere Optimierungsmöglichkeit gegeben, denn analog zur Anforderungsabdeckung lässt sich auch die Merkmalabdeckung maximieren. Die leeren Felder können unter Beachtung der Constraints zur maximalen Merkmalabdeckung befüllt werden. Dies ist aktuell noch in Arbeit. 3.3.3

Ergebnis

Für das Beispielsystem Klimatisierung (Merkmalmodell siehe Abbildung 2, Anforderungsspezifikation siehe Tabelle 1) wählt der Algorithmus drei Konfigurationen aus, nämlich c4 , c7 und c3 . Im ersten Schritt wird c4 ausgewählt, da Anforderung r4 ausschließlich von c4 abgedeckt wird und dieses somit die Bedingung |Ccov (rmin )| = 1 erfüllt. Im zweiten Schritt selektiert der Greedy-Algorithmus c7 , da |Rcov (c7 )| maximal ist bezüglich der noch nicht abgedeckten Anforderungen. Schließlich bleibt im dritten Schritt noch r2 übrig, wofür c3 , c5 und c8 gleichermaßen in Frage kommen. Da alle drei Kandidaten zur Abdeckung des verbliebenen Merkmals m6 beitragen würden, wird zufällig eins ausgewählt, beispielsweise c3 . Dadurch ist jede Anforderung und jedes Merkmal mindestens einmal abgedeckt und der Algorithmus terminiert. Das Ergebnis sowie die Entscheidungsgrundlage des Algorithmus in jedem der drei Durchläufe ist in Tabelle 4 dargestellt. Durchlauf Initialisierung Greedy 1 Greedy 2

rmin

Cmax

Cf max

ReqsToCover

FeatsToCover

c3 , c5 , c8

r1 , r2 , r3 , r4 , r5 r1 , r2 , r3 , r5 r2

m1 , m 2 , m3 , m4 , m5 , m6 m1 , m 3 , m5 , m6 m6

r4 c7 c3 , c5 , c 8

csel c4 c7 c3

Tabelle 4: Durchläufe sowie das Ergebnis des Vorgehens, beschrieben in Kapitel 3.3.2, für das System Klimatisierung

Für ein reales E/E-System der Daimler AG aus dem Bereich des Thermischen Komforts, welches hier aus Gründen der Geheimhaltung nicht behandelt werden kann, hat der Algorithmus neun Konfigurationen selektiert, dargestellt in Abbildung 3. Die Anforderungsspezifikation enthält dabei 847 Anforderungen, das Merkmalmodell 37 Merkmale und rund 2426

106 Konfigurationen. In der Testspezifikation, welche die Anforderungen des Systems abdeckt, werden Merkmale aus demselben Merkmalmodell den Testfällen zugeordnet. Auf Basis der generischen Testspezifikation lassen sich dadurch die passenden Testfälle für die neun selektierten Konfigurationen ausleiten.

Abbildung 3: Ergebnis des Selektionsalgorithmus für ein E/E-System aus dem Bereich des Thermischen Komforts

3.3.4

Tool-Unterstützung

Die in diesem Beitrag behandelten Anforderungs- und Testartefakte werden bei der Daimler AG in DOORS dokumentiert und verwaltet. Wie bereits in Kapitel 3.1 erwähnt ist das Tool DOORS jedoch nur bedingt für die Modellierung komplexer Beziehungen zwischen den Merkmalen geeignet. Daher wird für die Erstellung von Merkmalmodellen das Tool pure::variants genutzt, welches speziell für die Anforderungen des Variantenmanagements entwickelt wurde [pur]. Über eine existierende Schnittstelle zwischen DOORS und pure::variants können die Artefakte mit Anforderungs- und Testbezug von DOORS nach pure::variants transformiert werden. Die hier vorgestellte Selektion wird als ein Eclipsebasiertes Plug-in für pure::variants realisiert. Über dieselbe Schnittstelle können Daten wie die selektierten Anforderungen wieder zurück nach DOORS übertragen werden.

4 Zusammenfassung und Ausblick Der Beitrag beschreibt eine Methodik, welche eine durchgängige Dokumentation und Verwaltung der Varianten von Anforderungen bis zu den Testfällen ermöglicht. Aufgrund der Allgemeingültigkeit lässt sich das Verfahren ebenfalls auf weitere Entwicklungsdokumente übertragen. Darüber hinaus wird eine Selektionsmethodik vorgestellt, welche eine optimale Anforderungsüberdeckung gewährleistet und mithilfe eines Greedy-Algorithmus umgesetzt wird. Dadurch ist eine starke und systematische Reduktion der Anzahl zu testender Konfigurationen, eine hohe Wiederverwendung von Testfällen und ein erheblicher Effizienzgewinn im Testprozess sichergestellt. Momentan wird daran gearbeitet, das Optimierungsproblem mithilfe eines anderen heuristischen Verfahrens, des Simulated Annealing, zu lösen. Im Gegensatz zum Greedy2427

Algorithmus kann dieses lokale Optima wieder verlassen und somit möglicherweise bessere Ergebnisse liefern. Schließlich ist es denkbar, die freien Entscheidungen, welche nicht durch das DOORS-Merkmalmapping vorgegeben sind, nicht nur zugunsten einer maximalen Merkmalabdeckung, wie in Kapitel 3.3.2 angedeutet, sondern zugunsten der PairwiseAbdeckung von Merkmalen zu treffen.

Literatur [BKPS04]

Günter Böckle, Peter Knauber, Klaus Pohl und Klaus Schmid, Hrsg. SoftwareProduktlinien: Methoden, Einführung und Praxis. Dpunkt Verlag, 2004.

[BLKK09]

Renée C. Bryce, Yu Lei, D.Richard Kuhn und Raghu Kacker. Handbook of Research on Software Engineering and Productivity Technologies: Implications of Globalization, Kapitel Combinatorial Testing. IGI, 2009.

[Bur10]

Florian Burgdorf. Eine kunden- und lebenszyklusorientierte Produktfamilienabsicherung für die Automobilindustrie. Dissertation, Karlsruher Institut für Technologie, 2010.

[CNHR12]

Anastasia Cmyrev, Ralf Noerenberg, Daniel Hopp und Ralf Reissing. Consistency Checking of Feature Mapping between Requirements and Test Artefacts. In Proceedings of the 19th ISPE International Conference on Concurrent Engineering, 2012.

[Coh04]

Myra B. Cohen. Designing test suites for software interaction testing. Dissertation, The University of Auckland, 2004.

[dCMMdA12] Ivan do Carmo Machado, John McGregor und Eduardo Santana de Almeida. Strategies for testing products in software product lines. SIGSOFT Software Engineering Notes, 37:1–8, 2012. [DOO]

IBM Rational DOORS. awdtools/doors/.

[ER11]

Emelie Engström und Per Runeson. Software product line testing - A systematic mapping study. Information and Software Technology, 53:2–13, 2011.

[Gri95]

Klaus Grimm. Systematisches Testen von Software - Eine neue Methode und eine effektive Teststrategie. Dissertation, Technische Universität Berlin, 1995.

[ISO11]

ISO 26262 Road verhicles - Functional safety, 2011.

[Jaa02]

Ari Jaaksi. Developing Mobile Browsers in a Product Line. IEEE Software, 19:73– 80, 2002.

[JhQJ08]

Li Jin-hua, Li Qiong und Li Jing. The W-Model for Testing Software Product Lines. In Proceedings of the International Symposium on Computer Science and Computational Technology (ISCSCT) - Volume 01, 2008.

[Kol03]

Ronny Kolb. A Risk-Driven Approach for Efficiently Testing Software Product Lines. In Proceedings of the 5th GPCE Young Researches Workshop, 2003.

[KWG04]

D. R. Kuhn, D. R. Wallace und A. M. Jr. Gallo. Software Fault Interactions and Implications for Software Testing. IEEE Transactions on Software Engineering, 30:418–421, 2004.

http://www-01.ibm.com/software/

2428

[LLS+ 12]

Sascha Lity, Malte Lochau, Ina Schaefer, und Ursula Goltz. Delta-Oriented ModelBased SPL Regression Testing. In Proceedings of the 3rd International Workshop on Product Line Approaches In Software Engineering (PLEASE), 2012.

[Man11]

Oliver Manicke. Durchgängiges Variantenmanagement zur Komplexitätsbeherrschung im Entwicklungsprozess mechatronischer Fahrzeugfunktionen. Dissertation, Technische Universität Dresden, 2011.

[McG01]

John McGregor. Testing a Software Product Line. Bericht, Software Engineering Institute, 2001.

[McG08]

John McGregor. Toward a fault model for software product lines. In Proceedings of the 5th Software Product Line Testing Workshop (SPLiT), 2008.

[MD08]

Oliver Manicke und Dr. Rüdiger Dorn. Methoden zur Entwicklung eines Variantenmanagements zur Optimierung von EE-Funktionstests vernetzter Steuergeräte. In Tagungsband zur 2. AutoTest Fachkonferenz „Test von Hard- und Software in der Automobilentwicklung„, 2008.

[NCRMG11]

Ralf Nörenberg, Anastasia Cmyrev, Ralf Reißing und Klaus D. Müller-Glaser. An Efficient Specification-Based Regression Test Selection Technique for E/E-Systems. In Tagungsband zur 41. GI Jahrestagung, 9. Workshop Automotive Software Engineering, 2011.

[OMSM09]

Sebastian Oster, Florian Markert, Andy Schürr und Werner Müller. Integrated Modeling of Software Product Lines with Feature Models and Classification Trees. In Proceedings of the 13th International Software Product Line Conference (SPLC), MAPLE 2009 Workshop Proceedings. Springer Verlag, 2009.

[Ost11]

Sebastian Oster. Feature Model-based Software Product Line Testing. Dissertation, Technische Universität Darmstadt, 2011.

[pur]

pure::variants. http://www.pure-systems.com/pure_variants.49. 0.html.

[RKPR05]

Andreas Reuys, Erik Kamsties, Klaus Pohl und Sacha Reis. Model-Based System Testing of Software Product Families. In Proceedings of the 17th International Conference on Advanced Information Systems Engineering (CAiSE), 2005.

[Sch06]

Kathrin D. Scheidemann. Optimizing the Selection of Representative Configurations in Verification of Evolving Product Lines of Distributed Embedded Systems. In Proceedings of the 10th International Software Product Lines Conference (SPLC), Seiten 75–84, 2006.

[Sch07]

Kathrin D. Scheidemann. Verifying Families of System Configurations. Dissertation, Technische Universität München, 2007.

[Sch12]

Florian Schmidt. Ein effizienter Testprozess für sicherheitskritische und variantenreiche Systeme. In Tagungsband zur 4. AutoTest Fachkonferenz „Test von Hard- und Software in der Automobilentwicklung„, 2012.

[TTK04]

Antti Tevanlinna, Juha Taina und Raine Kauppinen. Product family testing - a Survey. SIGSOFT Software Engineering Notes, 29:1–12, 2004.

[ZZR04]

Hui Zeng, Wendy Zhang und David Rine. Analysis of testing effort by using core assets in software product line testing. In Proceedings of the 3rd Software Product Line Testing Workshop (SPLiT), 2004.

2429