1 Grundlagen: Aufzählungen Flashcards
Typische Ziele SW-Testen
ULTRAKURZ
- Vollständigkeit TO
- FW und FZ aufdecken
- Fehler Folge-AE vermeiden
- Risiken reduzieren
- Verifizieren Anforderungen
- Validieren Erwartungen
- Vertrauen in Qualität
- Informationen Entscheidungsfindung
- Konformität (compliance)
Warum Testen notwendig?
LEHRPLAN
Risiko von FW von SW im Betrieb reduzieren
Fehler beheben
=> Qualität K. oder S. steigern
vertragliche oder rechtliche Anforderungen/
branchenspezifische Standards erfüllen
Warum ist Testen notwendig?
DOJO
LZ
Gründliches Testen kann dazu beitragen, die
QUALITÄT von
- Komponenten
- System
- weiteren AE
zu erhöhen
ÜBERBLICK
Beziehung zwischen Testen & Qualitätssicherung
Testen als qualitätssichernde Maßnahme im gesamten Entwicklungsprozess
= Implementierung, Wartung, Betrieb
Lernen aus Fehlern vorangegangener Projekte
BEISPIELE
Beziehung zwischen Testen & Qualitätssicherung
Testen als qualitätssichernde Maßnahme im gesamten Entwicklungsprozess
- frühzeitiges Auffinden von FZ durch Reviews
- Identifikation von Anomalien durch statische Analysen
- Auffinden von produktionsverhindernden Fehlern
- Sicherstellung Akzeptanz durch Benutzer
Lernen aus Fehlern vorangegangener Projekte
- Fehlhandlungen identifizieren
- Entwicklungsprozesse verbessern
Erfolg engerer Sinn
durch (frühzeitigen)
Einbezug Tester lang
Überblick Lehrplan
Anforderungsreviews/ User-Story-Refinements:
- Entwicklung fehlerhafte oder nicht-testbare Features reduzieren
Systementwurf
- grundlegende Entwurfsfehler reduzieren
- gemeinsames Verständnis Entwurf & potenzielle Tests verbessern
Code-Entwicklung:
- FZ in Codes und in Tests reduzieren
- gemeinsames Verständnis Code & dessen Testung verbessern
Verifizierung & Validierung vor Freigabe:
- unentdeckte FW reduzieren
- Debugging unterstützen
- erhöhen Wahrscheinlichkeit, dass SW Bedürfnisse der Stakeholder entspricht und Anforderungen erfüllt
Erfolg:
Beitrag des Testens
LZ
Überblick Lehrplan
Erfolg engerer Sinn:
problematische Inbetriebnahmen SW reduzieren
- Fehler
- Bedürfnisse Stakeholder anderweitig nicht erfüllt
Erfolg weiterer Sinn = allgemeiner Erfolg:
- SW-Entwicklung
- SW-Wartung
Grundursachenanalyse:
Schritte
Identifikation von Grundursachen
Konzentration auf Behebung bedeutendste Grundursachen
Grundursachenanalyse:
Nutzen
Effizienter als auf FW zu warten
Auftreten vermeiden von vergleichbaren
- Fehlhandlungen
- Fehlerzuständen
- Fehlerwirkungen
- Auswirkungen
Prozessverbesserungen
Zusammenhang von Grundursache zu Auswirkungen
- Grundursache
- Fehlhandlung/ Umwelteinflüsse
- Fehlerzustand
- Fehlerwirkung
- Auswirkung
Gründe Fehlhandlungen
- Zeitdruck
- Menschliche Fehlbarkeit
- Unerfahrene/ nicht ausreichend ausgebildete Projektbeteiligte
- FEHLKOMMUNIKATION zwischen Projektbeteiligten, u.a. über Anforderungen und Entwurf
- KOMPLEXITÄT des Codes, Entwurfs, Architektur des zugrunde liegenden zu lösenden Problems, der genutzten Technologien
- Missverständnisse systeminterne und systemübergreifende SCHNITTSTELLEN
- Neue, unbekannte Technologien
Ursachen falsch - positive und - negative Testergebnisse
Folge von
- Fehlhandlungen in der Durchführung der Tests
- FZ in Testdaten, der Testumgebung und anderen Testmitteln
- …
7 Grundsätze des Testens
- Testen zeigt ANWESENHEIT von FZ
- VOLLSTÄNDIGES Testen unmöglich
- FRÜHES Testen spart Zeit und Geld
- HÄUFUNG FZ
- Pestizid-Paradoxon - Wiederholung
- Kontextabhängigkeit
(Produkt und Projektvorgehensweise) - “Keine Fehler” nicht automatisch brauchbares System
- Grundsatz des Testens
anders ausgedrückt im Hinblick auf Nutzen
Systematisches Testen
erhöht Wahrscheinlichkeit
- FZ aufzudecken
senkt Wahrscheinlichkeit
- von nicht entdeckten FZ
- Grundsatz des Testens:
Hintergrund
hohe Anzahl möglicher
- Eingabewerte
- Vorbedingungen
=> Kombination
=> nicht beherrschbare Menge von Testfällen
- Grundsatz des Testens:
Schlussfolgerungen
Testen immer nur stichprobenartige Prüfung
Stichproben (Testfälle) für
höchste Wahrscheinlichkeit
aufdecken Fehler
Testaufwand angepasst an
- Risiken
- Prioritäten
- Grundsatz des Testens:
Hintergrund
die relativen Fehlerbehebungskosten
steigen
im Lebenszyklus
- Grundsatz:
Hintergrund & Schlussfolgerung
Kleiner Teil der Module enthält
- meiste FZ entdeckt während Testphase oder
- meiste FW im Betrieb verantwortlich
Dort, wo eine FW nachgewiesen,
finden sich meistens noch weitere FZ.
Testaufwand auf Module fokussieren
proportional zu
- erwarteten und
- später beobachteten Fehlerdichte
- Grundsatz
Hintergrund
Wiederholungen der gleichen Tests
- wirkungslos
- finden irgendwann keine FZ mehr
- Grundsatz
Schlussfolgerungen
Pestizid-Paradox schafft scheinbare Sicherheit
Um neue FZ zu finden, müssen
- bestehende Tests & Testdaten möglicherweise verändert werden
- komplett neue Tests geschrieben werden