zusammenfassung - 227 - it systeme prüfen
TRANSCRIPT
Bernhard Tinner
1 227 IT-Systeme prüfen
20. Januar 2010
227 IT-Systeme
prüfen
Zusammenfassung
Massnahmen
konstruktive QS-Massnahmen
Wolle die Qualität bereits in der Erstellung des Systems einbringen
analytische QS-Massnahmen
Haben das Ziel, die Qualität der erstellten Produkte zu prüfen
Standards / Normen
ISO 9001
Prozesse sind standardisiert in vielen Branchen anerkannt
ISO 12207
Erweiterung der ISO-9000-Norm Bildet Rahmenbedingung für
Beschaffung
Lieferung
Entwicklung
Betrieb
Wartung
ISO 15504 (SPICE)
SPICE
Software
Process
Improuvement
Capability Determination
Kombination von
ISO 12207
CMM
Test Maturity Model (TMM)
Anlehnung an CMM
Übertragung der 5 Stufen an Softwaretests
Capability Maturity Model (CMM)
Softwareentwicklungsprozess
5 Reifegrad-Stufen
Reifegrad-Stufe
Detail
Integraler Prozess
Ad-hoc-Prozess
Kosten, Termine & Qualität nicht vorhersehbar
Wiederhol-barer Prozess
Intuitiver Prozess
Kosten, Termine & Qualität schwanken
Sind von den Erfahrungen der Individuen abhängig
Definierter Prozess
Qualitativer Prozess
Kosten, Termine & Qualität sind verbessert, aber noch nicht vorhersehbar
Prizesse sind institutionalisiert
Gesteuerter Prozess
Quantitativer Prozess (Menge)
Kosten, Termine & Qualität sind durch zuverlässige Metriken gesteuert und deshalb vorhersehbar
Optimierter Prozess
Rückgekoppelter Prozess
Kontinuierliche Verbesserung der Prozesse durch Feedback-Verarbeitung
5 Reifegrad-Stufen
Reifegrad-Stufe
Detail
Unsystematisch Tests hängen vom jeweiligen Programmierer ab
Starke Qualitätsschwankungen
Organisiert White- & Blackbox-Tests
Einzelen Projekte verwenden Testpläne
Kostensenkend Formelle Reviews
externe Testgruppen
QM gibt Muster für Testplan vor.
SW weist stabile Qualität auf
Systematisch Ein Teil des Tests wird automatisiert
Fehler werden auf die Quelle zurückverfolgt
Optimiert Testgruppe und Entwickler suchen kontinuierlich nach Verbesserungs- & Optimierungsmöglichkeiten
Bernhard Tinner
2 227 IT-Systeme prüfen
20. Januar 2010
Verifikation & Validierung
Verifikation
Doing the things right (mach es richtig)
Systemtests (ST)
Sind die Vorgaben erfüllt?
Validierung
Doing the right things (mach das Richtige)
User Acceptance Tests (UAT)
Kann das Ergebnis gebraucht werden? (Kunde)
Testprozesse
Phasenmodell
Linearer Ablauf
Tests
Testarten Detail
Review während Fachkonzept während DV-Konzept
Code-Inspektion während Realisierung
Unit-Tests während Realisierung
Integrationstests während Realisierung Abschluss in der Testphase
V-Model 97
Für SW-Entwicklung
Beschreibt die Aktivitäten und Produkte (Lieferobjekte) in einzelnen Subsystemen
Ist ISO-9001-kompatibel
Qualitätssicherung ist ein eigenes Subsystem
RUP
Rational Unified Process
De-facto-Standard in der objektorientierten Systementwicklung
Beschreibt die auszuführenden Tätigkeiten im Testprozess
Beschreibt die anzuwendenden Testarten
Gibt diverse Vorlagen für die Testdokumentation vor
Extreme Programming
einfaches Prozessmodell
verfolgt den sog. Test-First-Ansatz
Programmierer erstellen vor der Entwicklung zu zweit Tests
Unit-Tests für die vorgesehenen SW-Komponenten
Akzeptanz- bzw. Abnahmetests für die vorgesehenen Einsatzszenarien (Acceptance Tests)
Qualitätsdimensionen
Qualitätsdi-mension Aufgaben
Funktionalität (Functionality) System muss bestimmte Funktionen erfüllen
Aufgabenangemessenheit
Richtigkeit (korrekt und fehlerfrei)
Geforderte Genauigkeit
Verknüpfbarkeit (Interoperabilität)
Konformität (Gesetz, Regeln etc.)
Siehe auch: Konformitierbarkeit
Ordnungsmässigkeit
Sicherheit
Zuverlässigkeit (Reliability) System muss eine gewisse Qualität aufweisen
Robustheit
Reife
Fehlertoleranz
Wiederherstellbarkeit
Stabilität
Bernhard Tinner
3 227 IT-Systeme prüfen
20. Januar 2010
Qualitätsdi-mension Aufgaben
Benutzbarkeit (Usability) System muss eine gewisse Benutzbarkeit aufweisen
Ergonomie
Anwenderfreundlichkeit
Bedienbarkeit
Erlernbarkeit
Verständlichkeit
Effizienz (Performance) System muss eine gewissen Geschwindigkeit aufweisen
Zeitverhalten
Antwortzeiten
Batchverarbeitung
Verbrauchsverhalten
Lastverhalten
Datendurchsatz
Skalierbarkeit (Siehe auch: Erweiterbarkeit)
Wartbarkeit (Maintainability) System muss wart- und erweiterbar sein
Wartbarkeit
Erweiterbarkeit
Modifizierbarkeit
Parametrierbarkeit
Analysierbarkeit
Prüfbarkeit
Übertragbarkeit (Portability) System muss gewisse Bedingungen aufweisen
Installierbarkeit
Konformitierbarkeit
Austauschbarkeit
Anpassbarkeit
Teststrategie
In die Teststrategie fliessen die Vorgaben der IT-Strategie und aus dem QS-Plan, für alle laufenden IT-Projekte verbindlich, ein.
Deliverables
Was Inhalt
Testpolitik Regelt grundlegende Prinzipien zum Thema "Prüfen und Testen"
Definition du Bedeutung von Prüfen und Testen
Definition des zu erreichenden Qualitätsniveaus
Definition des Testprozesses und dessen Zusammenspiels mit Unternehmensprozessen
Metriken zur Messung der Wirksamkeit von Testaktivitäten
Ansatz zur Optimierung des Testprozesses (z.B. TMM)
Testhandbuch Regelt konkrete Aspekte des Testprozesses
Projektübergreifende Richtlinien
Darstellung der Risiken und effiziente Massnahmen
Aufzuziehende Testorganisation
Richtlinien für die Testumgebung
Infrastruktur
Testwerkzeuge
Workflow des Testprozesses
Einsatz von Testmethoden und Testarten (Teststufen)
Firmeninternes Glossar
Vorlagen für Test- & Berichtsdokumente
Bernhard Tinner
4 227 IT-Systeme prüfen
20. Januar 2010
Testvorgehen
Methodisches Vorgehen
Test-Art Beschreibung
Top-down/ Buttom-up Testfortschritt ist messbar
Abdeckung der Fälle berechenbar
Whitebox-Testing Modul- & Unit-Tests
Setzt detaillierte Kenntnisse des IT Systems voraus
Wird auch Glassbox-Test genannt
Testabdeckungsgrade
Graybox-Testing Integrationtests Getestet werden das Zusammenspiel und die Ablauffolgen der einzelnen Komponenten. Alle Komponenten werden mindestens einmal getestet. Alle Abläufe innerhalb des System müssen mit mindestens einem Testfall abgedeckt sein.
Blackbox-Testing Modul- & Unit-Tests
Systemtests
Es wird jeweils das Verhalten getestet.
Es werden die definierten Schnittstellen betrachtet-
Wird auch funktionelles Testverfahren genannt.
Ausgangsbasis sind die definierten Anwendungsfälle - Use Cases (Funktionale Anforderungen).
Die Testfälle werden an Hand von Äquivalenzklassen und Grenzwertanalysen gebildet.
Abdeckungsart Inhalt
Anweisungsabdeckung Jede Anweisung wird mindestens 1mal durchgeführt
Zweigabdeckung Jede Abzweigung muss mindestens einmal durchlaufen werden Jede Schleife wird mindestens einmal durchlaufen
Bedingungsabdeckung Bei jeder Bedingung sind alle möglichen, logischen Kombinationen mit mindestens einem Testfall abzudecken.
Pfadabdeckung Jeder mögliche Pfad muss mindestens einmal komplett durchlaufen werden. Wird in der Regel nicht angewendet, dass zu viele Kombinationen möglich sind.
Entscheidungstabelle Testfälle
Aquivalenzklassen Normalfälle Fehlerfälle
Bedingungen
Bruttowert…
1 >=5 und < 1000 X
2 >= 1000 und <= 5000 X
3 > 5000 und <= 10000 X
4 < 5 X
5 > 10000 X
Aktion
Nettowert…
1 = Bruttowert X
2 = Bruttowert * 0.95 X
3 = Bruttowert * 0.95 – 200 X
4 Fehlermeldung X X
Äquivakenzklasse Niedrigster Wert Höchster Wert Normal-/Fehlerfall
1 5 999 N
2 1000 5000 N
3 5001 10000 N
4 0 4 F
5 10001 99999 F
Bernhard Tinner
5 227 IT-Systeme prüfen
20. Januar 2010
Testkonzept (Testplan)
Hauptaspekte Aspekte
Testumfang Komponnetne und Funktionen, Testvorgehen, allgemeine Pass- und Fail-Kriterien
Testrahmen Zu erstellende Dokumente, Testumgebung
Testorganisation Verantwortlichkeiten, Aufbauorganisation, Ablauf- und Zeitplanung
Testfälle Inhalt
Zustandsbezogene Tests
Es wird nur der Zustand eines Testobjekts getestet.
Wird in einem Zustandsdiagramm aufgezeichnet
An Hand der möglichen Zustände wird ein Übergangsbaum erstellt
Diverenzierte Tests Back-to-Back-Test
Zwei Programmierer erstellen unabhängig voneinander ein Programm
Stimmen die Resultate beider Lösungen überein, haben sie keinen Fehler
Mutationentest
Es wird absichtlich ein Fehler oder eine Erweiterung eingebaut.
Sind die Resultate nicht unterschiedlich, scheint ein Programmfehler vorhanden zu sein.
Bernhard Tinner
6 227 IT-Systeme prüfen
20. Januar 2010
Exploratives Vorgehen
Vorteile
Zeitersparnis
Erfahrung des Testers ist nutzbar
Hohe Flexibilität
Tests
Ad-hoc Tests
Erfahrung basiertes Testen (hardest-first)
Intuitives Testen
Unsystematische Tests
Zufalls Tests
Guerilla Tests
Risikoorientiertes Vorgehen
Risiko = % Eintrittswahrscheinlichkeit * Kosten des Schadensausmass
Kritikalität
Kritikalität Verhalten
Sehr hoch Fehlverhalten kann zu Verluste von Menschenleben führen.
Fehlverhalten kann die Existenz des Unternehmens gefährden.
Hoch Fehlverhalten kann Menschenleben gefährden
Fehlverhalten kann zu massiven materiellen oder immateriellen Schäden führen.
Mittel Fehlverhalten kann zu kalkulierbaren materiellen oder immateriellen Schäden führen.
Niedrig Fehlverhalten kann zu geringen materiellen oder immateriellen Schäden führen.
Zuordnung der Kritikalität
Welches Testvorgehen (Testmethode)
Wieviele Testfälle (Testtiefe)
Welche Testfälle bevorzugt (Testfallpriorisierung)
Risikokategorien
Kategorien Ereignisse
Externe Risiken
Naturereignisse
Politische, gesetzliche Veränderungen
Gesellschaftliche Veränderungen
Marktwirtschaftliche Veränderungen
Strategische Risiken
Organisatorische Veränderungen
Finanzielle Risiken
Projektrisiken Vertragserfüllung
Mitarbeiter
Termine
Synchronisation bzw. Abhängigkeit mit anderen Tätigkeiten
Ressourcen
Kommunikation
Produktrisiken Funktionale Fehler
Akzeptanz durch Benutzer
Systemintegration und -konfiguration
Mengen
Datenmengen
Anzahl Benutzer
Anzahl Transaktionen
Image des Unternehmens
Sicherheit des Systems
Testarten
Statisches Prüfverfahren
Informelle Reviews
Ad hoc Sitzung
Zustellung mit bitte um Stellungnahme
Zustellung mit Checkliste und Beurteilungsbogen zur Stellungnahme (Peer Rating)
Walkthrough
Strukturiertes Vorgehen um Qualität der Testobjekte zu verbessern
In entspannter Atmosphäre gemeinsam eine Lösung finden
Effizienzsteigerung mit einer prüfobjektorientierten Checkliste
Testobjekte
Entwurfsdokumente
Anforderungsspezifikationen
Designdokumente
Programmsourcen
Datenbanksourcen
Dokumentationen
Installationsdok.
Benutzerhandbuch
Betriebshandbuch
Bernhard Tinner
7 227 IT-Systeme prüfen
20. Januar 2010
Technisches Review
Werden von der Projektleitung angeordnet
laufen nach definiertem Schema
3 mögliche Beschlüsse als Delivarables
Prüfling OK! Kann freigegeben werden.
Freigabe mit Vorbehalt! Mängel müssen behoben werden und vom Moderator geprüft werden. Dann erst erfolgt die Freigabe.
Prüfling wird zurückgewiesen! Der Autor muss den Prüfling überarbeiten. Ein erneutes Review ist danach erforderlich.
Inspektion
Überprüfung klar definierter Anforderungen
Ist eine formelle Prüfung
Bekannte Methode ist die "Fangan Code Inspection".
Audit
Wird vom Mgmt. ausserhalb der Ogranisation angeordnet.
Wird durch einen Assessmentbericht abgeschlossen
Untersuchung eines Gegenstandes auf die Erfüllung externer Anforderungen und Richtlinien Assessments
Assessment
Vorgehen Dokumentenstudium
Sitzung
Interview
Überprüfung vor Ort
Ziel Überprüfung der Angemessenheit und Einhaltung vorgegebener Vorgehensweisen, Anweisungen und Standards.
Überprüfung der Wirksamkeit und Sinnhaftigkeit.
Bernhard Tinner
8 227 IT-Systeme prüfen
20. Januar 2010
Auditarten an Hand des Auditgegenstandes
Auditgegenstand Details
Complience Übereinstimmung mit Vorschriften bzw. Gesetzen.
Systemaudit Gesamtsystem inkl. Prozesse und Strukturen
Prozessaudit Prozesseffizienz & -effektivität
Projektaudit Projektfortschritt
Produktaudit Einhaltung von Produktanforderungen
Dynamische Prüfverfahren
Sind die Tests im eigentlichen Sinn
V-Model
Jede Testart lässt sich einer Teststufe zuordnen.
Die Planung der Testarten wird Teststufenplan genannt.
Testaktivitäten unterstützen die Prüfverfahren.
Testaktivitäten
Aktivität Details
Prototypentests (zusammen mit Review)
Analysephase
Entwurfsphase
Proof-of-Concept (Wenn SW nicht selber entwickelt wird)
Evaluationsprozess
Lieferant macht Testinstallation
Prüfung der Machbarkeit
Prüfen der Versprechen des Lieferanten
Regressionstest Bei jeder Änderung des alten Systems, muss das gesamte System getestet werden
Die Auswahl der Testfälle ist Risikoorientiert, da nicht alle Eventualitäten getestet werden können.
Wird wenn immer möglich automatisiert.
Bernhard Tinner
9 227 IT-Systeme prüfen
20. Januar 2010
Teststufen
Teststufe
Unit-Test (UT) Ziel Funktionstest gemäss Detail- und Schnittstellenspezifikation Prüfung der Wartbarkeit mittels Review und Code Inspection
Hilfsmittel
Mit sg. Negativtests wird die Robustheit geprüft Bei zeitkritischen Komponenten wird das Zeitverhalten geprüft.
Methoden Whitebox
Blackbox
Review
Code Inspection
Prüfobjekte
Modul
Programm
Klasse (OOP)
Komponente (OOP)
Function, Stored Procedure, Trigger (in DB)
Liste 52
Integrationstest (IT)
Ziel Prüfen des Zusammenspiels einzelner Komponenten Prüfen der Schnittstellen zu den umgebenden Systemen
Basis Design des Systems Spezifizierte Testfälle
Prüfobjekte Zusammenstellen einzelner Komponenten um Interaktion und Ablauf zu testen (Komponentenintegration) Simulation der Schnittstellen der einzelnen Schichten um die Schichtenintegration zu testen. Prüfen von Form und Inhalt der ausgetauschten Informationen (Schnittstellentests) Prüfen der Hardwarekompatibilität. Dabei sollten alle Hardware Komponenten vorhanden sein.
Systemtest (ST) Ziel Nachweiserbringung der geforderten IT-Systemqualität
Testarten Funktionstest
Benutzbarkeitstest
Installationstest
Kompatibilitätstest / Zertifizierungstest
Performancetest
Benchmarktest
Katastrophentest
Sicherheitstest
Akzeptanztest (UAT)
Ziel Prüfung und Beurteilung des Systems aus Sicht des Kunden bzw. Auftraggebers
Varianten Test der vertraglich vereinbarten Akzeptanz Test der Benutzerakzeptanz Test der Akzeptanz durch den Systembetreiber Verknüpfung des Abnahmetests mit der Produktivstellung
Testarten Funktionstest
Benutzbarkeitstest
Livetest -> Produktion (PAV)
Varianten Parallelbetrieb Pilotbetrieb Beta-Test
Bernhard Tinner
10 227 IT-Systeme prüfen
20. Januar 2010
Testorganisation
Die Testorganisation ist Teil der Projektorganisation.
Ein Testteam muss mindestens 3 Rollen enthalten.
Organigramm Testteam
(Beispiel)
Testrollen
Rolle Skills
Testmanager Gutes Fachwissen in Qualitäts- & Testmanagement
Erfahrung in Personalführung
Testdesigner Experte in Testmethodik & Testmanagement
Experte in Systemanalyse
Testengineer Experte in Software- & Prozedurenentwicklung
Testauto-matisierer
Experte in Testwerkzeugen & Prozedurenentwicklung
Test-administrator
Experte als Systemadministrator
Gute Betriebs- & Softwarekenntnisse
Tester Experte für Testdurchführung & Fehlerberichte
Kennt die einzusetzenden Testwerkzeuge
Hat Erfahrung mit Testobjekten
Testprozess
Testaktivitäten
Test planen
Wichtige Informationen aus den Anforderungen und den Bedürfnissen einfliessen lassen.
Grundlagen
QS-Plan
Teststrategie
Anforderungs- & Entwurfsdokument
Projektplan
Sämtliche Testobjekte inkl. min. Qualitätsstandards werden identifiziert.
Test entwerfen
Testfall spezifizieren
Testprozedur erstellen
Testumgebung aufbauen
Test ausführen
Testprotokolle auswerten
Bernhard Tinner
11 227 IT-Systeme prüfen
20. Januar 2010
Testzyklus
Bernhard Tinner
12 227 IT-Systeme prüfen
20. Januar 2010
Testaktivitätenmatrix
Abdeckungsanalyse
Abdeckungsanalyse anhand eines Ablaufgrafes (Kontrollflussgraf)
A) Anweisungsabdeckung
Jede Anweisung wird mindestens einmal ausgeführt!
Fall 1: 1, 2, 3, 4, (B=True, C=True) 5, 4e, 1e
Fall 2: 1, 2, 7, 8, 7, 6, 1e
B) Zweigabdeckung
Jeder Programmzweig muss mindestens einmal durchlaufen werden!
Zusätzlich zu Fall 1 und 2
Fall 3: 1, 2, 3, 4 (B=False, C=False), 4e, 1e
Fall 4: 1, 2, 6, 1e
C) Bedingungsanleitung
Bei jeder Bedingung sind alle möglichen logischen Kombinationen mit mindestens einem Testfall abzudecken!
Zusätzlich zu Fall 1 bis 4
Fall 5: 1, 2, 3, 4, (B=False, C=True) 5, 4e, 1e
Fall 6: 1, 2, 3, 4, (B=True, C=False) 5, 4e, 1e
D) Pfadabdeckung
Jeder mögliche Pfad muss von Anfang bis zum Schluss mindestens einmal durchlaufen werden!
Zusätzlich zu Fall 1 bis 6
Fall 7: 1, 2, 7, 6, 1e
Fall 8: 1, 2, 7, 8, 7, 8, 7, 6, 1e
Quellennachweis:
IT-Systeme prüfen (227) (Hansruedi Tremp und Johannes Scheuring) 2. überarbeitete Auflage 2007, Compendio Bildungsmedian AG, Zürich