Verbesserte Softwarequalit¤t durch effiziente Testprozesse

Verbesserte Softwarequalitatdurch effiziente Testprozesse

Prof. Dr. Jan PeleskaTZI und Verified Systems International GmbH

Revision: 1.5

TECHNOLOGIE-ZENTRUM INFORMATIK •VERIFIED SYSTEMS INTERNATIONAL GMBH

Ubersicht

• Vorgehensmodelle: Der Testprozess imSoftware-Engineering

• Testarten auf unterschiedlichen Systemebenen: Unittest –Integrationstest – Subsystemtest – Systemtest

• Test-Techniken: statische und dynamische Tests,Testabdeckung, Metriken

• Spezifikationsbasiertes Testen am Beispiel von BusinessApplications und Embedded Systems

• Tools und Auswahlkriterien

• Design for Testability


Vorgehensmodelle: Der Testprozess imSoftware-Engineering

Vorgehensmodelle (V-Modelle) . . .

• . . . regeln den Entwicklungsprozess durch Definition vonAktivitaten und Produkten, die in den einzelnenEntwicklungsphasen durchzufuhren bzw. herzustellen sind,

• . . . geben Hinweise uber die mogliche Verteilung derVerantwortlichkeiten bei der Durchfuhrung der Aktivitaten,

• . . . sind generische Regelungen, die fur das spezifischeEntwicklungsvorhaben instantiiert werden (Tayloring).


Vorgehensmodelle mit Softwarebezug – Beispiele

• DIN ISO 9000 Teil 3 schreibt Testen und Validierungals festen Bestandteil des Qualitatssicherungssystems vor.

• IEEE Std. 829-1998 – IEEE Standard for SoftwareTest Documentation ist ein Standard furSoftwaretestdokumentation.

• ISO/IEC 12119 – Information Technology –Software packages – Quality requirements andtesting ist ein sehr allgemein gehaltener Standard, der dieallernotwendigsten Anforderungen an denSoftware-Testprozess beschreibt – kein Bezug zumSystemtesten


• RTCA/DO-178B (V-Modell fur Softwareentwicklung inder zivilen Luftfahrt) unterscheidet zwischen den ProzessenVerifikation (aktive Durchfuhrung von Verifikation,Validation und Test) und Qualitatsmanagement(Management aller Aktivitaten mit Qualitatsbezug).

• V-Modell des Bundesinnenministeriums1 sieht Testenals Bestandteil des Product Assessment (PA)

1siehe z.B. http://www.informatik.uni-bremen.de/∼uniform/gdpa/


Bestandteile des Product Assessment nach V-Modell

• Statische Analyse,

• Test,

• Simulation,

• Korrektheitsbeweis,

• Symbolische Programm-(Spezifikations-)ausfuhrung,

• Review,

• Inspektion.


Grundforderungen des V-Modells zum Testen – Testfall

• Testfallbeschreibung:

– Was wird gepruft (Test Objective, Referenz zuSystemanforderungen, SW-Anforderungen,Entwurfsanforderungen, Benutzerhandbuch,Installationshandbuch . . . )?

– Was sind die Randbedingungen/Anfangsbedingungenfur den Test (Execution Condition)?

– Welche Eingabedaten sind fur den Test erforderlich(Inputs) ?

– Was sind die erwarteten Resultate (Outputs, ExpectedResults)?


Grundforderungen des V-Modells zum Testen –Testprozedur

• Testprozedur:

– Instruktion (“Rezept”) zur Ausfuhrung eines Testfallsoder einer Kollektion mehrerer Testfalle

– Instruktionen zur Erzeugung der konkreten Testdaten– Instruktionen zu Reihenfolge und Zeitpunkten

(ggf. abhangig von den Ausgaben des Testlings), indenen die Testdaten auf die Eingabeschnittstellen desTestlings geschrieben werden

– Instruktionen zur Auswertung der konkreten Ausgabendes Testlings

– Instruktionen zum Vergleich der Ausgaben desTestlings gegen die erwarteten Resultate


Grundforderungen des V-Modells zum Testen –Ruckverfolgbarkeit (Traceability)

• Uberdeckungsmatrix:

– Strukturuberdeckung: WelcheArchitekturkomponenten und Codefragmente werdendurch den Test beruhrt ?

– Anforderungsuberdeckung: WelcheNutzer-/Sicherheits-/technischen Anforderungen,werden getestet ?


(Im Test zu prufende) Qualitatseigenschaften –Gliederung

• Wirksamkeit: Eignung des Systems, seine intendierteAufgabe zu erfullen. Die Prufung der Wirksamkeit durchTests, Analysen, Inspektionen etc. heisst Validierung.

• Korrektheit: Ubereinstimmung des Systems mitspezifizierten Eigenschaften. Die Prufung der Korrektheitdurch Tests, Analysen, Inspektionen, Formale Verifikationetc. heisst Verifikation.


Zuordnung: Testaktivitaten im Entwicklungsprozess

software

subsystemrequirements

requirementssoftware

code

target dependentsoftware design

systemacceptance tests

integration testssubsystem

acceptance tests

integration testssoftware

integration

codeobject

codesource

unit

software

sub−system

systemsystem requirements

and linkingcode compilation

unit tests

software

design of control andinformation processing functions

codeobject

software designtarget independent

(including all functions)

integrationlevel

software

requirements


(Im Test zu prufende) Systemeigenschaften – Gliederung

• Funktionale Eigenschaften: Charakteristika der

– Daten

– Datentransformationen

– Kausaleigenschaften (auch “Kontrolleigenschaften”,d. h. Reihenfolge bestimmmter Ereignisse,Synchronisation)

– Zeitverhalten:

∗ Diskrete Zeitpunkte fur die Anderung von Daten(time-discrete behaviour)

∗ Kontinuierliche Anderung von Daten (Stellgroßen)uber der Zeit (time-continuous behaviour)



• Struktureigenschaften:

– Eigenschaften der System- undSoftwarearchitektur: Aufrufhierarchie zwischenProzeduren oder Funktionen – Nachrichtenaustauschzwischen Objekten – Datenfluss zwischen Threads,Prozessen, Rechnern – Zugriff auf globale Daten –Kapselung von Methoden in Klassen – Kapselung vonProzeduren und Funktionen in Threads oder Prozessen– Hardwarearchitektur

– Eigenschaften der Softwarekontrollstruktueninnerhalb eines Moduls: ; - if-then-else - while



• nicht-funktionale Eigenschaften:

– Dependability: Reliability – Availability – Safety – Security

– Wartbarkeit

– Betriebskosten

– Ergonomische Eigenschaften – Benutzerfreundlichkeit

– Lastverhalten – Performanz – vom (Daten-)Volumenabhangiges Verhalten – Stressverhalten

– Robustheit

– Kompatibilitat

– Konfigurationseigenschaften (zulassigeBetriebssystemversionen, Sprachauswahl,. . . )

– Dokumentation


Testarten – Gliederung

Die Testarten lassen sich nach folgenden Kriterien klassifizieren:

• Systemeigenschaften: Funktionale Tests – Strukturtests –nicht funktionale Tests (siehe oben)

• Integrationslevel: Unittests – Integrationstests –Subsystemtests – Systemtests

• Umgebungsbedingungen: Test des Normalverhaltens –Test des Ausnahmeverhaltens

• Beobachtungstiefe: White-Box Tests – Black-Box Tests


• Intrusive/nicht intrusive Tests: Intrusive Testsverandern den Testling vor oder wahrend derTestausfuhrung (z. B. Hardwaremodifikationen, Crash Tests,instrumentierter Softwarecode). Nicht intrusive Testsverandern den Testling nicht.


Testarten – Unittests (= Modultests)

• Testscope: Unittests untersuchen die kleinsten “Bausteine”des Softwaresystems: Functions, Threads, Objects, DataContainer . . .

• Testziele: Korrekte Arbeitsweise der Unit in Abwesenheitanderer zum System gehorigen Softwarekomponenten =⇒die Unit wird isoliert gepruft.

• Referenz: Modulspezifikation, Feinentwurf


Testumgebung fur Unittests

Test Driver(Test Harness)

Unit under Test

Test−Stub 1 Test−Stub 2 . . . . . . . . . . . . .

