Kontrollflussorientierte Testverfahren (KFO)

· Anweisungsüberdeckung

· Zweigüberdeckung

· Pfadüberdeckung

o Vollständig

o Strukturiert

· Bedingungsüberdeckung (nicht relevant)

 

Vollständigkeitskriterien werden über Kontrollflussgraphen definiert.

· Definition einer Zwischensprache

· Definition der Transformation in die Zwischensprache

· Definition des Kontrollflussgraphen

Zwischensprache:

· Besteht aus beliebigen Befehlen, außer denen, die Ausführungsreihenfolge beeinflussen(bedingte Anweisungen Sprünge, Schleifen, etc.)

· Bedingten und unbedingten Sprungbefehlen zu beliebigen aber festen Stellen der Befehlsfolge

· Ist ähnlich zu Assembler Code

Strukturerhaltende Transformation einer Quellsprache, wenn:

· Ausschliesslich die Befehle, die die Ausführungsreihenfolge beeinflussen, durch Befehlsfolgen der Zwischensprache ersetzt werden, wobei die Ausführungsreihenfolge gleich bleibt

· Alle andere Befehle unverändert

· Transformationen, bei denen Anweisungsfolgen oder bedingte Sprünge repliziert werde, vermieden werden

DEF Grundblock bezeichnet eine maximal lange Folge fortlaufender Anweisungen der Zwischensprache,

· In die der Kontrollfluss nur am Anfang eintritt

· Die außer am Ende keine sprungbefehle enthält

Kontrollflussgraph

· N ist die Menge der Grundblöcke

· Die Kanten repräsentieren die Ausführungsfolge von Grundblöcken

· Startblock

· Stoppblock

Vollständiger Pfad startet beim Startknoten und endet beim Stoppknoten

Anweisungsüberdeckung:

· Nicht ausreichendes Testkriterium

· Nicht ausführbare Programmteile können gefunden werden

· Fehlende Programmteile werden nicht entdeckt

Zweigüberdeckung:

· Zweige, die nicht ausgeführt werden, können entdeckt werden

· Weder Kombination von Zweige noch komplexe Bedingungen berücksichtigt

· Schleifen werden nicht ausreichend getestet

· Fehlende Zweige nicht testbar, nicht entdeckt

Pfadüberdeckung:

· Pfadanzahl wächst bei Schleifen dramatisch an

· Manche Pfade können nicht ausführbar sein (gegenseitges Widersprechen der Bedingungen)

· Mächtige KFO Teststrategie

· Nicht praktikabel

Boundary-Interior Test testet Schleifen ausführlicher als Zweigüberdeckung, subsumiert Zweigüberdeckung

· Schleifenrumpf einmal queren

· Schleifenrumpf mindestens zweimal queren

· Verzweigungen im Schleifenrumpf mit Zweigüberdeckung berücksichtigen

Funktionale Tests

· Testfälle aus Spezifikation ableiten

· Interne Struktur nicht berücksichtigt, da unbekannt

· Vorteil: Testfälle unabhängig von der Implementierung erstellbar

· Nachteil: mögl. Kritische Pfade nicht bekannt, nicht getestet

So wenig Testfälle wie möglich, aber so viel, wie nötig, dass die Wahrscheinlichkeit groß genug ist, einen Defekt zu finden.

 

Verfahren zur Testfallbestimmung:

· Funktionale Äquivalenzklassenbildung

· Grenzwertanalyse

· Zufallstest

· Test von Zustandsautomaten

Grenzwertanalyse: Testfällen die die Grenzen der Äquivalenzklassen und deren unmittelbare Umgebung abdecken sind besonders effektiv. (Bei Monaten 0 und 1, 12 und 13, oder auch spezielle Kandidaten wie MAX_INT, NaN,…)

Zufallstest:

· Beobachtung: Tester neigen dazu, Testfälle zu erzeugen, die auch bei der Implementierung als nahe liegend erachtet wurden

· Vorteil: nichtdeterministisches Verfahren behandelt alle Testfälle gleich

· Sinnvoll als Ergänzung zu anderen Verfahren

· Sinnvoll, wenn viele Testfälle erzeugt werden müssen

· Sinnvoll als unterlagertes Kriterium

Testhelfern benutzen, wenn die Klasse, die benutzt werden sollen, noch nicht implementiert sind.

