Foliensatz 5

Prof. G. Kemnitz · Institut für Informatik, Technische Universität Clausthal 13. Juli 2012 1/96 

Test und Verlässlichkeit (F5) 

Kapitel 5: Testpraxis 

Prof. G. Kemnitz 

Institut für Informatik, Technische Universität Clausthal 

13. Juli 2012

of. G. Kemnitz · Institut für Informatik, Technische Universität Clausthal 13. Juli 2012 2/96 

Inhalt Foliensatz Testpraxis 

1 Softwaretest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

1.1 Fehlervermeidung und Kontrollen Spezifikation . . . . . . . . . . . 11 

1.2 Testauswahl mit Äquivalenzklassen . . . . . . . . . . . . . . . . . . . . . . . 17 

1.3 Ursache-Wirkungs-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

1.4 Testauswahl mit Automatenmodell . . . . . . . . . . . . . . . . . . . . . . . 30 

1.5 Kontrollflussorientierte Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

1.6 Datenflussorientierte Testauswahl . . . . . . . . . . . . . . . . . . . . . . . . 45 

1.7 Mutationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

1.8 Regressionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 

1.9 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2 Baugruppentest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

2.1 Funktionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

2.2 Strukturtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 

2.3 Boundary Scan / JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

2.4 Optische Inspektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

3 Selbsttest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 

4 HW/SW-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

Prof. G. Kemnitz · Institut für Informatik, Technische Universität Clausthal 13. Juli 2012 3/96

1. Software 


Software

1. Software 

Vergleich mit der Sichtweise in der Vorlesung: 

fehlerorientierte / zufällige Testauswahl 

Fehler entstehen in allen Phasen des Entwurfsprozesses 

Fehlermodellierung für alle Entstehungsphasen möglich 

Modellfehler und zu erwartende Fehler sollten 

sich Nachweisbedingungen teilen (gezielte Testauswahl) 

Nachweismengen vergleichbarer Größe haben (zufällige 

Testauswahl). 

rof. G. Kemnitz · Institut für Informatik, Technische Universität Clausthal 13. Juli 2012 5/96 

Testauswahl für Software 

Der Programmierer hat drei Informationsquellen für die Auswahl 

der Testdaten 

das Programm, 

seine Spezifikation und 

seine Kenntnis der häufigsten Programmfehler. 

[Howen 1976].

1. Software 

Entwurfs- und Testphasen 

Projektfortschritt 

Detaillierung 

Anforderungsanalyse 

Spezifikation 

Systementwurf 

Architekturentwurf 

⇒ 

⇒ 

⇒ 

⇒ 

Codierung 

Abnahme und 

Nutzung 

Systemintegration 

Integrationstest 

Modultest 

⇒ 

Entwurfsfluss 

Ableiten von 

Testbeispielen 

Phasenmodelle fordern nach jeder Entwurfphase Kontrollen 

für das Zwischenergebnis (Reviews, Simulation, Tests) 

Aus den Zwischenergebnissen jeder Phase lassen sich Tests 

für das Endprodukt ableiten. 

Zur Wiederholung: Phasenmodelle ⇒ Fehlervermeidung 


1. Software 

Zehnerregel: Die fehlerbezogenen Kosten vervielfachen sich mit 

jeder Entwurfsphase, die ein Fehler unerkannt bleibt. 

Beispielrechnungen postulieren gern eine Verzehnfachung. 

Die teuersten Fehler sind Anforderungsfehler, die zu spät 

erkannt werden. 

Die häufigsten Ursachen für das Scheitern von Entwurfsprojekten 

[CHAOS Report, Standish Group 1995]: 

Unvollständige Anforderungen 13.1% 

Kunden nicht ausreichend einbezogen 12.4 % 

Mittel nicht ausreichend 10.6 % 

Unrealistische Erwartungen 9.9 % 

Mangelnde Unterstützung durch Management 9.3 % 

Änderungen in den Anforderungen 8.7 % 

mangelnde Planung 8.1 % 

⇒ Fehlervermeidung und Tests ab Spezifikation notwendig. 

⇒ Aber auch den den Folgephasen entstehen Fehler ... 


1. Software 

Test- (auswahl-) arten 

Aus der Spezifikation können meist nur Testfälle ohne 

konkrete Eingaben und Sollausgaben, 

aus der Beschreibung der Zielfunktion Testfälle mit 

konkreten Eingaben und Sollausgaben und 

aus der Beschreibung der Realisierung zusätzlich 

Nachweisbedingungen für Fehler abgeleitet werden. 

Spezifikationsbasierter Test: Testauswahl auf Basis der 

Spezifikation; Stichprobentest zur Kontrolle, dass alle 

Anforderungen korrekt berücksichtigt sind. 

Funktionstest: Testauswahlbasis Funktionsbeschreibung; 

Auswahl von Ein- und Ausgabe-Tupeln. 

Strukturtest: Testauswahlbasis fertige Beschreibung der 

Realisierung. Auswahl von Ein- und Ausgabe-Tupeln + 

fehlerorientierte Bewertung. 



1. Software 

Funktionstest: 

Black-Box Test: keine Kenntnis der Realisierung. 

Grey-Box-Test: ungefähre Kenntniss der Realisierung. 

bereits nach dem Architekturentwurf möglich 

Verfahren für Software 

praktische Auswahl- und Bewertungstechniken 

zufällig, über Äquivalenzklassen, 

Ursache-Wirkungs-Analyse, 

automatenbasiert, ... 

Strukturtest: 

White-Box Test 

Kenntnis der Realisierung erforderlich 

erst nach der Codierung möglich 

praktische Auswahl- und Bewertungstechniken: 

kontrollflussorientiert, 

datenflussorientiert, 

fehlerorientiert (bei Software Mutationstest), ...

1. Software 


Prüfgerechte Strukturierung 

Vernünftige Testsätze lassen sich in der Regel auch bei Software 

nur dann entwickeln, wenn Testaspekte ab Spezifikation 

berücksichtigt werden. Typische Regeln: 

zu testende Beschreibungseinheiten nicht größer als 1 bis 3 

Seiten Quellcode 

dokumentierte, intuitiv verständliche Sollfunktion 

E-V-A-Struktur (kein Gedächtnis) 

Automaten (gesteuerte Funktionen in separat testbare 

Einheiten auslagern) 

Funktionen, deren Ausgaben sich über eine Probe oder 

Plausibilitätsbedingungen kontrollieren lassen, ...


1. Software 1. Spezifikation 

Spezifikation



Was gehört in die Spezifikation 

Festlegung, was das zu entwerfende System leisten soll. 

Funktionale Anforderungen: 

Welche Dienste soll es anbieten 

Eingaben, Verarbeitungen, Ausgaben 

Verhalten in bestimmten Situationen, ggf. was soll es explizit 

nicht tun 

Use-Cases: Beschreibung welcher Benutzer was für Aufgaben 

mit dem System lösen soll. 

