ISTQB Certified Tester Foundation Level 3

1.

3
1
2
Grundlagen
Testen im
Lebenszyklus
4
5
Testentwurfsverfahren
Testmanagement
V 3.0 - 1 / 43
ISTQB Certified Tester
Foundation Level
3
Statische
Methoden
63
Testwerkzeuge
T-Systems · PDC Test · 2010

2.

1
2
3
4
5
6
ISTQB Certified Tester
Foundation Level
Statische Methoden
Lernzielstufe
K2
Statische Prüftechniken und der Testprozess
K2
Reviewprozess
K2
Werkzeuggestützte statische Analyse
Sehe Lehrplan, Kapitel 3 für die Lernzielbeschreibung dieses Moduls
Siehe Modul 1, Anhang A, Beschreibung der Lernzielstufen
V 2.1 - 2 / 43
T-Systems · PDC Test · 2010

3. Statischer Test

3
Statischer Test
Testmethoden
Code wird NICHT
ausgeführt
Statisches Testen
G
Reviews
(manuell)
ISTQB Certified Tester
Foundation Level
Code wird
ausgeführt
Dynamisches Testen
Statische
Analyse (Tools)
White Box
(Struktur)
Black Box
(Verhalten)
• Kontrollfluss
• Datenfluss
• Metriken
Durch Einzelne:
Durch Gruppen:
Schreibtischtest
Korrekturlesen
Data Stepping
Reviews
Walkthroughs
Inspektionen
V 3.0 - 3 / 43
G Eine Bewertung eines Produkts oder
eines Projektstatus. Sie dient dazu,
Diskrepanzen zu den geplanten Ergebnissen aufzudecken und Verbesserungspotenziale zu identifizieren.
T-Systems · PDC Test · 2010

4. Was wird statisch geprüft ?

3
Was wird statisch geprüft ?
Anforderungsdefinition
prüfe
funktionaler
Systementwurf
prüfe
ISTQB Certified Tester
Foundation Level
Auch Testdokumente!
Anforderungsspezifikation
Abnahmepläne
Testpläne
Testspezifikationen
Testfälle, Testskripte
Testresultate
Fachliche
Designspezifikation
technischer
Systementwurf
Technische
Designspezifikation
prüfe
Komponentenspezifikation
Code
Quelltext
prüfe
Andere Projektphasen
prüfe
V 3.0 - 4 / 43
Anwenderhandbücher,
Webseiten, Trainingmaterial
T-Systems · PDC Test · 2010

5. Weitere Reviewkandidaten

3
Weitere Reviewkandidaten
Strategische
Dokumente, z.B.
Businesspläne
Marketingmaterial
Standards
& Prozeduren, z.B. für
Qualitätsmanagement
Tests
Sicherheit
Richtlinien
ISTQB Certified Tester
Foundation Level
& Styleguides, z.B.
zur Programmierung
zu Nutzeroberflächen
V 3.0 - 5 / 43
T-Systems · PDC Test · 2010

6. Welche Fehlerzustände finden Reviews?

3
ISTQB Certified Tester
Foundation Level
Die spezifizierten Anforderungen sind
Unvollständig
Nicht testbar
Inkonsistent
Designdokumente enthalten
Falsche Annahmen
Unvollständige Abdeckung der Anforderungen
Nicht realisierbares Design
Falsche Schnittstellenspezifikationen
Code mit unzureichender Wartbarkeit
Abweichungen von Standards und einzuhaltenden Richtlinien
Prozessfehler, die weitere Fehlerzustände verursachen
V 3.0 - 6 / 43
T-Systems · PDC Test · 2010

7. Was finden Code Reviews?

3
Was finden Code Reviews?
Seltsame oder unlogische
Funktionalität, die bei
dynamischen Tests selten
auffällt
100 ??
Wartungsprobleme, z.B.
!!!
Unerwünschter Testcode
Test ??
„Magische“ Zahlen
Schlechte Kommentierung
Logisch falsche Konstrukte
c, c++ !
ISTQB Certified Tester
Foundation Level
GetAccount (AccNumber)
If account in credit (AccNumber)
add to account (AccNumber ,sum)
else
issue letter (AccNumber)
delete account (AccNumber+1)
endif
If current_account > 100
add to account (AccNumber ,sum)
else
issue letter (AccNumber)
If Test then
delete account (AccNumber+1)
endif
Sum = GetCurrentAccount (AccNumber)
if (Sum = 0)
issue letter (AccNumber)
Print (Sum)
V 3.0 - 7 / 43
T-Systems · PDC Test · 2010

