27.11.2012 Aufrufe

Softwarezuverlässigkeitsbewertung auf Basis von ...

Softwarezuverlässigkeitsbewertung auf Basis von ...

Softwarezuverlässigkeitsbewertung auf Basis von ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

<strong>Softwarezuverlässigkeitsbewertung</strong> <strong>auf</strong> <strong>Basis</strong> <strong>von</strong> Betriebsprofiltreue<br />

und Schnittstellenüberdeckung<br />

Matthias Meitner, Francesca Saglietti<br />

Lehrstuhl für Software Engineering, Universität Erlangen-Nürnberg<br />

{matthias.meitner, saglietti}@informatik.uni-erlangen.de<br />

Zusammenfassung<br />

Dieser Artikel stellt einen neuen Ansatz zur <strong>Softwarezuverlässigkeitsbewertung</strong> vor, der über die Betriebstreue der auszuwertenden<br />

Testfälle hinaus auch eine hohe Überdeckung der Komponentenschnittstellen sicherstellt. Der Erfüllungsgrad<br />

der zugrunde liegenden Bedingungen hinsichtlich Profiltreue, Testdatenunabhängigkeit und Interaktionsüberdeckung<br />

wird durch geeignete Metriken erfasst und mittels genetischer Algorithmen multi-kriteriell optimiert. Insgesamt<br />

unterstützt das entwickelte Verfahren die automatische Generierung einer Testfallmenge, <strong>auf</strong> deren <strong>Basis</strong> eine konservative<br />

Softwarezuverlässigkeitsaussage bei gleichzeitiger Überdeckung der Komponenteninteraktionen ermöglicht<br />

wird.<br />

Schlüsselwörter: Software, Zuverlässigkeit, Schnittstellenüberdeckung, statistische Stichprobentheorie, Betriebsprofil,<br />

genetische Algorithmen.<br />

1 Einleitung<br />

Durch Wiederverwendung vorgefertigter und betriebsbewährter<br />

Software-Bausteine lassen sich Entwicklungs-<br />

und Zertifizierungskosten einsparen. Dadurch gewinnen<br />

komponentenbasierte Softwaresysteme zunehmend an<br />

Bedeutung. Das strukturbetonte Bausteinprinzip erhöht<br />

Transparenz und Verständlichkeit komplexer Entwürfe;<br />

gleichzeitig erfordert es allerdings den Einsatz neuer Verfahren<br />

zur Überprüfung der Komponenteninteraktion.<br />

Zahlreiche Vorfälle des vergangenen Jahrzehnts weisen<br />

<strong>auf</strong> die zunehmende Gefahr fehlerhafter Schnittstellen<br />

zwischen inhärent korrekten Komponenten hin [5]. Es<br />

sind deshalb neue Lösungsansätze gefragt, die die Zuverlässigkeit<br />

aus der besonderen Perspektive des Zusammenspiels<br />

bereits einzeln getesteter Komponenten qualitativ<br />

und quantitativ zu bewerten erlauben.<br />

Dabei unterscheiden sich Verfahren zu einer quantitativen<br />

Zuverlässigkeitsbewertung (also <strong>auf</strong> der <strong>Basis</strong> statistischer<br />

Stichprobentheorie) grundlegend <strong>von</strong> Verfahren zu<br />

einer qualitativen Zuverlässigkeitsaussage (etwa durch<br />

Überdeckung der Komponentenschnittstellen im Integrationstest).<br />

Bei Ersterem handelt es sich nämlich um einen<br />

reinen Black-Box-Test, der die innere Struktur der Software<br />

nicht berücksichtigt; insbesondere kann dabei nicht<br />

garantiert werden, dass die Interaktionen zwischen Komponenten<br />

angemessen überprüft werden. Ein Integrationstest<br />

andererseits ermöglicht zwar die Erzielung unterschiedlicher<br />

Kriterien der Interaktionsüberdeckung [1, 4,<br />

9, 13, 14, 17] und unterstützt dabei die Erkennung vielfältiger<br />

Schnittstellenfehler. Da die dabei generierten Test-<br />

