Optimierte Varianten- und Anforderungsabdeckung im Test

Transkript

1 Optimierte Varianten- und Anforderungsabdeckung im Test Anastasia Cmyrev, Ralf Reißing* Daimler AG Hochschule Coburg* Hanns-Klemm-Straße 45 Friedrich-Streib-Str Böblingen Coburg anastasia.cmyrev@daimler.com reissing@hs-coburg.de 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 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 expo- 2417

2 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 KonfigurationenC test, 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 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] ( ) 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 vonc test erlaubt.c test 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 C test die entsprechenden Testfälle zu Gemeinsames Merkmalmodell SLH SLH SLH SLH Produkt x Produkt y Produkt z Domain Engineering Testspec Testspec 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

3 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 Re- Verifikation, 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

4 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 Pairwise- Methode 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 L C,R zusammengefasst [Sch06]. Auf Basis der L C,R generiert ein Greedy- Algorithmus 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 L C,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 Varianten- 2420

5 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 (m x m y ) nur solche Konfigurationen erlaubt, bei denen m x in Kombination mit m y auftritt (wobei Konfigurationen mit m y nicht zwingend m x 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 Klimatisierung Klimamaßnahme HV-Batterie Bezugsobjekt Merkmalgruppe Sitzheizung Panelheizung 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 Kin- 2421

6 der, Merkmalausprägungen, enthalten die eigentlichen variablen Anteile und können entweder alternative oder oder-gruppen beschreiben 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 Anforderungenr k. Anforderungen, r k Merkmalmapping Klimatisierung HV-Batterie r 1 (Sitzheizung), (Sitzkühlung) (HV Groß), (HV Klein) r 2 (Kein HV) r 3 (Sitzkühlung) r 4 (Panelheizung) (HV Groß) r 5 (Sitzheizung), (Sitzkühlung) (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 r 5 in Tabelle 1 bedeutet dies, dass die Anforderung für: [(Sitzheizung) ODER (Sitzkühlung)] UND (HV Klein) gilt. r 5 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

7 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 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 c i, welche in Tabelle 2 dargestellt sind. Für jedes Merkmalm j, 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 KonfigurationF cov (c i ) gilt somit: { 1 falls m j F cov (c i ) cov(c i,m j ) = 0 sonst. c i cov(c i,m 1) (m 1=SH) cov(c i,m 2) (m 2=PH) cov(c i, m 3) (m 3=SK) cov(c i,m 4) (m 4=HVgr) cov(c i,m 5) (m 5=HVkl) cov(c i,m 6) (m 6=kHV) F cov(c i) c c c c c c c c Tabelle 2: Konfigurationsbildung c i gemäß der DOORS-Struktur sowie die Abbildung wie viele Merkmale von jeweils einer Konfiguration abgedeckt werden F cov(c i). 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 c 2 der Fall, in der das Merkmal (SK) enthalten sein kann oder nicht. Ein c i 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 c 2 das Merkmal (PH) nicht enthalten, da dies von (HVkl) ausgeschlossen ist. (PH) erhält somit in c 2 den Eintrag 0. In der letzten Spalte ist mit F cov (c i ) zusammengefasst, wie viele Merkmale eine Konfiguration jeweils abdeckt. 2423

8 Des Weiteren wird für jedesc i bestimmt, welche AnforderungenR cov (c i ) es abdeckt. Dies ist in Tabelle 3 dargestellt, wobei gilt: { 1 falls r k R cov (c i ) cov(c i,r k ) = 0 sonst. So ist die Anforderung r 1 bspw. für c 1, c 2, c 6 und c 7 gültig. In der letzten Spalte der Tabelle 3 ist die Kardinalität der Menge R cov (c i ) dargestellt, welche die Anzahl der von der jeweiligen Konfiguration, abgedeckten Anforderungen kennzeichnet. Ausgehend von der vorgestellten Basis erfolgt die Selektion der zu testenden Konfigurationen. c i cov(c i, r 1) cov(c i, r 2) cov(c i, r 3) cov(c i, r 4) cov(c i, r 5) R cov(c i) c c c c c c c c Tabelle 3: Abbildung welche Konfigurationen für welche Anforderungen gelten cov(c i, r i) sowie wie viele Anforderungen von jeweils einer Konfiguration abgedeckt werden R cov(c i) 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 c i 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

9 vorliegende Problem durch eine hohe Anforderungsabdeckung gegeben und lässt sich anhand von R cov (c i ) bestimmen. Im Beispiel deckt c 7 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 c i abgedeckt werden. Diese Bedingung wird von r 4 erfüllt, denn diesem ist ausschließlich c 4 zugeordnet (hellgrau hervorgehoben in Tabelle 3). c 4 muss in jedem Fall selektiert werden, wenn eine 100%ige Anforderungsabdeckung erreicht werden soll. Dac 4 außerr 4 weitere Anforderungen abdecken könnte, ist es sinnvoll, solchec i 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 r min in der Anforderungsliste ReqsToCover gesucht, welche durch exakt eine Konfiguration abgedeckt werden. Alle Konfigurationen, welche diese Bedingung C cov (r min ) = 1 erfüllen, werden als C sel gespeichert und der Menge der selektierten Konfigurationen SubsetConfigs hinzugefügt. Zusätzlich werden die beiden Listen der Anforderungen und Merkmale aktualisiert, indem die bereits durchc sel abgedeckten Elemente entfernt werden. Algorithmus 1 Greedy Configuration Selection function GREEDYCONFIGSELECTION(ReqsToCover, FeatsToCover, Configs) SubsetConfigs Phase 1: Initialisierung R min = {r min ReqsToCover C cov (r min ) = 1} C sel C cov (r min ) r min R min ReqsToCover ReqsToCover \ R cov (c) c C sel FeatsToCover FeatsToCover\ F cov (c) c C sel SubsetConfigs SubsetConfigs C sel Phase 2: Greedy-Algorithmus while ReqsToCover > 0 OR FeatsToCover > 0 do C max = {c max Configs d Configs( R cov (c max ) R cov (d) )} if C max = 1 then c sel c max C max else C fmax = {c fmax C max d C max ( F cov (c fmax ) F cov (d) )} c sel RandomSelect(c r C fmax ) end if ReqsToCover ReqsToCover \R cov (c sel ) FeatsToCover FeatsToCover \F cov (c sel ) SubsetConfigs SubsetConfigs c sel end while return SubsetConfigs end function 2425

10 In der darauf folgenden Phase des Greedy-Algorithmus wird nach Konfigurationen C max 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 MerkmalabdeckungC fmax gesucht. Bei mehreren Kandidaten wird von diesen zufällig eine c r ausgewählt und als c sel gespeichert. Schließlich wird geprüft, welche Anforderungen und Merkmale c sel abdeckt und die Liste der ReqsToCover sowie der FeatsToCover aktualisiert. Zuletzt wirdc sel der Menge aller selektierten Konfigurationen SubsetConfigs hinzugefügt. Wie bereits in Kapitel beschrieben, gibt es Konfigurationen c i mit leeren Merkmaleinträgen. D.h. für eine vollständige Konfiguration c v,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 denc v,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 Ergebnis Für das Beispielsystem Klimatisierung (Merkmalmodell siehe Abbildung 2, Anforderungsspezifikation siehe Tabelle 1) wählt der Algorithmus drei Konfigurationen aus, nämlich c 4,c 7 undc 3. Im ersten Schritt wirdc 4 ausgewählt, da Anforderungr 4 ausschließlich von c 4 abgedeckt wird und dieses somit die Bedingung C cov (r min ) = 1 erfüllt. Im zweiten Schritt selektiert der Greedy-Algorithmus c 7, da R cov (c 7 ) maximal ist bezüglich der noch nicht abgedeckten Anforderungen. Schließlich bleibt im dritten Schritt nochr 2 übrig, wofür c 3, c 5 und c 8 gleichermaßen in Frage kommen. Da alle drei Kandidaten zur Abdeckung des verbliebenen Merkmals m 6 beitragen würden, wird zufällig eins ausgewählt, beispielsweise c 3. 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 r min C max C fmax ReqsToCover FeatsToCover c sel Initialisierung r 4 r 1, r 2, r 3, r 4, r 5 m 1, m 2, m 3, m 4, m 5, m 6 c 4 Greedy 1 c 7 r 1, r 2, r 3, r 5 m 1, m 3, m 5, m 6 c 7 Greedy 2 c 3, c 5, c 8 c 3, c 5, c 8 r 2 m 6 c 3 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

11 10 6 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 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 Greedy- 2427

12 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 angedeutet, sondern zugunsten der Pairwise- Abdeckung von Merkmalen zu treffen. Literatur [BKPS04] Günter Böckle, Peter Knauber, Klaus Pohl und Klaus Schmid, Hrsg. Software- Produktlinien: Methoden, Einführung und Praxis. Dpunkt Verlag, [BLKK09] [Bur10] [CNHR12] [Coh04] 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, Florian Burgdorf. Eine kunden- und lebenszyklusorientierte Produktfamilienabsicherung für die Automobilindustrie. Dissertation, Karlsruher Institut für Technologie, 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, Myra B. Cohen. Designing test suites for software interaction testing. Dissertation, The University of Auckland, [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, [DOO] IBM Rational DOORS. awdtools/doors/. [ER11] [Gri95] Emelie Engström und Per Runeson. Software product line testing - A systematic mapping study. Information and Software Technology, 53:2 13, Klaus Grimm. Systematisches Testen von Software - Eine neue Methode und eine effektive Teststrategie. Dissertation, Technische Universität Berlin, [ISO11] ISO Road verhicles - Functional safety, [Jaa02] Ari Jaaksi. Developing Mobile Browsers in a Product Line. IEEE Software, 19:73 80, [JhQJ08] [Kol03] [KWG04] 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, Ronny Kolb. A Risk-Driven Approach for Efficiently Testing Software Product Lines. In Proceedings of the 5th GPCE Young Researches Workshop, 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: ,

13 [LLS + 12] Sascha Lity, Malte Lochau, Ina Schaefer, und Ursula Goltz. Delta-Oriented Model- Based SPL Regression Testing. In Proceedings of the 3rd International Workshop on Product Line Approaches In Software Engineering (PLEASE), [Man11] Oliver Manicke. Durchgängiges Variantenmanagement zur Komplexitätsbeherrschung im Entwicklungsprozess mechatronischer Fahrzeugfunktionen. Dissertation, Technische Universität Dresden, [McG01] [McG08] [MD08] [NCRMG11] [OMSM09] [Ost11] [pur] [RKPR05] [Sch06] [Sch07] [Sch12] [TTK04] [ZZR04] John McGregor. Testing a Software Product Line. Bericht, Software Engineering Institute, John McGregor. Toward a fault model for software product lines. In Proceedings of the 5th Software Product Line Testing Workshop (SPLiT), 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, 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, 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, Sebastian Oster. Feature Model-based Software Product Line Testing. Dissertation, Technische Universität Darmstadt, pure::variants. 0.html. 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), 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, Kathrin D. Scheidemann. Verifying Families of System Configurations. Dissertation, Technische Universität München, 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, Antti Tevanlinna, Juha Taina und Raine Kauppinen. Product family testing - a Survey. SIGSOFT Software Engineering Notes, 29:1 12, 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),