Test von Zustandsautomaten

· Testfälle aus Zustandsübergängen ableiten

· Mindestens einmal alle Übergänge durchlaufen

· Überdeckung aller Übergänge garantiert noch keinen vollständigen Test (vgl. Zweigüberdeckung)

Der α-ω-Zyklus bezeichnet den kompletten Lebenszyklus eines Objektes, von der Speicherallokation bis zur Speicherfreigabe.

Test bei automatisch speicherbereinigenden Sprachen problematisch

· Java: finalize()-Zombies (in der finalize Methode wird evtl. wieder eine lebendige Referenz auf das zu entfernende Objekt erzeugt, dadurch wird es nicht freigegeben)

· Schwache Referenzen – Objekte erleben ihr ω, wenn der Speicher knapp wird

· „shut-down hooks“ – Code, der bein Beenden des (Teil-) Systems ausgeführt wird

Leistungstests

· Lasttest testet auf Zuverlässigkeit im erlaubten Grenzbereich

o kann das System die geforderte Nutzerzahl bedienen?

o Können garantierte Antwortzeiten eingehalten werden?

o Kann diese Last beliebig lange bewältigt werden?

o Wie ist die Auslastung der erwarteten Flaschenhälse?

o Gibt es unerwartete Flaschenhälse?

Stresstest – testet das Verhalten des Systems beim Überschreiten der definierten Grenzen

· Wie ist die Leistungsverhalten bei Überlast?

o Seitenflattern

o Exponentielles Ansteigen der Antwortzeit

o Stillstand

· Kehrt das System zurück zum definierten Verhalten nach dem Rückgang der Überlast?

o Wie lange dauert das?

Manuelle Prüfung

· Einzige Möglichkeit, die Semantik zu prüfen

· Aufwendig (bis zu 20% Erstellungskosten)

· Zeit für die Prüfungen muss eingeplant sein

· Psychologischer Druck bei der Begutachtung der Arbeit eines Einzelnen durch eine Gruppe

· Berücksichtigung solcherlei Konfliktpotenzials im Prüfprozess

o Die Arbeit, nicht die Person wird begutachtet

o Die Arbeit aller Mitarbeiter regelmäßig begutachten

o Möglichst Keine Kunden/ höhere Manager anwesend

Software-Inspektionen

· Mehrere Inspektoren (2 bis 8) untersuchen unabhängig voneinander dasselbe Artefakt

· Gefunden Defekte werden aufgeschrieben und Gemeinsamkeiten durchgesprochen

· Hauptaugenmerk ist auf Probleme identifizieren; lösen erfolgt später.

· Strukturierter Prozess

o Rollen und Formulare

o Prüflisten und Perspektiven

Abgrenzung

· Inspektion (inspection) – Überprüfung anhand von Prüflisten oder Lesetechniken

· Überprüfung (review) – Mehr oder weniger formalisierter Prozess zur Überprüfung von schriftlichen Dokumenten durch einen „externen“ Gutachten.

· Durchsicht (walkthrough) – Der Entwickler führt einen oder mehrere Kollegen durch einen Teil des Codes bzw. Entwurfs, den er geschrieben hat. Die Kollegen stellen Fragen und machen Anmerkungen zu Stil, Defekten, Einhalten von Entwicklungsstandards und anderen Problemen.

DEF Inspektion: ist eine formale Qualitätssicherungstechnik, bei der Anforderungen, Entwurf oder Code eingehend durch eine von Author verschieden Person oder eine Gruppe von Personen begutachtet werden. Zweck ist das Finden von Fehlern, Verstößen gegen Entwicklungsstandards und anderen Problemen.

 

Vor und Nachteile von Inspektionen

· Vorteile

o Anwendbar auf alle Softwaredokumente

o Jederzeit und frühzeitig durchführbar

o Sehr effektiv in der industriellen Praxis

· Nachteile

o Gehen nur aufwendig von Hand

o Verbrauchen Zeit mehrerer Mitarbeiter

o Somit ist teuer

o Statisch (im Gegensatz zum Testen)

Zahlen

· Mesit mehr als 50% aller entdeckten Defekte werden in Inspektionen gefunden (bis 90%). Faustregel: (50-75% bei Entwurfsfehlern)

· Verhältnis der Fehlerbehebungskosten durch Inspektion versus durch Testen identifizierter Fehler oft zwischen 1:10 und 1:30