fälle i. Allg. keinen Bezug zum erwarteten Betriebsprofil<br />

<strong>auf</strong>weisen, erlaubt der Integrationstest allerdings keine<br />

quantitative Zuverlässigkeitsaussage, wie sie bei sicherheitskritischen<br />

Systemen angestrebt wird.<br />

Der in diesem Artikel vorgeschlagene Ansatz kombiniert<br />

die beiden Testarten, indem sowohl die Einhaltung<br />

der Voraussetzungen zur Anwendung der statistischen<br />

Stichprobentheorie als auch die Erzielung vorgegebener<br />

Schnittstellenüberdeckungsmaße zeitgleich verfolgt werden.<br />

Dadurch ist einerseits eine fundierte quantitative Zuverlässigkeitsbewertung<br />

herleitbar, die andererseits <strong>auf</strong><br />

einem möglichst breiten Spektrum an Interaktionen basiert.<br />

Der Artikel ist wie folgt <strong>auf</strong>gebaut:<br />

• in Abschnitt 2 werden die Grundlagen der statistischen<br />

Stichprobentheorie erläutert;<br />

• Abschnitt 3 behandelt die einzelnen Teilziele, die<br />

zeitgleich verfolgt werden;<br />

• Abschnitt 4 stellt den neuartigen Ansatz zur Kombination<br />

der einzelnen Teilziele mit Hilfe genetischer<br />

Algorithmen vor;<br />

• in Abschnitt 5 werden die Erkenntnisse zusammengefasst.<br />

2 Statistische Stichprobentheorie<br />

Mit der statistischen Stichprobentheorie steht ein fundierter<br />

Ansatz zur Herleitung einer quantitativen Zuverlässigkeitsaussage<br />

zur Verfügung [3, 7, 10, 11]. Da der Aufwand<br />

zur Anwendung dieser Theorie beträchtlich sein


kann, wurde in [15, 16] illustriert, wie sich dieser durch<br />

Nutzung <strong>von</strong> Betriebserfahrung wesentlich reduzieren<br />

lässt. Für die Anwendbarkeit der statistischen Stichprobentheorie<br />

müssen allerdings einige Bedingungen nachweisbar<br />

erfüllt sein.<br />

Die folgenden Voraussetzungen betreffen allgemeine<br />

Anforderungen an den Test:<br />

• Unabhängige Ausführung der Testfälle (notfalls<br />

durch reset - Mechanismen erzielbar);<br />

• Erkennung aller Versagen (domänenspezifische<br />

Herausforderung);<br />

• Kein Versagens<strong>auf</strong>treten (prinzipiell auch <strong>auf</strong> wenige<br />

Versagen erweiterbar, natürlich <strong>auf</strong> Kosten entsprechend<br />

geringerer Zuverlässigkeitsschätzwerte).<br />

Die Voraussetzungen für die Auswahl der Testdaten<br />

betreffen:<br />

• Betriebsprofiltreue (Auswahl der Testfälle wie im<br />

Betrieb zu erwarten);<br />

• Unabhängige Auswahl der Testfälle (ein Testfall<br />

beeinflusst nicht die Auswahl weiterer).<br />

Daraus lässt sich zu jeder beliebigen Aussagesicherheit<br />

β anhand einer Anzahl n (n > 100) an erfolgreich ausgeführten<br />

Testfällen eine obere Schranke p ~ der tatsächlichen<br />

Versagenswahrscheinlichkeit p herleiten [3, 18]:<br />

~<br />

p = 1 −<br />

n 1<br />

− β<br />

Die oben eingeführte Aussagesicherheit β ist als Komplement<br />

der Irrtumswahrscheinlichkeit α = 1 - β zu verstehen,<br />

die ein Hypothesentest mit Nullhypothese<br />

H : p<br />

~<br />

0 ≤ p nicht überschreiten darf.<br />

3 Testfallgenerierung mittels multiobjektiver<br />

Optimierung<br />

Da sich der Ansatz in diesem Artikel mit der Erstellung<br />

adäquater Testfälle beschäftigt, werden im Weiteren nur<br />

