gistfile1.txt

Benedikt Wolters

Zusammenfassung: Spillner - Basiswissen Softwaretests

Notizen/Anmerkungen/Zusammenfassungen
Teilweise stichprobenhaft, kein Anspruch auf Vollstaendigkeit.

==========================================
Kapitel 2 Grundlagen
==========================================

Begriffe

	Requirements/Anforderung:
		Bedingung/Fähigkeit, die eine Software erfüllen oder besitzen muss, 
		um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen

	Fehlerbegriff
		Fehler/Mangel: Nichterfuellung einer festgelegten Anforderung (Abweichung zw. Soll- und Istverhalten)
			(bspw. Beeintraechtigung der Verwendbarkeit, bei gleicher Erfuellung der Funktionalitaet)

		Ursachenkette fuer Fehler:
			Fehler entstehen nicht durch Alterung & Verschleiss
			-> seit Beginn in Software
			-> kommt jedoch erst bei der Ausfuehrung zu trage

		Fehlerwirkung (failure)/Fehlfunktion/ausserer Fehler/Ausfall
			-> hat Ursprung in einem Fehlerzustand (fault/defect)

		Fehlerzustand/innerer Fehler

		Fehlermaskierung: Fehlerzustand durch einen oder mehre Fehlerzustaende maskiert/verdeckt

		Fehlhandlung(error): Ursache fuer das Vorliegen eines Fehlerzustands

	2.1.2 Testbegriff
		Testen != Debugging
		Bekannt ist nur Fehlerwirkung, nicht die Stelle in der Software, die den Defect darstellt.
		Testen: stichprobenmhafte Ausfuehrung des Testobjekts, die der Ueberpruefung des Testobjekts dient.

		Testprozess: Plan, Durchfuehrung und Auswerten der Tests
		Testlauf: Ausfuerhung eines oder mehrerer Testfaelle
		Testfall: 
			-> Festgelegte Randbedingungen
			-> Eingabewerte/(erwartete Ausgabe/Verhalten)
			sollte so gewaehlt werden, dass er eine gewisse W'keit hat Fehlerwirkungen aufzudecken.
		Testszenario:
			Aneinanderreihung v. Testfaellen, wobei das Ergebnis eines Testfalls als Ausgangssituation fuer den folgenden Testfall genutzt wird

		Fehlerfreiheit ist durch Testen nicht erreichbar!

	2.1.3 Softwarequalitaet
		Testen dient Identifizierung von Defekten
		Beseitigunge der Defekte steigert die Softwarequalitaet
		Softwarequalitaet umfasst aber mehr als die Beseitigung der beim Tests aufgedeckten Fehlerwirkungen

		Qualitaetsmerkmale (nach ISO 9126 - Mnemo: 6 Items, 9 und 6 sieht so aehnlich aus wie Q, 1+2 = 3 *2 = 6,  6-2 = 4 digits)
			
			Funktionalitaet
			Zuverlaessigkeit
			Benutzbarkeit
			Effizienz
			Aenderbarkeit
			Uebertragbarkeit

	2.1.4 Testaufwand
		Austesten aller Moeglichkeiten praktisch nicht durchfuehrbar
		Testaufwand zu 25-50%
		Testaufwand bezahlt sich aus -> Risiko

		"Testen ist oekonomisch sinnvoll, solange die Kosten fuer das Finden und Beseitigen eines Fehlers
		im Test niedriger sind als die Kosten, die mit dem Auftreten eines Fehlers bei der Nutzung verbunden sind"

		Testintensitaet und - umfang abhaengig v. Risiko
		Test auf Funktionalitaet, die nicht gefordert ist
		Testfallexplosion:
			Dilemma fuer den Testmanager
			schnell viele Testfaelle + Testvarianten
			aber Beschraenkte Resourcen:
			Zeitverzug gegen Ende

		Fundamentaler Testprozess (wichtig fuer certified tester)

			Beginn
			  |
			 \/
			Planung 
			  |
			 \/
			Spezifikation
			  |
			 \/
			Durchfuerhung der Tests
			  |
			 \/
			 Protokollierung
			 |
			 \/
			 Auswertung
			  |
			 \/
			 Ende

	2.1.2 Testplanung
		- zu Beginn des Softwareprojekts
		- Resourcen, Hilfsmittel -> Testkonzept
		- wenn noetig Schulungen

		Festlegung der Teststrategie:
		- Prioritaeten anhand v. Risikoeinschaetzungen
		- optimale Verteilung der Tests auf die "richtigen" Stellen

		Ueberdeckungsgrad als Kriterium um ein Ende des Tests festzulegen
		Priorisierung der Tests
	2.2.2. Testspezifikation
		Spezifierung der Testfaelle unter den Methoden des Testplans
		logische vs. konkrete Testfaelle
			logisch: Aufgrund der Testsbasis (aus der Spezifikation), keine Konkreten Daten
			konkret: Anhand von konkreter (Eingabe-)daten
		Testfall:
			Vorbedingungen & Randbedingungen
			Nachbedingungen:
				- Pruefung der Ergebnisse und Reaktionen (insbesondere Negativtest)
				- Reaktionen auf ungueltige und unerwartete Eingaben (exception handling)
	2.2.3 Testdurchfuehrung
		- Pruefung auf Vollstaendigkeit der zu testenden Teile
		- Pruefung der Hauptfunktionalitaet zuerst, um Blocker zu finden
	2.2.4 Testprotokollierung
		Durchfuehrung ist zu protokollieren
		-> ohne Protokoll ist Testen wertlos
		Nachvollziehbarkeit wichtig
		Testrahmen, Eingabedatum, Testprotokoll
		Wiederholung sollte jederzeit moeglich sein
	2.2.5 Auswertung des Testendes / Testbewertung
		Liegt tatsaechlich eine Fehlerwirkung vor?
		Anhand der Fehlerklasse zu entscheiden mit welcher Prioritaet der Fehler zu Beheben ist
	Testende:
		Testende erreicht?
			Weiter aufwand gerechtfertigt?
			dead code, verhindert vollstaendige ueberdeckungs
			Kriterien zum Testende
				- Ueberdeckungskriterien
				- Fehlerfindungsrate (z.B. gefundene Fehler pro Teststunde)
		Abschliessende Arbeiten
			- Konservierung der Testware
			- Evaluation des Testprozess