8. Vorteile statischer Methoden

3
Vorteile statischer Methoden
ISTQB Certified Tester
Foundation Level
Zuverlässigkeit
Kundenvertrauen
Produktivität der Entwicklung
Mehr
Vorbeugende Qualitätssicherung
Entwicklungszeit
Weniger
Testzeit und Gesamtkosten
Fehlerzustände in späteren Testphasen
V 3.0 - 8 / 43
T-Systems · PDC Test · 2010

9. Frühe Korrektur ist billiger

3
Frühe Korrektur ist billiger
ISTQB Certified Tester
Foundation Level
Kosten
Reviews
Produktion
Test
Design
Anforderungen
Lebenszyklus
V 3.0 - 9 / 43
T-Systems · PDC Test · 2010

10. Kosteneffizienz – ein Beispiel

3
Kosteneffizienz – ein Beispiel
ISTQB Certified Tester
Foundation Level
Projekt R&I bei Ericsson Telecom
Reviews & Inspections (R&I) für 4.000 Personen an 40 Standorten
Zentrales R&I Competence Team aus 7 Personen leitet Einführung
Lokale R&I „Champions“ an den einzelnen Standorten
„Buy-in“ durch Roadshows, Trainingspakete und lokale
Steuerung der Prozesse.
Quelle:
Robert MacFarland, EuroSTAR 1998
V 3.0 - 10 / 43
T-Systems · PDC Test · 2010

11. Kosteneffizienz – ein Beispiel

3
Kosteneffizienz – ein Beispiel
ISTQB Certified Tester
Foundation Level
Bilanz R&I bei Ericsson Telecom
Geschätzte Kosten:
450.000 Pfund
Geschätzte Einsparungen:
1.800.000 Pfund
Return on investment (ROI)
4:1 (Schwankung 3:1 < > 6:1)
Geschätzte Zeitersparnis:
30.000 Personenstunden
10% der Arbeitsstunden
Ein 6-monatiges Projekt bräuchte ohne
Inspektionen fast 3 Wochen länger !
Quelle:
Robert MacFarland, EuroSTAR 1998
V 3.0 - 11 / 43
T-Systems · PDC Test · 2010

12. Weitere Erfahrungswerte

Quelle : Software Inspections,
Tom Gilb & Dorothy Graham
3
ISTQB Certified Tester
Foundation Level
Kosteneffizienz
Zeitrahmen um 25% reduziert
Über 80% der Fehlerzustände in jedem Stadium beseitigt
Wartungskosten um Faktor 28 reduziert
Kosten von Reviews
Etwa 5 bis 15% der Entwicklungskosten abhängig von
Anzahl der Dokumente im Review
Tiefe und Art des Reviews
Erfahrung mit der Durchführung
V 3.0 - 12 / 43
T-Systems · PDC Test · 2010

13. Statischer vs. dynamischer Test

3
Statischer vs. dynamischer Test
ISTQB Certified Tester
Foundation Level
Gemeinsames Ziel: Fehlerzustände finden
Statische und dynamische Techniken sind komplementär, da sie
auf verschiedene Fehlerarten abzielen
Statische Techniken finden primär Fehlerzustände
Dynamische Techniken finden primär Fehlerwirkungen
Statische Techniken brauchen keinen lauffähigen Code
Früherkennung / Vermeidung von Fehlerzuständen
Definitionen:
G Dynamischer Test: Prüfung des Testobjekts durch Ausführung auf
einem Rechner.
G Statische Analyse: Die Durchführung der Analyse eines Artefakts (z.B.
Anforderung oder Quelltext) ohne Ausführung der Software.
V 3.0 - 13 / 43
T-Systems · PDC Test · 2010

14.

1
2
3
4
5
6
ISTQB Certified Tester
Foundation Level
Statische Methoden
Statische Prüftechniken und der Testprozess
Reviewprozess
Werkzeuggestützte statische Analyse
V 2.1 - 14 / 43
T-Systems · PDC Test · 2010