die Voraussetzungen betrachtet, die die Auswahl der<br />

Testdaten selbst betreffen. Die Einhaltung der allgemeinen<br />

Voraussetzungen zur Anwendung der statistischen<br />

Stichprobentheorie ist im Falle der unabhängigen Ausführung<br />

durch reset - Mechanismen und in den anderen Fällen<br />

durch Domänen-Experten oder Software-Entwickler<br />

zu gewährleisten. Es werden prinzipiell zwei Arten <strong>von</strong><br />

Abhängigkeiten unterschieden:<br />

Zum einen können semantische Abhängigkeiten zwischen<br />

Eingabeparametern existieren, die durch die Anwendung<br />

vorgegeben werden, etwa Korrelationen der<br />

Eingabedaten infolge physikalischer Gesetze oder logischer<br />

Muster. Diese inhärenten Abhängigkeiten müssen<br />

bei der Erstellung des Betriebsprofils berücksichtigt werden<br />

(siehe Abschnitt 3.1).<br />

Zum anderen können zufallsbedingte Abhängigkeiten<br />

bei der Instantiierung der Parameter <strong>auf</strong>treten. Diese sind<br />

zu vermeiden bzw. herauszufiltern (siehe Abschnitt 3.2).<br />

3.1 Ziel 1: Betriebsprofiltreue<br />

Es wird vorausgesetzt, dass eine akzeptable Schätzung<br />

des zu erwartenden Betriebsprofils mittels der Verteilungsfunktionen<br />

der Eingabeparameter unter Berücksichtigung<br />

anwendungsspezifischer funktionaler Abhängigkeiten<br />

vorliegt.<br />

Zur Messung der Betriebsprofiltreue generierter Testfälle<br />

stehen verschiedene Goodness-of-Fit-Tests wie der<br />

χ 2 -Test [6], der Kolmogorow-Smirnow-Test [6] oder der<br />

Anderson-Darling-Test [6] zur Verfügung. Dabei wird<br />

zunächst folgende Nullhypothese formuliert:<br />

H0: Die beobachtete Datenverteilung stimmt mit der erwarteten<br />

Verteilung überein.<br />

Die Gültigkeit dieser Aussage wird mittels eines Signifikanztests<br />

überprüft. Dabei wird zu vorgegebenem Signifikanzniveau<br />

α der kritische Wert zur Annahme oder Ablehnung<br />

der Nullhypothese ermittelt. Ist der Wert der dem<br />

entsprechenden Goodness-of-Fit-Test zugrunde liegenden<br />

Teststatistik höher als der kritische Wert, so ist die Nullhypothese<br />

zum Signifikanzniveau α abzulehnen; liegt er<br />

unterhalb des kritischen Werts, so können die beobachteten<br />

Daten als ausreichend betrieblich repräsentativ angesehen<br />

werden. Abbildung 1 zeigt ein Beispiel für die Verteilungsanpassung<br />

einer Menge <strong>von</strong> Werten an eine Weibull-Verteilung.<br />

Abbildung 1: Beispiel für Verteilungsanpassung<br />

3.2 Ziel 2: Unabhängigkeit der Testfallauswahl<br />

Um die unabhängige Auswahl der Testfälle sicherzustellen,<br />

dürfen die Werte der zuvor als unabhängig eingestuften<br />

Eingabeparameter keine Korrelationen <strong>auf</strong>weisen.<br />

Zum Zwecke der Überprüfung unterscheidet man zwischen<br />

den beiden folgenden Korrelationsarten:


• die Autokorrelation misst den Einfluss eines Parameters<br />

innerhalb eines Testfalls <strong>auf</strong> denselben Parameter<br />

in weiteren Testfällen. In diesem Zusammenhang<br />

stellt der sog. Lag den Abstand zwischen<br />

den zu bewertenden Testfällen dar; ein Autokorrelationsmaß<br />

mit Lag 1 bezieht sich also <strong>auf</strong> die Abhängigkeit<br />

direkt <strong>auf</strong>einanderfolgender Testfälle;<br />

• die Kreuzkorrelation misst den Einfluss eines Parameters<br />