2.3 Sollwerte und Testorakel
	Testorakel: gibt sollergebnisse vorraus
	Ermittlung der Sollwerte
		- Aufgrund des Solldatums der Spezi(fikation
		- Prototypen anhand v. Spezifikation
		- Softwareprogramm wird mehrfach von Unabhaengigen Entwicklergruppen erstellt ("Back-to-Back" Test)
	Weitere Orakel: Benutzungshandbuch, Diagramme, Modelle, Nutzungsprofile

2.4 Priorisierung der Tests
	Erforderlich falls Zeit knapp wird um moeglichst viele bzw. wichtige kritische/Fehlerwirkungen zu finden

	Kriterien fuer die Priorisierung:
		- Eintrittswahrscheinlichkeit einer Fehlerwirkung im Betrieb
		- Fehlerschwere/Eintrittsw'keit
		- Wahrnehmung einer Fehlerwirkung durch den Endandwender
		- Prioritaet der korrespndieren Anforderung
		- Qualitaetsforderund des Kunden
		- Aus Sicht der Entwicklung (Versagen hat schwerwiegende Auswirkugnen auf das System)
		- Komplextitaet der Komponenten/ Systemteile
		- Fehlerwirkungen mit hohem Projektrisiko (!= Produktrisiko)
			-> Fehlerwirkungen, die hohe Ueberarbeitungsfolgen mit sich bringen

		"Wo viele Fehler sind finden sich meist noch mehr!"

2.5 Psychologie des Testens
	Entwicklung -> Konstruktiv
	Pruefung -> Destruktiv

	Kann der Entwickler sein eigenes Programm testen?
		- Begegnung des eingenen Werks zu optimistisch
		- Interesse moeglichst keine Fehlerzustaende zu finden
		- eher am Programmieren interessiert
		- Designfehler schwer zu finden

		Blindheit gegenueber eigenen Fehlern vs. gute Kenntnis des Codes

	Mitteilung v. Fehlern
		"Its not a Bug, its a feature!"
			-> Unklare Anforderung/Spezifikation
			-> Kunde/Management entscheidet
	Gegenseitiges Verstaendnis:
		Tester sollten die Grundlage des SW-Entwicklung kennen und vice versa. 


==========================================
Kapitel 3 Testen im Softwarelebenszyklus
==========================================

3.1 V-Modell (allg.)


Anforderungsdefinition  <---------------------------------------------------- Abnahmetest
/\    \
 |     \
 ------Funktionaler Systementwurf  <--------------------------------------- Systemtest
            /\    \
             |     \
             ------Technischer Systementwurf <---------------------- Integrationstest
                /\    \
                 |     \
                 ------Komponentenspezifikation <---- Komponententests
                        \                                 /
                     /\  \                               /
                      |   \                             /
                      |    \                           /
                      ------       Programmierung 

 <---- Validierung 

 /\
 |----- Verifizierung

 \  bzw. / Konstruktion & Integration

 Anforderungsdefition: Wuensche und Anforderungen des Auftraggebers oder spaeteren Systemanwenders sammeln, spezifizieren und verabschieden
 Funktionaler Systementwurf: Abbildung der Anforderungen auf Funktionen
 Technischer Systementwurf: technische Realisierung des Systems wird entworfen, Schnittstellendefinition
 Komponentenspezifikation: Fuer jedes Teilsystem werden Aufgabe, Verhalten, innerer Aufbau und Schnittstellen zu anderen Teilsystemen realisiert
 Programmierung: klar.

 Komponententest: prueft jede einzelne Softwarekomponente fuer die Vorgabe seiner Spezifikation
 Integrationstest: prueft ob Gruppen v. Komponenten im teschnischen Systementwurfe zusammenarbeiten
 Systemtest: prueft das System als ganzes hinsichtlich der Anforderung
 Abnahmetest: Pruefung aus Kundensicht auf vertraglich verebarte Leistung

 Validierung: Pruefung der Entwicklungsergebnisse gegen urspruengliche Anforderungen bzw. Spezifikation
 Verifikation: Pruefung auf Korrektheit und Vollstaendigkeit des einzelnen Phasenergebnisses

3.2 Komponetentest
	Testobjekt: Einzelne Softwarebaustein (Klasse, Unit, ... )
	Testtreiber notwendig: 
		Testtreiber: Programm, das die jeweilige Schnittstellen aufrufe absetzt und die Reaktion des Testobjekts entgegennimmt
	Testziele:
		Test der Funktionalitaet (Funktionstests)
		Test auf Robustheit (Abfangen v. Fehlersituationen -> Negativtest)
		Effizienz und Wartbarkeit
		Effizienz: Speicherplatz/Rechenzeit -> seher selten nur dort wo Anforderungen vorhanden sind
		Wartbarkeit: Codestruktur, Modularitaet, Kommentierung, Veraendlichkeit, Aktualitaet der Dokumentation
		Whitebox-Test:
			Tester kennt komponenteninterne Programmstruktur (Methoden, Variablen,)
			Per Debugger kann der interne Zustand veraendert werden (Test auf Robustheit)

		Oft sind einzelne Komponenten nicht oder nur als Zusammengesetzte Einheit testbar -> Integration- und Testplanung 

3.3. Integrationstest
	Vorraussetzung: vorheriger Komponententest
	Integration: Entwickler verbbinden Komponente zur groesseren "Baugruppe"
	"Integration im Grossen": Schnittstellen zur Systemumgebung ist Gegenstand von Integrationstest (z.B. Datenbank, Betriebssystem)

	Testumgebung: ggf. Wiederverwendbarkeit der Testtreiber aus Komponententest (wenn die gut geschrieben sind, sonst teure Neuentwicklung)
		Monitore: Programme die Datenbewegung zw. Komponenten mitlesen und protokollieren (z.B Netzwerkprotokolle)

	Testziele: Schnitstellenfehler aufdecken
		typische Fehler: 
			- funktional: Komponente uebermittelt keine oder falsche Daten
			- Fehlinterpretation der uebergebene Daten
			- Timing-Problem, Durchsatz-,Kapazitaets-,Lastproblem

	Kann auf Komponententest durch Integrationstest verzichtet werden?
		- Zugang zur Einzelkomponente im Integrierten Szenario schwer
		- dadurch bestimmte Provokation von Fehlerwirkungen nicht mehr moeglich
		- schwierig entstehungsort von Fehlern Einzugrenzen.

	3.3.5 Integrationsstrategien
		Schwierigkeit: Komponenten werden zu versch. Zeitabschnitten fertig
		Loesung: Platzhalter (stub)

		Je frueher integriert wird desto mehr Platzhalter notwendig

		Top-Down-Integration: Beginnt mit der (Wurzel)Komponente, die keine anderen Komponenten aufruft ->sukzessives Hinzufuegen niedriger Systemschichten
			Vorteil: einfache Teststreiber
			Nachteil: Platzhalter fuer untergeordnete Komponenten muessen geschrieben werden\

		Bottom-Up-Integration: Beginnt mit der elementaren Komponenten (Blaetter), grosse Teilsysteme werden sukzessive integriert
			Vorteil: wenig, bis keine Platzhalter
			Nachteil: Uebergeordnete Komponenten muessen durch Platzhalter simuliert werden 

		Ad-Hoc Integration:
			Zufaellige Integration der Komponenten anhand Ihrer Fertigstellung (chaotisch)
			Vorteil: Zeitgewinn, fruehe Integration
			Nachteil: Sowohl Platzhalter als auch Testtreiber notwendig.

		Big-Bang (Ploetzliche Integration aller Komponenten am Ende) vermeiden!
			Nachteil: Verlorene Testzeit durch Wartezeit, Fehlerwirkungen treten geballt auf

3.4 Systemtest
	Gruende fuer Systemtest: 
		-> Aus Perspektive des Kunden/Anwenders
		-> Viele Funktionen sind erst auf Ebene des Gesamtsystems beobachtbar u. testbar
	3.4.2 Testobjekt und Testumgebung:
		-> moeglicst nahe am Produktivumgebung 
		erfordert separate Testumgebung (nicht in der Produktivumgebung), denn
			- Beintraechtigung des Produktivumgebung des Kunden -> Systemausfall/Datenverlust
			- keine oder  geringe kontrolle ueber parameter und Konfiguration der Produktivumgebung

		Testziele
			2 Klassen
			 - Funktionale Anforderungen
			 - Nicht funktionale Anforderungen
		Test funktionaler Anforderungen
			anforderungsbasierte Tests
				Ableitung v. Testfaellen aus Anforderung
			anwendungsfallbasierte Tests
				anhand v. use-cases
			Lasttest - steigernde systemlast
			Peformanztests - Verarbeitungsgeschwindigkeit/Antwortzeit
			Volumen/Massetest - Abhaengigkeit der Datenmenge
			Stresstest - Ueberlastung
			Datensicherheit - unberechtigter Zugriff
			Stabilitaet/Zuverlaessigkeit - Dauerbetrieb
			Robustheit - Fehlbedienung, Hardwareausfall
			Kompatibilitaet - Import/Export
			unterschiedliche Konfigurationen - Betriebssysteme, Sprachen, Hardwareplattform
			Benutzerfreundlichkeit - Erlernbarkeit, Angemenssenheit der Bedienung
			Dokumentation
			Aenderbarkeit/Wartbarkeit

		Probleme
			Unklare Kundenanroderungen
			-> nur in den Koepfen
			Versaeumte Entscheidungen werden aufgedeckt
			nachtraegliche Anforderungsdefinition
			daher: Systemtest attestiert Scheitern des Projekts oftmals 

3.5 Abnahmetest
	Test auf vertragliche Aktzeptanz
	 -> Spezielle Form des Systemtests
	 in der Abnahmeumgebung des Kunden statt in der Systemtestumgebung != Produktivumgebung
	 Test auf Benutzeraktzeptanz
	 	Aktzeptanz jeder Anwendungsgruppe sicherstellen
	 	Prototypen vorzeitig vorstellen
	 	Umfang abh. von Risiko

	 Feldtest: Test durch repraesentative Kunden
	 	Alpha-Test: beim Hersteller
	 	Beta-Test: beim Kunden

3.6 Test neuer Produktversionen
	3.6.1 Wartung
		Anlaesse
			-System unter neuen unvorhergesehen, nicht geplaten Bedingungen eingesetzt
			- neue Kundenwuensche
			- Funktion fuer seleteneer und ungetestete Sonderfaelle benoetigt
			- sporadisch/nach laengerer Betriebszeit Ausfaelle
	3.6.2 Geplante Weiterentwicklung
		neuer Durchlauf des Projektphasen
		-> iterative Softwareentwicklung
	3.6.3 Regressionstest
		Sowohl Wartungsarbeiten/Weiterentwicklung
		Erneuter test des bereits getesteten Programms nach dessen Modifikation mit dem Ziel,
		dass keine neuen Defekte oder bisher maskierte Fehlerzustaende freigelegt wurden durch die Aenderung

		Umfang:
			1.) Wiederhoilung aller Test (Fehlernachtest)
			2.) test aller Programm,stellen, die geaendert wurden
			3.) Test neuer Funktionalitaet 
			4.) Komplette System (vollstaendiger Regressionstest)
				vollstaendiger Regressionstest idR sinnvoll aber zu kosten/zeitintensiv
				daher: 
					- Wiederholung von Tests aus dem Testplan, denen hohe Prioritaet zugeordnet ist
					- Verzicht auf gewisse Varianten v. Test
					- Einschraenkung auf bestimmte Konfigurationen
					- Einschraenkung auf bestimmte Teilsysteme/Teststufen