15. Reviews im Allgemeinen

3
Reviews im Allgemeinen
ISTQB Certified Tester
Foundation Level
G
Review: Eine Reviewtechnik, welche durch ein dokumentiertes
Vorgehen und Anforderungen charakterisiert ist
G
Reviewprozess: Planung, Vorbereitung, Durchführung und
Nachbereitung eines Reviews [nach IEEE 610]
G
Peer Review: Ein Review eines Arbeitsergebnisses durch Kollegen
des Erstellers mit dem Ziel, Fehlerzustände aufzudecken und
Verbesserungsvorschläge zu identifizieren. Beispiele sind
Inspektion, technisches Review und Walkthrough.
Reviews können sehr informell oder sehr formal (strukturiert und
geregelt) sein. Der Grad des Formalismus ist abhängig von
Reife
des Entwicklungsprozesses
Regulatorischen Anforderungen
Bedarf
an einem Prüfnachweis
V 3.0 - 15 / 43
T-Systems · PDC Test · 2010

16. Formale Reviews – der Prozess

3
Formale Reviews – der Prozess
Dokument mit
Fehlerzustän
den
weniger
Fehlerzustände
Planung
Kick-Off
ISTQB Certified Tester
Foundation Level
Kontrolle
Individuelle
Vorbereitung
Reviewsitzung
V 3.0 - 16 / 43
Überarbeitung
Nachbereitung
T-Systems · PDC Test · 2010

17. Beschreibung der Reviewphasen (K1)

3
Beschreibung der Reviewphasen (K1)
Planung & Kontrolle
Review- und Prüftkriterien festlegen
Benötigte Teilnehmer identifizieren und ihnen eine Reviewrolle zuordnen
Welche
ISTQB Certified Tester
Foundation Level
Spezialisten werden als Gutachter benötigt?
Wer soll die Rolle des Moderators übernehmen?
Eingangsdokument(e) festlegen (z.B. Anforderungsspezifikation)
Nach dem Kick-Off stellt der Moderator sicher, dass die vereinbarte Planung
eingehalten wird und dass die Reviewsitzung stattfinden kann.
Kick-Off
Planung und Reviewprozess abstimmen
„Commitment“ der Teilnehmer einholen (vor allem der Gutachter)
Eingangsdokument(e) verteilen
Individuelle Vorbereitung
Überprüfen des Dokuments und Notieren von Fehlerzuständen
Bemerkung: Besonderheiten für Inspektionen (formale Reviewart) werden auf Seite 23 gelistet
V 3.0 - 17 / 43
T-Systems · PDC Test · 2010

18. Beschreibung der Reviewphasen (K1)

3
Beschreibung der Reviewphasen (K1)
Prüfen/Bewerten/Festhalten der Ergebnisse (Reviewsitzung)
Diskussion über individuelle Bemerkungen (vom Moderator geleitet)
Festhalner der Fehlerzustände
Empfehlungen und Entscheidungen treffen
Erstellen eines Protokolls (optional)
Überarbeitung
ISTQB Certified Tester
Foundation Level
Behebung der Fehlerzustände und Fragen beantworten (meist durch den Autor)
Nachbereitung
Prüfung der Überarbeitung (meist durch den Moderator)
Freigabe des Dokuments
Sammeln von Metriken
Bemerkung: Besonderheiten für Inspektionen (formale Reviewart) werden auf Seite 23 gelistet
V 3.0 - 18 / 43
T-Systems · PDC Test · 2010

19. Reviews – die Rollen (K1)

Moderator
(Leiter)
- Planung
- Coaching
- Nachbereitung
3
ISTQB Certified Tester
Foundation Level
- Auswahl der Teilnehmer
- Leitung der Meetings
- Metriken
Autor
- Hauptverantwortlich für das zu prüfende Dokument
- Meist „passive“ Teilnahme an Meetings
- Notwendige Dokumentenanpassungen
Gutachter
- Person mit notwendigem technischem oder fachlichem
Hintergrund, um Befunde identifizieren zu können
- Einzelprüfung des Dokuments
- Vorbereitung der Meetings
- „Aktive“ Teilnahme an Meetings
(Reviewer, Inspektor)
Manager
- Entscheidung über Reviewgegenstand
- Ansetzen des Reviews
- Zeit im Projektplan zur Verfügung stellen
- Überprüfung der Zielerreichung
Protokollant
- Aufzeichnung der Meetingresultate
- Versorgt den Leiter mit Informationen zur effektiven
Steuerung der Meetings
(Protokollführer)
V 3.0 - 19 / 43
T-Systems · PDC Test · 2010