<strong>auf</strong> die weiteren Parameter innerhalb desselben<br />

Testfalls.<br />

Zur Messung der Korrelationen existieren wiederum<br />

verschiedene Metriken, die sich im Hinblick <strong>auf</strong> ihren Berechnungs<strong>auf</strong>wand<br />

und ihre Eignung zur Erfassung unterschiedlicher<br />

Arten <strong>von</strong> Abhängigkeiten bzw. Parameterverteilungen<br />

unterscheiden, darunter etwa der Korrelationskoeffizient<br />

nach Pearson [2], Spearmans Rangkorrelationskoeffizient<br />

oder Cramers V [19].<br />

3.3 Ziel 3: Hohe Überdeckung<br />

der Komponenteninteraktionen<br />

Neben den klassischen Testverfahren zur datenflussbasierten<br />

Programmüberdeckung [12] existieren weitere<br />

Ansätze, die vor allem <strong>auf</strong> die Überdeckung der Interaktionen<br />

verschiedener Komponenten zielen. Während die<br />

klassischen Verfahren für monolithische Systeme bis zu<br />

einer gewissen Größe geeignet sind, wären sie für bereits<br />

getestete bzw. betriebsbewährte Softwarekomponenten zu<br />

<strong>auf</strong>wändig. Bereits bestehende Testkriterien zur Schnittstellenüberdeckung<br />

übertragen deswegen die Konzepte<br />

des datenflussbasierten Testens <strong>auf</strong> die Integrationsebene.<br />

Die Funktionsweise dieser kopplungsbasierten Testkriterien<br />

soll im Folgenden kurz erläutert werden. Beim kopplungsbasierten<br />

Testen prozeduraler Programme nach [4]<br />

werden drei verschiedene Kopplungsarten unterschieden:<br />

• Aufruf einer Methode mit Parameterübergabe;<br />

• gemeinsame Benutzung globaler Variablen;<br />

• gemeinsame Benutzung eines externen Speichermediums.<br />

Dabei wird da<strong>von</strong> ausgegangen, dass <strong>von</strong> der Definition<br />

einer Variablen in der <strong>auf</strong>rufenden Komponente (caller)<br />

bis zum Aufrufpunkt (call site) und <strong>von</strong> der <strong>auf</strong>gerufenen<br />

Komponente (callee) zur Verwendung derselben<br />

Variable ein definitionsfreier Pfad bezüglich dieser Variablen<br />

existiert. Ein coupling-def bezeichnet einen Knoten,<br />

in dem eine Variable definiert wird. In [4] werden drei<br />

Arten <strong>von</strong> coupling-def unterschieden:<br />

• last-def-before-call: letzte Definition einer Variablen<br />

vor einem Methoden<strong>auf</strong>ruf;<br />

• last-def-before-return: letzte Variablendefinition<br />

vor dem Rückgabebefehl einer Methode;<br />

• shared-data-def: Definition einer globalen Variablen.<br />

Analog dazu bezeichnet ein coupling-use einen Knoten,<br />

in dem eine zuvor definierte Variable verwendet<br />

wird. Es werden drei Arten <strong>von</strong> coupling-use unterschieden:<br />

• first-use-after-call: erste Verwendung einer Variablen<br />

nach Ausführung der Methode;<br />

• first-use-in-callee: erste Verwendung einer Variablen<br />

in der <strong>auf</strong>gerufenen Methode;<br />

• shared-data-use: Verwendung einer globalen Variablen.<br />

Als Kopplungspfad (coupling path) wird ein definitionsfreier<br />

Pfad <strong>von</strong> einem coupling-def zu einem<br />

coupling-use derselben Variablen bezeichnet. Basierend<br />

<strong>auf</strong> diesen Definitionen wurde eine Kriterienhierarchie<br />

erstellt [4]:<br />

• call coupling: Überdeckung aller Aufrufpunkte mit<br />

Parameterübergabe;<br />

• all-coupling-defs: für jede Variable mindestens ein<br />

Kopplungspfad <strong>von</strong> jedem coupling-def zu mindestens<br />

