Sie sind auf Seite 1von 12

1 227 IT-Systeme prüfen

Capability Maturity Model (CMM)


227 Softwareentwicklungsprozess

IT-Systeme 5 Reifegrad-Stufen
Reifegrad- Detail

prüfen
Stufe
Integraler  Ad-hoc-Prozess
Prozess  Kosten, Termine & Qualität
nicht vorhersehbar
Zusammenfassung Wiederhol-  Intuitiver Prozess
barer  Kosten, Termine & Qualität
Massnahmen Prozess schwanken
 Sind von den Erfahrungen der
konstruktive QS-Massnahmen Individuen abhängig
Wolle die Qualität bereits in der Erstellung des Definierter  Qualitativer Prozess
Systems einbringen Prozess  Kosten, Termine & Qualität
sind verbessert, aber noch
analytische QS-Massnahmen nicht vorhersehbar
Haben das Ziel, die Qualität der erstellten  Prizesse sind institutionalisiert
Produkte zu prüfen Gesteuerter  Quantitativer Prozess (Menge)
Prozess  Kosten, Termine & Qualität
Standards / Normen sind durch zuverlässige
Metriken gesteuert und
ISO 9001 deshalb vorhersehbar
Optimierter  Rückgekoppelter Prozess
Prozesse sind standardisiert
Prozess  Kontinuierliche Verbesserung
in vielen Branchen anerkannt
der Prozesse durch Feedback-
ISO 12207 Verarbeitung

Erweiterung der ISO-9000-Norm 5 Reifegrad-Stufen


Bildet Rahmenbedingung für
Reifegrad- Detail
 Beschaffung
Stufe
 Lieferung
Unsystematisch  Tests hängen vom
 Entwicklung
jeweiligen Programmierer
 Betrieb
ab
 Wartung
 Starke
ISO 15504 (SPICE) Qualitätsschwankungen
Organisiert  White- & Blackbox-Tests
SPICE  Einzelen Projekte
verwenden Testpläne
 Software Kostensenkend  Formelle Reviews
 Process
 externe Testgruppen
 Improuvement
 QM gibt Muster für Testplan
 Capability Determination vor.
Kombination von  SW weist stabile Qualität
auf
 ISO 12207 Systematisch  Ein Teil des Tests wird
 CMM automatisiert
 Fehler werden auf die
Test Maturity Model (TMM) Quelle zurückverfolgt
Optimiert  Testgruppe und Entwickler
Anlehnung an CMM suchen kontinuierlich nach
Übertragung der 5 Stufen an Softwaretests Verbesserungs- &
Optimierungsmöglichkeiten
Bernhard Tinner
20. Januar 2010
2 227 IT-Systeme prüfen

Validierung
Verifikation & Validierung  Doing the right things (mach das Richtige)
 User Acceptance Tests (UAT)
Verifikation  Kann das Ergebnis gebraucht werden? (Kunde)
 Doing the things right (mach es richtig)
 Systemtests (ST)
 Sind die Vorgaben erfüllt?

Testprozesse RUP
 Rational Unified Process
Phasenmodell  De-facto-Standard in der objektorientierten
Linearer Ablauf Systementwicklung
 Beschreibt die auszuführenden Tätigkeiten im
Tests Testprozess
Testarten Detail  Beschreibt die anzuwendenden Testarten
Review während Fachkonzept  Gibt diverse Vorlagen für die
während DV-Konzept Testdokumentation vor
Code-Inspektion während Realisierung Extreme Programming
Unit-Tests während Realisierung
Integrationstests während Realisierung  einfaches Prozessmodell
Abschluss in der Testphase  verfolgt den sog. Test-First-Ansatz
 Programmierer erstellen vor der Entwicklung
V-Model 97 zu zweit Tests
 Unit-Tests für die vorgesehenen SW-
 Für SW-Entwicklung
Komponenten
 Beschreibt die Aktivitäten und Produkte
 Akzeptanz- bzw. Abnahmetests für die