==========================================
Kapitel 4 statischer Test
==========================================

Testobjekt wird nicht ausgefuehrt, sondern analysiert!

4.1 strukturierte Gruppenpruefungen

	4.1.2 Reviews/Inspektion
		-Ueberprueft Semantik v. Dokumenten
		-Mittel zur Sicherung der Qualitaet
		verifizierende Pruefung (V-Modell Abschluss einer Phase)
		Vorteil: 
			- Fehler werden fruehzeitig erkannt
			- Wissensaustausch
			- Zwang zur klaren Darlegung deckt Fehler womoeglich direkt beim Autor auf
			- Verantwortung fuer die Qualitaet des untersuchten Objekts traegt das Team
		Schwierigkeit:
			- psychologische angespannte Situation fuer Autor
			  (Pruefsituation)

	4.1.3 Grundlegende Vorgehensweise (nach IEEE 1028 - Mnemo: 1024 + 4 )

		Planung:
			-Welche Objekte?
			-Welcher Aufwand?
			-Zusammenstellung v. fachlich geeigneten Personen durch Manager -> Reviewteam
			-Reviewfaehigen Status durch Manager sicherstellen -> sonst rueckgabe an Autor

		Einfuehrung:
			Vorbersprechnung/Intialisierung
			Sinn und Zweck erlaeutern
			Bereitstellung v. notwendigen Dokumenten (Doku, Standards, Spezifikation etc.)
			Basisdokumente (baseline)
			Pruefkriterien

		Vorbereitung:
			Intensive Auseinandersetzung mit den Pruefobjekt durch einzelne Mitglieder
			Erkannte Maengel, Frangen, Kommentare notieren

		Reviewsitzung:
			Sitzungsleiter/Moderator
			fester Zeitrahmen
			Beurteilung des Profobjekts in Bezug auf Einhealtung und Umsetzung der Vorgaben und Richtlinien

			Regeln in der Reviewsitzung:
				- Begrenzung auf 2 Stunden
				- Moderator kann Sitzung absagen, wenn
					1. ) Gutachter schlecht vorbereitet
					2. ) er aus irgendinem Grund nicht in der Lange ist die Sitzung zu halten
				- Resultat und nicht der Autor stehen zur Diskussion
					-Ausdrucksweisen
					-autor sollte keine Angriffen ausgesetzt werden (Moderatorintervention)
				- Moderator != Gutachter
				- Allgemeine Fragen / Stilfragen duerfen nicht diskutiert werden
				- Entwicklung / Diskussion v. Loesungen ist nicht Aufgabe des Reviewteams
				- Jeder Gutachter muss gelegenheit haben seine Befunde angemessen zu praesentieren
				- Befunde != Anweisungen fuer den Autor
				- Gewichtung der Befundnisse
					- kritisch (unbrauchbar) 
					- Hautpfehler (beeintraechtigt)
					- Nebenfehler (geringfuegige Abweichumg)
					- Gut.

			Empfehlung ueber die Annahme des Pruefobjekts

		Nachbereitung
			Manager entscheided ob er Reviewempfehlung ueber Freigabe folgt
			Weiteres Review ansetzen?
			Auswertung des Reviewprozesses selbst
			Wiederkehrende oder haeufige Fehlerarten weisen auf Defizite in 
				a) Softwareentwicklungsprozess 
				b) Fachwissen 
				hin -> Schulungen ansetzen

	4.1.2 Rollen und Verantwortlichkeiten
		Manager:
			Auswahl der Pruefobjekte
			Bereitstellung v. Resourcen
			Sollte an Sitzungen nicht Teilnehmen!

		Moderator:
			leitet die Sitzung
			Darf nicht voreingenommen sein / achtet auf Untertoene

		Autor:
			stellt das Dokument
			Selektierung Hauptverantwortlicher falls mehrere

		Gutachter:
			Fachexperten
			unterschiedliche Sicht (Anwender, Sicherheit, Tests, ....)
			Kennzeichnung der Teile (gut - mangelhaft)

		Protokollant aka. Tippse
			dokumentiert ggf. Unklarheiten
			knapp und praezise formulieren


	4.1.5 Reviewarten (IEEE 1028)

		Walkthrough:
			informell
			Autor praesentiert das Dokuemnt in einer Sitzung den Gutachtern
			Vertiefung des Wissens 
			Vorbereitung hat geringen Umfang
			Geeignet fuer kleine Entwicklungsteams

		Inspektion
			folgt (sehr) formellen Ablauf
			Ziel: Aufdeckung v. Unklarheiten, Fehlern & Defekten, Bestimmung der Qualitaet
			anhand v. Checklisten
			Bewertung der Entwicklungs-/Inspektionsprozesses

		Technisches Review
			Uebereinstimmung mit Spezifikation
			Einhaltung von Standards
			Eignung fuer den Einsatz
			Hoher Aufwand in der vorbereitungsphase gegeben
			Autor nimmt in reviewsitzung nicht Teil
			Ergebnis muss einstimmig im Gesamturteil gefaellt und von allen Personen getragen und unterzeichnet werden.
			Nicht Aufgabe ueber Konsequenzen des Ergebnisses zu entscheiden -> Aufgabe des Managements.

		Informelles Review
			stark vereinfachte Form
			oft durch Autor initieiert
			ggf. blosses gegenlesen