einem coupling-use;<br />

• all-coupling-uses: für jede Variable mindestens ein<br />

Kopplungspfad <strong>von</strong> jedem coupling-def zu jedem<br />

erreichbaren coupling-use;<br />

• all-coupling-paths: für jede Variable alle Kopplungspfade<br />

<strong>von</strong> jedem coupling-def zu jedem erreichbaren<br />

coupling-use. Da diese Definition für<br />

Schleifen unter Umständen eine unbeschränkte Anzahl<br />

an Testfällen erfordern würde, wurde sie in [4]<br />

<strong>auf</strong> Ausführungen reduziert, die den Schleifenrumpf<br />

umgehen bzw. ihn mindestens einmal durchl<strong>auf</strong>en.<br />

Die oben definierten Kriterien berücksichtigen allerdings<br />

nicht den Fall, dass zwei Komponenten in einer<br />

Aufrufbeziehung zueinander stehen, dabei aber keine Parameter<br />

übergeben werden. Ein Beispiel hierfür ist die in<br />

Abbildung 2 dargestellte Aufzugsteuerung:<br />

Abbildung 2: Beispiel Aufzugsteuerung


• bei einem Aufruf des Fahrbefehls an die Aufzugskabine<br />

wird ein Parameter mit dem gewünschten<br />

Zielstockwerk übergeben und damit <strong>von</strong> den kopplungsbasierten<br />

Überdeckungskriterien erfasst;<br />

• wird hingegen in der Kontrollkomponente ein Befehl<br />

zum Schließen an die Türen einer Aufzugskabine<br />

gesendet, so hängt die erfolgreiche Ausführung<br />

aber lediglich <strong>von</strong> den Sensoren der <strong>auf</strong>gerufenen<br />

Aufzugskabine und nicht <strong>von</strong> einer Parameterübergabe<br />

ab.<br />

Diese Art der Abhängigkeit würde durch die oben genannten<br />

datenkopplungsbasierten Testkriterien nicht erfasst.<br />

Dadurch könnten beim Integrationstest Anwendungsfälle<br />

außer Acht gelassen werden, die zu einem<br />

Versagen des Systems führen könnten. Dementsprechend<br />

wurde der Ansatz aus [4] erweitert, indem beim Integrationstest<br />

die Überdeckung aller Aufrufpunkte zwischen<br />

zwei Komponenten gefordert wird.<br />

Mit der Entwicklung des objekt-orientierten Paradigmas<br />

verschiebt sich die Komplexität noch weiter <strong>von</strong> der<br />

intra-modularen Ebene <strong>auf</strong> die Interaktion zwischen<br />

Komponenten. Insbesondere werden objekt-orientierte<br />

Mechanismen wie Vererbung, Polymorphie und dynamisches<br />

Binden durch die kopplungsbasierten Kriterien aus<br />

[4] nicht erfasst. Deswegen wurde in [1] ein weiteres<br />

Konzept entwickelt, um die Anwendbarkeit kopplungsbasierter<br />

Testkriterien <strong>auf</strong> objekt-orientierte Programme zu<br />

erweitern. Es ist geplant, bei der Weiterentwicklung des<br />

beschriebenen Ansatzes auch diese Kopplungseigenschaften<br />

zu berücksichtigen [8].<br />

4 Kombination der Teilziele<br />

Der neu entwickelte Ansatz kombiniert die drei genannten<br />

Ziele:<br />

• Ziel 1: Betriebsprofiltreue;<br />

• Ziel 2: Unabhängigkeit der Testfallauswahl;<br />

• Ziel 3: Interaktionsüberdeckung.<br />

Da das entscheidende Anliegen die Herleitung einer<br />

quantitativen Zuverlässigkeitsaussage ist, dominieren die<br />

Voraussetzungen zur Anwendung der statistischen Stichprobentheorie.<br />

Ziel 1 und Ziel 2 sind also K.O.-Kriterien,<br />

die über Ziel 3 dominieren; angestrebt wird eine Maximierung<br />

<strong>von</strong> Ziel 3, ohne Ziel 1 bzw. Ziel 2 zu verletzen.<br />