(Lieferobjekte) in einzelnen Subsystemen
vorgesehenen Einsatzszenarien
 Ist ISO-9001-kompatibel (Acceptance Tests)
 Qualitätssicherung ist ein eigenes Subsystem

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
20. Januar 2010
3 227 IT-Systeme prüfen

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
20. Januar 2010
4 227 IT-Systeme prüfen

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 1 >=5 und < 1000 X
2 >= 1000 und <= 5000 X
Bruttowert… 3 > 5000 und <= 10000 X
4 <5 X
5 > 10000 X
Aktion 1 = Bruttowert X
2 = Bruttowert * 0.95 X
Nettowert… 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
20. Januar 2010
5 227 IT-Systeme prüfen

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  Es wird nur der Zustand eines Testobjekts getestet.
Tests  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
20. Januar 2010
6 227 IT-Systeme prüfen

Exploratives Vorgehen Zuordnung der Kritikalität


Vorteile  Welches Testvorgehen (Testmethode)
 Wieviele Testfälle (Testtiefe)
 Zeitersparnis  Welche Testfälle bevorzugt
 Erfahrung des Testers ist nutzbar (Testfallpriorisierung)
 Hohe Flexibilität
Risikokategorien
Tests
Kategorien Ereignisse
 Ad-hoc Tests Externe  Naturereignisse
 Erfahrung basiertes Testen (hardest-first) Risiken  Politische, gesetzliche
 Intuitives Testen Veränderungen
 Unsystematische Tests  Gesellschaftliche
 Zufalls Tests Veränderungen
 Guerilla Tests  Marktwirtschaftliche
Veränderungen
Risikoorientiertes Vorgehen
Strategische  Organisatorische
Risiko = % Eintrittswahrscheinlichkeit * Kosten Risiken Veränderungen
des Schadensausmass  Finanzielle Risiken
Projektrisiken  Vertragserfüllung
Kritikalität
 Mitarbeiter
Kritikalität Verhalten  Termine
Sehr hoch  Fehlverhalten kann zu Verluste  Synchronisation bzw.
von Menschenleben führen. Abhängigkeit mit anderen
 Fehlverhalten kann die Existenz Tätigkeiten
des Unternehmens gefährden.  Ressourcen
Hoch  Fehlverhalten kann  Kommunikation
Menschenleben gefährden Produktrisiken  Funktionale Fehler
 Fehlverhalten kann zu massiven  Akzeptanz durch Benutzer
materiellen oder immateriellen  Systemintegration und -
Schäden führen. konfiguration
Mittel  Fehlverhalten kann zu  Mengen
kalkulierbaren materiellen oder  Datenmengen
immateriellen Schäden führen.  Anzahl Benutzer
Niedrig  Fehlverhalten kann zu geringen  Anzahl Transaktionen
materiellen oder immateriellen  Image des Unternehmens
Schäden führen.  Sicherheit des Systems

 In entspannter Atmosphäre gemeinsam eine


Testarten Lösung finden
 Effizienzsteigerung mit einer
Statisches Prüfverfahren prüfobjektorientierten Checkliste
 Testobjekte
Informelle Reviews  Entwurfsdokumente
 Ad hoc Sitzung  Anforderungsspezifikationen
 Zustellung mit bitte um Stellungnahme  Designdokumente
 Zustellung mit Checkliste und  Programmsourcen
Beurteilungsbogen zur Stellungnahme (Peer  Datenbanksourcen
Rating)  Dokumentationen
 Installationsdok.
Walkthrough  Benutzerhandbuch
 Strukturiertes Vorgehen um Qualität der  Betriebshandbuch
Testobjekte zu verbessern

Bernhard Tinner
20. Januar 2010
7 227 IT-Systeme prüfen

Technisches Review
 Werden von der Projektleitung angeordnet
 laufen nach definiertem Schema

3 mögliche Beschlüsse als Delivarables Audit


 Prüfling OK! Kann freigegeben werden.  Wird vom Mgmt. ausserhalb der Ogranisation
 Freigabe mit Vorbehalt! Mängel müssen angeordnet.
