Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.2 Qualitätsmanagement Folie 1LM 13 Prüfung von SW-System und Abnahme Tests System-

Universität Stuttgart

Institut für Kernenergetik und Energiesysteme

LE 3.2 Qualitätsmanagement LM 13 Prüfung von SW-System und Abnahme Tests Folie 1

System- und Abnahmetests

Inhalt

• Testen des Systems unter Mitwirkung des Auftraggebers in der realen Einsatzumgebung ggf. mit echten Daten

• Typische Testfälle

• Beim Abnahmetest zu beachtende Punkte

• Abnahmearten bei großen Systemen




Motivation

• Ist nach viel Mühe ein Softwareprodukt entstanden, das dem Auftraggeber übergeben werden soll, so sollte dieses Produkt möglichst fehlerfrei sein.

• System- und Abnahemtests dienen dem Nachweis, dass das entwickelte Software-Produkt der Produkt-Definition (Funktionalität und Erscheinungsbild) entspricht.

• Systemtests finden ohne den Auftraggeber statt. Sie haben zum Ziel die Abnahme vorzubereiten.

• Der Abnahmetest wird vom Auftraggeber selbst oder mindestens in seinem Beisein in der realen Einsatzumgebung, eventuell sogar mit Echtdaten, durchgeführt.




System und Abnahme Tests

Verwendete Lernobjekte

LO 2: Testen mit System

LO 3: Systemtests

LO 4: Werkabnahme

LO 5: Abnahmetests

LO 6: Zusammenfassung, Abspann

LO 7: Tests zu LM13




Das sollten Sie heute lernen• Die Entwicklung grosser Softwaresysteme endet in der Regel mit einer

Werkabnahme. Dadurch wird nachgewiesen, dass in einer gemeinsam mit dem Auftraggeber definierten Umgebung die vertraglich festgelegten Funktionalitäten des Systemes realisiert wurden.

• Die Funktionalitäten werden über Testitems beschrieben. Testprozeduren beschreiben darauf aufbauend die zum Test notwendigen Voraussetzungen, die Durchführungsschritte und das erwartete Verhalten.

• Im Lehrmodul wird versucht die Verbindung des Abnahmetests mit der Spezifikation zu verdeutlichen und Erfahrungen aus Werkabnahmen grosser objektorientierter Systeme zu vermitteln.

• Der Test großer Systeme muß durch Testumgebungen unterstützt werden. An Hand einer ausgewählten Testumgebung (z.B. Test Studio von Rational) sollen die Vorteile solcher Tools erläutert werden.

• Der Einsatz des Tools wird an Beispielen wie etwa Funktions-, Regressions- und Performancetests gezeigt.




LE 3.2 - LM 13 - LO 2 Testen mit System




Der Testprozess als Bestandteil des SE Prozesses:




Fehlerfortpflanzung in Softwaresystemen




Übersicht „automatisiertes Testen“ Vorbereitung

• Auswahl und Erfassung der Testfälle• Zuordnung der Verantwortlichkeiten• Festsetzung eines Testkandidaten (TC)• Freigabe von Testfällen• Erstellung von automatisiertenTestskripten

Durchführung• Automatisierte bzw. manuelle Abarbeitung der• definierten Testfälle (Regressionstest)• Ergebnissicherung• Melden und Verfolgen von Fehlern

Auswertung• Erstellung/Generierung von Testprotokollen• Analyse und Auswertung der Testprotokolle ->Testbericht




Grundsätzlicher Arbeitsablauf Capture/Replay




(1) Auswahl und Erfassung der Testfälle• Die Spezifikation von abnahmerelevanten Testfällen wird vom AG vorgenommen.• In IMIS wird eine Access-basierte Testdatenbank zur Verwaltung der Testfälle verwendet.• Zu jedem Testfall wurden die Vorbedingungen, die durchzuführenden Testschritte mit Eingabedaten und die zu

erwartenden Systemreaktionen (Ergebnis) auf Maskenebene beschrieben.




(2) Freigabe von Testfällen durch den Entwickler• Die Verantwortlichkeiten für die Testfälle wurden durch die TPL festgelegt

• Jeder Entwickler hat Zugriff auf die Testfälle (analog /digital) und kann unter Nutzung der Testfall-DB Berichte mit der Beschreibung des Testfalles generieren