Infolge der hohen Komplexität dieser Problemklasse stoßen<br />

systematische Verfahren schnell an ihre Grenzen. Es<br />

bietet sich an, den Einsatz heuristischer Verfahren zur<br />

multi-objektiven Optimierung mittels genetischer Algorithmen<br />

in Betracht zu ziehen. Entscheidend ist dabei die<br />

Definition einer adäquaten Fitnessfunktion zur Bewertung<br />

der Eignung generierter Testfallmengen.<br />

Um den Erfüllungsgrad <strong>von</strong> Ziel 1 und Ziel 2 zu<br />

bestimmen, werden die für die genannten Korrelationsmetriken<br />

bzw. Goodness-of-Fit-Tests ermittelten Werte<br />

<strong>auf</strong> das Intervall [0;1] normiert, wobei<br />

• der Wert 1 die Erfüllung des Kriteriums,<br />

• der Wert 0 die größtmögliche Verletzung des Kriteriums<br />

wiedergibt;<br />

• dazwischen liegende Werte den relativen Erfüllungsgrad<br />

reflektieren.<br />

Bezeichnet man mit to den maximalen, noch akzeptablen<br />

Grenzwert für die Korrelation bzw. für die Verletzung<br />

der Betriebstreue, so entsprechen<br />

• alle Werte aus [0; to] der Erfüllung des Kriteriums;<br />

• alle Werte aus ]to; max] einer Verletzung des Kriteriums,<br />

wobei max den jeweils maximal möglichen<br />

Verletzungsgrad bezeichnet.<br />

Abbildung 3 zeigt eine generische, sowohl <strong>auf</strong> die Korrelation<br />

als auch <strong>auf</strong> die Verletzung der Betriebsprofiltreue<br />

anwendbare Normierungsfunktion.<br />

Abbildung 3: Normierungsfunktion für<br />

Korrelation bzw. Verletzung der Betriebsprofiltreue<br />

Die Fitnessfunktion wird als gewichtete Summe normierter<br />

