s

Validation: Überprüfung auf das vom Anwender gewünschte Verhalten (wurde das richtige System gebaut?). Verifikation: Werden die festgelegten Spezifikationen erfüllt (wurde das System richtig gebaut?).

1. Eine Version kann als Orakel für die Korrektheit der Ausgabe einer anderen dienen. 2. Erhöhung der Robustheit durch gleichzeitige Berechnung und Mehrheitsentscheidung (Voter).

Ein Prädikat oder Mechanismus, der vergleicht, ob die durch einen Testfall berechneten Ergebnisse des Testobjekts den erwarteten Werten entsprechen.

Komponententest, Subsystemtest, Integrationstest, Systemtest, Akzeptanztest.

Ein Fehler/Mangel ist seit dem Zeitpunkt der Entwicklung in der Software vorhanden. Software nützt sich nicht ab.

Ein stark formalisiertes Verfahren zur Durchsicht von Dokumenten durch ein Gutachterteam (inklusive Moderator), um Befunde zu identifizieren und Statistiken zur Prozessverbesserung zu erzeugen.

Eine weniger formale manuelle Prüfmethode als die Inspektion. Es gibt keinen formalen Inspektionsplan und Prozessverbesserung/Statistiken stehen nicht im Vordergrund.

Eine unstrukturierte Vorgehensweise, bei der der Autor des Dokuments vorliest und Gutachter ohne weitere Vorbereitung spontan Fragen stellen und Fehler suchen.

Vorgesetzte des Autors bzw. Manager.

Lösungen für entdeckte Fehler zu finden, die Fähigkeiten des Autors zu beurteilen oder ewig zu diskutieren, ob etwas ein Fehler ist.

Moderator, Autor (passiv), Gutachter(n), Protokollführer und ggf. Vorleser.

Der Prüfaufwand liegt bei 15-20% des Erstellungsaufwands, findet 60-70% der Fehler und bringt ca. 20% Ersparnis bei der Entwicklung und 30% bei der Wartung.

Beim dynamischen Testen wird das Testobjekt mit konkreten Eingabewerten ausgeführt. Statische Analysen untersuchen den Prüfling ohne ihn auszuführen.

Eine Metrik, die Eigenschaften der erzeugten Software misst, z.B. Qualität (Anzahl Fehler) oder Einhaltung von Standards.

Eine Metrik, die Eigenschaften des Entwicklungsprozesses misst, z.B. Dauer, Kosten (Mitarbeitermonate) oder Kundenzufriedenheit.

Einfachheit, Eignung (Validität), Stabilität, Rechtzeitigkeit und Reproduzierbarkeit.

Eine frei gewählte Menge von Bezeichnungen, z.B. die eingesetzte Programmiersprache (C++, Java, Fortran).

Die Anzahl der Klassen außerhalb eines betrachteten Teilsystems, die von den Klassen innerhalb des Teilsystems abhängen.

Die Anzahl der Klassen innerhalb eines betrachteten Teilsystems, die von Klassen außerhalb des betrachteten Teilsystems abhängen.

I = Ce / (Ce + Ca). Werte liegen zwischen 0 (maximal stabil) und 1 (maximal unstabil).

Es gilt Ce = 0. Das System importiert nichts von außen (ist also maximal stabil gegenüber externen Änderungen).

Die Bindung der Methoden einer Klasse basierend auf gemeinsamen Attributzugriffen (P = Paare ohne gemeinsamen Zugriff, Q = Paare mit gemeinsamen Zugriff. LOCOM1 = P-Q, falls P>Q, sonst 0).

Die Komplexität eines abgeschlossenen Teilprogramms sollte nicht höher als 10 sein, da das Programm sonst zu komplex und zu schwer zu testen ist.

ZZ = |E| - |N| + 2k (Kantenanzahl - Knotenzahl + 2 * Anzahl der Zusammenhangskomponenten).

Eine Variable ist von ihrer ersten Definitionsstelle im Kontrollflussgraph bis zu ihrer letzten Definitions- oder Referenzierungsstelle (vor dem Endknoten) "lebendig".

Die durchschnittliche Anzahl Kanten im Kontrollflussgraph zwischen zwei direkt aufeinanderfolgenden definierenden oder referenzierenden Zugriffen auf dieselbe Variable.