20. Aufwände für die Aktivitäten

3
Aufwände für die Aktivitäten
Planung, Organisation
Moderator
Indiv. VorbereitungGutachter
ISTQB Certified Tester
Foundation Level
5%
65%
Reviewsitzung
Alle
10%
Korrektur, Anpassung
Autor, Moderator 10%
Metriken
Moderator
5%
Prozessverbesserung
Moderator
5%
Quelle : Software Inspections,
Tom Gilb & Dorothy Graham
V 3.0 - 20 / 43
T-Systems · PDC Test · 2010

21. Reviewarten*

3
Reviewarten*
ISTQB Certified Tester
Foundation Level
(*Siehe auch IEEE 1028
und die formalen Definitionen, Seite 44)
Alle Reviewarten können als Peer Reviews gestaltet werden
Reviewart
Beschreibung
Inspektion
Formale Prüfung gewöhnlich durch gleichgestellte Personen nach
vorgegebenen Regeln und Checklisten. Definierte Eingangs- und
Endebedingungen. Formalisierte Nachverfolgung. Leiter ist speziell
geschult. Primärziel Fehlerzustände finden
Technisches
Review
Fehlersuche durch technisch orientierte Personen. Häufig als Peer
Review ohne Management-Beteiligung. Große Bandbreite bezüglich
der Formalität. Ergebnisse werden dokumentiert. Primärziele
Diskussion, Bewertung, Fehler finden, Problemlösung, Entscheidung
Informelles
Review
Walkthrough
Kein formaler Prozess. Häufig praktiziert als billige aber kaum definierte
Reviewmethode. Dokumentation optional. Nutzen variiert abhängig vom
Gutachter (z.B. technischer Leiter oder Teamkollege).
Primärziel Kostengünstiges Fehler finden
Der Autor verliest ein Dokument und erläutert den gewöhnlich
gleichgestellten Teilnehmern spezielle Inhalte, Annahmen oder
Entscheidungen. Durchspielen von Szenarien. Oft sehr langwieriger
Prozess. Große Bandbreite bezüglich der Formalität.
Primärziele Know-How-Transfer, Konsensbildung, Fehler finden
V 3.0 - 21 / 43
T-Systems · PDC Test · 2010

22. Inspektion – der Prozess

3
Inspektion – der Prozess
Dokument mit
Fehlerzuständen
QuellDokumente
Kick-Off
Checklisten für
spezifische
Dokumenttypen
Prozeduren
für jede Rolle
und Aktivität
Extraschritt bei
Inspektionen
Unterstützende
Dokumentation
Planung &
Organisatorische
Vorbereitung
B
E
G
I
N
N
ISTQB Certified Tester
Foundation Level
Kontrolle
Individuelle
Vorbereitung
Reviewsitzung
V 3.0 - 22 / 43
Überarbeitung
Nachbereitung
T-Systems · PDC Test · 2010
E
N
D
E

23. Besonderheiten der Inspektion

3
Besonderheiten der Inspektion
ISTQB Certified Tester
Foundation Level
Definierte Eingangs- und Endbedingungen (Prozess wird mit
definierten Aufgaben und Kriterien begonnen bzw. beendet)
Rollenspezifische Prozeduren unterstützen den Prozess
Checklisten unterstützen die Prüfung und definieren schwere und
geringfügige Fehler
Hohe Effektivität durch eine relativ geringe, durch Metriken regulierte
Prüfgeschwindigkeit
Prozessverbesserung kann zu einem integralen Bestandteil des
Inspektionsprozesses definiert werden
Rollen und Verantwortlichkeiten erfordern spezielles Training
Meetings laufen formaler ab mit weniger Diskussion und schnellerer
Fehlererfassung. Autor ist nur „passiv“ dabei
V 3.0 - 23 / 43
T-Systems · PDC Test · 2010