4.2 Statische Analyse

	Keine Ausfuerhung des Pruefobjekts
	Ziel: Aufdeckung vorhandener Fehler, fehlertraechtiger Stellen
		Ermittlung von Messgroessen zum Nachweis v. Qualitaet

	Vorraussetzung: formale Struktur liegt vor

	Alle Compiler fuehren statische Analyse durch (z.B. Syntaxpruefung)
		Verletzung der Syntax
		Konventions- und Standardabweichung
		-> Datenflussanomalien
		-> Kontrollflussanomalien
		-> typgerechte Verwendung 
		-> nicht deklarierte Variablen
		-> nicht erreichbarer Code

	Datenflussanalyse
		Datenflussanomalien
			bswp. referenzierung ohne initialisierung (ur-anonmalie)

			Drei Zustaende von Variablen
				definiert(d): Variable erhaelt einen Wert
				referenziert/read(r): Variable wird gelesen bzw. verwende
				undefiniert(u): Variable hat keinen definierten wert


			ur-Anomalien: Undefinierter Wert wird auf einem Programmpfad gelesen
			du-Anomalie: Variable erhaelt einen Wert (d) der allerdings ungueltig wird
			dd-Anomalie Die Variable erhalet auf einem Programmpfad ein zweites Mal einen Wert ohne das der erste wert verwndet wurde!

	Kontrollflussanalyse
		Kontrollflussgraph
			Sequenzen von Anweisungen werden ebenfalls als einziger Knoten dargestellt
		Kontrollflussanomalien
			z.B. Spruenge aus Schleifen
				Programmstueck das mehrere Ausgaenge hat

		Vorgaenger-Nachfolger Tabelle
			wie steht jede Anweisung mit anderen Anweisungen in Beziehung
			-> Dead Code?

		4.2.5 Ermittlung v. Metriken
			Metrik liefert immer nur Aussage ueber eien bestimmten Aspekt 

			Zyklomatische Zahl (McCabe Komplexitaet)
				"misst strukturelle Komplexitaet des Quellcodes"

				V(G) = e-n + 2p 

				e = Anzahl Kanten im Kontrollflussgraph
				n = Anzahl der Knoten
				p = Anzahl der verbundenen Komponeten (idR  1)

				Abschaetzung im Bezug auf Wartbarkeit / Testbarkeit