Bei der Äquivalenzklassenbildung wird ein beliebiger Wert aus der Klasse getestet. Die Grenzwertanalyse betrachtet zusätzlich explizit die Grenzen der Klasse (Ränder) als eigene Testfälle.

In einem Testfall für einen Negativtest darf maximal eine Fehlerklasse (ungültiger Wert) gewählt werden. Alle anderen Parameter müssen positiv/gültig sein.

Nicht jede mögliche Wertekombination wird getestet, sondern nur so viele Testfälle erzeugt, dass jedes mögliche Paar von Parameterwerten in mindestens einem Testfall vorkommt.

Es verhindert die kombinatorische Explosion der Testfälle, bietet aber eine hohe Fehlererkennung, da ca. 80% aller Kombinationsfehler durch die Interaktion von maximal zwei Parametern verursacht werden.

In [uv] (unterer Grenzwert), ]uv .. ov[ (Mitte) und [ov] (oberer Grenzwert).

Die Schnittstelle, über die das Testobjekt mit Testdaten versorgt wird.

Die Schnittstelle, über die Reaktionen und Ausgaben des Testobjekts beobachtet und ausgewertet werden.

Eine Platzhalter-Komponente im Testrahmen, die das Verhalten von Unterkomponenten simuliert, welche das Testobjekt aufruft, um das Testobjekt isoliert testen zu können.

Ein Rahmenprogramm, das Testfälle in das Testobjekt einspeist (via PoC) und die Testausgaben einsammelt.

Als disjunkte positive Ausprägungen (z.B. {"Eiche", "Buche", "Kiefer"} mit "+") und eine Fehlerklasse "sonstige" (mit "-").

1. Parameter, 2. Wertebereiche/Typen, 3. Äquivalenzklassen (+/-), 4. Grenzwertanalyse-Zerlegung, 5. Konkrete Testwerte.

Eine grafische Darstellung eines Programms, bei der Knoten Anweisungsblöcke sind und Kanten den möglichen Kontrollfluss (z.B. Verzweigungen) abbilden.

Ein Testkriterium, bei dem eine Testmenge so gewählt wird, dass jeder Knoten (Anweisung) des Kontrollflussgraphen mindestens einmal ausgeführt wird.

Ein Testkriterium, bei dem eine Testmenge so gewählt wird, dass jede Kante (Zweig) des Kontrollflussgraphen mindestens einmal durchlaufen wird.

Jede atomare Teilbedingung einer Gesamtaussage muss unabhängig von den anderen den Wahrheitswert der Gesamtaussage determinieren (einmal auf true, einmal auf false evaluiert werden).

Teilbedingungen, die vom Compiler nicht mehr ausgewertet werden (da das Gesamtergebnis z.B. bei einem "true OR ..." schon feststeht), gelten als irrelevant und werden mit "-" markiert.

Es enthält die Menge aller Knoten im Abhängigkeitsgraphen, die den Wert der Variablen v am Knoten n direkt oder indirekt (durch Kontroll- oder Datenfluss) beeinflussen.

Es enthält die Menge aller Knoten, die von einer Änderung der Variablen v am Knoten n im weiteren Programmverlauf beeinflusst werden.

Ein Programm-Graph, der den Datenflussgraphen um Kontrollabhängigkeitskanten erweitert und Grundlage für die Berechnung von Programm-Slices ist.

Zur Fehlersuche (Isolierung relevanter Programmteile) und zur Änderungsfolgeschätzung (Vorwärts-Slice).

d = definition (schreibend), c = computational reference (lesend in Berechnung), p = predicative reference (lesend in Bedingung), u = undefine.

Unbegründete Referenzierung: Eine Variable wird auf einem Pfad gelesen (r), obwohl sie vorher nicht definiert, sondern "undefiniert" (u) war.

Doppelte Definition: Eine Variable wird definiert (d) und auf dem nachfolgenden Pfad direkt wieder überschrieben (d), ohne zwischendurch gelesen zu werden.

Definition gefolgt von Undefine: Eine Variable wird definiert (d) und verliert ihre Gültigkeit (u), ohne dass der Wert genutzt wurde.

Wenn der Pfad mit der Anomalie segmentfrei (keine Schleifen) ist und der Zustand nicht durch dazwischenliegende korrekte Zugriffe verdeckt wird.

Knoten sind Anweisungen mit Variablenzugriffen (d, c, p, u). Kanten repräsentieren den reinen Datenfluss (die Zuweisung von Werten) einer Variable von Definition zu Nutzung.

Für jede definierte Variable (d) muss mindestens ein Pfad zu irgendeinem lesenden Zugriff (c oder p) durch Testfälle abgedeckt werden.

Für jede Definition (d) müssen alle möglichen Pfade zu ALLEN referenzierenden Zugriffen (c oder p) durch Testfälle abgedeckt werden.

Nein, das ist der gewünschte Normalfall: Eine Variable wird definiert und anschließend berechnend gelesen.

Das Auflösen des Modells (z.B. parallele oder genestete Zustände) in einen vollumfänglichen "flachen Automaten".

Sie werden logisch aufgelöst, sodass explizite, getrennte Transitionen für die verschiedenen wahren Belegungen entstehen.

Ein Baum, der ausgehend vom Startzustand als Wurzel alle durch Transitionen erreichbaren Pfade des flachen Automaten darstellt.

Wenn ein Zustand erreicht wird, der auf dem aktuellen Pfad von der Wurzel aus bereits zuvor besucht wurde, oder wenn ein Endzustand erreicht wird.

Indem man jeden möglichen Pfad von der Wurzel bis zu einem Blattknoten als eigenständige Testsequenz notiert (inkl. auslösender Ereignisse und Bedingungen).

Ereignisse, die in einem bestimmten Zustand laut Spezifikation nicht auftreten dürfen oder ignoriert werden sollen. Sie müssen auf Robustheit (Negativtest) geprüft werden.

Das interne Zustandsmodell ist nicht einsehbar. Man beobachtet nur Ereignisse und Outputs und kann schwer beweisen, dass die Software intern im korrekten Zustand ist.

Eine Bedingung (Pre-/Postcondition), die immer, also vor und nach Aufruf jeder Methode (außer im Konstruktor selbst) einer Klasse, wahr sein muss.

Ja, da ein Modifier den Objektzustand ändert, muss verifiziert werden, ob die Invariante nach der Änderung weiterhin erfüllt ist.

SCCS nutzt pessimistische Sperren und Vorwärtsdeltas. RCS nutzt optionale Sperren und speichert die neueste Revision voll, ältere als schnelle Rückwärtsdeltas.

Parallele Schreibzugriffe auf eine Datei sind zulässig. Konflikte werden durch Dreiwegeverschmelzung (Merge) und manuelle Konfliktbehebung gelöst (z.B. in Git, SVN).

Ein Entwickler erhält einen exklusiven Schreibzugriff (Lock/Single Write Access), während andere nur lesen dürfen. Es verhindert Konflikte, blockiert aber paralleles Arbeiten.

Unterschiede zwischen zwei Textdateien in Form von "Deltas". Diese bestehen aus "Hunks" (geänderte, hinzugefügte "+", gelöschte "-" Zeilen).

Eine Konfiguration, die zu einem Meilenstein (z.B. Phasenende) gehört und fest eingefroren sowie evaluiert/getestet wird.

Eine stabile Baseline, die ausgeliefert wird (intern an Entwickler oder extern an Kunden).

Eine Abspaltung vom Hauptzweig, in der Fehlerkorrekturen für ältere Releases entwickelt werden, parallel zur Weiterentwicklung auf dem Hauptzweig.

Sie verschmilzt die Änderungen zweier parallel bearbeiteter Versionen, indem sie diese mit ihrem letzten gemeinsamen Vorgänger vergleicht.

Jeder Entwickler hat ein vollständiges lokales Repository (inkl. Historie), kann offline arbeiten und Commits ausführen. Synchronisation erfolgt via Push/Pull.

Eine Menge verwandter Softwaresysteme für eine spezifische Anwendungsdomäne, die auf Basis einer gemeinsamen Plattform (Rahmenwerk) entwickelt werden.

Entwicklung der gemeinsamen Plattform und Variabilitätsmodelle (Development for Reuse).

Erstellung konkreter Software-Instanzen durch Auswahl von Features der Plattform (Development with Reuse).

Als Baum mit Mandatory (immer dabei), Optional, Or-Group (mindestens 1), Alternative (genau 1) und übergreifenden Constraints (Requires, Excludes).

Wenn in einer Konfiguration das Feature A gewählt ist, muss zwingend auch das Feature B ausgewählt sein.

Die Anzahl der zulässigen Konfigurationen verdoppelt sich, da das Feature in jeder bisherigen Konfiguration entweder an- oder abgewählt werden kann.

A(n) = 1 - ((1 - A(n1)) * (1 - A(n2))). (Die Reihe fällt nur dann NICHT aus, wenn BEIDE nicht ausfallen).

A(n) = A(n1) * A(n2). (Die Parallelschaltung fällt nur aus, wenn BEIDE ausfallen).

Man wählt einen Knoten n und berechnet: A(System) = A(n) * (Wahrscheinlichkeit, falls n ausfällt) + (1-A(n)) * (Wahrscheinlichkeit, falls n funktioniert).

Ein Mechanismus, der ein Ergebnis einer Berechnungseinheit nur dann akzeptiert und weiterreicht, wenn mindestens 2 von 3 parallel geschalteten, redundanten Komponenten das exakt gleiche Ergebnis liefern.

Die Überprüfung der Qualität und Vollständigkeit einer Test-Suite (Testfälle), indem synthetische Fehler ("Mutanten") in das Programm eingefügt werden, die von den Tests aufgedeckt ("getötet") werden müssen.

Reachability (Erreichbarkeit), Infection (Infektion/Zustandsänderung) und Propagation (Ausbreitung).

Der mutierte Code muss ausgeführt werden UND zu einem veränderten (fehlerhaften) internen Programmzustand (z.B. falschen Variablenwert) im Vergleich zum Originalprogramm führen.

Der veränderte (fehlerhafte) Programmzustand muss sich bis zu einer durch das Testorakel überprüften Ausgabe (Point of Observation) ausbreiten, um sichtbar zu werden.

RF = GF * (M / GM - 1). (GF = echte gefundene Fehler, M = absichtlich eingebaute Fehler, GM = gefundene Mutationen).

Ein Mutant, der zwar syntaktisch modifiziert wurde, semantisch jedoch exakt das gleiche Verhalten aufweist wie das Original. Er kann durch keinen Testfall getötet werden.

Eine "ur"-Anomalie (unbegründete Referenzierung), da ein prädikativer lesender Zugriff auf eine Variable erfolgt, die undefiniert ist.

Da man nicht alle denkbaren Kombinationen testen kann, wählt man aus jeder Äquivalenzklasse einen repräsentativen Wert, der für das Verhalten der ganzen Klasse steht.

Teilbedingungen erhalten das Attribut '-' (irrelevant), da ihr Ergebnis (aufgrund der Programmiersprachenspezifik) die Gesamtbedingung nach Auswertung vorheriger Bedingungen nicht mehr ändern kann.

Die aktuelle Version muss aus der ältesten Basis-Version (Startpunkt) und einer Kette von inkrementellen Änderungs-Patches (Deltas) errechnet werden (verwendet von SCCS).

Die aktuellste Version liegt vollständig im Speicher vor, alle älteren Versionen werden durch Dekrement-Patches rückwärts aus der neuesten berechnet (verwendet von RCS, ermöglicht schnellen Zugriff auf aktuelle Stände).

Ein Werkzeug zum Variantenmanagement und zur Modellierung von Software-Produktlinien (Feature-Modellen) und deren Konfigurationen.

Ein entdeckter potentieller Fehler oder eine Abweichung von Standards, der im Rahmen einer Inspektion dokumentiert und protokolliert wird.

Kontrollflussgraph, eine fundamentale Graphen-Repräsentation im White-Box-Testen.

Ein White-Box-Testverfahren zur Schleifenabdeckung, das erzwingt, dass Schleifen 0-mal (Boundary), 1-mal und mehrfach (Interior) durchlaufen werden.

Weil ein einziger Testfall (Zeile) simultan mehrere unterschiedliche Wertepaare abdecken kann (z.B. (A1, B1), (B1, C1), (A1, C1) in einem Test).

Klassische (wenngleich teilweise veraltete) Produktmetriken, die Komplexität basierend auf der Anzahl von verwendeten Operatoren und Operanden im Quelltext berechnen.