• Der Entwickler überprüft, ob die notwendige Funktionalität zur Ausführung eines Testfalles zur Verfügung steht. Wenn ja, setzt der Entwickler diesen Testfall in der Testfall-DB – unter Angabe des IntegrationRequest (IR)- auf testbar




(3) Testkandidat• Der KM-Verantwortliche stellt in regelmäßigen Abständen (Fertigstellungsgrad, Stand der

Fehlerbehebung) einen Testkandidaten (TC) zur Verfügung. Dieser wird in ClearCase als solcher gekennzeichnet (TC-JJMMDD-HHMM)

• In der Testfall-DB steht dem Testteam ein Bericht mit der Übersicht der freigegebenen Testfälle für den jeweiligen Testkandidaten (TC) zur Verfügung.




(4) Erstellung automatisierter Testskripte

• Mit dem RationalRobot werden Testscripte mittels „Capture und Replay“ Technik generiert. Dazu werden die Testfälle Schritt für Schritt abgearbeitet und anschließend - wo dies notwendig ist - manuell editiert.

• Prüfpunkte

• Synchronisationspunkte




(5) Testplan und Testsuiten

• Ist ein Script implementiert wird dies im Testplan dem jeweiligen Testfall zugeordnet

• Skripte und Testpläne sind in einem Testprojekt abgelegt, dass für alle Teammitglieder zugreifbar ist

• Regressionstest: Die Testscripte sollen möglichst Modular aufgebaut sein. Sie werden in TestSuiten kombiniert. Die TestSuiten werden für jeden Testkandidaten ausgeführt




(6) Ergebnissicherung

• LOG-Files: Für jeden Testfall (Suite), der mit dem Rational TestManager wiederholt wird, erzeugt das Werkzeug ein LOG-File. Die LOG-Files werden in Ordnern, deren Namen den Testkandidaten entsprechen, archiviert. Das LOG-File hat drei Konkretisierungsstufen.

• 1. Test Case Results: Gesamtergebnis

• 2. Test Case Details: Detailergebniss

• 3. Fehlerbeschreibung




(7) Melden und Verfolgen von Fehlern

• Problemreport

• Synopsis (Testfallname und „sprechende“ Kuzbeschreibung des Fehlers)

• Description (ausführlichere Fehlerbeschreibung)




(8) Analyse und Auswertung

• Testfallprotokoll für jeden Testfall

• Übersichten zu den Regressionstests für jeden Testkandidaten

• Testbericht für den jeweiligen Meilenstein Meilenstein




Möglichkeiten und Grenzen des automatisierten Testens

+ Automatisierte Tests laufen, wenn sie einmal erstellt wurden, schneller ab als manuelle Tests, sind konsistenter und können ohne großen Mehraufwand beliebig oft wiederholt werden

+ Automatisierte Tests - das Abspielen eines oder mehrerer Testskripts - können unbeaufsichtigt laufen. Dies ermöglicht die Durchführung von Tests nachts oder am Wochenende, was eine effektivere Nutzung der Zeit wochentags erlaubt, um die erkannten Fehler zu analysieren und die Tests zu vervollständigen.

- Beim automatisierten Testen treten zunächst zusätzliche Kosten auf. Das sind Anschaffungs-, Entwicklungs- und Instandhaltungskosten des C/R-Tools.

- Das Aufzeichnen von Benutzeraktivitäten ist erst zu einem sehr späten Zeitpunkt in der Entwicklung einer Software möglich, wenn die meiste Funktionalität bereits implementiert ist.

- Automatisiertes Testen ist erst wirtschaftlich, wenn Tests mehrfach wiederholt werden.




LE 3.2 - LM 13 - LO 3 Systemtests




System und Abnahmetests

• System- und Abnahemtests dienen dem Nachweis, daß das entwickelte Software-Produkt der Produkt-Definition entspricht.

• Systemtests finden ohne den Auftraggeber statt.

• Der Abnahmetest wird vom Auftraggeber selbst oder mindestens in seinem Beisein in der realen Einsatzumgebung, eventuell sogar mit Echtdaten, durchgeführt.




System Tests