==========================================
Kapitel 5 Dynamischer Test
==========================================

Testen der Software durch Ausfuehren

erfodert Ablauffaehiges Programm

Komponententest/Integrationstest erfodert Testrahmen (test bed)

Stellvertreter (stub) - wenn noch nicht fertig implementiert/simuliert

BlackBox-Verfahren: (aka funktional)
	PoD (Point of Observation) liegt ausserhalb des Testobjekts
	PoC (Point of Control)  liegt ausserhalb des Testobjekts

WhiteBox (!!! strukturell)
	wird auch auf den Programmtext zuruechgegriffen
	innerer Ablauf des Programmtext analysiert


Test-First/test-driven -> Blackbox Verfahren

5.1 BlackBox Verfahren

	5.1.1 Aequivalenzklassenbildung

		Einteilung der Eingabewerte in Aequivalenzklassen
		-> Ungeultige werte wichtig
		-> Annahme: Test v. Werten in gleicher Aequivalenzklassen bringt keine neue Erkenntnis
			1.) Ermittlung des Definitionsbereichs
			2.) Verfeinerung der Aequivalenzklassen
				-> Eingabewerte
				-> Ausgabewerte

			Kombinationsregel
				1.) Representante "gueltiger" Aequivalenzklassen mit allen moeglichen Kombinationen tests -> gueltiger Testfall
				2.) Representaten "gueltiger" Aequivalenzklassen nur mit "ungueltigen" Aequivalenzklassen kombinieren -> Negativ-Testfall

			Bei wenigen Parametern bereits viuele gueltige Testfaelle

			Regeln zur Testfalleinschraenkung
				1.) Nach Haeufigkeit sortieren (Reihenfolge priorisieren)
				2.) Bevorzugung v. Grenzwerten/Grenzwertkombinationen
				3.) Paarweise Kombination statt vollsteaendiger Kombination der Representanten
				4.) Jeder Repaesentatant mindestens einmal
				5.) Representanten ungueltiger aequivalenzklassen nicht miteinander kombinierem

			Testendekriterien
				Ak-Ueberdeckung = (#getester AK / # AK ) * 100 %

	5.1.2 Grenzwertanalyse 
		Ergaenzung zu den Testfaellen, die durch Aequivalenzklassenbildung entstandne sind.
		nur sinnvoll bei geordneten Daten und wenn sich Grenzen identifieren lassen
		jeder Rand wird bereucksichtigt (innerhalb/ausserhalb)
		+ Grenzwert selbst
		Bei Flieskommazahlen -> Toleranzen beachten

		GW-Ueberdeckung = (Anzahl getestete GW / gesamtzahl GW) * 100%

		Zusammenfallende werte gelten als ein Wert


	5.1.3 Zustandsbezogene tests
		Uebergansbaum erstellen
		Erweiterung des Uebergangsbaums - alle Funktionen
		Eigenen sich gut bei Systemtests / GUI

		Testendekriterien

			Zustand wurde min einmal erreicht
			Jeder Zustanduebergang wurde min einmal ausgefuehrt
			Alle spezifikationsverletzenden Zustandsuebergaenge wurden geprueft

	5.1.4 Allgemeine Bewertung der BlackBox Verfahren

		Weitere Blackbox Verfahrne
			Ursache-Wirkungs-Graph Analyse
			Syntaxtest (Syntax der Eingaben kommt aus Spezifikation != Syntaxueberpruefung des Codes, daher BlackBox)
			Zufallstest
			Smoke Test


		Nachteile:
			- erkennen keine Fehler der Spezifikation (-> Reviews)
			- Kann nicht ueberprueft werden ob Testobjekt zusaetzliche Funktionalitaet bereitstellt
			- Ueberdeckungskriterien nur nach Anforderungen

5.2 Whitebox Verfahren

	-> codebasierte Testverfahren

	-> Programmtext muss vorliegen und wird u.U. manipuliert (instrumentalisiert)

	Idee: Alle Codeteile sollen min 1. zur Ausfuehrung kommne

	- Anweisungsueberdeckung (C0)
	- Zweigueberdeckung (C1)
	- Test der Bedingungen 
		- Einfache Bedingungsueberdeckung
		- Mehrfachbedingunsueberdeckung
		- Minimale Mehrfachbedingungsueberdeckung
	- Pfadueberdeckung

	5.2.1 Anweisungsueberdeckung 
		-> Transformation in Kontrollflussgraphen
		Anweisungen als Knoten, Kontrollfluss als Kanten
		Kriterien zur Beendigung 
			 Anweisungsueberdeckung =  #durchlaufener Anweisungen / Anweisungen 
			 	(C0 Mass)

	5.2.2 Zweigueberdeckung
		Ueberdeckung der Zweige des Kontrollflussgraphen
		C1-Mass analog

	5.2.3. Test der Bedingungen
		Einfache Bedingungsueberdeckung (branch condition testing)
			jede atomatre Teilbedingung muss einmal den Wert wahr bzw. falsch annehmen
			schwaecher als Anweisungs/Zweigueberdeckung
		Mehrfachueberdeckung (branch condition combination testing)
			moeglichst alle Varianten der atomaren Teilbedingungen
			Komplexitaet steig 2^n
			Nicht immer moeglich ( x > 5 && x <= 3)
		Minimale Mehrfachueberdeckung (modified branch condition decision testing)
			Nur Kombinationen bei denen die Aenderung des Wahrheitswertes den Wahrheitswert der logischen Verknuefung anedenr Kann

			Beispiel 
			T od. T  = T <-- entfaellt T da maskiert
			T od. F
			F od. T
			F od. F 

			# Testfaelle liegt zw. 2n und n+1 (n Anzahl boolscher Operanden)


		minimale Mehrfachueberdeckung >>> Zweigueberdeckung >>> Anweisungsueberdeckung

		Probleme: vorgezogene Boolsche variablen die in Bedingungen auftauchen, Compileroptimierung


	5.2.4 Pfadueberdeckung

		Pfadueberdeckung: forder Ueberdeckung aller moeglichen Pfade im Testobjekt 
		Alle Pfade von Beginn nach Ende
		Bei schleifen  keine 100% ueberdeckung moeglich

	Instrumentierung des Testobjkekts
		Um Whitebox Verfahren auzuwerten (z.B. Zaehler)
		=> Werkzeuge zur Instrumentierung nutzen.

5.3 Intuitive Testfallermittlung
	ergaenzt systematische Testfaelle
	Grundlage Erfahrungswerte 
	nicht als erstes oder einziges Testverfahren verwenden -> nur zur ergaenzung


==========================================
Kapitel 6 Testmanagement
==========================================

	Organisationsformen
		1.) Testen liegt ausschliesslich in der Verantwortung des einzelnen Entwicklers.
			Jeder Entwickler testet seine eigenen Programmteile
		2.) Testen liegt in der Verantwortlichkeit des Entwicklungsteams.
			Die Entwickler testen ihre Programmteile gegenseitig.
		3.) Mindestens ein Mitglied des Entwicklerteams ist fuer Testarbeiten abgestellt.
			Es erledigt alle Testarbeit des Teams
		4.)	Es gibt ein oder mehrere dedizierte Testteams innerhalb des Projekts, die nicht an der Entwicklung beteiligt sind.
		5.) Eine separate Organisation (Testabteilung, externer Dienstleister) uebernimmt das Testen.

	Problem: "Blindheit gegenueber eigenen Fehlhandlungen"
		=> Erstrebenswert: Test und Entwicklung moeglichst unabhaengig zu organisieren

	Komponententest:
		Modell 1) (s.o.) oft anzutreffen aber schlecht
		Modell 2) kann oft realisiert werden und bringt Qualitaetsgewinne
		Modell 3) sinnvoll sofern genuegend Tester abgestellt werden

		Gefahr Entwickler verstehen sich im Wesentlichen als Entwickler und vernachlaessigen Testarbeit
			-> Loesung: Testplaene vorgeben, Testprotokolle einfordern

			Coaching durch Testspezialisten

	Integrationstest:
		methodisch analog zum Komponententest
			- Je nach Groesse 3-5 erwaegenswert
			- gemischtes Integrationsteam (beide Entwicklerteams aus beiden Komponenten, da sonst einseitig Sicht)

	Systemtest
		nur Modell 4/5 (s.o.)