· Return on Investment wird öfter mit 500%+ angegeben.

Warum sind Inspektionen effektiv

· Viele sehen mehr als einer

· Inspektoren haben Abstand zum Software-Dokument

· Inspektoren bringen Erfahrung ein

· Gemeinsame Diskussion über die Identifizierten Problempunkte

o Ist es ein Defekt?

o Ist es eine Schwäche?

o Ist es nur unvorteilhaft?

Phasen einer Inspektion

1. Vorbereitung

a. Teilnehmer und Rollen festlegen

b. Dokumente und Formulare vorbereiten

c. Lesetechniken festlegen

d. Zeitlichen Ablauf planen (optional Initialtreffen)

2. Individuelle Fehlersuche

a. Jeder prüft für sich das Dokument

i. Jeweils etwa 1(+-0.8) Seite pro Stunde pro Inspektor

ii. Teile von 1-4 Seiten netto

b. Benutzt vereinbarte Lesetechnik

c. Schreibt alle Problempunkte und die genaue Stelle im Dokument auf

d. Problempunkte: Defekte, Verbesserungsvorschläge, Fragen

3. Gruppensitzung

a. Individuell gefundene Problempunkte sammeln

b. Jeden einzelnen Problempunkt besprechen

c. Fragen zum Dokument klären

d. Weitere Problempunkte sammeln, die während der Diskussion gefunden werden

e. Verbesserungsvorschläge zur Durchführung von Inspektionen sammeln

4. Nachbereitung

a. Liste mit allen Problempunkten an den Editor des Dokuments übergeben

b. Editor identifiziert tatsächliche Defekte und klassifiziert sie

c. Editor leitet Änderung des Dokuments ein

d. Alle Problempunkte werden bearbeitet

e. Deren Bearbeitung wird überprüft

f. Schätze Restdefekte

i. # nicht entdeckte Defekte etwa= # entdeckte Defekte

ii. 1/6 der Korrekturen ist fehlerhaft/verursacht neuen Defekt

g. Dokument wird freigegeben, wenn #geschätzte Def. < N

5. Prozessverbesserung

a. Prüflisten und perspektiven anpassen

b. Standards für Dokumente erarbeiten

c. Defekt-Klassifikationsschema anpassen

d. Formulare verbessern

e. Planung und Durchführung verbessern

Rollen

· Inspektionsleiter – leitet alle Phasen

· Moderator – leitet die Gruppensitzung (meist Inspektionsleiter)

· Inspektoren – prüfen das Dokument

· Schriftführer – protokolliert Defekte in der Gruppensitzung

· Editor – klassifiziert und behebt Defekte (meist der Autor)

· Autor – hat das Dokument verfasst

Formular für Problempunkte

· Stelle: Seite und Zeile

· Beschreibung

· Wichtigkeit: hoch gering

· Problemtyp: Defekt, Anregung, Frage

· Defekttyp

· Behoben: ja, nein

· Nachgeprüft: ja, nein

Defektklassifikation

· Schwerwiegend odre leicht (major/minor)

· Defekt(defect), Anregung (suggestion), Frage

· Defekttyp z.B nach NASA SEL

Lesetechniken

· Prüflisten

o Liste mit Fragen zum Dokument

o Fragen sollen das Aufspüren von Defekten erleichtern

o Jede Frage bezieht sich auf ein einzelnes Qualitätsmerkmal

o Fragen müssen abgehakt werden

o Prüflisten abhängig von Art des Dokumentes, verwendeter Programmiersprache, verwendete Bibliotheken

· Perspektiven oder Szenarien

o Anleitung, wie das Dokument zu prüfen ist

o Satz von Fragen

o Perspektive deckt bestimmte Sichtweise oder Art von Defekten ab

o Verschiedene Perspektiven für die Inspektoren

o Im Allgemeinen effektiver als Prüflisten

Richtlinien für Gestaltung von Prüflisten

· Liste höchstens 1-2 Seiten lang und gegliedert

· Möglichst präzise Fragen stellen

· Fragen sollen Hinweis geben, auf welche Weise hohe Qualität erreicht werden kann

· Fragen vermeiden, die automatisch geprüft werden können

· Fragen auf neustem technischen Stand halten

 

Perspektiven oder Szenarien