• Test des Gesamtsystems (ev. Prototyp) beim Auftragnehmer

• Basis des Abnahmetests einer Phase

• Übergang zwischen zwei Meilensteinen

• Basis Softwareanforderungen des Softwareentwicklungsvertrags

• Durchführung als Black Box Test, da Implementierung kaum mehr interessiert

• Ziel Validierung der Software

• Tips: siehe Abnahme Test




Zielsetzung von Systemtests

Je nach Zielsetzung können verschiedene Systemtests unterschieden werden:

Funktionstests,

Leistungstests

ergänzende Tests wie der Benutzbarkeitstest und der Sicherheitstest.




Funktionstest

Funktionstests prüfen Implementierung gegen ihre Spezifikation und lassen die interne Programmstruktur unberücksichtigt: • Komplementär zu „White-Box“-Verfahren• für Abnahmetest ohne Kenntnis des Quellcodes geeignet• setzt vollständig und widerspruchsfreie Spezifikation voraus • repräsentative Eingabewerte/Szenarien müssen ausgewählt werden (man kann i.a. nicht alle Eingabekombinationen testen)

– Sequenzdiagramme aus Anwendungsfällen (use cases) beschreiben wichtige Testfälle

• man braucht Fachwissen oder „Orakel“ für Überprüfung der Korrektheit der Ausgaben




LeistungstestsMit Leistungstests wird die Erfüllung der Leistungsanforderungen untersucht. Leistungsanforderungen können sich auf die vom System verarbeitbaren Datenmengen oder gegebene Zeitrestriktionen, wie beispielsweise maximale Antwortzeiten, beziehen. Massentests dienen zur Überprüfung der vom System maximal verarbeitbaren Datenmengen. Die Einhaltung von Zeitrestriktionen wird mit Hilfe von Zeittests festgestellt. Zur Überprüfung des Systemverhaltens im zulässigen Grenzbereich werden Lasttests eingesetzt. Wurden die Massen- und Zeittests bereits im Grenzbereich durchgeführt, so sind die betreffenden Lasttests bereits in den Massen- und Zeittests enthalten. Je nach Anwendungsfall und festgelegten Anforderungen beinhalten Lasttests auch die Überprüfung des Systemverhaltens in Situationen wie dem Ausfall einer Hard- oder Softwarekomponente, dem Erreichen der maximal zulässigen Benutzerzahl oder dem Eintreffen von ungewöhnlichen oder unzulässigen Eingabedaten. Das Systemverhalten bei Überschreiten der festgelegten Leistungsgrenzen wird mit Hilfe von Stresstests untersucht. Mögliche Fragestellungen von Stresstests sind beispielsweise das Systemverhalten bei Überlast und/oder anschließendem Rückgang auf Normallast.




Ergänzende Tests

Mit Benutzbarkeitstests wird überprüft, ob das Software-Produkt die Anforderungen an die Benutzungsschnittstelle der System-Definition erfüllt. Zur Überprüfung der in der System-Definition vorgeschriebenen Sicherheitsmaßnahmen, beispielsweise bezüglich der Verwaltung von Paßwörtern und Zugriffsrechten, werden Sicherheitstests durchgeführt. Die Zusammenarbeit zwischen dem entwickelten Software-System und anderen Systemen der realen Umgebung wird mit Interoperabilitätstests überprüft. Ziel des Installationstests ist es, nachzuweisen, daß das Software-Produkt mit der Installationsbeschreibung installiert und betriebsfertig gemacht werden kann. Zur Überprüfung des Systemverhaltens in Restartsituationen dienen Restarttests bzw. Wiederinbetriebnahmetests. Ziel dieser Tests, ist es festzustellen, ob das entwickelte Software-System nach einem unplanmäßigen Programmabbruch, beispielsweise durch einen Stromausfall, mit den vorliegenden Beschreibungen wieder in Betrieb genommen werden kann.




LE 3.2 - LM 13 - LO 4 Werkabnahme




Abnahme und AbnahmetestAbnahmetestAuftraggeber überprüft die (vertraglich vereinbarten) Abnahmekriterien

Wartung verbleibt bei Auftragnehmer: Benutzbarkeit, Effizienz, Zuverlässigkeit, Korrektheit, … werden getestet