6.2 Mitarbeiterqualifikation

Testmanager: Experte fuer Testplanung und Teststeuerung mit Know-How/Erfahrung in den Bereichen Softwaretest, Qualitaetsmanagement, Projektmanagement und Personalfuehrung

Testdesigner: Experte fuer Testmethoden, Testspezifikation, mit Know How/Erfahrung in den Bereichen SW-Test, Software-Engineering und Spezifikationsmethoden

Testautomatisierer: Experte fuer TEstautomatisierung (Testgrundlagenwissen, Programmiererfahrung und sehr gute Kenntnisse der eingesetzten Testwerkzeuge und Scriptsprachen)

Testadministrator: Experte fuer Installation und Betrieb der Testumgebung (Sysadmin Know-How)

Tester: Experte fuer Testdurchfuerhung und Fehlerberichte (IT-Grundlagen, Grundlagenwissen, Bedienung der eingesetzten Testwerkzeuge, Verstaendnis des Testobjekts)


Testprozess:
	Testplanung			| parallel zu Entwicklungsarbeiten
	Testspezifikation 	| 
	Testdurchfuerhung
	Testprotokollierung
	Testbewertung

Testmanager: initiert und ueberwacht Testzyklen je nach groesse einzelner Testmanager pro Teststufe

Testzyklusplanung:
	zu berueckschtigen:
		Entwicklungsstand - eingeschraenkte oder veraenderte funktionalitaet
		Testergebnisse: vorrangegangene Testzyklen machen eventuell eine Aenderung der Testpriorisierung notwendig
			korrigierte Defekte erfordern Fehlernachtests, die wiederrum einzuplanen sind

		Resourcen: Der akt. Testzyklus muss mit dem aktuellen Projektplan in Einklang stehen.
			-> Urlaubs/Personalplanung, Verfuegbarkeit der Testumgebung / Testwerkzeuge

			-> Schaetzung des Aufwands / Zeitbedards
			-> Festlegung welche Testfaelle von welchen Tester in welcher Reihenfolge auszufuerhren sind