. . . . . .

Unit Interface

Interf. Unit 1 Interf. Unit 2

Test−Input Data

Test Driver controls test execution,provides input data, stores outputsof Unit Under Test

Test Stubs replace "real" units of the system under test,stubs provide same interface as real units

Main Program:


Testarten – Software-Integrationstest

• Testscope: Teilsysteme kooperierender Komponenten(Functions, Threads, Processes)

• Testziele: Korrekte Kooperation der Komponenten prufen:

– Datenfluss, Schnittstellen

– Synchronisation beim Zugriff auf gemeinsameRessourcen

• Referenz: Software-Subsystemanforderungen,Modulspezifikationen, SW-Architekturdesign (Grobentwurf)


Testarten – Subsystem-Integrationstest

• Testscope: HW/SW-Subsysteme (einzeln undkooperierend) – endet mit dem Test des Gesamtsystems

• Testziele: Korrekte Arbeitsweise der Subsysteme prufen:

– Zusammenspiel zwischen Hardware und Software imeinzelnen Subsystem

– Kooperation mehrerer Subsysteme

– Funktionsweise der Kommunikationsmedien zwischenHW/SW-Subsystemen

• Referenz: Systemanforderungen, Subsystemanforderungen,Systemdesign


Testarten – Systemannahmetest

• Testscope: Gesamtsystem

• Testziele: Nachweis der spezifiziertenBenutzeranforderungen =⇒ Systemannahmetest ist haufigeine Untermenge der auf Gesamtsystem-Leveldurchgefuhrten Integrationstests.

Fruher wurden Systemannahmetests auch mit demZiel der Validierung (d.h. Prufung des Systemshinsichtlich seiner Wirksamkeit) durchgefuhrt. Eineso spate Validierung wird heute als viel zu riskantfur den Projekterfolg angesehen.

• Referenz: Benutzeranforderungen


Testarten – Normalverhalten versusAusnahmeverhalten

• Normal Behaviour Tests prufen die Korrektheit desTestlings unter normalen Umgebungsbedingungen.

• Exceptional Behaviour Tests (Robustness Tests)prufen die Korrektheit des Testlings in spezifizierten(d. h. vorhersehbaren) Ausnahmesituationen.

• Normal und Exceptional Behaviour Tests konnen auf jederIntegrationsstufe (Unit-Level bis System-Level)durchgefuhrt werden.


Testziele der Robustheitstests

Test-Level Testziele – Robust gegen . . .Unit falsche Eingabeparameter – falsche DatenobjekteIntegration falsche Daten an Prozess/Thread-Interfaces –

falsche I/O-Folgen in der Kommunikation zwi-schen Komponenten – fehlende Ressourcen –Timeouts – Ausfall einzelner SW-Komponenten

Subsystem fehlerhafte Kommunikationsprotokolle – lokaleHardwarefehler – lokale Uberlast – Ausfall einzel-ner SW-Komponenten

System Subsystemausfalle – Uberlastsituationen imGesamtsystem


Testarten – Black-Box versus White-Box

• Black-Box Tests untersuchen funktionale Eigenschaftender Komponente durch Analyse ihres an der Schnittstellesichbaren Verhaltens.

Black-Box Tests konnen i.a. nicht alle relevantenfunktionalen Eigenschaften des Testlings prufen(⇐= nicht sichtbare interne Entscheidungen fuhrenzu nicht-deterministischem Verhalten an derSchnittstelle)!

– =⇒ erzielte Strukturuberdeckung beim Black-Box Testmessen !

– =⇒ ggf. zusatzliche White-Box Tests zum Erreichender Strukturuberdeckung durchfuhren !


Testarten – Black-Box versus White-Box

• White-Box Tests untersuchen strukturelle Eigenschaftender Komponente.

Fur sinnvolle White-Box Tests mussen dieErgebnisse auch bzgl. ihrer funktionalen Korrektheitgepruft werden!

• Black-Box und White-Box Tests konnen auf jederIntegrationsstufen (Unit-Level bis System-Level)durchgefuhrt werden.


Test-Techniken

• Statische Tests – formale Verifikation

• Dynamische Tests