24. Steuerung durch Metriken

3
Steuerung durch Metriken
ISTQB Certified Tester
Foundation Level
Ansatz für Technische Reviews:
Verfügbare Zeit
4 Stunden
Prüfgeschwindigkeit
50 Seiten/Stunde
Dokumentenlänge
200 Seiten
Einige Fehlerzustände
werden gefunden
aber viele
übersehen
Ansatz für Inspektionen:
MetrikDatenbank
Verfügbare Zeit
4 Stunden
optimale
Prüfgeschwindigkeit
2 Seiten/Stunde
Prüfbar
Mehr Fehlerzustände
werden gefunden
(auch die weniger
offensichtlichen)
8 Seiten
V 3.0 - 24 / 43
T-Systems · PDC Test · 2010

25. Inspektionen sind gründlicher

Aspekt
Technisches Review
3
ISTQB Certified Tester
Foundation Level
Inspektion
Ansatz bei der Prüfung
„Bitte suchen Sie Probleme
in diesem Dokument“
„Dies ist Deine Rolle, bitte prüfe
das Dokument anhand dieser
Prozedur nach dieser Checkliste“
Umfang der Prüfung
In der Regel das
gesamte Dokument
Teile des Dokuments, die speziell für
den Prüfer ausgewählt werden
Prüfgegenstand
Ein spezielles Dokument
Das Dokument selbst und alle
bei der Erstellung verwendeten
Dokumente
Umgang mit Fehlern
„Dies hier sieht irgendwie
nicht richtig aus“
„Verstoß gegen Regel N aus
Checkliste ABC“
Durchführung
des Meetings
Wenig kontrolliert mit viel
Diskussionen und häufig mit
Zeitüberschreitung. Autor ist
an Debatten über Lösungen
und Rechtfertigungen beteiligt.
Strikte Moderation, auf maximal 2
Stunden begrenzt, kaum Diskussion,
sehr fokussiert. Meeting findet nicht
statt, bevor die Eingangskriterien
erfüllt sind. Autor bleibt passiv.
Prüfmethode
Der Prüfer liest das Dokument
relativ schnell durch und macht
sich Notizen
Der Prüfer wertet das Dokument
anhand von Richtlinien und
Checklisten methodisch aus
V 3.0 - 25 / 43
T-Systems · PDC Test · 2010

26. Effektivität und Effizienz

3
Effektivität und Effizienz
Techn.
Review
ISTQB Certified Tester
Foundation Level
Inspektion
Einführung
Ausgereift
Effektivität*
10 - 20%
30 - 40%
80 - 95%
Return on
Investment
variabel
6-8
8 - 30
* Effektivität :
Aufdeckungsquote von Fehlerzuständen
V 3.0 - 26 / 43
Quelle : Software Inspections,
Tom Gilb & Dorothy Graham
T-Systems · PDC Test · 2010

27. Reviewarten im Vergleich

3
Reviewarten im Vergleich
Reviewtyp
Moderator
Inspektion
Speziell
geschult
(nicht
Autor)
Team
3-6
Vorbereit. Metrik
Ja
Resultat
Checklisten
ISTQB Certified Tester
Foundation Level
Vorteile
Effektiv
Ja
Im
Protokoll
Opt.
Geringer
Aufwand,
findet Fehler
Ja
Technisches
Review
Beliebig
3-6
Ja
Opt.
Im
Protokoll
Informelles
Review
Beliebig
3 - 10
Ja
Opt.
Opt.
Nein
Geringer
Aufwand
Opt.
Opt.
Opt.
Nein
Einführung
für großen
Teilnehmerkreis
Walkthrough
Autor
Viele
Teilnehmer
Opt. = optional
V 3.0 - 27 / 43
Nachteile
Anfangsinvestitionen
Subjektiv
Uneffektiv,
trügerische
Sicherheit
Relativ
aufwendig
Quelle : Software Inspections,
Tom Gilb & Dorothy Graham
T-Systems · PDC Test · 2010

28. Generelle Zielsetzung von Reviews