6.3.2 Testzyklusueberwachung
	anhand v. Testmetriken
	- Fehlerbasierte Metriken: #gefundene Fehlerzustaende
	- Testfallbasierte Metriken: #spezifizierter und geplanter Test, #blockierter Tests, #nicht Fehler -aufdeckender Tests
	- Testobjektbasierende Metriken: Codeabdeckung, Dialogabdeckung, abgedeckte Installationsvarianten

Teststatusbericht:
	beinhaltet
		- Testobjekte/Teststufe/Testzyklus-Datum
		- Testfortschritt: geplante/gelaufene/blockierte Test
		- Fehlerstatus: neue/offene/korrigierte Fehler
		- Risiken: neue/veraenderte/bekannte Fehler
		- Ausblick: Planung des naechsten Testzyklus
		- Gesamtbewertung: Beurteilung der Freigabereife des Testobjekts

Testendekriterien
	haengt ab v. Kritikalitaet der Software
	verfuegbare Testresourcen (Zeit,Personal,Werkzeuge)
	muss so gewaehlt sein, dass es sich aus den laufend erhobenen Metriken berechnen laesst

Produktfreigabe
	Auslieferung: Uebergabe an die nachfolgende Teststufe
	Systemtest -> Kunde
	Abnahmetest -> Einsatz

	Freigabe != Fehlerfreiheit

6.3.3 Testzyklussteuerung
	Reagiere auf Planabweichungen
		-> mehr Resourcen bereitstellen (Personal, Arbeitsplaetze, Werkzeuge)
		-> Anpassens des Testplans (Streichung v. Test mit niedriger Prioritaet, Testvarianten in nur einer Variante, ...)7
		-> gravierende Maengel/Defekte
			=> Verlaengerung der Testdauer

6.4 Testplanung 
	Qualitaetssicherungsplan (IEE 739)
		Zweck und Anwendungsbereich
		Referenzierte Dokumente
		Projektorganisation und Management
		Dokumentation
		Standards, Verfahren, Konventionen und Metriken
		Software-Reviews
		Softwaretests
		Problemmelde und Korrekturverfahren
		Werkzeuge, Techniken und Methoden
		Verwaltung der Medien und Datentraeger
		Lieferantenmanagement
		Qualitaetsaufzeichnungen
		Trainigsmassnahmen
		Risikomanagement
		Glossar
		Aenderungsverfahren und Aenderungsverzeichnis

	Testkonzept (test plan != schedule)

		Grobplanung erfolgt moeglichst frueh
		IEEE 829 (bzw. 1012)

		1.) Testkonzeptbezeichnung
		2.) Einfuerhung
		3.) Testobjekte
		4.) Zu testende Leistungsmerkmale
		5.) Leistungsmerkmale, die nicht getestet werden
		6.) Teststrategie
		7.) Abnahmekriterien
		8.) Kriterien fuer Testabbruch/Testfortsetzung
		9.) Testdokumentation
		10.)Testaufgaben
		11.)Testinfrastruktur
		12.)Verantwortlichkeit/Zustaendigkeit
		13.)Personal, Einarbeitung, Ausbildung
		14.)Zeitplan/Arbeitsplan
		15.)Planungsrisiken und Unvorhergesehenes
		16.)Genehmigung / Freigabe

6.5 Konsten - und Wirtschaftlichkeitsaspekte
	Ab wann Aufwand/Nutzen?

	6.5.1 Fehlerkosten
		Direkte Fehlerkosten: Kosten durch Fehlerweirkungen beim Betrieb der Softwareprodukts -> beim Kunden
		Indirekte Fehlerkosten: Kosten/Umsatzverlust fuer Hersteller
		Fehlerkorrekturkosten: Kosten im Zuge der Fehlerkorrektur: Fehleranalyse, Regressiungstest, erneuge Auslieferung, Verzug etc.

		Risikoanalyse
			Testkosten werden beeinflusst v. 
				-> Reifegrad des Entwicklungsprozess
					Fehlerhaeufigkeit der Entwickler, Rate von Softwareaenderungen
				-> Testbarkeit der Software 
					Aussagekraft / Qaulitaet Doku
				-> Testinfrastruktur
					Verfuegbarkeit v. Testwerkzeugen
						Testumgebung / infrastruktur
				-> Mitarbeiterqualifikation
				-> Qualitaetsziele
					Angestrebte Abdeckung / Restfehlerrate / Zuverlaessigkeit
				-> Teststrategie
					Anzahl und Umfang der Teststeufen, Wahl der Testmethoden, Zeitliche Planung der Tests

			Wann soll mit Testen begonnen werden?
				so frueh wie moeglich
				allen Phasen

6.6 Fehlermanagement
	Testprotokoll
		Analyse: Soll vs. Istverhalten
			Ursache Aufgabe der Entwickler
		Fehlermeldung:
			Problemmeldung
			Fehlerdatenbank
			Einheitliches Schema

			Fehlerklassifikation: Severity
			Fehlerprioritaet: Priority
			Fehlerstatus
				Entwickler setzt nie Erledigt, nur Tester

			change control board
				Fehlermeldungen vs. Entwicklungswuensche
				interdisziplinaeres control board aus Produkt, Projekt, Testmanagement und Kundenvertretern


6.7 Konfigurationsmanagement
	Versionsverwaltung
	Konfigurationmverwaltung
	Statusverfolgung von Fehlern und Aenderungen
	Konfigurationsaudits

6.8 Normen und Standards
	Firmenstandards
		Programmierrichtlinien
		Rahmentestplan
	Best Practices
		fachlich bewaehrte Vorgehensweise (Stand der Technik)
	QM Standards
		z.B. ISO 9000
	Branchenstandards
		Mindestumfang Tests

	SW-Test Standards
		z.B. IEEE 829, IEEE 1028, BS 7925-2

==========================================
Kapitel 7 Testwerkzeuge
==========================================
	Typen: CASE vs. CAST

7.1.1 Testplanung und Manamgenet
	oft Kopplung von Fehlermanagement & Testplanung