Wartung geht auf Auftraggeber über: zusätzlich spielen Wartbarkeit, Portierbarkeit, Testbarkeit, Erweiterbarkeit, … eine wichtige Rolle

Abnahmeprotokoll:In ihm werden die durchgeführten Abnahmetests und ihre Ergebnisse festgehalten.

Werkabnahme:Schriftliche Erklärung der Annahme des Softwareprodukts (im juristischen Sinne) - Zahlungsmeilenstein.




Plan für Werkabnahme

• Erfolgreiche Durchführung der Systemtests

• Vorlage ausgewählter Prozeduren aus den Systemtests als Basis der Abnahmetests (es müssen alle muss Kriterien enthalten sein)

• Auswahl der Prozeduren für Werkabnahme durch Auftraggeber

• Festschreibung des Systemzustandes

• Probe der Abnahmeprozeduren

• Durchführung der Werkabnahme

• Erst anschließend freies Testen erlauben




LE 3.2 - LM 13 - LO 5 Abnahmetests




Abnahme Tests

• Systemtest mit Kunden

• Basis der Auslieferung der Software

• Übergang von Entwicklungs- in Wartungs- Phase

• Basis Softwareanforderungen des Softwareentwicklungsvertrags

• Durchführung als Black Box Test, da Implementierung nicht mehr interessiert

• Validierung der Software

• Tips:

– Softwareanforderungen auf das Wesentliche konzentrieren, Abnahme Test sollte nicht länger als eine Tag (Projekte bis 1 ME) oder eine Woche (Projekte grösser 1 ME) dauern

– Systemtest sollte schon während Designphase geplant werden. Dann noch genügend Zeit, um Eckpunkte zu setzen und zu dokumentieren




Plan für Abnahme Tests

• Funktionstests– Testfälle unter Berücksichtigung der Daten des Kunden entwickeln– Tests auf Zielrechner durchführen– Vorkehrungen für Wiederherstellung der Ausgangsumgebung treffen

• Strukturtests– Ergänzung der Funktionstests um nicht überdeckte Pfade bis vorgegebene

Überdeckungsrate erreicht wird• Regressionstests

– Überprüfung der Auswirkung von Fehlerbeseitigung• Sonstige Empfehlungen

– Wiederanlaufen der Software nach Fehlerabbruch nachweisen– Soll die Software auch ausserhalb der regulären Arbeitszeit einsatzbereit sein,

dafür geeignete Tests beim Kunden vorsehen.– Erwartete Ergebnisse rechtzeitig vor Testbeginn dokumentieren– Kriterien für Akzeptanz möglichst eindeutig formulieren




Grenzwertanalyse

• Unter der Voraussetzung, daß die Elemente einer Äquivalenzklasse auf natürliche Weise geordnet werden können, ist es mit Hilfe der Grenzwertanalyse möglich, die durchschnittliche Effektivität der Testfälle zu erhöhen. Als Testfälle werden bei diesem Verfahren die Grenzwerte der Äquivalenzklassen ausgewählt. Die Annäherung an die Äquivalenzklassengrenze kann vom gültigen oder vom ungültigen Bereich aus erfolgen.




Tests spezieller Werte

• Mit dem Oberbegriff des Tests spezieller Werte wird eine Reihe von Testverfahren bezeichnet, die für die Eingabedaten oder für von den Eingabedaten abhängige Aspekte bestimmte Eigenschaften fordern. Ziel dieser Testverfahren ist es, durch die Nutzung vorhandener Erfahrungen möglichst fehlerträchtige Testfälle aufzustellen. Bekannte Ansätze sind neben der Grenzwertanalyse das Zero Value-Kriterium, die Zuweisung des Wertes 0 an Variablen, die in Berechnungen eingesetzt werden und das Distinct Value-Kriterium, bei dessen Einsatz miteinander in Beziehung stehende Datenelemente mit unterschiedlichen Werten belegt werden.




Zufallstests

• Zur Vermeidung der Entstehung von Testfällen durch eine deterministische Strategie können Zufallstests eingesetzt werden. Diese basieren auf der zufälligen Auswahl von Testwerten aus dem Definitionsbereich der Eindabedaten. Durch den Einsatz dieser Verfahren kann vermieden werden, nur naheliegende Testfälle, die dementsprechend bereits bei der Implementierung berücksichtigt wurden, auszuwählen.