3
Generelle Zielsetzung von Reviews
ISTQB Certified Tester
Foundation Level
Bewertung und Prüfung von Artefakten (Dokumente, Spezifikationen,
Code, usw.) anhand von Anforderungen und Spezifikationen
Bewertung und Prüfung von Dokumenten anhand von Standards für
alle Produkte des Unternehmens
Früherkennung von Fehlerzuständen
Aufbau von Vertrauen in das Projekt, noch bevor der Code entsteht
Verbesserung des Prozesses, der zur Entstehung des geprüften
Dokuments führte
Mit Ausnahme der Inspektionen...
Konsensbildung über ein breites Spektrum an Themen im Projekt
V 3.0 - 28 / 43
T-Systems · PDC Test · 2010

29. Kritische Erfolgsfaktoren 1/2

3
Kritische Erfolgsfaktoren 1/2
ISTQB Certified Tester
Foundation Level
Verständnis der Rollen und Verantwortlichkeiten
Management-Unterstützung
Angemessenes Training in den nötigen Methoden
Einplanung benötigter Zeit und Ressourcen für Reviews
Lernfähigkeit: Neben reiner Fehlerkorrektur werden auch die
Fehlerursachen untersucht und bekämpft
Identifizierte Prozessverbesserungen werden angegangen
Überwindung von Widerständen gegen Formalien
Der Reviewprozess wird durch Standards (z.B. Rollen und
Checklisten) sinnvoll unterstützt
Klar definierte Ziele
V 3.0 - 29 / 43
T-Systems · PDC Test · 2010

30. Kritische Erfolgsfaktoren 2/2

3
Kritische Erfolgsfaktoren 2/2
ISTQB Certified Tester
Foundation Level
Einbindung der dafür geeigneten Personen, z.B. auch Tester
Bringen spezifisches Know-How ein
Werden früh mit dem Produkt vertraut
Einsatz von Techniken ist angepasst an Teilnehmer und
Reviewgegenstand
Offener und positiver Umgang mit
Gefundenen Fehlern
Verbesserungsvorschlägen
Fragen
Berücksichtigung psychologischer Aspekte
Gegenseitige Wertschätzung
Vermeidung von Vorwürfen und Rechtfertigungen
V 3.0 - 30 / 43
T-Systems · PDC Test · 2010

31.

1
2
3
4
5
6
ISTQB Certified Tester
Foundation Level
Statische Methoden
Statische Prüftechniken und der Testprozess
Reviewprozess
Werkzeuggestützte statische Analyse
V 2.1 - 31 / 43
T-Systems · PDC Test · 2010

32. Statische Analyse

3
Statische Analyse
ISTQB Certified Tester
Foundation Level
Prüfung, dass bestimmte Standards umgesetzt wurden:
Richtlinien zur Programmierung
Standards zur Dokumentation
Designgrundsätze
Früherkennung realer oder potenzieller Fehlerzustände, die vom
Compiler nicht und mit dynamischen Testmethoden nur unter hohem
Aufwand gefunden werden.
Aufschlüsse über Design und Code, die einen wertvollen Beitrag zur
Risikobewertung liefern.
Methoden sind z.B. Datenfluss- und Kontrollflussanalyse
Toolunterstützung notwendig, bspw. auch als automatische Kontrolle
beim Einchecken in einem Konfigurationsmgmt.werkzeug
V 3.0 - 32 / 43
T-Systems · PDC Test · 2010

33. Typische Datenfluss-Fehler

3
Typische Datenfluss-Fehler
ISTQB Certified Tester
Foundation Level
Typenkonflikte
Undeklarierte/uninitialisierte Variablen
Verletzung von Feldgrenzen
Schlechter Stil, der als Fehlerzustand gewertet werden kann,
z.B. implizite Typumwandlung
Solche Fehlerzustände werden häufig mit Tools ausgewertet
Zum Beispiel, Compiler können undeklarierte oder
uninitialisierte Variablen entdecken
V 3.0 - 33 / 43
T-Systems · PDC Test · 2010

34. Datenflussanalyse