7.1.2 Testspezifikation
	Festlegung Vor und Nachbedingungen, Sollwert
	Tesdatengeneratoren
		- datenbankbasiert - anhand DB
		- codebasiert anhand v. Codeanalysen, keine sollwerte -> Testorakel, aehnlich Whitebox testing
		- schnittstellenbasiert
			- Aequivalenz/Grenzwertanalyse anhand v. Schnittstellen
		- spezifikationsbasiert
			- aus Spezifikation
			vorr.: Vorlage Spezifikation
		- kreative-analystische Arbeit muss Tester machen

7.1.3 Testdurchfuehrung
	Aufgaben: Automatisierung der Testdurchfuerhung
	Vers. mit Daten (Testobjekt)
	Zeichnet die Reaktion des Testobjekts auf
	Debugger: zeilenweise Abarbeitung
		Analysewerkzeuge des Entwicklers ggf. sinnvoll bei Test um bestimmte Testsituationen zu ergaenzen
	Testtreiber:
		Werkzeuge, die Mechanismen bieten um ein testobjekt, das keine Benutzerschnittsstelle aufweist anzusprechen
		Primaer: Komponententest/Integrationstest
	Testrahmengenerator:
		enthaelt die benoetigten Initialisierungen und Aufrufsequenzen, um das Testobjekt ansteuern zu koennen evt. Dummies oder Stubs notwendig
	Simulation:
		bildet die eigentliche Einsatuzumgebung realistisch nach
	Testroboter:
		Prinzip des Videorecorders (Capture and Replay)
	Last & Performancetests
		generieren synthetische Last z.B. DB-Abfragen, Benutzertransaktionen, Netzverkehr
	Monitor:
		Messfuehler z.B. Antwortzeit

Test und Testobjektanalyse
	Komparatoren:
		Abweichung zw. Soll- und Istdaten herausfiltern
	Dynamische Anaylse
		zusaetzliche INformationen ueber den internen Zustand der getesteten SW (Memory Leaks, Pointerarithmetik)
	Ueberdeckungsanalyse
		Masszahl der strukturellen Testumgebung waehrend der Testdurchfuehrung
	Statische Analyse
		Liefern Charakteristika des Programmcodes wie z.B. zyklomatische Zahl und Quellcodemetrik
		Berechnen Datenfluss und Kontrollflussanomalien

7.2. Auswahl und Einfuerhung v. Testwerkzeugen
	"Automating Chaos just givfes faster chaos"

	Einfuerhungsreihenfolge v. Tools bei chaotischem Testprozess:
		1.) Fehlermnanagement
		2.) Konfigurationsmanagement
		3.) Planung v. Tests
		4.) Testdurchfuehrung
		5.) Testspezifikation

		Lernkurve Beachten!

7.2.1 Wirtschaftlichkeit
	Kosten Hardware/Mitarbeiterschulung
	Kosten/Nutzen Bilanz
		Armotisierung meist erst mit Regressionstestslaeufen
		Aufwand fuer Programmierung der Test miteinrechnen

	Lebenszyklus eines Testfalls:

	kreativer Prozess:	

		Geplant -> Spezifiziert -> Automatisiert
										|
	mechanischer Prozess:			   \/

									Gelaufen -> Gelaufen ...


	Testplanung Testspezifikation	Testdurchfuehrung Testdurchfuerhtunng folgereleases...

7.2.2 Werkzeugauswahl
	1. Anforderungssepzifikation fuer den Werkzeugeinsatz
	2. Marktstudie (Aufstellen von moeglichen Kandidaten)
	3. Vorfuehrung v. Werkzeugdemos
	4. Evaluierung der Werkzeuge der engeneren Wahl
	5. Review der Ergebnisse und Werkzeugauswahl

7.2.3 Werkzeugeinfuerhung
	1. Pilotprojekt
	2. Review der Pilotprojekterfahrung
	3. Prozessanpassung
	4. Anwenderschulung
	5. Breiteneinfuehrung
	6. Begleitendes Coaching


==========================================
APPENDIX A IEEE 829
==========================================


Testkonzeptbezeichnung: Klare Referenzierung
	Dokumentenname, Dokumentversion, Freigabestatus

Einfuehrung:
	kurze Darstellung des Projekthintergrunds
	Auflistung aller Ausgansdokumente

Testobjekte:
	Auflistung der Komponenten Kompontenten des Tests

Zu testende Leistungsmerkmale

Leistungsmerkmale, die nicht getestet werden

Teststrategie:
	Definition der Testziele basierend auf Risikoanalyse
	Welche Testziele sind unverzichtbar?
	Ausawahl Testmethoden

Abnahmekriterien:
	Abnahme/Testendekriterien
	"fehlerfreiheit" unsinn

Kriterien fuer Testabbruch/fortsetzung
	falls Testobjekt so schlecht, dass nie Abhnahmefaehigkeit erreicht wird
	Analog kriterien fuer Fortsetzung

Testdokumentation
	Berichte und Ergebnisse der Testarbeit
	Planungsdokumente, nicht Testergebnisse z.B. Testkonzept, Testspezifikation, Zeitplab
	Begleitdokumente zu testobjektuebergabe

Testaufgaben
	Auflistung aller Aufgaben
	Zuordnung der Verantwortlichkeit
	Aufgabenstati

Testinfrastruktur
	Testplattform
	Testerarbeitsplaetze
	Ausstattung (Testtools, Entwicklungswerkzeuge)

Verantwortlichkeit/Zustaendigkeit
	Weisungsbefugnis
	Aufteilung / Organisation des Personals
		in testgruppen/Teststufen

Personal Einarbeitung, Ausbildung

Zeitplan/Arbeitsplan
	grober Zeitplan der Testaktivitaaeten auf Meilensteinebene
Planungsrisiken/Unvorhergesehenes
	Risiken, die daraus resultieren, dass wunscheswerte Massnahmen nicht-eingeplant wurden,
	da bereits a priori klar ist, dass sie im konkreten Projekt nicht umsetzbar sind

Genehmigung / Freigabe
	Personen/Organisationseinheiten die das Testkonzept Freigeben

Glossar