Externe Tester

• Durch den Einsatz einer externen Testgruppe erfolgen Testvorbereiung und Testdurchführung - im Idealfall - unvoreingenommen und unparteiisch. Des weiteren können Abweichungen im Verständnis des Lastenhefts, vor dem Abnahmetest durch den Auftraggeber, aufgedeckt werden.

• Eine konsequente Weiterentwicklung des Einsatzes einer externen Testgruppe ist das Cleanroom-Prinzip. Wesentliche Kennzeichen dieses Ansatzes bezüglich der Software-Qualitätssicherung sind

die Einteilung des Entwicklungsteams in drei unabhängige Gruppen, denen die Tätigkeitsbereiche Analyse, Entwicklung und Test zugeordnet werden,

Moduln kommen unter Konfigurationskontrolle, sobald sie fehlerfrei übersetzbar sind und

Moduln und Programme werden nur von der Testgruppe ausgeführt.




LE 3.2 - LM 13 - LO 6 Zusammenfassung und Abspann




Zusammenfassung

• Ergebnisse der Aktivitäten eines Prozessmodelles sind Produkte, die vorgegebenen Qualitätsmerkmalen genügen müssen. Handelt es sich bei den Produkten um Software, so erfolgt der Nachweis des Erreichens der Qualitätsziele durch Tests.

• In der Endphase eines Projektes werden das Gesamtprodukt (System) und sein Verhalten getestet.

• Aus den Systemtests entwickelt man Abnahmeprozeduren, mit deren Hilfe dem Auftraggeber stichprobenartig nachgewiesen wird, dass das Produkt die geforderten Eigenschaften aufweist.

• Daraufhin erfolgt die Abnahme, an die sich eine ausführliche Phase des Testens durch den Auftraggeber anschließt.




Testing Frameworks im Internet

• Testing Framework (xUnit, unit testing) http://www.xprogramming.com/software.htm

• Kent Beck‘s orginal Test Framework Paperhttp://www.xprogramming.com/testfram.htm

• Xunit testing frameworkshttp://www.junit.org/index.htm

• Bugzilla

http://www.mozilla.org/projects/bugzilla/

• Automatisches Unit Testinghttp://www.parasoft.com




Literatur• D. A. Wheeler, Software Inspection: an industry best practice, Los Alamitos,

(1966)

• G. J. Myers, The Art of Softwaretesting, New York, (1979)

• T. A. Thayer, Software Reliability, Amsterdam, (1978)

• G. E. Thaller, Software Test: Verifikation und Validation Heise, (2000)

• Balzert, Helmut: Lehrbuch der Software-Technik : Software-Entwicklung. Heidelberg u.a.: Spektrum Akademischer Verlag, (1996).

• Davis, Alan: Software Requirements: Analysis and Specification. Englewood Cliffs: Prentice Hall, 1990.

• G.E.Thaller, Software und Systementwicklung Aufbau eines praktikablen QM Systems nach ISO 90001:2000, Heise Verlag 2002

• H. Balzert: Lehrbuch der Softwaretechnik: Software-Management, Software-Qualitätssicherung,Unternehmensmodellierung, Spektrum Verlag (1998)

• G.E. Thaller: Software-Metriken: einsetzen, bewerten, messen, Heise-Verlag (1994)




Danksagung

Aus folgenden Vorlesungen und Foliensammlungen aus dem Bereich Softwaretechnik konnten wir Anregungen zur Gestaltung dieses Lernmoduls gewinnen:

P. Göhner Softwaretechnik 1 IAS Uni Stuttgart

A. Schürr Software Engineering 1 Uni BW München




LE 3.2 - LM 13 - LO 7

Tests zu LM 13




Diese Fragen sollten Sie jetzt beantworten können

• Wer führt Systemtests durch

• Wer führt Abnahmetests durch

• Was sind Systemtests

• Was ist das Cleanroom Prinzip

• Welch Regeln sollten beim Abnahmetest beachtet werden

Test 1

Documents

Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.2 Qualitätsmanagement Folie 1LM 13 Prüfung von SW-System und Abnahme Tests System-