Nicht-funktionale Anforderungen: 

Wie soll das System/einzelne Funktionen arbeiten 

Qualitätsanforderungen wie Performance und Zuverlässigkeit 

Anforderungen an die Benutzbarkeit des Systems. 

Ergebnisse der Risikoanalyse: 

...



Ergebnisse der Risikoanalyse: 

Auflistung potenzieller sicherheitskritischer Fehlfunktionen. 

Quantitative Bewertung 

Festlegung von Maßnahmen zur Fehlervermeidung, 

-beseitigung, -behandlung und Schadensbegrenzung. 

Weitere Maßnahmen zur Sicherung der Verlässlichkeit: 

Wartungskonzept 

Reparaturgerechtheit 

...



Fehlervermeidung und Kontrollen 

Vermeidung von Fehlern in der Spezifikation: 

strukturiertes Vorgehen bei der Erarbeitung 

klare, eindeutige, widerspruchsfreie Formulierung 

Diagramme, Tabellen 

Formulierung als überprüfbare Eigenschaften 

Entwicklung eines Modells und Validierung am Modell 

Checkliste zur Vermeidung bekannter Fallstricke (siehe 

häufigste Ursachen für das Scheitern von Entwurfsprojekten) 

Kontrollmöglichkeiten: 

Review (Korrekturlesen, frühe Erkennung, geringe 

Fehlerkosten) 

Simulation des Zielverhaltens, 

Aufbau und Test eines Prototyps 

Test am Endprodukt (hohe Fehlerkosten)



Auswahlkriterien für Prüfmerkmale nach [1, S.40] 

1 gesetzliche Forderungen (Arbeitsschutz, Brandschutz, 

Gesundheitsschutz, ...) 

2 administrative Festlegungen (Liefer-, Prüf-, 

Inbetriebnahmevereinbarungen, Arbeitsanweisungen), 

