Zusammenfassung - 227 - IT Systeme prüfen

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


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


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


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


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


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


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


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


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


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


20. Januar 2010

Testzyklus

Bernhard Tinner


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

Documents

Zusammenfassung - 227 - IT Systeme prüfen