Ziele (bez. durch #) definiert:<br />

Fitnesswert = 1,0 * # Betriebsprofiltreue +<br />

1,0 * # Unabhängigkeit +<br />

0,1 * # Überdeckung<br />

Die Gewichte sind dabei so gewählt, dass selbst eine<br />

maximale Erfüllung <strong>von</strong> Ziel 3 die Verletzung eines der<br />

beiden Ausschlusskriterien Ziel 1 bzw. Ziel 2 nicht kompensieren<br />

kann:<br />

• eine Testfallmenge, die beide Ausschlusskriterien<br />

einhält (Fitnesswert ≥ 2,0) wird immer höher bewertet<br />

als<br />

• eine Testfallmenge, die mindestens ein Ausschlusskriterium<br />

verletzt (Fitnesswert < 2,0), unabhängig<br />

<strong>von</strong> der erzielbaren Maximierung des dritten Kriteriums.


5 Zusammenfassung<br />

In diesem Artikel wurde ein Ansatz zur Bewertung der<br />

Softwarezuverlässigkeit bei gleichzeitig möglichst hoher<br />

Überdeckung der Komponenteninteraktionen vorgestellt.<br />

Die Testfallmenge wird dabei mit Hilfe genetischer Algorithmen<br />

generiert. Zu diesem Zweck wurde eine passende<br />

Fitnessfunktion definiert, die die Erfüllung der vorgestellten<br />

Ziele zu erfassen erlaubt. Durch die Wahl dieser Fitnessfunktion<br />

kann der genetische Algorithmus eine Testfallmenge<br />

erstellen, die sowohl die Ableitung einer Zuverlässigkeitsaussage<br />

ermöglicht, als auch eine hohe Interaktionsüberdeckung<br />

erreicht.<br />

Danksagung. Der beschriebene Ansatz ist im Rahmen<br />

einer Kooperation mit der Firma Siemens Corporate<br />

Technology entstanden, für deren finanzielle Unterstützung<br />

wir uns bedanken.<br />

6 Literaturverzeichnis<br />

[1] Alexander, R. T., Offutt A. J.: Coupling-based Testing<br />

of O-O Programs, Journal of Universal Computer<br />

Science, vol. 10(4), 2004<br />

[2] Hartung, J.: Statistik, Oldenbourg, 1995<br />

[3] Ehrenberger, W.: Software-Verifikation, Hanser<br />

Verlag, 2002<br />

[4] Jin, Z., Offutt A. J.: Coupling-based Criteria for Integration<br />

Testing, Software Testing, Verification &<br />

Reliability 8(3), 133-154, 1998<br />

[5] Jung, M., Saglietti, F.: Supporting Component and<br />

Architectural Re-usage by Detection and Tolerance<br />

of Integration Faults, 9th IEEE International Symposium<br />

on High Assurance Systems Engineering<br />

(HASE '05), IEEE Computer Society, 2005<br />

[6] Law, A. M., Kelton, W. D.: Simulation, Modeling<br />

and Analysis, McGraw-Hill, 2000<br />

[7] Littlewood, B., Wright, D.: Stopping Rules for Operational<br />

Testing of Safety Critical Software, 25th<br />

International Symposium Fault Tolerant Computing<br />

(FCTS 25), 1995<br />

[8] Meitner, M., Saglietti, F.: Software Reliability Assessment<br />

based on Operational Representativeness<br />

and Interaction Coverage, Workshop Proceedings of<br />

the 24th International Conference on Architecture of<br />

Computing Systems (ARCS 2011), VDE, 2011<br />

[9] Oster, N., Saglietti, F.: Automatic Test Data Generation<br />

by Multi-Objective Optimisation, Computer<br />

Safety, Reliability and Security, Lecture Notes in<br />

Computer Science, Vol. LNCS 4166, Springer-<br />

Verlag, 2006<br />

[10] Parnas, D., van Schouwen, J., Kwan, S.: Evaluation<br />

of Safety-critical Software, Communications of the<br />

ACM, 33(6), 1990<br />

[11] Quirk, W. J. (ed.): Verification and Validation of<br />

Real-time Software, Springer-Verlag, 1985<br />

[12] Rapps, S., Weyuker, E. J.: Data Flow Analysis<br />

Techniques for Test Data Selection, 6th International<br />

Conference on Software Engineering (ICSE ’82),<br />

1982<br />

[13] Rehman, M., Jabeen, F., Bertolino, A., Polini, A.:<br />

Software Component Integration Testing: A Survey,<br />

Journal of Software Testing, Verification, and Reliability<br />

(STVR), 2006<br />

[14] Saglietti, F., Oster, N., Pinte, F.: Interface Coverage<br />

Criteria Supporting Model-Based Integration Testing,<br />

Workshop Proceedings of the 20th International<br />

Conference on Architecture of Computing Systems<br />

(ARCS 2007), VDE, 2007<br />

[15] Söhnlein, S., Saglietti, F., Bitzer, F., Meitner, M.,<br />

Baryschew, S.: Software Reliability Assessment<br />

based on the Evaluation of Operational Experience,<br />

Measurement, Modelling, and Evaluation of Computing<br />

Systems - Dependability and Fault Tolerance,<br />

Lecture Notes in Computer Science, Vol. LNCS<br />

5987, Springer-Verlag, 2010<br />

[16] Söhnlein, S., Saglietti, F., Meitner, M., Bitzer, F.:<br />

Bewertung der Zuverlässigkeit <strong>von</strong> Software, Automatisierungstechnische<br />

Praxis, 52. Jahrgang, 6/2010,<br />

32-39, Oldenbourg Industrieverlag, 2010<br />

[17] Spillner, A.: Test Criteria and Coverage Measures<br />

for Software Integration Testing, Software Quality<br />

Journal 4, 275-286, 1995<br />

[18] Störmer, H.: Mathematische Theorie der Zuverlässigkeit,<br />

R. Oldenbourg, 1970<br />

[19] Storm, R.: Wahrscheinlichkeitsrechnung, mathematische<br />

Statistik und Qualitätskontrolle, Hanser Verlag,<br />

2007

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!