3 Schwere der Fehlerwirkung (kritischer Fehler, Hauptfehler, 

Nebenfehler [DIN 85], 

4 Sensibilität (Grad des Einflusses von Fehlern und Störungen 

auf das Qualitätsmerkmal), ... 

5 Nachweis potenzieller Spezifikationsfehler. 

Ablauf und Kontrollen bei der Anforderungsanalyse: 

Systembeschreibung aus Kundensicht, Review 

Systembeschreibung aus Realisierungssicht, Review 

Entwicklung eines Modells, Validierung am Modell, ...



Ableitung von Testbeispielen aus der Spezifikation 

Für alle aufgelisteten Eigenschaften, Use-Cases, ...: 

Festlegung von zu überprüfenden Beispielabläufen und 

der Art, wie diese zu kontrollieren sind. 

Die aus den Anforderungen ableitbaren Testfälle sind, da die 

Sollfunktion erst später festgelegt wird, nur Rahmenvorgaben 

später zu ergänzenden Eingabewerten, Sollausgaben oder anderen 

Kontrollvorschriften. Sie dienen insbesondere zum Erkennen 

vergessener und 

falsch umgesetzter 

Anforderungen.


1. Software 2. Testauswahl mit Äquivalenzklassen 

Testauswahl mit Äquivalenzklassen

gehört zu den Funktionstests 

Testerstellung bereits vor oder unabhängig von der 

Codierung möglich 

nicht ganz unabhängige (zufällige) Auswahl in Bezug auf zu 

erwartende Fehler 

Auswahltechnik für Programmmodule mit EVA-Struktur 



Testauswahl mit Äquivalenzklassen 

Äquivalenzklasse: Menge ähnlich 

verarbeiteter Eingabewerte 

Annahme, dass die meisten Fehler 

mit Werten an den Bereichsgrenzen 

nachweisbar sind. 

E 1 

E 2 

E 3 

E 4 

E 5 

E 6 

Ω Eingaberaum 

E i Äquivalenzklasse 

Gezielte Suche von Werten an Bereichsgrenzen. 

optionale Wichtung der Testanzahl innerhalb der Bereiche 

nach Wichtigkeit, Kompliziertheit, ... der Funktion 

Ω


praktisches Vorgehen: 

Beschreibung der gesamten Funktion durch Bedingungen 

b i (x) und Funktionen f i (x), nach denen unter diesen 

Bedingungen die Ausgabe zu berechnen ist: 

wenn b 1 (x) dann y = f 1 (x) 

wenn b 2 (x) dann y = f 2 (x) 

Bedingungen bestehen aus Vergleichen und logischen 

Operationen, z.B.: 

int a, b, c; if ((a>3)|(b+c>5))&(a



int a, b, c; 

... 

if ((a>3)|(b+c>5))&(a

x y Beispiel Testauswahl für x 

0 ≤ x < 1 y := x 0, 0.5, 0.999 

1 ≤ x < 3 y := (x − 2) 2 1, 1.5, 2, 2.7, 2.98 

3 ≤ x ≤ 4 y := 3 − x 3, 3,2, 4 

sonst Fehlermeldung -100, -0.1, 4.01, 345 

Beschreibung als Programm: 

function f(x: real) return real is 

variable y: real; 

begin 

assert x>0.0 and x



x y Beispiel Testauswahl für x 

0 ≤ x < 1 y := x 0, 0.5, 0.999 

1 ≤ x < 3 y := (x − 2) 2 1, 1.5, 2, 2.7, 2.98 

3 ≤ x ≤ 4 y := 3 − x 3, 3,2, 4 

sonst Fehlermeldung -100, -0.1, 4.01, 345 

Testrahmen mit Testeingaben: 

type tRealArray is array (natural range ) of real; 

constant xVektor: tRealArray := (0.0, 0.5, ..., 345.0); 

variable x, y: real; 

... 

for idx in xVector’range loop 

x := xVector(idx); 

y := f(x); 

write("x=" & str(x) & " y=" & str(y)); 

end loop; 

Die Testausgaben sind hier manuell zu kontrollieren.


Richtlinien zur Festlegung der Äquivalenzklassen: 

überschaubare Anzahl 

einfach beschreibbare Einzelfunktionen 1 

Abschlussbemerkungen 

Über Äquivalenzklassen ausgewählte Tests erkennen in der 

Regel mehr Fehler als Zufallstestsätze derselben Länge. 

Den Aufwand, eine Funktionsbeschreibung in die 

≫Äquivalenzklassenform≪ zu bringen, ist relativ hoch. 

Aus einer Äquivalenzklassenbeschreibung lässt sich relativ 

einfach (auch automatisiert) ein Programm erzeugen; 

Über den Weg ≫Nachbildung durch 

Äquivalenzklassenform≪ ⇒ ≫Abbildung in ein 

Programm≪ lassen sich diversitäre Beschreibungen für 

Mehrversionsvergleich ableiten. 

1 gut strukturiert, kurz und übersichtlich sind auch Grundregeln zur 

Fehlervermeidung 



1. Software 3. Ursache-Wirkungs-Analyse 

Ursache-Wirkungs-Analyse



Ursache-Wirkungs-Analyse 

Ursache: einzelne Eingabe- oder Zustandsübergangsbedingungen 

Wirkung: Ausgabe aktualisieren, Signal versenden, Zustand 

verändern, ... 

praktisches Vorgehen bei der Testauswahl: 

Aus der Spezifikation Ursachen, Wirkungen und logische 

Beziehungen dazwischen zusammenstellen: 

Binärabstraktion der Zielfunktion für die Testauswahl 

Eingabe: ≫1≪ Ursache eingestellt, ≫0≪ nicht eingestellt 

Ausgabe: ≫1≪ Wirkung eingetreten, ≫0≪ nicht eingetreten 

Testauswahl wie für digitale Schaltungen, z.B. Toggle-, 

Haftfehler-, Zellenfehler- und Verzögerungsfehlertest, ... 2 

Ergebnis ist eine Menge von Ursache-Wirkungs-Tupeln 

(zufällige) Auswahl von Eingaben, die die Ursachen erfüllen und 

Kontrollkriterien für die erwarteten Wirkungen 

2 Software-Tests haben eigene Bezeichnungen, die dasselbe beschreiben.



Beispiel: Zähle Zeichen 

& 

0 ∗ 

Wirkungen: 

W 1 : Anzahl TypA +1 

W 2 : Anzahl TypB +1 

W 3 : Gesamtzahl +1 

W 4 : Programm beenden 

Ursachen: 

U 1 : Zeichen ist vom Typ A 

U 2 : Zeichen ist vom Typ B 

U 3 : Zeichenanzahl < Maximalwert 

sich ausschließende Ursachen 

UND-Verknüpfung muss ≫0≪ sein 

U 2 

& 

≥1 W 3 

W 2 

U 1 

& 

W 1 

U 1 

U 2 

U 3 

W 1 

W 2 

W 3 

W 4 

Eingabezeichen kann 

nur Typ A oder B sein 

Test mit allen einstellbaren 

Ursachen 

0 1 0 1 0 1 0 1 

0 0 1 1 0 0 1 1 

0 0 0 0 1 1 1 1 

0 0 0 0 1 0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

1 

1 1 1 0 0 0 

eine Ursache-Wirkungs-Analyse deckt Mehrdeutigkeiten und 

Widersprüche in der Spezifikation auf 

∗ 

U 3 

W 4



Testobjekt als VHDL- bzw. Ada-Funktion 

type tCounter is record A, B, N: natural; end record; 

function ZZ(Ct max: natural) return tCounter is 

variable z: character; 

variable Ct: tCounter:=(0, 0, 0); 

begin 

for Ct.N


z=0 A=1 B=0 N=1 

Funktionsaufrufe Ausgaben U 1 U 2 U 3 W 1 W 2 W 3 W 4 

ZZ(3) 

1 0 0 1 0 1 0 

U 3 max. Zählwert erreicht 

W 3 N weiterzählen 

z=A A=1 B=1 N=2 0 1 0 0 1 1 0 

z=x A=1 B=1 N=3 0 0 0 0 0 1 0 

Ende 

1 0 0 0 1 

ZZ(1) z=1 A=1 B=0 N=1 1 0 0 1 0 1 0 

Ende 

1 0 0 0 1 

ZZ(1) z=B A=0 B=1 N=1 0 1 0 0 1 1 0 

Ende 

1 0 0 0 1 

ZZ(0) Ende 

1 0 0 0 1 

U 1 

U 2 

Zeichen ist eine Ziffer 

Zeichen ist ein Großbuchstabe 

W 1 

W 2 

A weiterzählen 

B weiterzählen 

es wird kein Zeichen gelesen W 4 Funktion beenden 

erkannte Widerspruche in der Spezifikation: 

in der UW-Analyse wird bei U 3 = 1 ein Zeichen gelesen 

Testobjekt liest bei U 3 = 0 kein Zeichen 




Aufwand und Nutzen UW-Analyse 

Die Aufstellung der ≫Binärdarstellung≪ aus Ursachen und 

Wirkungen ist aufwändig und kaum automatisierbar. 

für weniger schwach vernetzte Ursachen ist eine Auswahl 

mit Äquivalenzklassen einfacher und genauso gut 

Nutzen: 

Diversität zur Originalbeschreibung (vermeidet gleiche 

Denkfehler) 

Analyse auf Spezifikationswidersprüche automatisierbar 

Schwaches Auswahlkriterium: 

ignoriert viele intuitiv erforderliche Testfälle, z.B. die 

Kontrolle für jedes Zeichen, das es richtig zugeordnet wird 

ohne die zusätzliche Testausgabe lassen sich viel mehr nicht 

nachweisbare Fehler konstruieren 

trotz hohem Aufwand nur Auswahlverfahren für Grobtests


1. Software 4. Testauswahl mit Automatenmodell 

Testauswahl mit Automatenmodell



Automatenmodell 

X 1.1 

Z 1 Y 1.1 Z 2 

Y 1 

Y 2 

X 1.2 

Y 1.2 

Z 3 

Y 3 

X 2.1 

Y 2.1 

X 2.2 

Y 2.2 

Z i Zustand 

Y i Ausgabewert 

Y 3.1 

Y 3.1 

X i Eingabewerte, bei denen der 

Zustandsübergang erfolgt 

Kennzeichen für den Anfangszustand 

nach der Initialisierung 

Beschreibung eines Systems durch einen Menge von Eingaben, 

Zuständen und Ausgaben; übliche Art der Spezifikation 

Beziehung zum UW-Modell 

Ursachen: Eingabe + Zustand 

Wirkung: Folgezustand, Ausgabe 

Testauswahl: Suche einen Weg über alle Kanten



Verbindungsaufbau und -abbau beim Telefonieren 

U 4 /W 4 

Verbunden 

W 2 Ziffer zur Rufnummer 

hinzufügen 

W 3 Verbindung aufbauen 

U 1 Abnehmen 

U 2 Ziffer wählen 

U 1 /W 1 Wählend U 2 /W 2 U 3 Rufnummer gültig 

Getrennt 

U 3 /W 3 W 1 Rufnummer zurücksetzen 

U 4 Auflegen 

W 4 Verbindung trennen 

Test der Soll-Funktion: U 1 → U 2 → . . . → U 2 → U 3 → U 4 

Verhalten für andere Eingabefolgen 

Abnehmen, Wählen, Auflegen (U 1 → U 2 → U 4 ) 

Abnehmen, Wählen, Wählen, falsche Nummer) 

... 

⇒ Ablaufgraph ist noch unvollständig



U 1 /W 1 

Wählend 

U 5 ∨ U 6 

U 4 

U 

U 1 

Getrennt 

3 /W 3 

Eingabefehler 

U 2 /W 2 

∨U 5 ∨ U 6 ∨U 5 ∨ U 6 U 1 ∨ U 3 ∨ U 5 

U 4 

U 4 /W 4 Verbunden 

U 2 ∨ U 3 ∨ U 4 U 1 ∨ U 2 ∨ U 3 

interne Fehlfunktion / Fehlerbehandlung 

U 1 

U 2 

U 3 

U 4 

U 5 

U 6 

Abnehmen 

Ziffer wählen 

Rufnummer gültig 

Auflegen 

Rufnummer ungültig 

Timeout 

W 1 

W 2 

W 3 

W 4 

Rufnummer zurücksetzen 

Ziffer zur Rufnummer 

hinzufügen 

Verbindung aufbauen 

Verbindung trennen 

Ergänzung um Knoten und Kanten für alle denkbaren 

Ursachen und Wirkungen; Präzisierung der Spezifikation



U 1 /W 1 

Wählend 

U 5 ∨ U 6 

U 4 

U 

U 1 

Getrennt 

3 /W 3 

Eingabefehler 

U 2 /W 2 

∨U 5 ∨ U 6 ∨U 5 ∨ U 6 U 1 ∨ U 3 ∨ U 5 

U 4 


U 2 ∨ U 3 ∨ U 4 U 1 ∨ U 2 ∨ U 3 


Test aller Zustandsübergänge, Wirkungen, ... 

Abheben,Wählen, Wählen, Rufnummer gültig, Auflegen 

Abheben, Wählen, Auflegen 

Abheben, Wählen, Wählen, Timeout, Auflegen 

Abheben, Wählen, Rufnummer ungültig, Auflegen

der Test erfordert das Setzen und Lesen des Zustands 

Automatenbeschreibungen eigenen sich gut zur Präzisierung 

der Zielfunktion und zur Testauswahl 

Die Aktionen in den Knoten können auszuführende Programme sein; 

zum Testen durch Dummies ersetzen, die z.B. nur den Zustandsnamen 

protokollieren 



U 1 /W 1 

Wählend 

U 5 ∨ U 6 

U 4 

U 

U 1 

Getrennt 

3 /W 3 

Eingabefehler 

U 2 /W 2 

∨U 5 ∨ U 6 ∨U 5 ∨ U 6 U 1 ∨ U 3 ∨ U 5 

U 4 


U 2 ∨ U 3 ∨ U 4 U 1 ∨ U 2 ∨ U 3 


Test der Reaktion auf interne Fehlfunktionen 

Initialisieren, Auflegen 

Initialisieren, Rufnummer gültig, ...



Zusammenfassung 

Automaten sind ein bewährten Spezifikationsmodell 

gut geeignet zur Kontrolle der Spezifikation auf 

Vollständigkeit und Widersprüche 

Ein Test, der 100% alle Knotenübergänge überprüft, ist perfekt, 

wenn: 

an jeder Kante nur eine Eingabewert als 

Übergangbedingung ausgewertet, 

die gesteuerten Aktionen ausschließlich Ausgaben und 

alle falschen Kantenübergänge an den Ausgaben 

beobachtbar sind. 

Automaten, die Operationen steuern und Operationsergebnisse 

auswerten 

verstecken Funktionalität in Operationen, die nur zufällig 

getestet werden, ...


1. Software 5. Kontrollflussorientierte Tests 

Kontrollflussorientierte Tests



Ein Beispielprogramm und sein Kontrollflussgraph 


function ZZ(Ct max: natural) return tCounter is 



Testauswahlgrundlage 

Kontrollflussgraph 

begin 

n1: for Ct.N


Testauswahlregeln 

Start 

100% Anweisungsüberdeckung 

jede Anweisung muss mindestens 

einmal ausgeführt werden; 

Beispiel: Start n 1 , n 2 , n 3 , n 4 , n 7 , 

n 1 , n 2 , n 3 , n 5 , n 6 , n 7 , n 1 , Ende 

100% Zweigüberdeckung 3 

jede Kante muss mindestens 

einmal durchlaufen werden; 

Beispiel: Start n 1 , n 2 , n 3 , n 4 , n 7 , 

n 1 , n 2 , n 3 , n 5 , n 6 , n 7 , n 1 , n 2 , n 3 , 

n 5 , n 7 , n 1 , Ende 

100% Pfadüberdeckung 

n 3 

n 1 

n 2 

n 4 n 5 

n 6 

n 7 

Ende 

bei 100% Anweisungsüberdeckung 

möglicherweise 

ungetestete Kante 

3 vom Standard RTCA DO-178 B ab Level C (Software, die bedeutende 

Ausfälle verursachen kann) gefordert. 



Start 

n 1 

Ende 

Start 

n 1 

n 1 

n 1 

Start n 2 n 3 n 4 n 7 Ende 

n 5 n 7 n 1 Ende 

n 3 

n 7 n 1 n 2 n 3 n 4 n 7 . . . 

n 2 

Start n 1 n 2 n 3 n 4 n 7 n 1 n 3 

n 4 

Start n 1 n 2 n 3 n 4 n 7 n 1 n 2 

n 5 

n 6 

n 3 n 4 n 7 n 1 n 2 n 3 n 4 

n 7 

Ende 

ein Pfad ist einer kompletter Weg durch den Graphen 

in zyklischen Graphen (mit Schleifen) Anzahl → ∞ 

100% Pfadüberdeckung: unrealistisches Auswahlkriterium 4 

4 Denkbar wäre z.B. ein Test mit 0, 1 und 5, aber nicht mit 0, 1, 2, 3, ... 

∞ Schleifendurchläufen. 




Bedingungsüberdeckung 5 

Entscheidungen können an komplexe Bedingungen geknüpft sein, 

z.B.: 

n1: if (((A>10) and (A1) and (B



n1: if (((A>10) and (A1) and (B 10 

A < 20 

B > 1 

B < 100 

C = 1 

x 1 

x 2 

x 3 

x 4 

x 5 

1 

1 

1 

1 

1 

≥1 1 Zusatzbedingungen 

aus der Abhängig- 

x 5 x 4 x 3 x 2 x 1 

keit der Elementar- 

≥1 1 

entscheidungen 

sa1(x 1 ) 1 1 0 1 0 

sa1(x 2 ) 1 0 1 0 1 

impliziter 

0 

sa1(x 3 ) 1 1 0 1 0 

Nachweis 

& 

sa1(x 4 ) 1 0 1 0 1 

z 1 

1 

sa1(x 5 ) 0 1 1 

≥1 0 sa0(z 1 ) 1 1 1 1 0 

z3 

& y 

0 

sa0(z 2 ) 1 1 0 1 1 

& 

z 2 

Entscheidung 

y 

0 

0 

0 

0 

0 

1 

1 

ein Testsatz mit 100% Bedingungsüberdeckung arbeitet 

jeder Zweig mindestens einmal und oft mehrmals ab



Abschließende Bemerkungen 

Automatisierbarkeit: 

automatische Einprogrammierung eines ≫Abhake-Flags≪ für 

jede zu überprüfende Nachweisbedingung 

Anweisungstest: für jede verzweigungsfreie Anweisungsfolge 

Zweigtest: für jede Verzweigung 

für jeden nicht implizit nachweisbaren Verzweigungshaftfehler 

Subsumption (unter den Oberbegriff fallen von): 

Testauswahlkriterium A subsumiert ein Auswahlkriterium 

B, wenn jeder nach A ausgewählte Testsatz auch B erfüllt 

Zunahme der Testsatzlänge und Fehlerüberdeckung 

100% 

Anweisungs- 

überdeckung 

subsumiert 100% subsumiert 

Zweigüberdeckung 

100% 

Bedingungsüberdeckung

die Auswahlkriterien Anweisungs-, Zweig- und 

Bedingungsüberdeckung definieren notwendige 

Anregungsbedingungen, aber keine hinreichenden 

Anregungs- und keine Beobachtungsbedingungen 

Sicherung der Beobachtbarkeit durch Test im Schrittbetrieb 

oder zusätzliche Ausgaben während des Tests oder der 

Simulation. 

Ohne Beobachtung aller Zwischenergebnisse lässt sich von 

den Kontrollflussüberdeckungen kaum auf die 

Fehlerüberdeckung schließen. 



Vergleich mit Fehlermodellen 

Ω Ω Eingaberaum 

Nachweismenge eines Modellfehlers 

Nachweismenge eines tatsächlichen Fehlers 

Eingabemenge einer Anregungsbedingung


1. Software 6. Datenflussorientierte Testauswahl 

Datenflussorientierte Testauswahl



Datenflussorientierte Testauswahl 

Ergänzung der Testauswahlkriterien 

um Beobachtungsbedingungen 

Klassifizierung der Datenoperationen: 

def(...) Wertzuweisung 

c-use(...) Verwendung in einer 

Berechnung 

p-use(...) Verwendung in einer 

Verzweigungsbedingung 

out(...) Wert direkt beobachtbar 

Auswahlkriterien: jedem ≫def≪ eines 

Datenobjekts muss im Berechungsfluss 

mindestens eine ≫use≪-Anweisung folgen. 

notwendige, aber nicht hinreichende 

Beobachtungsbedingung 

Start 

n 1 

n 2 

n 3 

n 4 

n 5 

n 6 

n 7 

Ende 

def(N max) 

def(Ct.A) 

def(Ct.B) 

def(Ct.N) 

p-use(N max) 

p-use(Ct.N) 

def(z) 

p-use(z) 

c-use(Ct.A) 

def(Ct.A) 

p-use(z) 

c-use(Ct.B) 

def(Ct.B) 

c-use(Ct.N) 

def(Ct.N) 

out(Ct.A) 

out(Ct.B) 

out(Ct.N)


Das Programm zum Beispielgraphen: 


function ZZ(N max: natural) return tCounter is 



begin 

n1: for Ct.N



N Max 

intuitive Testauswahl für den Beispielgraphen 

1 Start: def(N max), n 1 : p-use(N Max), 

Ende 

2 Start: def(N max), n 1 : p-use(N Max), 

n 2 , n 3 , n 5 , n 7 , n 1 : p-use(N Max), 

Ende 

Ct A 

1 Start: def(Ct A), n 1 , n 2 , n 3 , 

n 4 : p-use(Ct A), def(Ct A), n 7 , n 1 , 

Ende: out(Ct A) 

2 Start: def(Ct A), n 1 , n 2 , n 3 , 

n 4 : p-use(Ct A), def(Ct A), n 7 , n 1 , 

n 2 , n 3 , n 4 : p-use(Ct A), def(Ct A), 

n 7 , n 1 , Ende: out(Ct A) 

... 

Start 

n 1 

n 2 

n 3 

n 4 

n 5 

n 6 

n 7 

Ende 

def(N max) 

def(Ct.A) 

def(Ct.B) 

def(Ct.N) 

p-use(N max) 

p-use(Ct.N) 

def(z) 

p-use(z) 

c-use(Ct.A) 

def(Ct.A) 

p-use(z) 

c-use(Ct.B) 

def(Ct.B) 

c-use(Ct.N) 

def(Ct.N) 

out(Ct.A) 

out(Ct.B) 

out(Ct.N)


Auswahlkriterien und Beobachtbarkeit 

direkt beobachtbar: ≫def≪ → ≫out≪ 

Beobachtbarkeit 6 : 100% 

Beobachtungspfad über mehrere Verarbeitungsoperationen: 

≫def≪ → ≫c-use/def≪ → ≫c-use/def≪ → . . .→ ≫out≪ 

abnehmende Beobachtbarkeit mit der Pfadlänge 

n∏ 

b ges = 

(b i – Beobachtbarkeit von Operandenfehlern am 

Operationsergebnis; für Add, Subb, Mult, ... groß) 

Beobachtbarkeit über Verzweigung: ≫def≪ → ≫c-use≪ 

Beobachtbarkeit < 50% 

Je schlechter die Beobachtbarkeit für ein ≫def≪, desto mehr 

unterschiedliche Testbeispiele sind für den Testtyp erforderlich. 

6 Genau genommen Wahrscheinlichkeit der Beobachtbarkeit. 


i=1 

b i



Zusammenfassung 

Datenflussorientierte Testauswahl ist 

ist meist aufwändiger als kontrollflussorientierte Tests im 

Schrittbetrieb abzuarbeiten 

hat dennoch eine schlechtere Beobachtbarkeit, weil keine 

Datenflußpfade bis zu Ausgabe gesucht werden 

eine akademische Disziplin mit geringer praktischer 

Akzeptanz 

ohne die breite Software-Unterstützung wie die etablierten 

kontrollflussorientierten Techniken.


1. Software 7. Mutationstest 

Mutationstest



Mutationstest 

fehlerfreie 

Beschreibung 

(Reparaturziel) 

Beschreibung 

zur Testauswahl 

Nachweisbedingung ∗ 1 

Nachweisbedingung ∗ 2 

∗ 

Hinzufügen eines Fehlers 

Fehlerbeseitigung 

Definition Nachweisbedingung 

oder Modellfehler 

Für Entwürfe gibt es keine korrekte Sollbeschreibung. 

Statt der Modellfehler lassen sich nur Mutationen einer 

potenziell fehlerhaften Beschreibung konstruieren. 

Kein Soll-/Istvergleich für die Kontrolle der Testergebnisse; 

Alternativen: Mehrversionsvergleich, Probe, ...



Fehlerorientierte Testauswahl 

Ω 

F 

M 

Nachweismenge eines Fehlers 

Eingabemenge, die eine korrespondier- 

rende Nachweisbedingung erfüllt 

relative Größe der Schnittmenge als 

Schätzwert für die Wahrscheinlichkeit, 

dass ein Test aus M den Fehler nachweist 

Fehlerorientierte Testauswahl setzt große Schnittmengen der 

Nachweismengen zwischen tatsächlichen Fehlern und 

Mutationen voraus.



Ω 

F 

M 


Eingabemenge, die eine korrespondier- 

rende Nachweisbedingung erfüllt 

relative Größe der Schnittmenge als 

Schätzwert für die Wahrscheinlichkeit, 

dass ein Test aus M den Fehler nachweist 

Für einen erheblichen Teil der potenziellen Fehler, z.B. 

vergessene Funktionen oder Fallunterscheidung erlaubt die 

Entwurfsbeschrei- bung keine Rückschlüsse auf deren 

Nachweisbedingungen: 

keine ähnlich nachweisbaren Mutationen konstruierbar, 

Nachweis nur durch Zufall möglich. 

Nachweisähnlichkeit der Mutationen mit tatsächlichen 

Fehlern setzt eine weitgehend korrekte Beschreibung voraus.


Zufallstest 

Eine fehlerorientierte Festlegung der Testsatzlänge für einen 

Zufallstest verlangt Annahmen / Schätzungen des Fehlerprofils: 

aus der Testzeit, nach der jeweils neue Fehler gefunden 

werden, 

aus den Nachweiswahrscheinlichkeiten einer Stichprobe von 

Mutationen oder 

den Fehlerprofilen vergleichbarer Systeme. 

Für die Modellfehler/Mutationen zur Abschätzung des 

Fehlerprofils genügen überschneidungsfreien Nachweismengen 

vergleichbarer Größe. 

Ω 

F 

M 


Nachweismenge, die eine korrespondierrenden 

Modellfehler nachweist 

zufällig ausgeählter Test 




Mutationstest als Test des Tests 

In der Praxis werden Mutationstests hauptsächlich dazu genutzt, 

die Fehlersensibilität anders ausgewählter Tests zu testen: 

Auswahl einer Stichprobe von Mutationen 

Von den gewählten Mutationen unabhängige Auswahl eines 

Testsatzes (nach einem der vorherigen Verfahren oder 

zufällig) 

Bestimmung der Fehler- bzw. Mutationsüberdeckung. 

Bei Bedarf Suche weiterer Test zur Erzielung der geforderten 

Mutationsüberdeckung.



Typische Mutations-Transformationen: 

Verfälschung arithmetischer Ausdrücke (x=a+b x=a*b) 

Verfälschung boolescher Ausdrücke (if(a>b){} if(a


1. Software 8. Regressionstest 

Regressionstest


1. Software 8. Regressionstest 

Formen: 

Regressionstest (v. lat. regredior, regressus sum = 

zurückschreiten) versteht man in der Softwaretechnik die 

Wiederholung aller oder einer Teilmenge aller Testfälle, um 

Auswirkungen von Modifikationen in bereits getesteten 

Teilen der Software aufzuspüren. 

Solche Modifikationen entstehen regelmäßig z. B. aufgrund 

der Pflege, Änderung und Korrektur von Software. 

Aufgrund des Wiederholungscharakters und der Häufigkeit 

dieser Wiederholungen ist es sinnvoll, den Regressionstest zu 

automatisieren. 

Soll/Ist-Testfälle: Verwendung der aufgezeichneten Ist-Werte 

des Referenzsystems als Sollwerte (verlangt


1. Software 9. Aufgaben 

Testbedingungen) 

Mehrversionsvergleich: paralleler Betrieb beider Versionen 

und Ergebnisvergleich (auch unter Betriebsbedingungen 

möglich). 

Im Gegensatz dazu ordnet Liggesmeyer (Lit.: Liggesmeyer) 

den Regressionstest in die Gruppe der Diversifizierenden 

Tests ein. Dadurch wird im Unterschied zu 

Funktionsorientierten Testtechniken die Korrektheit der 

Testergebnisse nicht anhand der Spezifikation entschieden, 

sondern durch Vergleich der Ausgaben der aktuellen Version 

mit den Ausgaben des Vorgängers. Ein Testfall gilt beim 

Regressionstest als erfolgreich absolviert, wenn die Ausgaben 

identisch sind.



Aufgaben



Testauswahl mit Äquivalenzklassen 

Schnittstelle der Zielfunktion 

type tIFeld is array (natural range ) of integer; 

function sort(x: tIFeld) return tIFeld; 

das unsortierte Eingabefeld soll auf ein aufsteigend sortiertes 

Ergebnisfeld abgebildet werden 

definieren von Äquivalenzklassen für die Eingabe 

Auswahl von Grenzwerten und typischen Werten für jede 

Äquivalenzklasse 

Besser oder schlechter als ein Zufallstest



Automatenbasierte Testauswahl 

weiter: Kernoperationen, Operationsablaufgraph, ... 

Testauswahl auf Grundlage des Automatengraphen 

Bild ≫serieller Dividierer aus EDS≪ 

Besser oder schlechter als ein Zufallstest

2. Baugruppentest 


Baugruppentest

2. Baugruppentest 


Wichtige Verfahren für den Baugruppentest 

Funktionstest: Hardware-Nachbildung eines Testrahmens zur 

Bereitstellung von Eingaben und Kontrolle von Ausgaben 

Test in der Funktionsumgebung 

Funktionstester 

HIL (Hardware in the Loop) Tester 

Strukturtest: gezielte Suche nach Bestückungs- und 

Verbindungsfehler 

In-Circuit-Test 

Boundary-Scan


2. Baugruppentest 1. Funktionstest 

Funktionstest



Modularer Funktionstester 

Rechner mit einem modular zusammensetzbaren System aus: 

Logikgenerator- und Logikanalysatorbaugruppen 

DAU- und ADU-Baugruppen 

programmierbaren Spannungsversorgungen 

Baugruppen für Busschnittstellen (RS232, SPI, CAN, ...) 

Lastschaltungen, Adapter, ...



HIL- (Hardware in the 

Loop) Tester 

Test von Steuergeräten 

Das zu steuernde System (Maschine, Auto, Flugzeug) wird 

über ein Modell simuliert, das aus den Aktorausgaben des 

Steuergeräts Sensordaten für die Eingabe berechnet. 

Test von Regelkreisen in Echtzeit



Anwendungsbereiche für HIL-Tester 

Maschinen und Anlagenbau: 

physikalische Simulation der gesteuerten Maschine oder 

Anlage 

3D-Visualisierung des physikalischen Verhaltens 

Verkürzung der Inbetriebnahmephase 

Untersuchung von Grenzwert- und Gefahrensituationen 

Fahrzeugbau, Luft- und Raumfahrt 

physikalische Simulationen von Motoren, Lenksystemen bis 

hin zu kompletten Flugzeugen 

Nachstellung komplizierter Testsituationen im Labor 

(fahrendes Auto, Flugzeug in der Luft, ...) 

Jedes Simulationsmodell hat Genauigkeitsgrenzen. Kein 

vollständiger Ersatz für den Test in der 

Anwendungsumgebung


2. Baugruppentest 2. Strukturtest 

Strukturtest



Strukturtest 

Baugruppen (Leiterplatten) bestehen aus einem 

Verdrahtungsträger und Bauteilen (Widerstände, 

Kondensatoren, Schaltkreise, ...) 

Verdrahtungsträger und Bauteile werden vor dem 

Zusammenbau gründlich getestet. 

Der Baugruppentest zielt überwiegend auf 

Fehlbestückungen, Kurzschlüsse und Unterbrechungen. 

Erkennung und Lokalisierung aller potenzieller Bestückungsund 

Verdrahtungsfehler über das Ein-/Ausgabeverhalten 

schwierig 

Alternativen: direkte Kontrolle auf Abwesenheit von 

Bestückungs- und Verdrahtungsfehler durch: 

elektrischen Messungen 

optische Inspektion



In-Circuit-Test 

Kontaktierung aller Schaltungspunkte mit Nadeln 

Suche potenzieller Bestückungs- und Verdrahtungsfehler mit 

elektrischen Messungen



Analoge Signaturanalyse 

Leiterplattenprüfung im spannungsfreien Zustand 

Messung der Strom-Spannungskennlinie zwischen zwei 

Punkten und Vergleich mit einer Referenzkennlinie 

Einspeisung einer mit Wechselspannung überlagerten 

Gleichspannung + Strombegrenzung 

Bauteiltypische Signaturen: 

Widerstand: Gerade 

Kondensator: Elypse 

Diode: Kennlinie mit Knick


IC 

Testobjekt 

Signalgenerator 

R M 

x 

y 

Oszi 

die Signatur zwischen zwei Punkten hängt von der 

kompletten Schaltung, nicht nur einzelnen Bauteilen ab 

bestimmbar durch Ausprobieren an einem ≫Golden Device≪; 

problematisch kann sein die 

die Festlegung der Toleranzbereiche für die Signatur aus den 

Bauteilstreuungen 

die Erkennungssicherheit, z.B. Fehlbestückungen bei kleinen 

Kondensatoren. 




Elektrische Isolation 

IC 

Testobjekt 

Kompensationsspannungsquelle 

− 

+ 

A 

V 

U m = 100 mV 

Unterdrückung von Parallelströmen zum Testobjekt durch 

Kompensation der Spannungsabfälle über den wegführenden 

Bauteilen auf einer Testobjektseite auf null 

Vereinfacht die Bestimmung der Signaturen bzw. Sollwerte.


Bestückungstest für Schaltkreise 

digitaler Schaltkreis 

U V 

x 

y 

Einspeisen eines Messstroms 

≈ 1 mA 

Kontrolle der 

Flussspannung 

Schaltkreise haben an ihren Eingängen i.Allg Schutzdioden 

zur Versorgungsspannung und Masse 

Test auf Unterbrechungen durch Stromeinspeisung Messen 

der Flussspannung 

Erkennt nicht, ob es der richtige Schaltkreis oder Anschluss 

ist. 



Auch an den Ausgängen existieren in der Regel Dioden zur 

Betriebsspannung und Masse. 

Verbindungskontrolle wie bei Eingängen 

x 

G2 

G1 

U V 

y 

U V 

x 

G1 

G2 

y 

n-Wanne 

p + -Gebiet 

n + -Gebiet 

Polysilizium-Streifen 

Metallleiterbahn 

Durchkontaktierung 

parasitäre Ausgangsdioden 




Isolierter Logiktest für digitale ICs 

Tester 

Deaktivierung Test Deaktivierung 

IC 

IC 

Testobjekt 

IC 

Signalquellen, die der 

Tester überschreibt 

Überschreiben digitaler Eingabesignale des Testobjekts 

andere Schaltkreise werden möglichst deaktiviert 

(Anschlüsse hochohmig)



Voraussetzung für ICT-Einsatz 

≫prüfgerechter Entwurf≪: 

bei Vakuumansaugen luftdichter 

Rand, keine Löcher 

geeignete Kontaktflächen 

Deaktivierungsmöglichkeit 

der Schaltkreise, ... 

Automatisch Generierung der Testvorschrift möglich: 

Zusammensetzen aus Test- und Deaktivierungsvorschriften 

für alle Bauteile (gut gestellt) 

Fehlererkennung und Lokalisierung: 

erkennt fast alle Kurzschlüsse, Unterbrechungen und 

Fehlbestückungen und gibt den genauen Fehlerort an


2. Baugruppentest 3. Boundary Scan / JTAG 

Boundary Scan / JTAG



Das Prinzip von Boundary-Scan 

Schaltkreisanschluss 

serieller 

Eingang 

serieller 

Ausgang 

Mux D D 

Mux 

interne 

Schaltung 

IS 

ExS 

schaltkreisinterne Schaltungsteile 

externe Schaltungsteile 

Verbindungstest 

Takt- und Steuersignale 

Tester 

Testdateneingang (TDI) 

Testtakt (TCK) 

Teststeuersignal (TMS) 

Testdatenausgang (TDO) 

IS 

& 

ExS 

IS 

Ersatz der mechanischen Nadeln durch ≫silicon 

nails≪ (seriell beschreibbare Register an den 

Schaltkreisanschlüssen, im Normalbetrieb überbrückt) 

Aufspaltung in viele kleine, separat testbare Teilschaltungen


Schaltkreisanschluss 

serieller 

Eingang 

serieller 

Ausgang 

Mux D D 

Mux 

interne 

Schaltung 

IS 

ExS 

schaltkreisinterne Schaltungsteile 

externe Schaltungsteile 

Verbindungstest 

Takt- und Steuersignale 

Tester 

Testdateneingang (TDI) 


Teststeuersignal (TMS) 

Testdatenausgang (TDO) 

IS 

& 

ExS 

IS 

Ablauf eines Testschritts für den Baugruppentest: 

BS-Register aller Schaltkreise auf der Baugruppe seriell 

beschreiben 

einen Arbeitsschritt ausführen 

Die im Arbeitsschritt in den BS übernommenen Werte 

seriell an den Tester ausgeben und zeitgleich nächsten 

Eingabevektor laden 




Ursprungsidee: Alternative zu den teueren, für jede 

Baugruppe speziell anzufertigenden Nadeladapter 

als IEEE 1149.1 standardisierter serieller Testbus 

wird weitere Test-, Diagnose- und 

Rekonfigurationsfunktionen (z.B. für Xilix-FPGA und 

ATMEGA-Mikroprozessoren aus den Übungen: 

Programmierung, ChipsScope, Debugger-Verbindung, ...)


Die Testbusarchitektur der Schaltkreise 

Datenregister 

Teststeuersignal 

(TMS) 

Boundary-Scan-Register 

Bypass-Register 

optionale Register 

Befehlsregister 

Multiplexer 

serieller Testbus- 

eingang (TDI) 

serieller Testbusausgang 

(TDO) 


TAP-Controller 

den TAP- (test access port) Controller 

ein Befehlsregister 

mehrere Testdatenregister (mindestens das Boundary-Scanund 

das Bypassregister). 


Über TMS und TAP-Controller steuerbare Funktionen: 

Capture: Übernahme von Daten aus der Schaltung in das 


Shift: Werte im Befehlsregister eine Position weiter schieben 

Update: eingeschobenes Bitmuster in das Befehlsregister 

übernehmen 

dieselben drei Funktion für ein über das Befehlswort 

Prof. G. Kemnitz ausgewähltes · Institut für Datenregister 

Informatik, Technische Universität Clausthal 13. Juli 2012 83/96 


Datenregister 


(TMS) 





Multiplexer 


eingang (TDI) 


(TDO) 


TAP-Controller


Datenregister 


(TMS) 





Multiplexer 


eingang (TDI) 


(TDO) 


TAP-Controller 

Datenregister: 

Boundary-Scan: Register am Schaltkreisrand 

Bypass: 1-Bit-Register zur Überbrückung des Schaltkreises 

in der Schieberegisterkette der Baugruppe 

Optionale Erweiterungen: 

Hersteller- und Bauteilidentifikationsregister 

weitere Test-, Programmier- oder Debug-Register 



TAP-Controller, Busprotokoll 

Automat mit 16 Zuständen 

Kantenauswahl über TMS- 

(test mode select) Signal 

Typischer Testablauf: 

Befehlsregister lesen (enthält 

ein Muster zur Erkennung von 

Busunterbrechungen und der 

Größe der Befehlsworte je 

Schaltkreis) 

Bauteilnummern lesen 

(Bestückungskontrolle) 

ein Teil der Schaltkreise auf 

Bypass setzen, für die anderen 

Datenregister auswählen 

... 

Testfunkt. 1 

0 

lt. Befehl 

0 normale Funktion 

(Testlogik rücksetzen) 

1 

1 

0 

0 

Übernahme Übernahme 

1 0 

1 0 

Schieben 0 Schieben 

1 

1 

1 

1 

0 

0 

P 0 

P 0 

1 

1 

0 

1 

0 

1 

Übergabe 

Übergabe 

1 0 1 0 

1 

Datenübertragung 

Befehlsübertragung 


0


2. Baugruppentest 4. Optische Inspektion 

Optische Inspektion



Inspektion in der Baugruppenfertigung 

visuelle Kontrolle auf Bestückungs- und Lötfehler 

manuelle Inspektion: 

Güte/Eigenschaften ähnlich wie bei der Inspektion von 

Entwurfsdokumenten 

erkennt auch elektrisch nicht nachweisbare Lötfehler 7 

Pflicht für sicherheitskritische Baugruppen (Automotive) 

7 siehe Abb. Kleber auf der Lötstelle; Ausfall bei Vibration



Automatisierte Baugruppeninspektion 

Bildverarbeitungssystem mit Beleuchtung, Kamera, 

Verarbeitung, Monitor 

Lernen von Bildern mit Fehlern und korrekten Bauteilen 

Generierung des Prüfprogramms aus einer geometrischen 

Beschreibung und einer Bilddatenbank 

Vorteile der Automatisierung 

hohe Inspektionsfehlerüberdeckung (Ausschluss Störquelle 

Mensch) 

hohe Effizienz und Effektivität

3. Selbsttest 


Selbsttest

3. Selbsttest 


Falls noch Zeit übrig, aus [2, Kap. 4] übernehmen.

4. HW/SW-Systeme 


HW/SW-Systeme



Der Hardware-Entwurf gleicht bis zur Simulation der 

Funktionsbeschreibung dem Software-Entwurf. 

Der Architekturenwurf verteilt die Funktionalität 

auf Hard- und Software-Bausteine 

Definiert die Funktion der Bausteine und 

der Schnittstellen dazwischen. 

Ergebnis ist ein System aus miteinander kommunizierender 

Funktionsbausteine. 

Die Schritte danach 

Synthese, Technologieabbildung 

Platzierung und Verdrahtung 

sind meist automatisiert.



Diagnosesystem und Einschalttest 

Komplexe IT-Systeme (Rechner, Programme, ...) enthalten in 

der Regel Funktionen für Test und Fehlerlokalisierung 

zur Vereinfachung von Reparatur und Wartung 

zur Erzeugung und Übermittlung der Fehlerinformationen 

an den Hersteller, damit dieser die zugrunde liegenden 

Fehler sucht beseitigt. 

Typische Lösungen: 

Systeme mit Rechner haben einen Einschalttest, der die 

Funktion der Hardware testet. 

Baugruppen und Schaltkreis mit Test- und 

Wartungsbusanschluss für einen Diagnoserechner. 

Programm, die bei internen Fehlern Fehlercodes an den 

Hersteller senden. 

eingebaute Diagnosesysteme mit auslesbarem Fehlerspeicher.


Prüfgerechte 

Mikrorechnersoftware 

Initialisierungs- 

Code 

externe Signale 

Zählerübertrag 

. . . 

Task 1 

bereit 

ja 

Task 1 

nein 

Interupt- 

Routinen 

Initialisierungs-Code 

Sprünge zum Programmbeginn 

und den Interrupt- 

Routinen 

Initialisieren der SFR (Peripherie 

initialisieren, Stack einrichten, ...) 

Einschaltselbstest 

Task 2 

bereit 

nein 

Task n 

bereit 

ja 

ja 

Task 2 

Task n 




Testen der Tasks 

Testrahmenprogramm für Unterprogramme auf dem Mikrorechner 

Wiederhole immer 

cmd = getByte(); 

Fallunterscheidung nach dem 

Wert von cmd 

Byte Setzen Byte Lesen 

adr = getWort() adr = getWort() 

Wert = getByte() Wert = Lese(adr) 

Schreibe(adr, Wert) sendByte(Wert) 

sendByte(Cmd) 

Teststeuerdatei auf dem PC und Testergebnisse 

# Aktion Adresse Eingabewert Rückgabewert 

L 

L 

X 

S 

211 

212 

2145 

115 

45 

3 

Unterprogramm · · · 

ausführen 

adr = getWort() · · · 

RestartTimer() 

Ausfuehren(adr) 

sendTime() 

 

 

 



Testen der Interrupt- und Task-Abarbeitung 

ISR1: 

... 

Debug = ISR Nr; 

... 

reti; 

Task1: 

Debug = Task1 Begin; 

... 

Debug = Task1 Ende; 

ret; 

· · · 

Logikanalysator 

Mikro- 

· · · 

Rechner 

· · · 

Zeit 

in µs 

Debug- 

Nummer 

Aktion 

3 0 Start-Up Beginn 

45 

162 

184 

212 

1 

5 

28 

29 

Start-Up Ende 

ISR1 

Task 1 Beginn 

Task 1 Ende 

... ... ... 

PC



[1] R. Kärger. 

Diagnose von Computern. 

Teubner, 1996. 

[2] G. Kemnitz. 

Test und Verlässlichkeit von Rechnern. 

Springer, 2007. 

n

Foliensatz 5

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

Template löschen?

Als Template speichern?