Softwarezuverlässigkeitsbewertung auf Basis von ...
Softwarezuverlässigkeitsbewertung auf Basis von ...
Softwarezuverlässigkeitsbewertung auf Basis von ...
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