• Testabdeckung

• Metriken


Spezifikationsbasiertes Testen

• Spezifikationsbasiertes Testen auf Grundlageformaler – maschinell interpretierbarer –Spezifikationen ist die Voraussetzung furAutomatisierung!


Spezifikationsbasiertes Testen

Einige Fakten aus der Theorie:

• Anforderungen, die sich mit Hilfe paralleler, kooperierenderZustandsmaschinen formulieren lassen, erlaubenautomatische Testerzeugung, Durchfuhrung undAuswertung in Echtzeit.

• Auch fur nicht terminierende Systeme (z.B. Controller) lasstsich die Vollstandigkeit der erzielten Uberdeckung prufen,wenn eine obere Schranke fur die Anzahl der moglichenSystemzustande bekannt ist.

• Es gibt Anforderungen, die untestbar sind.

• Es gibt Anforderungen, die nicht automatisiert testbar sind.


Tools und Auswahlkriterien

Specifications

. . . . additionalsystem

Target System

Test MonitorTest Driver

Test Generator Test Evaluator

interface monitoring channels


Design for Testability – Kompositionalitat

• Kompositionalitat: Komponenten erfullen ihreSpezifikation unabhangig davon, ob weitere Komponentenparallel aktiv sind oder nicht.

– Beispiel “nicht kompositionell”: zwei Prozessegreifen unsynchronisiert auf globale Variable zu

– Beispiel “kompositionell”: zwei Prozesse greifenmittels Monitor auf globale Variable zu



Auswirkung der Kompositionalitat auf das Testen:

• Funktionstests konnen mit den isolierten Komponentenausgefuhrt werden.

• Integrationstests mussen nur noch die korrekteKooperation prufen (Strukturtest).



Herstellung von Kompositionalitat im Design – Kompositionalitatbzgl. Datentransformation und Kausalitat:

• Zugriff auf globale Daten kapseln

• Zugriff auf kritische Abschnitte in gleichformiger Artsynchronisieren:

– Verwendung von Monitoren

– Verwendung von Semaphoren

– Verwendung von Active-Wait-Mutex Verfahren

Achtung: bei Kompositionalitatbzgl. Timing-Eigenschaften mussen ggf. paralleleKomponenten auf mehrere Prozessoren verteilt werden!


Design for Testability – StrukturerhaltendeTransformation von Anforderungen ins Design

• Strukturerhaltende Transformation: Struktur undDatenfluss der Anforderungsspezifikation wird fur dasArchitekturdesign ubernommen =⇒ direkte Beziehungzwischen Systemkomponente und der von ihrimplementierten funktionalen Anforderung.

Vorteil der strukturerhaltenden Transformation beim Testen:

• Uberdeckung der funktionalen Anforderungen beimTesten erzeugt gleichzeitig bereits dieStrukturuberdeckung.


Design for Testability – HW/SWTestschnittstellen

Zielsetzung: Bereits im Design “Testpunkte”, d.h. zusatzlicheSchnittstellen fur den spateren Test einplanen – am besten alspermanente Systemschnittstellen vorsehen. Anwendungsbereiche:

• Monitoring der erzielten Uberdeckung

• Kunstliche Herbeifuhrung von im operationellen Betriebselten auftretenden Zustanden

• Fehlerinjektion auf Software und Hardwareebene


Design for Testability – Kohasion

• Kohasion: SW-Komponenten tragen zur Implementierungvon nur einer funktionalen Anforderung bei – es werdennicht mehrere funktionalen Anforderungen gleichzeitig inderselben Komponente bearbeitet.

Vorteile beim Testen:

• Reduktion der Anzahl erforderlicher Testfalle


Design for Testability – Separation vonKontrolle und Datentransformation

• Separation von Kontrolle und Datentransformation:

– Kontrolle wird von ubergeordneten Komponentenausgeubt, die keine Datentransformationendurchfuhren.

– Datentransformationen werden von untergeordnetenKomponenten ausgefuhrt, die moglichst linear arbeitenund von den Kontrollkomponenten aktiviert werden.


Design for Testability – Separation vonKontrolle und Datentransformation

Vorteile beim Testen:

• Fur den Test der Kontrollkomponenten kann von Nutzdatenweitgehend abstrahiert werden.

• Fur die Erzielung der erforderlichen(Verzweigungs-)Uberdeckung bei Datentransformationensind weniger Testfalle erforderlich.


Design for Testability – Kapselung der kritischenFunktionen, Partitionierung

• Partitionierung: Trennung kritischer Funktionen vonunkritischen Funktionen im Systemdesign – Ausfuhrung derunkritischen Funktionen muss nebenwirkungsfrei fur diekritischen Funktionen sein.

• Kapselung: Implementierung der kritischen Funktionen inmoglichst wenigen Komponenten.


Design for Testability – Kapselung der kritischenFunktionen, Partitionierung

Aus Partitionierung und Kapselung resultiert verminderterTestaufwand:

• Unkritische Funktionen konnen mit geringerer Uberdeckunggepruft werden. (=⇒ Das gilt nur bei guter Partitionierung– sonst kann ein Dominoeffekt von unkritischen zukritischen Fehlern erzeugt werden!)

• Nur wenige Funktionen sind mit maximaler Uberdeckung zuprufen.

• Kein Integrationstest fur kritische Funktionen imZusammenspiel mit unkritischen erforderlich.


Design for Testability – Probleme beimOO-Design

Folgende OO-Merkmale erschweren den vertrauenswurdigen Testvon OO-Komponenten:

• Dynamische Objekterzeugung/Objektvernichtung:Das korrekte Verhalten hangt nicht allein von derProgrammierung der Objekte, sondern von den Zeitpunktender Objektallokation/-deallokation ab. (AnalogesProblem: Polymorphie und Vererbung mit dynamischerBindung)

• Generische Klassen: Die Korrektheit des Codes fur diegenerische Klasse garantiert noch nicht die Korrektheit jedermoglichen Instanz, da die konkreten Datentypen derInstantiierung besondere Probleme erzeugen konnen, die aufKlassenebene nicht sichtbar sind.


Anhang: Begriffe

Analytische Qualitatssicherung Sicherung der Qualitat durchUntersuchung der Produkteigenschaften

Prozessbezogene Qualitatssicherung Sicherung der Qualitatdurch Prufung der Angemessenheit und korrektenAusfuhrung des Entwicklungsprozesses

Test Case (RTCA/DO-178B) A set of inputs, executionconditions, and expected results developed for a particularobjective, such as to exercise a particular program path orto verify compliance with a specific requirement.

Testen analytische Qualitatssicherung von ausfuhrbarenSW-Programmen oder vollstandigen HW/SW-Systemen


Testing (RTCA/DO-178B) The process of exercising a systemor system component to verify that it satisfies specifiedrequirements and to detect errors.

Test Procedure (RTCA/DO-178B) Detailed instructions forthe set-up and execution of a given set of test cases, andinstructions for the evaluation of results of executing thetest cases.

Dynamisches Testen Prufung von ausfuhrbarenSW-Programmen oder vollstandigen HW/SW-Systemendurch dynamische Ausfuhrung mit speziellen Eingabedaten

Statische Analyse analytische Qualitatssicherung von Softwaredurch Untersuchung des Quellcodes ohne seine dynamischeAusfuhrung


Validation Prufung des Systems (oder seinerAnforderungsspezifikation) hinsichtlich Wirksamkeit(Adaquatheit), Vollstandigkeit, Widerspruchsfreiheit,Eindeutigkeit

Validation (RTCA/DO-178B) The process of determiningthat the requirements are correct requirements and thatthey are complete. The sysrem life cycle process may usesoftware requirements and derived requirements in systemvalidation.


Verifikation Prufung eines Produktes gegen eineReferenzspezifikation

Verification (RTCA/DO-178B) The evaluation of the resultsof a process to ensure correctness and consistency withrespect to the inputs and standards provided to thatprocess.

Formale Verifikation Prufung eines Produktes gegen eineformale Spezifikation mittels mathematischerNachweisverfahren


Verbesserte Softwarequalit¤t durch effiziente Testprozesse

Documents

Transcript of Verbesserte Softwarequalit¤t durch effiziente Testprozesse