behoben werden und vom Moderator  Wird durch einen Assessmentbericht
geprüft werden. Dann erst erfolgt die abgeschlossen
Freigabe.  Untersuchung eines Gegenstandes auf die
 Prüfling wird zurückgewiesen! Der Autor Erfüllung externer Anforderungen und
muss den Prüfling überarbeiten. Ein Richtlinien  Assessments
erneutes Review ist danach erforderlich.
Assessment
Inspektion
Vorgehen  Dokumentenstudium
 Überprüfung klar definierter Anforderungen  Sitzung
 Ist eine formelle Prüfung  Interview
 Bekannte Methode ist die "Fangan Code  Überprüfung vor Ort
Inspection". Ziel  Überprüfung der Angemessenheit
und Einhaltung vorgegebener
Vorgehensweisen, Anweisungen
und Standards.
 Überprüfung der Wirksamkeit und
Sinnhaftigkeit.

Bernhard Tinner
20. Januar 2010
8 227 IT-Systeme prüfen

Auditarten an Hand des Auditgegenstandes


Dynamische Prüfverfahren
Auditgegenstand Details
Complience Übereinstimmung mit Sind die Tests im eigentlichen Sinn
Vorschriften bzw.
Gesetzen.
Systemaudit Gesamtsystem inkl.
Prozesse und Strukturen
Prozessaudit Prozesseffizienz & -
effektivität
Projektaudit Projektfortschritt
Produktaudit Einhaltung von
Produktanforderungen
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  Analysephase
(zusammen mit Review)  Entwurfsphase
Proof-of-Concept  Evaluationsprozess
(Wenn SW nicht selber  Lieferant macht Testinstallation
entwickelt wird)  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
20. Januar 2010
9 227 IT-Systeme prüfen

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 Ziel Prüfen des Zusammenspiels einzelner Komponenten
(IT) 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 Ziel Prüfung und Beurteilung des Systems aus Sicht des Kunden bzw.
(UAT) 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 -> Varianten Parallelbetrieb
Produktion Pilotbetrieb
(PAV) Beta-Test

Bernhard Tinner
20. Januar 2010
10 227 IT-Systeme prüfen

Testorganisation Testprozess
 Die Testorganisation ist Teil der
Projektorganisation.
 Ein Testteam muss mindestens 3 Rollen
enthalten.

Organigramm Testteam
(Beispiel)

Testrollen
Rolle Skills Testaktivitäten
Testmanager  Gutes Fachwissen in
Qualitäts- & Testmanagement  Test planen
 Erfahrung in Personalführung  Wichtige Informationen aus den
Anforderungen und den Bedürfnissen
Testdesigner  Experte in Testmethodik &
einfliessen lassen.
Testmanagement  Grundlagen
 Experte in Systemanalyse  QS-Plan
Testengineer  Experte in Software- &  Teststrategie
Prozedurenentwicklung  Anforderungs- & Entwurfsdokument
Testauto-  Experte in Testwerkzeugen &  Projektplan
matisierer Prozedurenentwicklung  Sämtliche Testobjekte inkl. min.
Test-  Experte als Qualitätsstandards werden identifiziert.
administrator Systemadministrator  Test entwerfen
 Gute Betriebs- &  Testfall spezifizieren
Softwarekenntnisse  Testprozedur erstellen
Tester  Experte für Testdurchführung  Testumgebung aufbauen
& Fehlerberichte  Test ausführen
 Kennt die einzusetzenden  Testprotokolle auswerten
Testwerkzeuge
 Hat Erfahrung mit
Testobjekten

Bernhard Tinner
20. Januar 2010
11 227 IT-Systeme prüfen

Testzyklus

Bernhard Tinner
20. Januar 2010
12 227 IT-Systeme prüfen

Testaktivitätenmatrix

Abdeckungsanalyse

Abdeckungsanalyse anhand eines Ablaufgrafes A) Anweisungsabdeckung


(Kontrollflussgraf) 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

Bernhard Tinner
20. Januar 2010

Das könnte Ihnen auch gefallen