3
Datenflussanalyse
ISTQB Certified Tester
Foundation Level
Deklaration, Definition und Referenzierung von Variablen
Eine Variable wird deklariert, wenn ihr ein Datentyp zugewiesen wird.
Eine Variable wird definiert, wenn ihr ein Wert zugewiesen wird.
Eine Variable wird referenziert, wenn dieser Wert verwendet wird.
Alle Variablen werden
deklariert
integer
sum, subtotal1, subtotal2
subtotal1 = calculate_subtotal(1)
subtotal2 = calculate_subtotal(2)
Variable sum
wird definiert
Potentieller Datenfluss-Fehler:
subtotal1 wird ohne
Aufruf neu definiert
Variablen subtotal1 und
`2 werden referenziert
sum = subtotal1 + subtotal2
integer
Variablen subtotal1 und
´2 werden definiert
sum, subtotal1, subtotal2
subtotal1 = 25
subtotal1 = calculate_subtotal(1)
sum = subtotal1 + subtotal2
V 3.0 - 34 / 43
Datenfluss-Fehler:
subtotal2 wird ohne
Definition referenziert
T-Systems · PDC Test · 2010

35. Typische Kontrollfluss-Fehler

3
Typische Kontrollfluss-Fehler
ISTQB Certified Tester
Foundation Level
Fehlerzustände (oder Indikatoren für Fehler), die durch
Kontrollflussanalyse aufgedeckt werden können:
Nicht ausführbare Anweisungen („Toter Code“)
Endlosschleifen
Mehrere Eingänge oder Ausgänge für Schleifen
Nicht definierte, nicht verwendete Sprungziele
Schlechter Stil, z.B. komplexe Zeigerarithmetik
Übertriebene Komplexität („Zyklomatische Komplexität“)
Abweichungen
von Styleguides zur Codestruktur
V 3.0 - 35 / 43
T-Systems · PDC Test · 2010

36. Kontrollflussanalyse

3
Kontrollflussanalyse
integer
integer
ISTQB Certified Tester
Foundation Level
sum, count, var1, subtotal1, subtotal2
bonus = 10000
subtotal1 = abs(calculate_subtotal(1))
subtotal2 = abs(calculate_subtotal(2))
Sonstiger Fehler:
Nicht abgefangene
Division durch Null
sum = subtotal1 + subtotal2
count = int (subtotal1 / subtotal2)
if (sum < count) then
count = 0
endif
Kontrollflussfehler:
Endlosschleife für
count >= 0
do while count >= 0
sum = sum + bonus
end do
Datenflussanomalie:
count wird neudefiniert : Verwendung
Kontrollflussfehler:
Anweisung wird
nie ausgeführt
Sonstiger Fehler:
Möglicher
Integerüberlauf
count = count -1
write (sum)
V 3.0 - 36 / 43
T-Systems · PDC Test · 2010

37. Zyklomatische Komplexität (CC)

3
ISTQB Certified Tester
Foundation Level
Statische Analysen
Zyklomatische Komplexität (CC) misst die Komplexität des
Kontrollflussgraphen
Zyklomatische Zahl = Anzahl Verzweigungen + 1
Anzahl unabhängiger Pfade
Höhere CC bedeutet einen komplexeren Kontrollfluss
Hohe Komplexität bedeutet häufig:
Code oder Design sind schwach strukturiert
Code oder Design sind fehlerträchtig
CC kann verwendet werden als Metrik für die relative Wahrscheinlichkeit
(d.h. das Risiko), dass ein vorliegendes Design oder Codestück
Fehlerzustände enthält.
V 3.0 - 37 / 43
T-Systems · PDC Test · 2010

38. CC - Übung

3
CC - Übung
ISTQB Certified Tester
Foundation Level
CC = 1
CC = 2
CC = 3
Legende
Proc.
Beispiele
if
do
CC = 8
V 3.0 - 38 / 43
T-Systems · PDC Test · 2010

39. Metriken der statischen Analyse

3
Metriken der statischen Analyse
Design- oder Codequalität
ISTQB Certified Tester
Foundation Level
Schnittstellenkomplexität
Kopplung
Fan-in / Fan-out
Kohäsion
Funktionsaufrufe
Datenflusskomplexität
Kontrollflusskomplexität
Operanden & Operatoren (Halstead)
Komplexität von OO-Systemen
Verschachtelungstiefe
McCabe Metrik (CC)
Tiefe des Vererbungsbaums
Sonstige
Methoden in einer Klasse
Lines of Code (LOC)
Viele Compiler und Entwicklungsumgebungen
liefern solche Informationen
V 3.0 - 39 / 43
T-Systems · PDC Test · 2010

40. Die Rolle des Compilers

3
Die Rolle des Compilers
Programmcode wird in Maschinencode „übersetzt“
Analyse des Programmcodes („Syntaxprüfung“)
Generierung von Informationen (nützlich in der Wartung):
ISTQB Certified Tester
Foundation Level
Variablennutzung
Referenzen
zwischen Variablen, deren Bezeichnern
und Verwendung in Funktionen (Cross Reference Listen)
Datentypkonflikte
Speicherbelegung
Generierung von Metriken
V 3.0 - 40 / 43
T-Systems · PDC Test · 2010

41. Eigenschaften statischer Analyse

3
Eigenschaften statischer Analyse
Vorteile
ISTQB Certified Tester
Foundation Level
Nachteile
Findet Fehler, die kaum durch
Inspektion und nur mit hohem
Aufwand durch dynamische
Tests aufgedeckt werden
Wird durch Tools unterstützt
Häufig früher durchführbar als
dynamische Tests
Auch auf Design anwendbar
Objektive Aussagen über die
Qualität von Design und Code
Gefundene Fehler müssen auf
Wichtigkeit interpretiert werden
Output der Tools muss gefiltert
werden, um die Informationen
überschaubar zu halten
Objektive Bewertung der Metriken
ist entscheidend, um das „Na
und?“ Problem zu vermeiden
Fehler beim Betrieb des Systems
(Timing, Speicherbelegung)
werden nicht gefunden
V 3.0 - 41 / 43
T-Systems · PDC Test · 2010

42. Besondere Stärken

3
Besondere Stärken
ISTQB Certified Tester
Foundation Level
Prüfung gegen Standards verbessert die Wartbarkeit von
Design
Code
Früherkennung von Abhängigkeiten und Inkonsistenzen in
Softwaremodellen (z.B. Links)
Schnittstellen (von Modulen, Komponenten, Systemen)
Fehlervermeidung (wenn neben individuellen Fehlern auch
systematische Ursachen identifiziert und bekämpft werden)
Aufdeckung
von Sicherheitsschwächen
V 3.0 - 42 / 43
T-Systems · PDC Test · 2010

43. Zusammenfassung: Statische Methoden

3
Zusammenfassung: Statische Methoden
ISTQB Certified Tester
Foundation Level
Reviews werden in frühen Projektphasen eingesetzt, um Fehlerzustände
in der Dokumentation zu finden
Es gibt verschiedene Reviewtypen: Walkthrough, Technisches Review,
Informelles Review, Inspektion ...
Ein Review kann als Prozess beschrieben werden
Inspektionen sind formaler, aber auch effektiver bei der Fehlersuche
Inspektionen verwenden Prozeduren und Checklisten
Inspektionen sind kosteneffizient!
Statische Analysen liefern Informationen über Qualität von Design bzw.
Code und finden Fehlerzustände, ohne den Code auszuführen
V 3.0 - 43 / 43
T-Systems · PDC Test · 2010

44. Änderungsverzeichnis

3
Reviewarten definiert
Reviewart
Inspektion
Technisches
Review
Informelles
Review
Walkthrough
Formale Definition nach
ISTQB Certified Tester
Foundation Level
G
Eine Reviewart, die Mängel durch die Sichtprüfung von
Dokumenten finden soll. Solche Mängel können sein:
Nichteinhaltung von Entwicklungsstandards, Nichtkonformität
gegenüber zugrundeliegenden Dokumenten. Es ist die
formalste Reviewtechnik und sie folgt deshalb einem
dokumentierten Vorgehen [nach IEEE 610, IEEE 1028].
Eine Diskussion in einer Gruppe gleichgestellter qualifizierter
Mitarbeiter, die sich darauf konzentriert, eine Übereinstimmung
über technische Vorgehensweisen zu erreichen [Gilb und
Graham], [IEEE 1028].
Review ohne festgelegten formalen (dokumentierten) Ablauf
Eine schrittweise Präsentation eines Dokuments durch den Autor, um
Informationen zu sammeln und ein gemeinsames Verständnis des
Inhalts aufzubauen. [Freedman and Weinberg]
V 3.0 - 45 / 43
T-Systems · PDC Test · 2010