· Warter

· Code-Analyse

· Tester

· Entwerfer

· Qualitätssicherung

Perspektiven-basierte Lesetechniken bestehen aus:

· Erklären der Perspektive und ihrer Ziele

· Anleitung zum Durcharbeiten des Dokuments

· Liste mit Fragen zu dem Dokument

Werkzeuge zur Inspektionsführung

· Agile Review

· Jupiter

· Phabricator

· Review Board

· RhodeCode

Inspektion kann die Änderung entweder vor der Einbuchung überprüfen (verpflichtende Bestandteil z.B. Gerrit) oder nach der Einbuchung (dann ist das ein optionaler Schritt z.B. Agile Review)

Prüfprogramme

· Die statische Analyse einer Software findet während der Übersetzung des Quelltextes statt.

· Für die statische Analyse des Quelltextes gibt es spezielle Anwendungen und Einschübe für viele Entwicklungsumgebungen.

· Warnungen und Fehler, wie nicht init Variablen, nicht erreichbare Anweisungen usw.

· Programmierstil überprüfen

· Fehler anhand von Fehler-Muster finden

Integrationstest

· Voraussetzung: jede involvierte Komponente wurde bereits für sich überprüft

· Schrittweise Integration

o Integriere eine weitere Komponente in die bereits im Zusammenspiel geprüfte Komponentenmenge (wiederholen, bis System komplett integriert)

o Getestet wird das Zusammenspiel der Komponenten

o Stummel und Attrappen werden mit den Implementierungen ersetzt

Unmittelbar

· Keine Treiber und keine Platzhalter

· Alles Systemkomponenten auf einmal überprüft

· Defekt schwer zu lokalisieren

· Testüberdeckung schwierig

· Für größere Systeme nicht geeignet

Inkrementell

· Testen fertiger Komponenten und Fertigstellung unfertiger Komponenten parallelisierbar

· Testfälle leichter konstruierbar

· Testüberdeckung prüfbar

· Viele Resttreiber und Testhelfer nötig

Vorgehensorientiert – Integrationsreihenfolge leitet sich von der Systemarchitektur ab

Testzielorientiert – Jeweils benötigte Komponenten werden zusammenmontiert

Big bang – alles auf einmal, nichts geht, bis alles geht.

Geschäftsprozessorientiert – Alle Komponenten werden integriert, die zu einem Anwendungsfall gehören.

Funktionsorientiert – Teste, die funktionale Anforderungen testen, und alle Komponente werden integriert, die durch Testfälle betroffen sind

Nach Verfügbarkeit - Integration sofort nach Abschluss ihrer Überprüfung

Top-down – Integration von höchster logischer Ebene her (z.B. GUI)

· Frühere Verfügbarkeit eines Simulationsmodells, anhand dessen Defekte in der Produktion identifizierbar sind

· Späte Prüfbarkeit des Zusammenspiels mit Hardware und Basissoftware

· Integrierte Systemkomponenten setzen Dienste niedriger logischer Ebenen voraus d.h. aufwendige, schwierige zu erstellen Testhelfer

Bottom-up – Integration von niedrigster logischer Ebene her (Komponenten, die nicht von anderen Komponenten abhängen)

· Testtreiber erforderlich

· Leichteres Herstellen von Testbedingungen

· Leichtere Interpretation von Testergebnissen

Outside-in – Versuch, die Nachteile von top-down und bottom-up zu mindern

· Beginnt gleichzeitig auf höchster und niedrigster logischer Ebene

· Schrittweise Integration in beide Richtungen aufeinander zu

Inside-out – Beginnt auf mittlerer Ebene mit der Integration

· Schrittweise Integration in beide Richtungen

· Vereinigt eher die Nachteiel von top-down und bottom-up

· Höchstens sinnvoll in Verbindung mit hardest-first

Hardest-First – zuerst werden die kritischen (also kompliziert zu testenden oder potenziell fehlerhaften) Komponenten integeriert

· Bei jedem Integrationsschritt werden die kritischen Komponenten indirekt mitgeprüft

· Letztlich die am besten getesteten Komponenten

Systemtest

· Prüfung des Komplettsystems gegen die Produktdefinition

· System als Black Box – nur die äußere Systemansicht

· Reale Umgebung, z.B. eingebettetes System, technische Anlage, Bedienfeld, etc.