Grundlagen des Testens Kapitel 1 Einführung
Transcript of Grundlagen des Testens Kapitel 1 Einführung
1
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Grundlagen des Testens
Rainer Schmidberger
Seminarunterlagen
Folie 2se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Inhaltsübersicht
Kapitel 1: Einführung (2h)Kapitel 2: Testen im Software-Lebenszyklus (6h)
Kapitel 3: Testfallentwurfsverfahren (6h)Kapitel 4: Testmanagement (2h)
Kapitel 5: Testdokumentation (2h)Kapitel 6: Testwerkzeuge (3h)Kapitel 7: Test-Standards (3h)
2
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 1Einführung
Übersicht der PrüfverfahrenMotivation und BegriffeFundamentaler TestprozessTestzieleTestprinzipien nach G. Myers
Folie 4se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Das Objekt der Begierde ...
[Grace Hopper, Logbuch-Seite des Mark II Aiken Relay Calculator mit dem ersten „Bug“ von1947]
3
Folie 5se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Prüfverfahren
Folie 6se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Prüfverfahren
Organisatorisch: Regelung von ZuständigkeitRegelung von Richtlinien, Standards, ChecklistenSchulung der Mitarbeiter
KonstruktivEinsatz geeigneter Methoden, Sprachen und Werkzeuge. Verwendung bestimmter Prozessmodelle
Das Entstehen von Fehlern wird durch geeignete Maßnahmen während der Entwicklung verhindert:
4
Folie 7se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Der Prüfgegenstand (Teil-, Zwischen- oder Endprodukt) wird auf Fehler hin untersuchtDie Qualität des Prüfgegenstands wird bewertetEs wird geprüft, ob ein Prüfgegenstand bestimmte vorgegebene Qualitätskriterien erfüllt
Prüfverfahren
Folie 8se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
PrüfverfahrenDurchsicht (Schreibtisch-Test)Informell, wird vom Urheber selbst durchgeführtStellungnahmeEinholen einer anderen MeinungTechnischer ReviewWohldefiniertes, dokumentiertes Verfahren zur Bewertung eines PrüfgegenstandsWalkthroughMischform zwischen der Stellungnahme und dem technischen Review
5
Folie 9se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Stilanalysen wie z. B. Konformität zu ProgrammierrichtlinienArchitekturanalysen Anomalien (z. B. Datenflussanomalien)Code-Metriken
Prüfverfahren
Folie 10se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
„Testen ist die Ausführung eines Programms mit der Absicht, Fehler zu finden“
[Myers, 1979]
und
Dokumentation der genauen Ausführungs-bedingungen wie z.B. Version, Testfälle und Resultate.
Prüfverfahren
6
Folie 11se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TestAn activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component.
lEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
Folie 12se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlhandlung, Defekt, FehlverhaltenVermeidbar oder erkennbar durch
DefinitionBegriff
TestFehlverhalten eines Programms gegenüber der Spezifikation, das während seiner Ausführung (tatsächlich) auftritt.Die Anwendung zeigt einen Fehler
Failure(Fehlverhalten, Fehlerwirkung, Mangel)
Inspektion, Review, Programmanalyse
Fehlerhafte Stelle (Zeile) eines Programms, die ein Fehlverhalten auslösen kann.Das Programm enthält einen Fehler
Fault/Defect/ Bug (Defekt, Fehlerzustand, Fehlerursache)
Schulung, Konvention, Prozess-verbesserung
Fehlerhafte Aktion einer Person (Irrtum), die zu einer fehlerhaften Programmstelle führt.Eine Person macht einen Fehler
Error/Mistake(Fehlhandlung, Versagen, Irrtum)
Begriffe gem. ISTQB
7
Folie 13se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ariane Flug 501ESA, Kourou, Franz. Guyana, 4. Juni 1996
Selbstzerstörung der Ariane 5 beim Jungfernflug 39 Sekunden nach dem Start4 Satelliten werden verloren: 400-500 M Euro, 2 Jahre Verzug im Entwicklungsprogramm: > 500 M Euro, 2 zusätzliche Erprobungsstarts
Folie 14se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
8
Folie 15se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Der Quellcodedeclare
vertical_veloc_sensor: float;
horizontal_veloc_sensor: float;
vertical_veloc_bias: integer;
horizontal_veloc_bias: integer;
...
begin
declare
pragma suppress(numeric_error, horizontal_veloc_bias);
begin
sensor_get(vertical_veloc_sensor);
sensor_get(horizontal_veloc_sensor);
vertical_veloc_bias := integer(vertical_veloc_sensor);
horizontal_veloc_bias := integer(horizontal_veloc_sensor);
...
exception
when numeric_error => calculate_vertical_veloc();
when others => use_irs1();
end;
end irs2;
Folie 16se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ariane: Chronik der Ereignisse – 1Die Software für das Trägheitsnavigationssystem wird unverändert von der Ariane 4 übernommen. Ein Test dieser Software unterbleibt daher.Die übrigen Systeme der Rakete werden komponentenweise gründlich getestet. Ein gemeinsamer Test der gesamten Steuerungssoftware der Rakete unterbleibt aus Kosten- und Machbarkeitsgründen.In der Software für das Trägheitsnavigationssystem gibt es eine Abgleichsfunktion, deren Werte eigentlich nur sinnvoll sind, solange die Rakete noch nicht fliegt. Diese Funktion arbeitet programmgemäß bis ca. 40 s nach H0 weiter, weil das bei der Ariane 4 im Fall eines Countdownabbruchs kurz vor dem Abheben sinnvoll war.Flug 501 startet am 4. Juni 1996. Die Triebwerke zünden um H0=9:33:59 Ortszeit. Die ersten 36 Sekunden des Flugs verlaufen normal.
Lions, J.L. (1996). ARIANE 5 Flight 501 Failure. Report by the Inquiry Board. Paris: ESA.http://esamultimedia.esa.int/docs/esa-x-1819eng.pdfZusammenfassung von Martin Glinz, Universität Zürich
9
Folie 17se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ariane: Chronik der Ereignisse – 2Da die Ariane 5 eine andere Flugbahn hat als die Ariane 4, berechnet die Abgleichsfunktion einen Wert, der wesentlich größer ist als erwartet.Bei der Konvertierung dieses Werts von einer 64 Bit Gleitkommazahl in eine 16-Bit Festkommazahl tritt ein Überlauf ein; der Rechner erzeugt eine Ausnahmebedingung.Die Ausnahmebedingung wird nicht behandelt (obwohl dies in der verwendeten Programmiersprache Ada möglich wäre).Der Trägheitsnavigationsrechner setzt eine Fehlermeldung an den Steuerrechner der Rakete ab und schaltet sich 36,75 s nach H0 ab.Das Trägheitsnavigationssystem ist aus Sicherheitsgründen doppelt ausgelegt. Ein Umschalten auf das zweite System schlägt fehl, da dieses System das gleiche Problem gehabt und sich vor 0,05 s ebenfalls abgeschaltet hat.
Lions, J.L. (1996). ARIANE 5 Flight 501 Failure. Report by the Inquiry Board. Paris: ESA.http://esamultimedia.esa.int/docs/esa-x-1819eng.pdfZusammenfassung von Martin Glinz, Universität Zürich
Folie 18se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ariane: Chronik der Ereignisse – 3Die Software des Steuerrechners ist auf den Ausfall beider Trägheitsnavigationssysteme nicht ausgelegt und interpretiert die gemeldeten Fehlercodes als Flugbahndaten.Dies führt zu völlig unsinnigen Berechnungen und als Folge davon zu unsinnigen Stellbefehlen an die Steuerdüsen der Rakete: Diese werden bis zum maximal möglichen Anstellwinkel ausgeschwenkt.Aufgrund der resultierenden Scherkräfte zerbricht die Rakete, worauf der Selbstzerstörungsmechanismus ordnungsgemäßanspricht. Dieser sprengt Rakete und Nutzlast und verhindert damit, dass größere Trümmerteile auf den Boden fallen.
Lions, J.L. (1996). ARIANE 5 Flight 501 Failure. Report by the Inquiry Board. Paris: ESA.http://esamultimedia.esa.int/docs/esa-x-1819eng.pdfZusammenfassung von Martin Glinz, Universität Zürich
10
Folie 19se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ariane: Lessons Learned für den TestIntegration: Bei der Prüfung von Software, die aus mehreren Komponenten besteht, genügt es nicht, jede Komponente nur isoliert für sich zu prüfen.Fehlerbehandlung: Liefert eine Komponente Fehlerdaten, sind Testfälle erforderlich, die die Fehlersituation prüfen.Systemtest ist unumgänglich aber aufwändig (im Fall Ariane praktisch unmöglich)Fehler treten gerne dort auf, wo man sie nicht erwartet; aber aus Schaden sollte man „klug“werden.Fehler haben ein unterschiedliches Schadens-potential: Der Test sollte dies berücksichtigen.
Nach Martin Glinz, Universität Zürich
Folie 20se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ziele des systematischen TestsReproduzierbarkeit: Ergebnisse entstehen nicht zufällig sondern systematisch und nachvollziehbar
Planbarkeit: Aufwand und Nutzen (gefundene Fehler!) können prognostiziert werden
Wirtschaftlichkeit: Aufwand und Nutzen werden optimiert: Testsuite-Optimierung, Dokumentation, Werkzeugeinsatz, Prozess-Optimierung
Risiko- und Haftungsreduktion: Der systematisch Test gibt Sicherheit, dass kritische Fehler nicht auftreten.
11
Folie 21se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Unsystematischer TestLaufversuch: Der Entwickler „testet“
Entwickler übersetzt, bindet und startet sein ProgrammLäuft das Programm nicht oder sind Ergebnisse offensichtlich falsch, werden die Defekte gesucht und behoben (“Debugging”)Der „Test “ ist beendet, wenn das Programm läuft und die Ergebnisse vernünftig aussehen
Wegwerf-Test: Testen ohne SystematikJemand „probiert“ das Programm mit verschiedenen Eingabedaten ausFallen „Ungereimtheiten“ auf, wird eine Notiz gemachtDer Test endet, wenn der Tester findet, es sei genug getestet Nach Martin Glinz, Universität Zürich
Folie 22se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ziel: Systematischer Test
Nach Martin Glinz, Universität Zürich
Systematischer Test: Spezialisten testenTest ist geplant, eine Testvorschrift liegt vorDas Programm wird gemäß Testvorschrift - der Testspezifikation - ausgeführtIst-Resultate werden mit Soll-Resultaten verglichenTestergebnisse werden dokumentiertFehlersuche und -behebung erfolgen separatNicht bestandene Tests werden wiederholtTest endet, wenn vorher definierte Testziele erreicht sindDie Testspezifikation wird laufend aktualisiert
12
Folie 23se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testbegriffe – 1Testfall (Test case): besteht aus Ausführungs-bedingungen, Eingabedaten und SollresultatTestsuite: Sammlung an TestfällenSollresultat (Expected result): das für eine Eingabe spezifizierte ResultatÜberdeckung (Coverage): TestvollständigkeitsmaßTestware: die gesamte Testumgebung (das Testgeschirr – test harness)Test-Orakel: ein Modul, das das Sollresultat für einen Testfall berechnetTestobjekt: der PrüflingSUT: System (hier im Sinne der Software!) under Test, das Testobjekt
Folie 24se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testbegriffe – 2
False-Positive:Auf Fehler bewertet, obwohl kein Fehler vorlag.
„Pseudo-Fehler“
False-Negative: Auf „kein Fehler“ bewertet, obwohl ein Fehler vorlag.
True-Positive: Korrekt gefundener Fehler
True-Negative: Korrekt auf „kein Fehler“ bewertet
Problemfälle
13
Folie 25se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testfall-DokumentationBeschreibung der Ausgangssituation
Genaue Beschreibung des Systemzustands
Eingaben bzw. AktionenGenaue Beschreibung, welche Funktionen ausgeführt werdenGenaue Dokumentation der Eingaben
Soll-ResultatWelche Ausgaben bzw. welches Verhalten wird vom System erwartet.
Folie 26se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Test-Orakel
Test-Report
Ist-Tesultat
Testfall1
Soll-Resultat
Fundamentaler Testprozess
Test-vorbereitung
Test-durchführung
SUT
Spe
zifikatio
nd
es SU
T
Test-auswertung
Soll-Resultat
Testsuite
Vergleich
We
itere
Bea
rbe
itung: Fe
hlera
nalyse
und
Fehle
rbe
heb
ung
Testprozess
14
Folie 27se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Aktivitäten beim Test
TestvorbereitungTestfallentwurfTestdatengenerierungSoll-Resultats-bestimmung
TestdurchführungTestumgebung einrichten (Test-Setup)Ist-Resultate erheben
TestauswertungAuswertung der Soll-und Ist-Resultate
Steuerung Datenfluss
TestmanagementZieleStandardsPersonal
TestdokumentationTestplanTestfälleResultate
Methoden, VerfahrenRessourcenTestende, Testabbruch
Testbericht
Folie 28se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testprozess-Schnittstellen
Fehler-datenbank
Entwicklung
Anforderungs-spezifikation /
Change Request
Test-auftrag
TestTestmanagement
Test-vorbereitung
Test-durchführung
Test-auswertung
Testdokumentation
15
Folie 29se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TestauftragPrüfling (Version, zu testender Teil des Prüflings, genaue Testrahmenbedingungen)TermineVerfügbarer Testaufwand und ggf. RessourcenTestgüte
„Rerun-all“Modifikationstest (nur Änderungen testen)Fehlernachtest (nur behobene Fehler testen)Nur Testfälle einer bestimmten Priorität
Testende- und Testabbruchkriterien
Folie 30se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TestendekriterienMan kann den Test beenden, wenn
alle spezifizierten Testfälle ausgeführt sinddie Testfälle einer bestimmten Risikogruppe getestet sindeine bestimmte Zeit kein weiterer Fehler mehr gefunden wirdeine bestimmte Anzahl an Fehlern gefunden istStrukturtest-Kriterien erfüllt sind (z. B. Anweisungsüberdeckung)der vereinbarte Testaufwand geleistet ist
Die Bestimmung des Testendes ist eine der wesentlichen Aufgaben des Testmanagements!
16
Folie 31se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kosten pro entdecktem Fehler
Kosten pro entdecktem Fehler
Zahl der entdeckten Fehler
t
Fehlerzahl und relative Kosten
Kosten-grenze
Aus Ludewig, Lichter, „Software Engineering“, 1. Auflage, Seite 463, dpunkt Verlag, 2006
[1] Ellims, M., Bridges, J., and Ince, D. C. „The Economics of Unit Testing“, Empirical Softw. Engg. 11, 1 (Mar. 2006),
Beispiel aus [1]: 8,4 Tage / Fehler
Folie 32se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Entstehung und Entdeckung von Fehlern(aus Balzert, IEEE Software, Jan. 1985, S.83)
0%
10%
20%
30%
40%
50%
60%
Anforderungs- undEntwurfsphase
TechnischeEntwurfsphase
Konstruktions- undSystemphase
Abnahmetest undBetriebsphase
Eingebrachte Fehler
Gefundene Fehler
17
Folie 33se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Relative Kosten zur Fehlerbeseitigung(H. Balzert, 1998; Boehm, 1976)
3 510
15
40
150
0
20
40
60
80
100
120
140
160
Definition Entwûrf Implementierung Entwicklungstest Abnahmetest Betrieb
Folie 34se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Komponenten-
Test
User-
Acceptance-
Test
Abnahmetest
Integrations-test
Systemtest
Stresstest
Blackbox-Test
Glass-Box-Test
Funktionstest
Lasttest
Modell-basierter Test
Beta-Test
Regressions-test
Zufallstest
Feldtest
Entwicklertest
Fehlernach-test
Spezifikations-basierter Test
Experten Test
Zustands-bezogener
Test
Risiko-basiertes
Testen
18
Folie 35se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testarten - StrukturierungsmöglichkeitKomponenten-
Test
User-Acceptance-
Test
AbnahmetestIntegrations-test Systemtest
Stresstest
Blackbox-Test
Glass-Box-Test
Funktionstest
Lasttest
Modell-basierter Test
Beta-Test
Regressions-test
Zufallstest
Feldtest
Entwicklertest
Fehlernach-test
Spezifikations-basierter Test
Experten Test
Zustands-bezogener
Test
Risiko-basiertes
Testen
Teststufe
Methode zur Herleitung der Testfälle
Testauftrag, Teststrategie
Testorganisation
Zu testende Eigenschaften
Folie 36se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Auf den Testmix kommt es an …Die Testverfahren unterscheiden sich hinsichtlich
dem Zeitpunkt im Projektverlauf, zu dem sie angewendet werden könnendem Einrichtungsaufwandden Fehlern die gefunden werden könnendem Automatisierungsgradder Effektivität (Aufwand pro gefundenem Fehler)dem Profil des Testers …
Testen besteht in der Regel aus einem Mix an verschiedenen Verfahren. Die Zusammenstellung des „passenden“ Mixes ist eine der zentralen Aufgaben
des Testmanagements.
19
Folie 37se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testprinzipien nach G. Myers – 1Ein notwendiger Bestandteil eines Testfalls ist die Definition der erwarteten Werte oder des Resultats.Ein Programmierer sollte nicht versuchen, sein eigenes Programm zu testen.Die Resultate eines jeden Tests sollen gründlich geprüft werden.Testfälle müssen für ungültige und und unerwartete ebenso wie für gültige und erwartete Eingabedaten definiert werden.Ein Programm darauf hin zu untersuchen, ob es nicht tut, was es tun sollte, ist nur die eine Hälfte der Schlacht. Die andere Hälfte besteht darin, zu untersuchen, ob das Programm etwas tut, was es nicht tun soll.
Folie 38se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testprinzipien nach G. Myers – 2Wegwerftestfälle sollten vermieden werden, es sei denn, das Programm ist wirklich ein Wegwerfprogramm.Es sollten keine Testverfahren geplant werden unter der stillschweigenden Annahme, dass keine Fehler gefunden werden.Testen ist eine extrem kreative und intellektuell herausfordernde Aufgabe.Testen ist der Prozess, ein Programm in der Absicht auszuführen, Fehler zu finden.Ein guter Testfall ist dadurch gekennzeichnet, dass er mit hoher Wahrscheinlichkeit einen bisher unbekannten Fehler anzuzeigen imstande ist.Ein erfolgreicher Testfall ist dadurch gekennzeichnet, dass er einen bisher unbekannten Fehler entdeckt.
20
Folie 39se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
AustestenWenn es genau x Möglichkeiten gibt, ein Programm auszuführen, und alle x Möglichkeiten im Test geprüft werden, ist der Test vollständig; das Programm ist ausgetestet.Aber angenommen, eine Prozedur erwartet 2 Integer-Werte als EingabedatenBei 32 Bit Länge ergeben sich 232 x 232 viele Kombinationen von Eingabewerten (≈ 1,8 x 1019)Selbst wenn ein automatischer Testtreiber in 1 ms einen Testfall ausführen kann, dauert der vollständige Test aller Eingabewerte in etwa 570 Mio. Jahre.
Das Austesten eines Programms ist (praktisch) unmöglich!
Folie 40se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Edsger W. Dijkstra, Notes on structured programming, Academic Press, 1972
Testen kann die Anwesenheit von Fehlern aufzeigen, aber nie einen Nachweis von Fehlerfreiheit liefern!
21
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 2Testen im Software-Lebenszyklus
V-ModellTeststufenTest nichtfunktionaler Anforderungen
Folie 42se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
V-Modell nach ISTQB
Anforderungs-definition
Funktionaler Systementwurf
technischer Systementwurf
Komponenten-spezifikation
Programmierung
Komponententest
Integrationstest
Systemtest
Abnahmetest
Validierung
Verifikation
Konstruktion und Integration
22
Folie 43se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Verifikation und ValidierungSprachgebrauch im V-Modell nach ISTQB
Verifikation: Prüfung, ob die Ergebnisse einer Entwicklungs-phase die Vorgaben der Eingangsdokumente erfüllen („Are we doing the thing right?“)Validierung: Prüfung, ob ein Entwicklungsergebnis die spezifizierten Anforderungen erfüllt („Are we doing the right thing?“)
Validierung
Verifikation
Alternativer SprachgebrauchVerifikation = formaler KorrektheitsbeweisValidierung = informelle Überprüfung
Testen bedeutet validieren!
Folie 44se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Verifikation und Validierung
Verification: (1) The process of evaluating a system orcomponent to determine whether the products of a given development phase satisfy the conditionsimposed at the start of that phase. (2) Formal proof of program correctness.
Validation: The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.
[IEEE Std 610.12 (1990)]
23
Folie 45se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Teststufen - ÜbersichtTestgegenstand sind Komponenten, teilintegrierte Systeme oder Systeme
Bilder: Martin Glinz, Universität Zürich
Komponententest, Modultest (Unit-Test)„autarke“ Komponenten werden isoliert getestet
IntegrationstestTeilintegrierte Komponenten testen die Komponenteninteraktion
SystemtestTest des Gesamtsystems
Folie 46se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TeststufenKomponententestIntegrationstestSystemtest
Weitere TeststufenUser Acceptance Test (UAT)Beta-TestAbnahmetestDeployment-Test
Test gegen nichtfunktionale Anforderungen
24
Folie 47se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Komponententest (1)„Testen im Kleinen“ (Liggesmeyer)Das Testobjekt beim Komponententest ist eine Komponente (=Unit, Modul, Subsystem). Komponenten sind ein Teil einer Applikation, z. B. eine (oder mehrere) Klassen oder eine Prozedur.Es gibt weder feste Vorgaben für die Größe einer Komponente (z.B. in LOC) oder für die Anzahl der Komponenten im Gesamtsystem. In der Praxis findet man Systeme, die aus 10 Komponenten aufgebaut sind bis hin zu Systemen, die aus 10.000 Komponenten und mehr aufgebaut sind.Im Komponententest wird die Komponente an den Schnittstellen gegen die Spezifikation getestet. Dazu ist eine Komponenten-Spezifikation erforderlich!
Folie 48se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Komponententest (2)Die Komponente sollte möglichst isoliert getestet werden; die Isolierung hat dabei den Zweck, komponentenexterne Einflüsse beim Test auszuschließen. Die Schnittstelle einer Komponente ist in der Regel eine Programmierschnittstelle. D.h., die Ausführung der Testfälle wird in der Regel in der Programmiersprache des Moduls programmiert.Wird ein Fehler gefunden, lässt sich die Ursache in der Regel der getesteten Komponente zuordnen.Es stehen Frameworks zur Verfügung: Visual Studio 2008, www.junit.org, www.testng.org, CppUnit, TESSY, Rational Test Realtime
25
Folie 49se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
component. One of the parts that make up a system. A component may be hardware or software and may be subdivided into other components. Note: The terms “module,” “component,” and “unit” are often used interchangeably or defined to be subelementsof one another in different ways depending upon the context. The relationship of these terms is not yet standardized.
component testing. Testing of individual hardware or software components or groups of related components. Syn: module testing.See also: integration testing; interface testing; system testing; unit testing.
lEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
Folie 50se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Komponente vs. UnitDer Unit-Test stellt zwar nach lEEE Std 610.12-1990 ein Synonym zum Komponenten-Test dar, in der Praxis wird aber Unit-Test in der Regel im Kontext von Klassen objektorientierter Programme gesprochen.
26
Folie 51se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testaufbau
Prüfling
Testtreiber
StubEin Stub (Platzhalter) ersetzt eine vom Prüfling genutzte Funktion
Der Testtreiber startet die Ausführung des Prüflings und nimmt Resultate entgegen (Beispiel: JUnit, TTCN-3, Tessy)
Folie 52se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: JUnit 4.0JUnit ist ein Komponententest-Framework für JavaEine beliebige Java-Klasse kann als Testtreiber verwendet werdenÜber Annotationen wird das Verhalten des Testtreibers bestimmt
public class MeineTestklasse {
@Before public void setUp() {// Testobjekt initialisieren
}@After public void tearDown() {// Belegte Ressourcen wieder freigeben
}
@Test public void testMethode1() { ... }@Test public void testmethode2() { ... }
}
27
Folie 53se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: CppUnit – 1CppUnit ist die „C/C++“-Variante von JUnithttp://sourceforge.net/projects/cppunitclass MeineTestklasse : public TestFixture{
CPPUNIT_TEST_SUITE (MeineTestklasse);CPPUNIT_TEST (testfall1);CPPUNIT_TEST (testfall2);CPPUNIT_TEST (testfalln);CPPUNIT_TEST_SUITE_END ();
public:void setUp();void tearDown();
protected:void testfall1();void testfall2();void testfalln();
private:// ... Hier wird in der Regel das Testobjekt referenziert
};
Folie 54se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: CppUnit – 2Beispiel einer Testfall-ImplementierungCPPUNIT_TEST_SUITE_REGISTRATION (MeineTestklasse);
void MeineTestklasse::setUp(){// Vorbereitungen treffen; Testobjekt initialisieren
}void MeineTestklasse::tearDown(){// Freigaben, evtl. das Testobjekt wieder löschen
}
void MeineTestklasse::testfall1(){double sollResultat = ...;
// Methode methode1 testenCPPUNIT_ASSERT_EQUAL (testobjekt->methode1(), sollResultat);
}...
28
Folie 55se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: CppUnit – 3MFC TestRunner
Folie 56se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Unit-Test - Beispiel: Klasse „Bruch“public class Bruch {
private int zaehler;private int nenner;public override bool Equals(object obj) {
Bruch b = (Bruch)obj;return this.zaehler == b.zaehler && this.nenner == b.nenner;
}public Bruch() {
nenner = 1;}public Bruch(int z, int n) {
zaehler = z;nenner = n;
}public static explicit operator double(Bruch b) { // cast von Bruch nach double
return ((double)b.zaehler) / b.nenner;}static public Bruch operator +(Bruch a, Bruch b) { // hier sitzt der Fehler
return new Bruch(a.zaehler * b.zaehler + b.zaehler * a.nenner, a.nenner * a.nenner);}static public Bruch operator !(Bruch a) {
return new Bruch(a.nenner, a.zaehler);}public override string ToString() {
return string.Format("{0} / {1}", zaehler, nenner);}
}
29
Folie 57se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Unit-Test mit Visual StudioEs wird ein Test-Projekt angelegt; das Projekt mit den zu testenden Klassen wird „referenziert“ (Hinweis: die zu testenden Klassen müssen dort public sein)Testklassen und Testmethoden werden über Attribute gesteuertEs ist oft hilfreich, wenn die zu testende Klasse eine Equals-Methode implementiert hat
[TestClass] public class UnitTestBruch{[TestMethod]public void TestInit(){
Bruch b = new Bruch(1, 2);Assert.AreEqual((double)b, 0.5, "Fehler beim Initialisieren");
}}
Folie 58se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Testmethoden für BruchBeispiel Testmethoden
[TestMethod]public void TestAddiere(){
Bruch b1 = new Bruch(1, 2);Bruch b2 = new Bruch(1, 3);Bruch b3 = new Bruch(5, 6);Bruch b4 = b1 + b2;Assert.AreEqual(b3, b4);
}[TestMethod]public void TestKehrwert(){
Bruch b1 = new Bruch(1, 2);Bruch b2 = new Bruch(2, 1);Bruch b3 = !b2;Assert.AreEqual(b1, b3);
}
Ausgangssituation
Aktion
Resultatsvergleich
Ausgangssituation
Aktion
Resultatsvergleich
30
Folie 59se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Unit-Test Attribute[ClassInitialize]
Wird vor Ausführung des ersten Testfalls [TestMethod]aufgerufen. Es können Initialisierungen vor Beginn des Tests vorgenommen werden.
[ClassCleanup]
Aufräumarbeiten nach Ende aller Testfälle [TestMethod][TestInitialize]
Initialisierung, die vor jedem einzelnen Testfall [TestMethod]aufgerufen werden
[TestCleanup]
Aufräumarbeiten, die nach jedem einzelnen Testfall[TestMethod] aufgerufen werden
[TestMethod]
Ein Testfall
Folie 60se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Test Result für die Klasse BruchVisual Studio 2008
Aufruf der ToString()-Methode
31
Folie 61se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zusammenfassung Unit-TestDie Werkzeugunterstützung und die Verankerung in den (Klassen)-Bibliotheken ist sehr gut.Der Fokus liegt auf objektorientierten Programmen, wobei in der Regel Unit=Klasse gilt.Bei sehr kleinen Units ist die Chance, Fehler zu finden, eher gering; die Fehler liegen in der Praxis eher in der Interaktion.Nicht selten werden zu Diagnose-Zwecken extra öffentliche Methoden aufgenommen.
Unit-Tests hinterlassen im Prüfling ihre Spuren!
Folie 62se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TTCN-3Testing and Test Control Notation„Konformitätstesten“Von der ETSI (European Telecommunications Standards Institute) standardisiertTTCN-3 ist eine SkriptspracheTTCN-3 wird für die Automatisierung von Tests speziell für kommunikationsbasierte Systeme verwendetTTCN-3 wird beispielsweise auch für das Testen von CAN- und MOST-Bussen verwendetEs sind kommerzielle und freie Werkzeuge verfügbarSiehe: www.ttcn-3.org
32
Folie 63se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TTCN-3 Architektur
Quelle: http://www.ttcn-3.org/Tutorials.htm
Folie 64se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TTCN-3: Beispiel – 1
testcase TC_resolveEtsiWww() runs on DnsClient{
timer t_ack;serverPort.send(m_dnsQuestion("www.etsi.org"));t_ack.start(1.0);alt {
[] serverPort.receive(mw_dnsAnswer("172.26.1.17")) {setverdict (pass);}
[] serverPort.receive { // any other messagesetverdict(fail);}
[] t_ack.timeout {setverdict(inconc);
}
}t_ack.stop;
}
Quelle: http://www.ttcn-3.org/Tutorials.htm
33
Folie 65se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
testcase TC_resolveEtsiWww() runs on DnsClient
TTCN-3: Beispiel – 2
DnsClientmtc
DnsPortserverPort
m_dnsQuestion("www.etsi.org")
timer t_ack
t_ack
altmw_dnsAnswer("172.26.1.17")
?
t_ack
inconc
fail
pass
t_ack
Quelle: http://www.ttcn-3.org/Tutorials.htm
Folie 66se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Aus:TTCN-3 User Conference 2007Anthony Wiles
http://www.ttcn-3.org/TTCN3UC2007/Presentations/Thu/ETSI%20TTCN-3%20keynote.pdf
34
Folie 67se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Entwurfskriterium: TestbarkeitDie Isolierbarkeit einer Komponente ist eine Voraussetzung für KomponententestsIsolierbare Komponenten entstehen bei Entwurf nicht zwangsläufig – die Isolierbarkeit muss aktiv im Entwurf herbeigeführt werdenEmpfehlung: Testbarkeit sollte bei Entwurfsreviewsmit einbezogen werden
Folie 68se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Test-First-AnsatzEs werden zuerst die Testfälle (in der Regel eingebettet in den Testtreiber) implementiert und anschließend der produktive ProgrammcodeTest-First entstammt den agilen Vorgehensweisen (Extreme Programming)Vorteile
QS der AnforderungAutomatisierung spart AufwandDer Test verliert den negativen BeigeschmackTestfälle werden dokumentiert und sind reproduzierbar
In der Praxis stellt eine unvollständige Komponentenspezifikation ein großes Problem dar!
35
Folie 69se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zusammenfassung KomponententestTest einer einzelnen isolierten Komponente
VorteileDer Test einer Komponente ist früh im Entwicklungsprozess möglichEs besteht eine gute WerkzeugunterstützungTestbarkeit ist ein hilfreiches EntwurfskriteriumKomponententests sind gut in den Entwicklungsprozess integrierbar
NachteileDie Interaktion zwischen den Komponenten wird nicht getestetZ. T. Aufwändiges Erstellen der Stubs
Folie 70se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TeststufenKomponententestIntegrationstestSystemtest
Weitere TeststufenTest gegen nichtfunktionale Anforderungen
36
Folie 71se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
IntegrationstestDer Integrationstest bildet die Brücke zwischen dem Komponententest und dem SystemtestZiel des Integrationstests ist es, Schnittstellen- und Protokollfehler aufzudecken
Inkompatible SchnittstellenformateUnterschiedliche Interpretation der übergebenen DatenTiming-Problem: Daten werden richtig übergeben, aber zum falschen oder verspäteten Zeitpunkt oder in zu kurzen Zeitintervallen (Durchsatz- oder Lastproblem).
Folie 72se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
integration. The process of combining software components, hardware components, or both into an overall system.
integration testing. Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. See also: component testing; interface testing; system testing; unit testing.
lEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
37
Folie 73se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Top-Down-Integration K1
S2
S2
Zu prüfende Komponente
Stub, der eine Komponente ersetzt
K1
S3 K2
K1
K3
S4 S5 S6 S7 S8
t
Der Test beginnt mit der „Hauptkomponente“Vorteil: Keine Testtreiber erforderlichNachteil: Noch nicht integrierte Komponenten müssen durch Platzhalter ersetzt werden.
Folie 74se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Bottom-Up-Integration K1 Zu prüfende Komponente
Treiber, der eine Komponente ausführt
T56 T7
K5 K6 K7 K8
t
Der Test beginnt mit den „untersten“KomponentenVorteil: Keine Platzhalter nötig, „intuitive“ VorgehensweiseNachteil: Übergeordnete Komponenten müssen durch Testtreiber simuliert werden. Damit sind viele zusätzliche Testfälle notwendig.
T3
K2 K3
K5 K6 K7 K8
T2 T3
T8
38
Folie 75se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Big-Bang-Integration
K2
K1
K3
K4 K5 K6 K7 K8
Der Test beginnt mit dem vollintegrierten SystemVorteil: Es sind keine Testtreiber und Stubs nötigNachteil: Schwierige Fehlersuche
Folie 76se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ad-hoc-Integration K1
S2
S2
Zu prüfende Komponente
Stub, der eine Komponente ersetzt
K1
S3
t
Vorteil: Fertiggestellte Komponenten können zeitnah integriert werden.Nachteil: Sowohl Testtreiber als auch Platzhalter sind erforderlich
K3
S6 S7
T7
K7 K8
T8
T3
Treiber, der eine Komponente ausführt
T3
39
Folie 77se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
IntegrationsstrategienTop-Down-Integration
Vorteil: Keine Testtreiber erforderlichNachteil: Noch nicht integrierte Komponenten müssen durch Platzhalter ersetzt werden.
Bottom-up-IntegrationVorteil: Keine Platzhalter nötigNachteil: Übergeordnete Komponenten müssen durch Testtreiber simuliert werden.
Ad-hoc-IntegrationVorteil: Fertiggestellte Komponenten können zeitnah integriert werden.Nachteil: Sowohl Testtreiber als auch Platzhalter sind erforderlich.
Big-Bang-Integration
Folie 78se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zusammenfassung IntegrationstestTest der Interaktion teilintegrierter Komponenten
VorteileAufdecken von SchnittstellenfehlernTest der integrierten KomponentenQS des Entwurfs„How do we eat an elephant?“ – „Bite by bite“
NachteileTeilintegration muss in der Regel aufwändig manuell erfolgenJe Teilintegration sind spezielle Testfälle erforderlichZ. T. aufwändige Erstellung der Stubs
40
Folie 79se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TeststufenKomponententestIntegrationstestSystemtest
Weitere TeststufenTest gegen nichtfunktionale Anforderungen
Folie 80se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
SystemtestTest des Gesamtsystems
Test des Zusammenspiels aller integrierten SystemkomponentenTest in produktionsnaher TestumgebungAchtung: Der Begriff „System“ ist keines falls eindeutig definiert (SW, SW+HW, SW+HW+Fahrzeug?)
TestzielPrüfung der spezifizierten Systemeigenschaften
Kundensicht statt Entwicklersicht
41
Folie 81se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
SystemgrenzenWas gehört alles zum „System“?
Die Summe aller Steuergeräte?Ein Steuergerät?Die Software des Steuergeräts?
Vor Systemtestbeginn (besser vor Projektbeginn) ist diese Frage genauestens zu klären!
Folie 82se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testziel im SystemtestVollständigkeit
Auf Basis der SystemspezifikationLeistung bzw. EffizienzZuverlässigkeit und Robustheit
Einschl. Missuse-TestfälleSicherheit (Security)Benutzbarkeit, Dokumentation
42
Folie 83se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Probleme beim SystemtestTestaufbau ist aufwändig(blöde, d.h. leicht vermeidbare) Fehler halten den Systemtest immer wieder aufDie Fehlerursache ist aufwändig zu findenFehler können Schaden an der Betriebsumgebung anrichten (z.B. bei angeschlossenen Geräten)
Um Fehler zu finden ist der Systemtest der ungeeignetste Test! Besser, man findet die Fehler
früher.
Folie 84se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Test gegen nichtfunktionale Anforderungen – 1
Lasttest: Systemverhalten (Speicherverbrauch, Antwortzeiten) bei steigender Last (z. B. Anzahl parallel arbeitender Anwender, Anzahl Transaktionen).Performanztest: Messung der Rechenzeit bestimmter Funktionen, in der Regel in Abhängigkeit von steigender LastVolumen-/Massentest: Systemverhalten bei steigenden DatenmengenStresstest: Systemverhalten bei ÜberlastungTest auf Sicherheit gegen unberechtigten Systemzugang (siehe www.bsi.de)Test auf Stabilität und Zuverlässigkeit im Dauerbetrieb
43
Folie 85se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Test gegen nichtfunktionale Anforderungen – 2
Test auf Robustheit gegenüber Fehlbedienung oder Fehlerzuständen der Umgebung, WiederanlaufverhaltenTest auf Kompatibilität/Datenkonversionen: Prüfung auf Verträglichkeit mit vorhandenen Systemen, Import/Export von DatenbeständenTest unterschiedlicher Konfigurationen: Betriebssysteme, Hardware, Ländereinstellungen (Dezimalzahlen, Einheiten, Datum), Spracheinstellungen Test auf Benutzungsfreundlichkeit: Prüfung von Erlernbarkeit und Verständlichkeit, bezogen auf die verschiedenen Benutzergruppen
Prüfung der DokumentationPrüfung auf Änderbarkeit/Wartbarkeit
Folie 86se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Systemtest: HiLTest realer Steuergeräte (-verbünde)
Zielsoftware läuft auf ZielhardwareTesten in geschlossenen Regelschleifen
Testsystem arbeitet Testsuite abVorspielen von Dateien mit Verläufen der StimuliAufzeichnen von Dateien mit Verläufen der Reaktionen
Hardware
SW-Modul 1
SW-Modul 2
SW-Modul n
TestsuiteTestfall 1Testfall 2
Testfall n
Test-Logfile
SUT
Bild: www.etas.de
44
Folie 87se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
HiL-TestsVorteile von HiL-Tests
Testabdeckung auch wenn reale Umgebung fehlt / nicht verfügbar (z. B. Glatteis)Gezielte Herbeiführung von GrenzsituationenAutomatisches Durchschreiten von ParametersätzenNachbildung von im Feldversuch aufgetretenen Auffälligkeiten
ProblemeAufwändige (teure) HardwareTestskripte müssen programmiert werden (wer testet diese Skripte?)In der Praxis gibt es eine hohe Zahl an False-PositivesSpezifikation von Sollverhalten und Testauswertung ist aufwändig
Folie 88se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zusammenfassung SystemtestTest des Gesamtsystems gegen die Systemanforderungen
VorteileBedeutsamste TeststufeTest aller Systemkomponenten
NachteilAufwändige FehlersucheTest erst spät im Entwicklungsprozess möglichEntwurfsänderungen sind nur schwer umsetzbar
45
Folie 89se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TeststufenKomponententestIntegrationstestSystemtest
Weitere TeststufenUser Acceptance Test (UAT)Beta-TestAbnahmetestDeployment-Test
Test gegen nichtfunktionale Anforderungen
Folie 90se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Weitere Teststufen – 1User Acceptance Test (UAT)
Meinungen bzw. Bewertungen der Benutzer einholenResultate sind in der Regel nicht reproduzierbar
Beta-TestErprobung durch ausgewählte Benutzer
46
Folie 91se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
AbnahmetestDer Abnahmetest ist ein spezieller Systemtest
Test auf vertragliche Konformität (juristische Relevanz)In der Regel durch den Kunden/Auftraggeber
Mögliche ResultateAbnahmebescheinigungNachbesserungs-forderungenRückgabe bzw. Minderung
Folie 92se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Weitere Teststufen – 2Deployment-Test (Test auf Installierbarkeit)
Test der InstallierbarkeitDie für die Installation zugesicherten Installationsumgebungen werden getestetVirtuelle Umgebungen können den Aufwand zur Bereitstellung der nötigen Testumgebung deutlich reduzieren
Update-TestÄhnlich dem Deployment-TestMögliche Ausgangsversion sind zu berücksichtigen
Test auf Deinstallierbarkeit
47
Folie 93se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlerentdeckung über die Teststufen
Hitachi Software Engineering, 12 Monate, 10 Entwickler, 1990100 kLOC C-Code10.000 Testfälle“ …We do not use sophisticated tools or state-of-the-art methodology—we simply test programs and fix the bugs detected. …”
Tsuneo Yamaura, Hitachi Software Engineering: "How To Design Practical Test Case", IEEE Software November/ December 1998
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 3Testfallentwurfsverfahren
Spezifikationsbasierter TestGlassbox-Test Erfahrungsbasierte Verfahren
48
Folie 95se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Spezifikationsbasierter Test - ÜbersichtDas SUT wird von außen, an den System-schnittstellen, betrachtet ( Blackbox-Test)Grundlage zur Herleitung der Testfälle bildet die SpezifikationMethoden zur Herleitung der Testfälle :
Anforderungsbasiertes TestenÄquivalenzklassen-MethodeGrenzwertanalyseKlassifikationsbaummethodeEntscheidungstabellentestZustandsbasierter TestAnwendungsfallbasierter TestZufallstestModellbasierter Test
Folie 96se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TestfallentwurfsverfahrenEin Testfall ist gut, wenn er mit hoher Wahrscheinlichkeit einen noch nicht entdeckten Fehler aufzeigtEin idealer Testfall ist
Repräsentativ: Er steht stellvertretend für viele andere TestfälleFehlersensitiv: Er hat nach der Fehlertheorie eine hohe Wahrscheinlichkeit, einen Fehler aufzuzeigenRedundanzarm: Er prüft nicht, was auch andere Testfälle schon prüfen
49
Folie 97se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Anforderungsbasiertes TestenDie Grundlage bildet die AnforderungsspezifikationFür jede einzelne Anforderung werden Testfälle erstellt (Anforderungsüberdeckung)Eine tabellarische Anforderungsspezifikation ist hierfür vorteilhaftRequirement-Management-Werkzeuge unterstützen in der Regel das anforderungsbasierte Testen
Vorteil: Wenn systematisch Testfälle zu den Anforderungen erfasst werden, findet damit auch eine Qualitätssicherung der Anforderungen statt
Folie 98se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ÄquivalenzklassenmethodeDie Äquivalenzklassenbildung hat zum Ziel mit möglichst wenig Testfällen möglichst wirkungsvoll zu testen.Die Spezifikation wird nach Eingabegrößen und deren Gültigkeitsbereichen durchsucht
Je Gültigkeitsbereich wird eine Äquivalenzklasse definiertTipp: Wann immer man vermutet, dass Eingabe-werte innerhalb einer Äquivalenzklasse nicht gleichartig behandelt werden, sollte entsprechend in mehrere Äquivalenzklassen aufgeteilt werden. Je „Mitte“ einer Äquivalenzklasse wird ein beliebiges Element - ein Repräsentant - als Testfall ausgewählt.
Vollständigkeit: Alle Repräsentanten sind getestet (Äquivalenzklassenüberdeckung )
50
Folie 99se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel zu ÄquivalenzklassenEin Sensor meldet an ein Programm die Motor-öltemperatur. Ist die Öltemperatur (T) unter 50°C soll eine blaue Kontrolllampe leuchten, bei T über 150 °C soll eine rote Kontrolllampe leuchten. Sonst soll keine der Lampen leuchten.
rote Lampe leuchtet
keine Lampe leuchtet
blaue Lampe leuchtet
Soll-Resultat
17°CT < 50°C1
159°CT > 150°C3
97°C50 ‰ T ‰ 150°C2
RepräsentantÄquivalenzklasse
Wenn ein „Verdacht“ besteht, dass z. B. ab Frost mit einem speziellen Verhalten des Sensors oder des Programms zu rechnen ist, so wird die Äquivalenzklasse 1 entsprechend in weitere Äquivalenzklassen aufgeteilt.
Folie 100se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Äquivalenzklassenbildung in der Schlangenschule
Quelle: Holger Schlingloff
51
Folie 101se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
GrenzwertanalyseAufdeckung von Fehlern im Zusammenhang mit der Behandlung der Grenzen von WertebereichenIm Unterschied zur Äquivalenzklassenbildung wird kein beliebiger Repräsentant der Klasse als Testfall ausgewählt, sondern Repräsentanten an den „Rändern“ der KlassenDie Methode ist dann anwendbar, wenn die Menge der Elemente, die in eine Äquivalenzklasse fallen, auf natürliche Weise geordnet werden kannHintergrund der Grenzwertanalyse: In Verzweigungen und Schleifen gibt es oft Grenzwerte, für welche die Bedingung gerade noch zutrifft (oder gerade nicht mehr). Diese Grenzwerte sollen getestet werden.
Folie 102se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Grenzwertanalyse: TestfälleBereiche
Werte auf den GrenzenWerte „rechts“ bzw. „links neben“ den Grenzen (ungültige Werte, kleiner bzw. größer als Grenze)
Mengen (z.B. bei Eingabedaten, Datenstrukturen, Beziehungen)
Kleinste und größte gültige AnzahlZweitkleinste und zweitgrößte gültige AnzahlKleinste und größte ungültige Anzahl (oft: leere Menge)
Bei strukturierten Daten kartesisches Produkt der Grenzwerte
Achtung, kombinatorische Explosion!
52
Folie 103se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel zur GrenzwertanalyseWie im Beispiel zu den Äquivalenzklassen: Ein Sensor meldet an ein Programm die Motor-öltemperatur. Ist die Öltemperatur (T) unter 50°C soll eine blaue Kontrolllampe leuchten, bei T über 150 °C soll eine rote Kontrolllampe leuchten. Sonst soll keine der Lampen leuchten.
keine Lampe leuchtetT = 150°CTestfall 5
keine Lampe leuchtetT =50°CTestfall 2
blaue Lampe leuchtetT =49°CTestfall 1
rote Lampe leuchtet
keine Lampe leuchtet
keine Lampe leuchtet
Soll-Resultat
T =51°CTestfall 3
T = 151°CTestfall 6
T = 149°CTestfall 4
Grenzwerte
Folie 104se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Grenzwertanalyse Vor- und NachteileVorteile
An den Grenzen von Äquivalenzklassen sind häufiger Fehler zu finden als innerhalb dieser Klassen"Die Grenzwertanalyse ist bei richtiger Anwendung eine der nützlichsten Methoden für den Testfallentwurf“ (Myers)Effiziente Kombination mit anderen Verfahren, die Freiheitsgrade in der Wahl der Testdaten lassen
NachteileRezepte für die Auswahl von Testdaten schwierig anzugebenBestimmung aller relevanten Grenzwerte schwierigKreativität zur Findung erfolgreicher Testdaten gefordertOft nicht effizient genug angewendet, da sie zu einfach erscheint
53
Folie 105se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
KlassifikationsbaummethodeBehandelt das Problem der kombinatorischen Vielfalt
Aus: Pitschinetz, R.; Grochtmann, M.; Wegener, J.: Test eingebetteter Systemehttp://www.systematic-testing.com/
Folie 106se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Klassifikationsbaum ÜbersichtEinfache grafische Methode zur Unterstützung der Testfall-ErzeugungWerkzeugunterstützung: Classification Tree Editor (eXtended Logics)Begriffe
Klassifikation: Variable oder Eingabeparameter, erwartetes ErgebnisKlasse: Wertebereich einer Klassifikation. Der Wertebereich kann z.B. eine Äquivalenzklasse seinDie Klassen müssen disjunkt sein und den Wertebereich der Klassifikation vollständig wiedergeben
54
Folie 107se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Klassifikationsbaum Methode1. Klassifikationen wählen
Der gesamten Eingabe- oder Ausgabedatenraum des Prüflings wird in testrelevante Gesichtspunkte untergliedert Klassifikationen
2. Klassen wählenJede Klassifikation wird in Wertebereiche unterteilt. Wertebereiche können z.B. Äquivalenzklassen sein. Die Wertebereiche (Klassen) sind disjunkt.
3. Testfälle wählenTestfälle entstehen durch die Kombination von Klassen unterschiedlicher Klassifikationen
Folie 108se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Klassifikationsbaum – ein Beispiel
55
Folie 109se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Klassifikationsbaum: Testfälle erzeugen3 Klassifikationen (A, B, C) mit folgenden Klassen:
Um jede Klasse mindestens einmal in einem Testfall zu berücksichtigen sind 5 Testfälle erforderlichVollständige Kombination aller Klassen ergibt 5 x 3 x 3 Testfälle
Folie 110se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Manuel Testfälle erzeugenEs wird ein Testfall neu angelegt und je Klassifikation eine Klasse selektiert
56
Folie 111se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testfälle generieren: Vollständig
Folie 112se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testfälle generieren: Einfach markierenJede Klasse wird einmal markiert. Die Auswahl geschieht zufällig.
57
Folie 113se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testfälle generieren: TwowiseKombiniert jeweils zwei der angegebenen Klassifikation vollständig miteinander.
Folie 114se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ursache-Wirkungs-Graph -1Grafische Darstellung von Wirkungen zwischen Eingabedaten und Ausgabedaten bzw. Aktionen
1: Parken im Parkverbot2: Polizist kommt vorbei
10: Strafzettel erhalten
1
2
10v
3: Rückwärtsgang eingelegt4: Langsam vorwärts fahren
20: Abstandswarner aktivieren
3
4
20vE
58
Folie 115se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ursache-Wirkungs-Graph - 2 Logische Symbole
Folie 116se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ursache-Wirkungs-Graph - 3Einschränkungen
59
Folie 117se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ursache-Wirkungs-Graph - 4Übertragung in eine Entscheidungstabelle
Folie 118se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Entscheidungstabellentest – 1
FFT-Bedingung 2
Regeln
Aktionen
Regel k…Regel 3Regel 2Regel 1Bedingungen
xAktion j
xxAktion 2
xxxAktion 1
---FBedingung i
FTFTBedingung 1Don‘t care
IF (Bedingung 1) AND (Not Bedingung i)Aktion 2Aktion j
END-IF
Laurence I. Press, „Conversation of Decision Tables to Computer programs", Comm. ACM 8, No. 6, 385-390 (Juni 1965)
Beding-ungen ver-wenden Eingabe-daten
Aktionen erzeugen Ausgabe-daten
60
Folie 119se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Entscheidungstabellentest – 2Entscheidungstabellen beschreiben sehr anschaulich (Geschäfts-) Regeln der Art „wenn ... dann ... sonst“.Typische Anwendungssituation: Abhängig von mehreren logischen Eingangswerten sollen verschiedene Aktionen ausgeführt werdenEntscheidungstabellen unterstützen durch ihren Aufbau die Vollständigkeit des TestsJeder Tabellenspalte (Regel) entspricht ein TestfallRegelüberdeckung: Je Regel wird mindestens ein Testfall gewählt.Das Soll-Resultat ergibt sich durch die entsprechend ausgeführten Aktionen
Folie 120se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Kaffeeautomat
xxxWasser erhitzen
xxBetrag einziehen
--TeeCappu-ccino
KaffeeAusgewähltes Getränk
x
Nein
Nein -JaJaJaBezahlung ist erfolgt
Regeln
Aktionen
Regel 5Bestellung
abgebrochen
Regel 4 Zutatenfehlen
Regel 3Tee
bestellen
Regel 2Cappu-ccino
bestellen
Regel 1Kaffee
bestellen
Bedingungen
xVorgang abbrechen
XxKaffee aufbrühen
xMilch aufschäumen
JaNeinNeinNeinBestellung ist abgebrochen
-NeinJaJaJaZutaten und Becher vorhanden
61
Folie 121se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Kaffeeautomat Testfälle
xxVorgang abbrechen
xKaffee aufbrühen
xxxWasser erhitzen
xxMilch aufschäumen
JaNeinNeinNeinNeinBestellung ist abgebrochen
Aktionen / Soll-Resultate
--TeeCappu-ccino
KaffeeAusgewähltes Getränk
Nein -JaJaJaBezahlung ist erfolgt
Testfall 5Bestellung
abgebrochen
Testfall 4 Zutatenfehlen
Testfall 3Tee
bestellen
Testfall 2Cappu-ccino
bestellen
Testfall 1Kaffee
bestellen
Bedingungen
xxBetrag einziehen
-NeinJaJaJaZutaten und Becher vorhanden
Folie 122se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zustandsbezogener TestAusgangsbasis bildet die Spezifikation des Programms als Zustandsgraph (Endl. Automat, state chart)Zustände und Zustandsübergänge sind so beschriebenBeispiel:
A B C
D
a b1
b2
cd b3 b4
Ein Testfall wird ausdem Ausgangszustand, dem Ereignis ( Ein-gabedaten) und demSoll-Folge-Zustand ( Soll-Resultat)
gebildet
Testumfang für einen betrachteten Zustand
Alle Ereignisse, die zu einem Zustandswechsel führen Alle Ereignisse, die auftreten können, aber ignoriert werdenAlle Ereignisse, die auftreten können und eine Fehlerbehandlung erfordern
62
Folie 123se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zustands-überdeckung
Zustandspaar-überdeckung
Transitions-überdeckung
Jeder Zustand muss mindestens einmal erreicht werden
Von jedem Zustand muss in jeden möglichen Folgezustand gewechselt werden
Alle Zustandsübergänge müssen mindestens einmal wirksam werden
A B C
D
a b1
b2
cd b3 b4
A B C
D
a b1
b2
cd b3 b4
A B C
D
a b1
b2
cd b3 b4
A B C
D
a b1
b2
cd b3 b4
Testfälle:Aa
Bb1
Cc
Testfälle:Aa
Bb1
Bb4
Cc
Dd
Testfälle:Aa
Bb1
Bb2
Bb3
Bb4
Cc
Dd
Folie 124se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Roundtrip-Folgen
Roundtrip-FolgenBeginnend im StartzustandEndend in einem Endezustand oder in einem Zustand, der bereits in dieser oder einer anderen Roundtrip-Folge enthalten warZustandsübergangsbaum
A B C
D
a b1
b2
cd b3 b4
A B
Cc db1
Cb2
D A
D
b3
D
b4
a
Testfälle:Aa Bb1 Cc Dd
Aa Bb2
Aa Bb3
Aa Bb4
63
Folie 125se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel - Zustandsautomat
Folie 126se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Zustandsübergangsbaum
64
Folie 127se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Anwendungsfallbasierter Test
Folie 128se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Anwendungsfallbasierter Test – 2Vorteil
Gutes StrukturierungsinstrumentAnwendungsfälle beschreiben Vor- und Nachbedingungen sowie die Benutzeraktionen.Sonderfälle werden behandelt.
NachteilDie Anwendungsfälle enthalten wenig Details und sind oft unvollständig.
65
Folie 129se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Test auf Basis des AktivitätendiagrammsAktivitäten- und Kanten-überdeckung als Vollständigkeits-kriterium
Folie 130se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ZufallstestsAus dem Wertebereich der Eingabedaten werden zufällig Testfälle erzeugtVoraussetzungen
Datentypen und Datenstrukturen der Eingabedaten sowie die Wertebereiche müssen bekannt seinSollresultate für die (zufällig gewählten) Eingabedaten müssen automatisch berechnet werden können (Testorakel)
AblaufTestfälle mit Sollresultaten werden vorab generiert, und zu einem späteren Zeitpunkt ausgeführtEingabedaten werden während der Testausführung zufällig generiert und das Sollresultat wird „on-the-fly“ermittelt
66
Folie 131se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testfallentwurf: Methodik
Funktionen gem. Spez.„Missuse“Schrittweise Verfeinerung
Testfälle
Missuse Funktionen
Prüfa
spekte
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testfall Nr.:
Requirement Nr., Anforderung aus der Spezifikation:
Ausgangszustand (Testdaten-Stand, vorhergehende Abläufe):
Ist-Resultate:
Soll-Resultate:
Testablauf (Bedienung, Ausführung, exakte Beschreibung der Eingabedaen):
Abweichungen:
Ist-Resultate entsprechen den Soll-Resultaten, Datum, Zeichen:
Pro
gra
mm
-Aus
füh
run
g
Sim
ulie
rte
-Aus
führ
ung
Testfall-Formular
67
Folie 133se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Darstellung von Testfällen - TextText- bzw. tabellenbasierend
Testfälle werden in Testsequenzen gruppiertDie Abfolge der Testfälle ergibt die ReihenfolgeVorteile: Einfach, „Excel“als Werkzeug möglichNachteil: wenig anschaulich, Prüfung auf Vollständigkeit ist schwierig
Folie 134se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Darstellung von Testfällen – GrafischEin Knoten beschreibt einen TestfallKanten können mit Bedingungen (ähnl. Zustandsdiagramm) versehen werdenKanten beschreiben die Abfolge der TestfälleWerkzeug – oft mit eigenen Anpassungen – erforderlichAlternative Ausführungspfade bei Varianten sind darstellbar
Testfall 1
Sollresultat 1
Testfall 2b
Sollresultat 2b
Testfall 2a
Sollresultat 2a
Version == A1 Sonst
…
68
Folie 135se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Modellbasierter Test – MBTDie (verbale) Spezifikation wird in ein Modell (z. B. Zustandsautomaten) übertragen.Aus den Modellen werden Testfälle generiert.Die Testfälle werden (automatisiert) ausgeführt.
Vorteile des MBTQualitätssicherung der Spezifikation durch die Modellierung; Aufdecken von SpezifikationsmängelnAnschauliche Modelle statt (sehr) vieler TestfälleAutomatische Generierung der Testfälle aus den Modellen
Nachteile des MBTDie Modelle sind oft nicht mächtig genug; nur ein Teil der Anforderungen lassen sich im MBT behandeln.Die Modelle der modell-basierten Entwicklung können nicht verwendet werden.
Folie 136se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Test-Orakel
Test-Report
Ist-Tesultat
Testfall1
Soll-Resultat
Datenfluss beim modellbasierten Testen
Test-ausführung
SUT
Spe
zifikatio
nd
es SU
T
Test Reporting
Soll-Resultat
Testsuite
VergleichModell
Zustands-automatUML (Klassen-, Aktivitäten-Diagramm)…
Modell-Erstellung
Testfall-Generierung
Testfälle werdenaus dem Modellgeneriert
69
Folie 137se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Leirios
Quelle: www.smartesting.com
Folie 138se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zusammenfassung MBTDer MBT bildet einen interessanten Ansatz: Modelle sind in vielen Fällen anschaulicher d. h. lesbarer/prüfbarer als Text oder Code.Aus den Modellen werden (viele) Testfälle generiert; eine automatische Ausführung ist erforderlich.Die Modelle sind – zumindest in den Werkzeugen am Markt – in der Regel aus der UML (Klassendiagramm, Zustandsdiagramm, Interaktionsdiagramm, …)
Zur weiteren Spezifizierung wird oft noch die OCL (ObjectConstraint Language) hinzugenommenUML deckt vieles, aber eben nicht alle Testanforderungen ab: Nicht alle Systemmerkmale können mit dem UML-MBT getestet werden
Interessante Ansätze zeigen domänenspezifische Modelle; oft werden Werkzeuge dazu selbst entwickelt oder stark adaptiert.Vorsicht beim Einsatz der Modelle der modellbasierten Entwicklung!
70
Folie 139se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Weitere TestverfahrenSmoke-Test
„Vorabtest“, der prüft, ob der Prüfling betriebs-und testbereit ist
SyntaxtestBei Vorliegen einer formal definierten Interaktionssprache
Folie 140se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
RegressionstestTest auf (unbeabsichtigte Neben-) Effekte bei Korrektur, Anpassung oder Erweiterung.„Verhält sich das Programm noch so, wie es sich vor der Modifikation verhalten hatte?“Verwendung in der Regel in der WartungEingabedaten können aus den Betriebsdaten gewonnen werden, Sollresultate werden aus der Version vor der Änderung gewonnen.
regression testing: Selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specifiedrequirements [IEEE Std 610.12 (1990)]
71
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 3Testfallentwurfsverfahren
Spezifikationsbasierter TestGlassbox-Test Erfahrungsbasierte Verfahren
Folie 142se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Glassbox-TestAlternative Bezeichnungen: Coverage-Test, Whitebox-Test, Strukturtest.Der Glassbox-Test (GBT) beurteilt die Vollständigkeit eines Tests anhand der vollständigen Ausführung einzelner „Bausteine“ des Programms Glassbox-Test-Entität (GBT-Entität)GBT-Entitäten repräsentieren ein „Stück“ Programmcode wie beispielsweise Anweisungen, Verzweigungen, Schleifen oder Bedingungsterme. Als Resultat des Glassbox-Tests entsteht das Glassbox-Test-Protokoll. Daraus kann u. a. der Anteil der im Programm ausgeführten GBT-Entitäten angeben werden Überdeckung, Coverage.Eine Übersicht zu GBT-Werkzeugen steht unter
www.iste.uni-stuttgart.de/se/people/Schmidberger/Glassboxtools.html
72
Folie 143se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Structural testing. Testing that takes into account the internal mechanism of a system or component. Types include branch testing, path testing, statement testing. Synonym: glassbox testing; white-box testing.Contrast with: functional testing (1).
lEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
Folie 144se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Glassbox-Test ÜbersichtIn der Praxis wird der Glassbox-Test in der Regel in drei Gruppen aufgeteilt:
Glassbox-Test(Strukturorientierter Test, Whitebox-Test)
Strukturtest (Kontrollflussorientierter
Test)Datenflussorientierter Test Bedingungsterm-
orientierter Test
73
Folie 145se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Teilschritte beim Glassbox-TestBeim Glassbox-Test wird das Programm speziell „präpariert“ um die Ausführung protokollieren zu können ( instrumentieren). Hierzu sind Werkzeuge erforderlich.Die Ausführung erfolgt genau gleich wie beim Blackbox-TestDas Resultat des Glassbox-Tests ist die Information welcher Programmcode ausgeführt wurde und welcher nicht
Programm instrumentieren
Programm ausführen
Resultate analysieren
Folie 146se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Strukturtest (1)Anweisungsüberdeckung
Anteil der ausgeführten Anweisungen (StatementsStatement coverageAuch als c0-Test bezeichnet
ZweigüberdeckungAnteil der ausgeführten ProgrammzweigeBranch coverageGrundlage bildet in der Regel der Kontrollflussgraph (Kantenüberdeckung)Auch als c1-Test bezeichnet
74
Folie 147se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Strukturtest (2)Pfadüberdeckung
Anteil der ausgeführten Programmpfade (Achtung: die Gesamtmenge der Pfade ist in der Regel unendlich groß!)Auch als c2a-Test bezeichnet
SchleifenüberdeckungAnteil der Schleifen, die nicht, einmal oder mehrfach durchlaufen werdenAuch als Boundery-Interiour-Test oder als c2b-Test bezeichnet
FunktionsüberdeckungAnteil der ausgeführten Funktionen
Folie 148se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel Strukturtest
bool istEinSchaltjahr(int jahr){// Defaultannahme: kein Schaltjahrbool istSchaltjahr = false;
if ((jahr % 400) == 0) {istSchaltjahr = true; // s1
} else {if((jahr % 100) == 0) {istSchaltjahr = false; // s2
} else {if((jahr % 4) == 0) {istSchaltjahr = true; // s3
}}
}return istSchaltjahr;
}
if(jahr % 400)
else
Exit
Entry
then
Wie viele Testfälle sind erforderlich?
if(jahr % 100)
else then
else
then
if(jahr % 4)
Zur Anweisungsüberdeckung: 3 Testfälle, z.B. 2000, 1990, 2008Zur Zweigüberdeckung: 4 Testfälle, z.B. 2000, 1990, 2008, 2005
s1
s2
s3
75
Folie 149se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Werkzeug Tessy (1)Test mit den Eingabedaten:
Nicht ausgeführter Zweig
Folie 150se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Werkzeug Tessy (2)Beispiel Tessy: Ausführungen werden je selektiertem Testfall angezeigt
Selektierter Testfall
76
Folie 151se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Tessy „c1-Report“**************************************************************************** MODULE Quadrat* TESTOBJECT istEinSchaltjahr* DATE OF INSTRUMENTATION 08.10.2008 08:49:33**************************************************************************** C1-COVERAGE 83.33 %**************************************************************************** BRANCHES 6* REACHED BRANCHES 5* UNREACHED BRANCHES 1***************************************************************************
Function: istEinSchaltjahr File: C:\dummy\TessyBsp\beispiel.cLine: 6 Coverage: 83.33 %Branches: 6 Reached: 5Unreached: 1
---------+-----------------------------------------------------------------| bool istEinSchaltjahr(int jahr)| {| // Defaultannahme: kein Schaltjahr| bool istSchaltjahr = false; | if ((jahr % 400) == 0) {
****** 0 || istSchaltjahr = true; // s1| } else {| if((jahr % 100) == 0) {| istSchaltjahr = false; // s2
3 || } else {| if((jahr % 4) == 0) {
1 || istSchaltjahr = true; // s3| }| }| }
2 || return istSchaltjahr;| }
1 |
Test mit den Eingabedaten:
Folie 152se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: CodeCoverwww.codecover.org
77
Folie 153se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
DatenflusstestGrundidee: Es wird der Datenfluss im Programm betrachtet, um Testziele zu definierenVariablenzugriffe werden in Klassen eingeteilt
Variablenzuweisung (def)Verwendung in Berechnung (c-use)Verwendung als Bedingungsprädikat (p-use)
Für jede Variable muss ein Programmpfad durchlaufen werden, für den bestimmte Zugriffskriterien zutreffen (def/use-Kriterien)
all defs: Für jede Definition ( all defs) einer Variablen wird eine Berechnung oder Bedingung getestetall p-uses: Jede Kombination aus Definition und prädikativer Benutzung wird getestetall c-uses: Jede Kombination aus Definition und berechnender Benutzung wird getestet
Der Datenflusstest hat kaum praktische Bedeutung
Folie 154se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
BedingungstestTesten zusammengesetzter Bedingungsausdrücke, z. B.
Verbreitete MetrikenEinfache Bedingungsüberdeckung (simple condition coverage)Bedingungs-/Entscheidungsüberdeckung (condition/decision coverage)Mehrfach-Bedingungsüberdeckung (multiple conditon coverage )Modifizierte Bedingungs-/Entscheidungsüberdeckung (modifiedcondition/decision coverage, MC/DC)
if( (A and B) OR (C AND D) )
78
Folie 155se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Bedingungstest – 1
(A and B) OR (C AND D)
wahrwahrwahrfalschfalsch2
wahrfalschfalschwahrwahr1
ResultatDCBATestfall
Einfache Bedingungsüberdeckung (simple condition coverage)
Je Einzelterm wird der Test auf wahr und falsch gefordertZwei Testfälle genügenAchtung: Die einfache Bedingungsüberdeckung subsumiert die Zweigüberdeckung nicht!
Folie 156se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Bedingungstest – 2
(A AND B) OR (C AND D)
falschwahrfalschfalschfalsch2
wahrfalschwahrwahrwahr1
ResultatDCBATestfall
Bedingungs-/Entscheidungsüberdeckung (condition/decision coverage)
Wie Einfache Bedingungsüberdeckung, aber der Gesamtausdruck muss je einmal wahr und einmal falsch ergebenAnzahl Testfälle: 2Subsumiert die Zweigüberdeckung
79
Folie 157se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Bedingungstest – 3
(A and B) OR (C AND D)
wahrfalschfalschwahrwahr3
falschfalschfalschfalschwahr2
…
wahrwahrwahrwahrwahr16
falschfalschfalschfalschfalsch1
ResultatDCBATestfall
Mehrfach-Bedingungsüberdeckung (multiple conditoncoverage )
Test aller Wahrheitswertekombinationen der EinzeltermeAnzahl Testfälle: 2n, d.h. in der Regel nicht praktisch anwendbar
Folie 158se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Bedingungstest: MC/DC – 1Modifizierte Bedingungs-/Entscheidungsüberdeckung (modifiedcondition/decision coverage, MC/DC)Stammt aus dem Standard der Luftfahrtindustrie DO-178B „Software Considerations in Airborne Systems and Equipment Certification“ der RTCA und wird für sicherheitskritische Software (Level A) gefordert.Definition nach RTCA, DO-178B: Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to affect that decisionoutcome independently. A condition is shown to affect a decision's outcome independentlyby varying just that decision while holding fixed all other possibleconditions.
Quelle: Software Considerations In Airborne Systems and Equipment Certification, DO-178B. RTCA, 1992
80
Folie 159se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Bedingungstest: MC/DC – 2
(A and B) OR (C AND D)
falschwahrfalschfalschwahr3
falschwahrfalschwahrfalsch2
wahrwahrwahrfalschwahr4
falschfalschwahrfalschwahr5
wahrwahrfalschwahrwahr1
ResultatDCBATestfall
Anzahl Testfälle: n + 1, bei n Teiltermen
Folie 160se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Glassbox-Test - Übersicht
Pfadüberdeckungstest
Boundary interior-Pfadtest
Zweigüberdeckungstest
Anweisungs-Überdeckungstest
Mehrfacher Bedingungs-überdeckungstest
minimal mehrfacher Bedingungs-
überdeckungstest
Einfacher Bedingungs-überdeckungstest
B = A subsummiert BA
Methoden- und Klassen-Überdeckungstest
81
Folie 161se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Nutzen des Glassbox-Tests1. Codeüberdeckungsmaße als Metrik zur Testgüte
Objektives Vollständigkeitskriterium, das beispielsweise als Test-endekriterium verwendet werden kann
2. Testsuite-ErweiterungDer Glassbox-Test zeigt Programmcode, der für eine Testsuite nicht ausgeführt wird und damit ungetestet bleibt.
3. Grundlage für selektiven Regressionstest Anstelle der „rerun-all“-Strategie sollen nur einzelne, ausgewählte Testfälle ausgeführt werden.
4. Testsuite-ReduktionFür den Regressionstest soll die Testsuite verkleinert werden, ohne dabei aber (wesentlich) an Testgüte einzubüßen
5. Unterstützung beim ProgrammcodeverständnisDer Glassbox-Test zeigt, welcher Programmcode von welchem Testfall ausgeführt wird.
Folie 162se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Glassbox-Test-Tool
Datenfluss beim Glassbox-Test
SUT
Analyse
Überdeckung
Programmcode-Repository
Ausführungs-recording
Testsuite-Optimierung
Test-Orakel
Test-ReportIst-
Resultat
Testfall 1
Soll-Resultat
Testfall-herleitung
Test Ausführung
Spe
zifikatio
nd
es SU
T
Test Reporting
Soll-Resultat
Testsuite
Vergleich
82
Folie 163se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
xxC/C++, Java, Adawww.soft.com/Products/index.htmlTCAT
xxC, C++, Java, Adawww-306.ibm.com/software/awdtools/test/realtimeRational Test Realtime
xxCwww.razorcat.comTessy
CPLxJavacoverlipse.sourceforge.netcoverlipse
xxC/C++, Java, Adawww.telelogic.com/products/logiscopeTelelogic Logiscope
xxC/C++www.verifysoft.comTestwell CTC++
xxC/C++, Ada, COBOLwww.ldra.co.uk/softwaretesting.aspLDRA Testbed
xC/C++, COBOL, Java, PL/1www.caseconsult.deCC Analyser
GPL xxJavacobertura.sourceforge.netCobertura
LicenceBCSCLanguageVendorProduct
EPLxxJava, COBOLwww.codecover.orgCodeCover
xxC/C++, C#, PHP, COBOL, www.semdesigns.comSemantic Designs
xxC/C++, Java, , .netwww-306.ibm.com/software/awdtools/purifyplusRational PurifyPlus
xJavawww.koalog.com/php/kover.phpKoalog
xxJavawww.mmsindia.com/JCover.htmlJCover
xxJava , .netwww.parasoft.comJTest
xxC/C++www.parasoft.comInsure++
GPLxC/C++gcc.gnu.org/onlinedocs/gcc-3.0/gcc_8.htmlgcov
CPLxJavaemma.sourceforge.netEMMA
xxC/C++www.dynamic-memory.comDynamic
xxJava, .netwww.cenqua.com/cloverClover
xxC/C++www.bullseye.comBullseye
xxJavawww.agitar.comAgitar
Glassbox-Test Werkzeuge
SC = Statement coverage BC = Branch coverage
Folie 164se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
InstrumentierungQuelltextinstrumentierungIm Quelltext werden vor der Kompilierung Anweisungen ergänzt (eingewoben), die die Protokollierung der Laufzeitinformation durchführen. Nachteil dieser Instrumentierung ist der aufwändigere Build-Vorgang.Bytecode-InstrumentierungDer bereits kompilierte Programmcode wird instrumentiert.„On-the-fly“-InstrumentierungDie Laufzeitumgebung wird so modifiziert, dass die gewünschten Informationen erhoben und ausgegeben werden. Nur bei Programmiersprachen mit ausgeprägter Laufzeitumgebung (i. d. R. Interpreter) möglich.
Generelle Probleme sind das „Application blow up“ und das „Execution slow down“
83
Folie 165se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
[...]
When test coverage had not previously been measured, testerstended to overestimate coverage of their test cases. The first time testers measured coverage during function test, they found thatthe coverage was in the range of 50% to 60%. The testers weresurprised at the low percentage of coverage they were getting. They expected a much higher percentage of code coverage. Sometesters estimated that their coverage was 90% or higher.
[...]
Piwowarski, P., Ohba, M., and Caruso, J. „Coveragemeasurement experience during function test“, Proceedings of the IEEE 15th international Conferenceon Software Engineering, 1993
Folie 166se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Glassbox-Test-ProzessVorrangig wird der spezifikationsbasierte Test (Blackbox-Test) durchgeführt.Sind alle Möglichkeiten des spezifikationsbasierten Tests angewendet, d. h. es können keine weiteren Testfälle über die spezifikationsbasierten Methoden gefunden werden, kommt der Glassbox-Test zum Einsatz.Die Testfälle werden nun mit „eingeschaltetem“ Glassbox-Test-Werkzeug erneut ausgeführt1. Aus den Resultaten des Glassbox-Tests werden weitere Testfälle ermittelt. Die Soll-Resultate werden aus der Spezifikation entnommen.Diese weiteren Testfälle werden ausgeführt, das Ist-Resultat mit dem Soll-Resultat verglichen.
1Wenn davon ausgegangen werden kann, dass der Glassbox-Test die Funktion des Systems nicht verändert, kann bereits der spezifikationsbasierte Test mit aktiviertem Glassbox-Test-Werkzeug durchgeführt werden.
84
Folie 167se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Zusammenfassung Glassbox-TestDer Glassbox-Test zeigt ausgeführten sowie nicht ausgeführten Programmcode an.Der Glassbox-Test
dient der Testsuite-Optimierung: Z.B. können aus dem nicht ausgeführten Programmcode neue, fehlende Testfälle abgeleitet werden.liefert eine objektive Testgütemetrik
Ein Glassbox-Test-Werkzeug ist erforderlich.Der Glassbox-Test bildet keine Alternative sondern eine Ergänzung zum Blackbox-Test.
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 3Testfallentwurfsverfahren
Spezifikationsbasierter TestGlassbox-Test Erfahrungsbasierte Verfahren
85
Folie 169se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Erfahrungsbasierte Verfahren„Error guessing“
Einsatz in höheren Testebenen, um systematische Tests zu ergänzen.Kann von systematisch erstellten Testfällen „inspiriert“ werden.Error Guessing kann äußerst unterschiedliche Grade von Effizienz erreichen, abhängig von der Erfahrung des Testers.
Exploratives Testen„Ad-hoc“-Testfallentwurf, Testdurchführung, TestprotokollierungDie Testgüte hängt in hohem Maße von der Kompetenz der Tester abDer Ansatz, erscheint dann als sinnvoll, wenn es nur wenig oder ungeeignete Spezifikationen gibt
Test-Ideen (RUP)Grundlage bildet ein „Brainstorming-Prozess“Test Ideen werden in einer Liste gesammelt und sukzessive verfeinert.
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 4Testmanagement
TestorganisationTestrollenFehlermanagementTestmetrikenTeststrategie
86
Folie 171se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TestorganisationTyp1: Testen liegt ausschließlich in der Verantwortung des
einzelnen Entwicklers. Jeder Entwickler testet seine eigenen Programme.
Typ2: Testen liegt in der Verantwortung des Entwicklungsteams. Die Entwickler testen ihre Programme gegenseitig.
Typ3: Mindestens ein Mitglied des Entwicklerteams ist für Testarbeiten abgestellt. Es erledigt alle Testarbeiten des Teams.
Typ4: Es gibt ein oder mehrere dedizierte Testteams innerhalb des Projekts (die nicht an der Entwicklung beteiligt sind).
Typ5: Eine separate Organisation (Testabteilung, externer Testdienstleister, Testlabor) übernimmt das Testen.
Folie 172se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Test-RollenTestmanagerTestplanung und Teststeuerung (Kompetenz: Qualitäts-management, Projektmanagement, Personalführung)TestdesignerErstellung der Testfälle und der Testspezifikation, Priorisierung(Domänenwissen, Anwenden der Testmethoden zur Herleitung der Testfälle, Dokumentation)TestautomatisiererTestautomatisierung (Testgrundlagenwissen, Programmiererfahrung und sehr gute Kenntnisse der eingesetzten Testwerkzeuge).TestadministratorInstallation und Betrieb der Testumgebung (Systemadministration).TesterTestdurchführung und Erstellung der Fehlerberichte (IT-Grundlagen, Testgrundlagenwissen, Bedienung der eingesetzten Testwerkzeuge, Verständnis des Testobjekts)
87
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 4Testmanagement
TestorganisationTestrollenFehlermanagementTestmetrikenTeststrategie
Folie 174se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ablauf einer FehlermeldungNeu
OffenBeobachtung Abgewiesen
Analyse
Korrektur
Test ErledigtFlop
Neu: Ein neu gefundener Fehler wird erfasst
Offen: Bearbeitung durch den Testmanager Beobachtung: Z. B. Problem mit der
Nachvollziehbarkeit
Abgewiesen: Kein Defekt im Testobjekt
Analyse: Die Untersuchung zur Fehlerursache läuft
Durchführung der Korrektur durch den zuständigen Entwickler
FehlernachtestFehlernachtest zeigt kein Fehlverhalten
Flop: Fehlernachtest zeigt erneut das
Fehlverhalten
Nach Linz, T, Spillner, A.: Basiswissen Softwaretest, dpunkt Verlag
88
Folie 175se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlermeldung – 1Nummer: laufende, eindeutige Meldungsnummer (oft auch als „Ticket“ bezeichnet)Testobjekt: Bezeichnung des Testobjekts, in welchem System bzw. Subsystem trat der Fehler aufVersion: Identifikation der genauen Version des TestobjektsTestfall: Beschreibung des Testfalls (Name, Nummer) bzw. der Schritte, die zur Reproduktion der Fehlerwirkung führenPlattform: Identifikation der HW-/SW-Plattform bzw. der TestumgebungEntdecker: Identifikation des Testers (ggf. mit Teststufe)Entwickler: Name des für das Testobjekt verantwortlichen Entwicklers oder TeamsErfassung: Datum, ggf. Uhrzeit, an dem das Problem beobachtet wurdeTeststufe: Komponenten-, Intergations-, System-, Beta- … -Test
Folie 176se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlermeldung – 2Problem: Beschreibung der Fehlerwirkung; erwartete vs. tatsächliche Ergebnisse bzw. VerhaltenKommentar: Stellungnahmen der Betroffenen zum MeldungsinhaltStatus: Bearbeitungsfortschritt der Meldung; möglichst mit Kommentar und Datum des EintragsKlasse: Klassifizierung der Schwere des ProblemsPriorität: Klassifizierung der Dringlichkeit einer Korrektur (Auftrittswahrscheinlichkeit und Schadensmaß)Anforderung: Verweis auf die (Kunden-)Anforderung, die wegen der Fehlerwirkung nicht erfüllt oder verletzt istFehlerquelle: Soweit feststellbar, die Projektphase, in der die Fehlhandlung begangen wurde (Analyse, Design, Programmierung); nützlich zur Planung prozessverbessernder MaßnahmenVerweis: Querverweise auf andere zugehörige MeldungenKorrektur: Korrekturmaßnahmen des zuständigen Entwicklers mit Angabe des fehlerhaften Artefakts („injected in/by“)
89
Folie 177se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ein Beispiel-Fehler im System „ecadia“
...double dTmp = fromDateEntry.getTime().getTime() - fromDate.getTime().getTime();double dTmpInDays = dTmp / 1000 / 60 / 60 / 24;long offset = (long)dTmpInDays;dTmp = toDateEntry.getTime().getTime() - fromDateEntry.getTime().getTime();dTmpInDays = dTmp / 1000 / 60 / 60 / 24;long duration = (long)dTmpInDays + 1; ...
Z.B.: Start der Belegungen am Sonntag und nicht am Montag
Fehlerwirkung: Im Kalender werden Belegungen falsch eingetragen
fromDateEntryfromDate
Folie 178se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlerkorrektur:Die Verschiebung beim Wechsel Winterzeit/Sommerzeit muss berücksichtigt werden!
...double dTmp = fromDateEntry.getTime().getTime() +
fromDateEntry.get(Calendar.DST_OFFSET) –fromDate.getTime().getTime() –fromDate.get(Calendar.DST_OFFSET);
double dTmpInDays = dTmp / 1000 / 60 / 60 / 24;long offset = (long)dTmpInDays;
...
90
Folie 179se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlerdatenblatt
LeichtReproduzierbarkeit
HochPriorität zur Fehlerbehebung
Sehr lästig, verschobene Kalenderanzeige, Kalender damit praktisch nutzlosSchadenswirkung, Risiko
2 Stunden Sachbearbeiter und HelpdeskAufwand zur Fehlererhebung
Betrieb, BenutzerGefunden durch
4 StundenFehler beheben
Codierfehler, Berechnungsfehler, Fehler im Ausdruck, API-FehlbenutzungFehlertyp
CodeFehlerstelle
Größerer Umbau des Kalenders im Sommer 2008Zeitpunkt oder Phase der Fehlereinfügung
Fehlerursache, Verursacher
2 StundenAufwand zur Neurelease-Erstellung
1 StundeAufwand zur Fehlerlokalisierung
1. Fehler finden und dokumentieren
2. Fehler beheben und neues Release ausliefern
Programmcode wird nach ähnlichen Programmstellen durchsucht, Kommunikation der Fehlerursache an die anderen Entwickler
Prozess
Neue Testfälle zu Test des Kalenders für Winter-/Sommerzeitwechsel werden ergänzt
Testsuite
3. Schlussfolgerungen zur Prozessverbesserung
Folie 180se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlerklassifikationen„Anleitung“ zur FehlerabstraktionBestehen in der Regel aus mehreren Kategorien mit je mehreren KlassifikationenEin Fehler soll nachvollziehbar und reproduzierbar einer Klassifikation zugeordnet werden könnenVerwendungszweck
„In-Process“ Feedback, Prozessverbesserung, aus (häufiger wiederkehrenden) Fehlern lernenEntscheidungsgrundlage zur Fehlerbehebung: „major/minor“Behandlung von Gewährleistungsansprüchen, Service-Levels, Abnahmebehinderung
91
Folie 181se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Fehlerklassifikationen in der LiteraturODC (Orthogonal Defect Classification)
Chillarege et al., „Orthogonal defect classification-a concept for in-process measurements“, TSE 1992
IEEE Std 1044-1993, IEEE Standard Classification for Software Anomalies„HP approach“
Robert Grady 1992: “Practical software metrics for project management and process improvement”, Englewood Cliffs, NJ: Prentice Hall
Fehler-Taxonomie von BeizerBoris Beizer, „Software Testing Techniques“, van NostrandReinhold, 2. Auflage1990
BITKOM Leitfaden Fehlerklassifikation für Softwarehttp://www.bitkom.org/de/publikationen/38337_50074.aspx
Folie 182se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ODC - Orthogonal Defect Classification
Schadensauswirkung für den BenutzerImpact
Fehlerentdeckungstechnik, eine Untergliederung von Aktivität
Defect trigger
Aktivität zur Fehlerentdeckung: Code/Design Test Unit-, Function-, System (wobei mit System hier die spezielle Betriebsumgebung gemeint ist)
Activity
Art der Dokumentänderung (missing, incorrect, irrelevant, obscure)
Defect qualifier
Art des Fehlers (assignment, checking, algorithm, timing/serialization, interface, function, build/package/merge, documentation)
Defect type
Zeitpunkt der Fehlereinfügung (base, new, rewritten, refix)Age
Das betroffene Dokument (Entwurf, Code, …)Target
Fehler finden und dokumentieren
Fehler beheben
92
Folie 183se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ODC Beispiel: Auswertung nach „Trigger“Ram Chillarege, Kothanda Ram Prasad: “Test and Development Process Retrospective – a Case Study using ODC Triggers”, IEEE DSN 2002
DESIGN CONFORMANCE: A review trigger where the implemented design is compared against a reference - either design document, pattern, or guideline.LOGIC/FLOW: Checking for correctness or flaws using knowledge of the practice.BACKWARD COMPATIBILITY: Examining compatibility with prior version of the product.LATERAL COMPATIBILITY: Examining for compatibility with other products and platforms that need to work with this release.CONCURRENCY: Serialization, shared resources, multithreaded tasks, timing, etc.INTERNAL DOCUMENT: Inconsistencies in prologs, and sections in the same work product. LANGUAGE DEPENDENCY: Programming standards, specific implementation considerations, environment restrictions, execution modes, etc.SIDE EFFECTS: Usage behavior beyond design, but relevant in context. Do A; B happens.RARE SITUATION: Unusual issues related to idiosyncrasy of environment, hardware, or software.
SIMPLE PATH: White box -Straightforward usage of code path and branches.COMPLEX PATH: White box - Exercising conditionals, and circuitous coverage.COVERAGE: Black box -Straightforward usage of function or single parametrized execution.VARIATION: Black box - straightforward like coverage, but with a variety of parameters.SEQUENCING: Black box - multiple functions, with a specific sequence.INTERACTION: Black box - when two or more bodies of code are involved.WORKLOAD STRESS: Pushing the limits of performance, resources, users, queues, traffic, etc. Recovery: Invoke exception handling, recovery, termination, error percolation, etc.STARTUP/RESTART: Major events of turning on, off or changing the degree of service availability.HARDWARE CONFIGURATION: Issues surfaced as a consequence of changes in hardware setup.SOFTWARE CONFIGURATION: Issues surfaced as a consequence of changes to software setup.BLOCKED TEST/NORMAL MODE: Test could not run during system test. Normal Mode - archaic: customer found nonspecific trigger.
Folie 184se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Werkzeuge für das Bug-TrackingÜbliche Funktionen
Fehler- und ÄnderungsmanagementNative und Web-Client VersionenKonfigurierbare Oberfläche und DatenfelderKonfigurierbarer WorkflowReporting- und Statistik-FunktionenEinsatzmöglichkeit verschiedener Datenbanksysteme
Verbreitete WerkzeugeRational ClearQuestHP Quality Center (vormals Mercury)Und viele weitere (http://www.testingfaqs.org/t-track.html)
93
Folie 185se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel Bug-Tracking: Bugzilla – 1
Folie 186se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel Bug-Tracking: Bugzilla – 2
94
Folie 187se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel Bug-Tracking: Bugzilla – 3
Folie 188se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Estimating software quality„If the test cases are properly developed, you can easily estimate the quality of the target software in the midst of debugging by applying the fish-in-the-pond analogy: If you detect four bugs after executing 100 test cases out of 1000, common sense says the software will carry about 40 bugs altogether. State-of-the-art software reliability theory is not that simple, but this quick and easy estimation gives you a rough idea of the software’s quality.”
Tsuneo Yamaura, Hitachi Software Engineering: "How To Design Practical Test Case", IEEE Software November/ December 1998
95
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 4Testmanagement
TestorganisationTestrollenFehlermanagementTestmetrikenTeststrategie
Folie 190se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testmetriken – 1
ZeiterfassungAufwand zur Qualitätssicherung der Testware (Testsuite, Testsystem, Testdaten, Testskripte, ...)
#8
Log-FileTestdurchlaufzeiten#6
ZeiterfassungEinarbeitungsaufwand#7
FehlerdatenbankAnzahl der False-Positives#9
Qualität der Testware bewerten
ZeiterfassungTestskript-Wartungsaufwand (z. B. Aufwand je veränderter Seite oder Seitenabfolge)
#5
Transparenz der Automatisierung:Aufwände,Wirtschaftlichkeits-rechnung
ZeiterfassungTestskript-Erstellungsaufwand#4
ZeiterfassungAufwand zur Erstellung eines Testfalls
#1
ZeiterfassungAufwand zur Testdurchführung je Testfall und für die gesamte Testsuite
#2
ZeiterfassungSetup der Testumgebung#3
Aufwands-transparenz, Nachweis von Effekten einer Prozess-verbesserung
ErhebungMetrikenZiel
96
Folie 191se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testmetriken – 2
FehlerdatenbankAnzahl gefundener Restfehler(Delivered defects)
#14
FehlerdatenbankMean time to failure#15
FehlerdatenbankMean time between failures#1´6
FehlerdatenbankGefundene Fehler: Fehler-auswertung und Fehler-klassifizierung (gruppiert nach Teststufe, Subsystem, Ursache, ...)
#10
#14a
#13
#12
#11
FehlerdatenbankFehlerfindungsrate bei „Error seeding“
Nachweis und Verbesserung der Wirksamkeit (Effektivität)Objektive Testgüteangabe
Coverage-Werkzeug
Requirements-management, Traceability
Erhebung
Fehlerentdeckungsrate#10 / (#10 + #14)
Codeüberdeckung
Anforderungsüberdeckung
MetrikenZiel
Folie 192se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testmetriken – 3
Statische AnalyseProgrammcode Basismetriken: LOC, Prozeduren, Schnittstellen, ggf. Function Points
#20
FehlernachtestBad-fix Injections #18
Testeffizienz: Die Effizienz ist eine abgeleitete Metrik aus der Anzahl an gefundenen Fehlern und dem hierfür erforderlichen Testaufwand.
#17Bewertung der Testeffizienz
Fehlerdatenbank Defect-removal efficiency#19
Bewertung des Fehlerbehebungsprozesses
Testsuite Kenngrößen der Testsuite: Anzahl Testfälle
#21
Vergleichbarkeit, Normierung
Fehlerdichte#22Qualitäts-bewertung des PrüflingsFehlermetriken
Expertenschätzung, Erfahrungswerte
Defektpotential#23
ErhebungMetrikenZiel
97
Folie 193se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testmetriken – 4
Log-FilesAuslastung und Verfügbarkeit#24Transparenz der Ressourcen/ Testware-Auslastung
Personal-entwicklung
Anteil der speziell für Testaufgaben qualifizierten Mitarbeiter im Projektteam (z. B. „Certified Tester“o. ä.)
#25Personal
TestprotokollAnzahl durchgeführter Testfälle (mit/ohne gefundenem Fehler), Anzahl blockierter Tests (z. B. wegen nicht beseitigter Fehler)
#26Testfortschritts-messung
ErhebungMetrikenZiel
Folie 194se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testmetriken – Beispiel 1
Nach F. Fraikin,E.-H. Riedemann, A. Spillner, M. Winter
98
Folie 195se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testmetriken - Beispiel 3
Nach F. Fraikin,E.-H. Riedemann, A. Spillner, M. Winter
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 4Testmanagement
TestorganisationTestrollenFehlermanagementTestmetrikenTeststrategie
99
Folie 197se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TeststrategieTestziel festlegen: Orientierung an Abnahmekriterien, Risiken und FolgekostenFestlegung von Überdeckungskriterien je TeilsystemPriorisierung einzelner Teilsysteme oder Anwendungsfunktionen Risikobasiertes TestenFestlegung der Aufwandsverteilung zwischen den TeststufenWerkzeugeinsatz festlegenFestlegung des Automatisierungsgrads: Orientierung an der Wiederholrate der einzelnen Testausführungen
Folie 198se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Risikobasiertes TestenDas risikobasierte Testen hat zum Ziel, die Fehler im Programm zu finden, von denen eine hohes Risiko auf den Projekterfolg ausgehtAls Risikoindikator wird in der Regel das Produkt von Fehlerauftrittswahrscheinlichkeit und erwartetem Schaden angenommenDie Testfälle werden priorisiertJe nach verfügbarem Testaufwand werden die höher priorisierten Testfälle ausgeführt
100
Folie 199se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Priorisierung der Testfälle – 1Eintrittswahrscheinlichkeit der Fehlerwirkung im normalen Betrieb
Funktionen, die viel genutzt werden, sollten intensiver getestet werden
FehlerschwereIntensiver Test auf Fehler, die hohen Schaden anrichten
(Subjektive) WahrnehmungIntensiver Test auf Fehler, die einem Benutzer besonders auffallen und „stören“
Priorität der AnforderungTestfälle zu wichtigen Anforderungen werden bevorzugt getestetZentrale und architekturbeeinflussende Anforderungen werden bevorzugt getestet
Folie 200se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Priorisierung der Testfälle – 2Komplexität der einzelnen Komponenten
Intensiver Test komplexer (im Sinne von schwer verständlicher, komplizierter) Komponenten
TestaufwandTestfälle mit geringem Aufwand werden bevorzugt (z. B. Bevorzugung automatisierter Testfälle)
FehlerprognoseTestfälle, die aus der „Erfahrung“ oft Fehler aufdeckenNeue Funktionen, geänderte Funktionen
TestabdeckungTestfälle mit hoher Abdeckung werden bevorzugt
101
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 5Testdokumentation
Testplan: IEEE 829TestberichtTestsuite / Testfälle
Folie 202se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testplan-Inhaltsverzeichnis IEEE 829 1. Testplanbezeichnung2. Zusammenfassung des Testziels, der Testobjekte und der zu
testenden Eigenschaften3. Testobjekte (genaue Beschreibung, Spezifikation und Version)4. Zu testende Leistungsmerkmale5. Leistungsmerkmale, die nicht getestet werden6. Teststrategie, Lösungskonzept, Vollständigkeitskriterien7. Abnahmekriterien, Soll-Resultate je Testobjekt beschreiben8. Kriterien für den Testabbruch und Testfortsetzung9. Beschreibung der zu erstellenden Testdokumentation (Testplan,
Testaufbau, Testfälle, Log-Dateien, Bericht)10. Testtätigkeiten11. Testinfrastruktur, Testumgebung12. Verantwortlichkeit und Zuständigkeit13. Personal und Training14. Zeitplan15. Risiken16. Genehmigung/Freigabe
Was
Wie
WerWann
102
Folie 203se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TestspezifikationEindeutige Kennung der Testfallspezifikation.Testgegenstände: Liste der Testgegenstände und Funktionen bzw. Eigenschaften, die von diesem Testfall überprüft werden. Referenzen auf die Dokumentationen der Testgegenstände sind anzugeben.Spezifikation der Eingaben: Detaillierte Angabe aller Eingaben und deren Beziehungen (zum Beispiel Abfolge).Spezifikation der Ausgaben: Auflistung aller Ausgaben und Eigenschaften (wie z.B. Antwortzeiten), die zu erfassen sind undderen Werte bzw. Wertebereiche (Toleranzen)Umgebungsanforderungen: Detaillierte Beschreibung der Hardware und Softwareanforderungen und anderer Anforderungen. Definition aller speziellen Beschränkungen oder EigenheitenWechselbeziehungen zu anderen Testfällen: Auflistung aller Testfälle, die vor diesem Testfall auszuführen sind und Angabe der Art der Wechselbeziehungen
Folie 204se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Teststatusbericht (Zwischenbericht) Ein Teststatusbericht sollte folgende Informationen enthalten:
Testobjekt(e)TeststufeTestzyklus-Datum von ... bisTestfortschritt (geplante/gelaufene/blockierte Tests)Fehlerstatus (neue/offene/korrigierte Fehler)Risiken (neue/veränderte/bekannte Risiken)Ausblick (Planung des nächsten Testzyklus)Gesamtbewertung (Beurteilung der Freigabereife des Testobjekts)
103
Folie 205se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TestabschlußberichtPrüfling, genaue VersionTester, Ort, Umfeld, ZeitrahmenAusgeführte Testfälle
Angabe der Testfall-KennungenAufwändeRessourcenverbrauchVerwendetes Testgeschirr
Glassbox-BerichtResultate
Gefundene FehlerAuffälligkeiten
Ggf. VerbesserungsvorschlägeErgänzungen
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 6Testwerkzeuge
TypenNutzen und RisikenEinführungsstrategien
104
Folie 207se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testwerkzeuge TypenübersichtUnit-Test-Werkzeuge (siehe Kapitel Komponententest)Glassbox-Test-Werkzeuge (siehe Kapitel Glassbox-Test)
GUI-Test-WerkzeugeManual-Test-Werkzeuge
Verwaltung der Testfälle, die manuell ausgeführt werdenUnterstützung bei der Testdurchführung und Berichtserstellung
Bug-Tracking-Werkzeuge (siehe Kapitel Fehlermanagement)
Viele kleine „Helferlein“Testdaten-GenerierungWerkzeug zum Vergleich zweier Text-DokumenteAutomatisches Einspielen von Testdatenbanken mit z. B. Anonymisierung
Folie 208se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
GUI-TestwerkzeugeCapture Replay:
Eine einmal aufgezeichnete (oder programmierte) Eingabefolge kann wiederholt ausgeführt werden
Positiv:Viele Werkzeuge sind am Markt verfügbarSinnvoller Einsatz z. B. bei Belastungstests oder Stresstests
Negativ:Abhängigkeit von der Technologie der GUIProblematisch bei Änderungen der GUI; hoher Aufwand für Pflege und Wartung der Skripte
105
Folie 209se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
GUI-Test, Beispiel „Quicktest“
Folie 210se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
„Manual Tests“TestfallbeschreibungenUnterstützung bei der TestdurchführungBerichtserstellung
106
Folie 211se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Doors (Telelogic)
Quelle: http://www.telelogic.com
Folie 212se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Justus: Testfälle erfassenhttp://justus.tigris.org/
107
Folie 213se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Justus: Test durchführen
Folie 214se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Justus: Testbericht
108
Folie 215se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Justus: Testbericht
Folie 216se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
LaufzeitanalyseSpeicherbedarf (Memory Profile)Glassbox-Test-Resultate (z. B. Anweisungsüberdeckung, Zweigüberdeckung, …)Visualisierung von BotschaftsflüssenLaufzeiten (Performance Profile)
109
Folie 217se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Rational Realtime – 1
Folie 218se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Rational Realtime – 2
110
Folie 219se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Werkzeugauswahl und -einführung1. Kriterien für Werkzeugeinsatz festlegen, Commitment
des Managements2. Marktstudie3. Bewertung vornehmen (anhand Werkzeugdemo,
Probeeinsatz, Produktinformationen, ...)4. Werkzeugfestlegung und Beschaffung
5. Pilotprojekt6. Erfahrungen des Pilotprojekts zusammenfassen und
Benutzungsunterlagen erstellen7. Anwenderschulung8. Breiteneinführung9. Begleitendes Coaching
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Kapitel 7Test-Standards
BS 7925-2, Software TestingIEEE 829ISTQBTestprozess-ReifegradmodelleRUP
111
Folie 221se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
BS 7925-2, Software testing
Ziel, Strategie, Zeitplan, Personal, RessourcenPlanung
Spezifikation
Durchführung
Protokollierung
Auswertung
Ende
parametrisierte (=logische) Testfälle, konkrete Testfälle(definierte Eingabedaten)
Ausführung der Testfälle
Präzise und detaillierte Protokollierung der Testdurchführung
Bewertung der Zielerreichung, Aufwandsbewertung, Fehlermanagement
Beginn
Quelle: British Standard 7925-2, Software testing, Part 2; Software component, 1998
Folie 222se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testprozess nach IEEE 829
Testplan
Testdesign-Spec. Testdesign-Spec.Testdesign-Spec.
Testcase-Spec.
Testproc.-Spec.
Testexecution
Testlog Testincident-Report
Testsummary-Report
Testitem-TransMittal
-Report
Projectdoc. Itemdoc. Testitem
Document specifiedby this Standard
Document not specifiedby this standard
Testitem (not specifiedby this standard)
Process not specifiedby this standard
Quelle: IEEE Std 829-1998
112
Folie 223se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
IEEE 1008-1987 Standard for Software Unit TestingThe unit testing process is composed of three phases that are partitioned into a total of eight basic activities as follows:1. Perform the test planning
a) Plan the general approach, resources, and scheduleb) Determine features to be testedc) Refine the general plan
2) Acquire the test seta) Design the set of testsb) Implement the refined plan and design
3) Measure the test unita) Execute the test proceduresb) Check for terminationc) Evaluate the test effort and unit
Quelle: Standard for Software Unit Testing. ANSI/IEEE Std 1008-1987. IEEE
Computer Society Press.
Folie 224se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
IEEE 1008-1987
Quelle: Standard for Software Unit Testing. ANSI/IEEE Std 1008-1987. IEEE
Computer Society Press.
113
Folie 225se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
IEEE 1008-1987: Unit Test ActivitiesPlan the General Approach, Resources, and ScheduleDetermine Features To Be TestedRefine the General PlanDesign the Set of TestsImplement the Refined Plan and DesignExecute the Test ProceduresCheck for TerminationEvaluate the Test Effort and Unit
Folie 226se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Plan the General Approach, Resources, and Schedule
Specify a General Approach to Unit TestingAdressierte Risiken, Funktionen, die getestet werden müssen
Specify Completeness RequirementsÜberdeckungsvorgaben
Specify Termination RequirementsKriterien für den regulären und den außer-gewöhnlichen Abbruch
Determine Resource RequirementsAufwandsschätzung für Testaufbau, Durchführung, ggf. Wiederholung, Dokumentation
Specify a General Schedule
114
Folie 227se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Determine Features To Be TestedStudy the Functional Requirements
Eindeutige Kennzeichnung sicherstellenIdentify Additional Requirements and AssociatedProcedures
Nicht-Funktionale Anforderungen, wie z.B. Performanz oder Robustheit
Identify States of the UnitZustände und Transitionen zusammenstellen
Identify Input and Output Data CharacteristicsEin- und Ausgabedaten: Formate, Werte, Wertebereiche
Select Elements to be Included in the Testing
Folie 228se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Refine the General PlanRefine the ApproachSpecify Special Resource RequirementsSpecify a Detailed Schedule
115
Folie 229se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Design the Set of TestsDesign the Architecture of the Test Set
Hierarchische Strukturierung: … design a hierarchically decomposed set of test objectives so that each lowest-level objective can be directly tested by a few test cases
Obtain Explicit Test Procedures as RequiredTestmethoden (gemeint sind die „Verfahrensweisen“)
Obtain the Test Case SpecificationsAugment, as Required, the Set of Test-CaseSpecifications Based on Design InformationComplete the Test Design Specification
Folie 230se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Implement the Refined Plan and DesignObtain and Verify Test Data
BestandsdatenObtain Special ResourcesObtain Test Items
Prüfgegenstände
116
Folie 231se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Execute the Test ProceduresRun TestsDetermine Results
For each failure, have the failure analyzed and record the fault information in the Summary of Results section of the test summary report.
Case 1: A Fault in a Test Specification or Test Data. Case 2: A Fault in Test Procedure Execution.Case 3: A Fault in the Test Environment (for example, system
software). Case 4: A Fault in the Unit Implementation. Case 5: A Fault in the Unit Design.
Folie 232se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Check for TerminationCheck for Normal Termination of the Testing ProcessCheck for Abnormal Termination of the TestingProcessSupplement the Test Set
117
Folie 233se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Evaluate the Test Effort and UnitDescribe Testing Status
Z. B. Abweichungen gegenüber dem PlanDescribe Unit’s StatusComplete the Test Summary ReportEnsure Preservation of Testing Products
Folie 234se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ISTQBInternational Software Testing Qualifications BoardStandard Glossary of Terms„Certified Tester“ AusbildungsprogrammSiehe www.istqb.org und www.german-testing-board.de
118
Folie 235se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Qualitätsmerkmale ISO 9126 Funktionalität: Inwieweit besitzt die Software die geforderten Funktionen?Zuverlässigkeit: Kann die Software ein bestimmtes Leistungsniveau unter bestimmten Bedingungen über einen bestimmten Zeitraum aufrechterhalten? Benutzbarkeit: Welchen Aufwand fordert der Einsatz der Software von den Benutzern und wie wird er von diesen beurteilt? Effizienz: Wie ist das Verhältnis zwischen Leistungs-niveau der Software und eingesetzten Betriebsmitteln? Änderbarkeit: Welchen Aufwand erfordert die Durch-führung vorgegebener Änderungen an der Software? Übertragbarkeit: Wie leicht lässt sich die Software in eine andere Umgebung übertragen?
Folie 236se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ISO 9126: Funktionalität Vorhandensein von Funktionen mit festgelegten EigenschaftenDiese Funktionen erfüllen die definierten AnforderungenRichtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z.B. die benötigte Genauigkeit von berechneten WertenAngemessenheit: Eignung der Funktionen für spezifizierte Aufgaben, z.B. aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen.Interoperabilität: Fähigkeit, mit vorgegebenen Systemen zusammenzuwirkenOrdnungsmäßigkeit: Erfüllung von anwendungsspezifischenNormen, Vereinbarungen, gesetzlichen Bestimmungen und ähnlichen VorschriftenSicherheit: Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern.
119
Folie 237se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ISO 9126: ZuverlässigkeitReife: Geringe Versagenshäufigkeit durch FehlzuständeFehlertoleranz: Fähigkeit, ein spezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht-Einhaltung ihrer spezifizierten Schnittstelle zu bewahrenWiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen
Folie 238se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testprozess-Reifegradmodelle
An CMM angelehnt mit fünf Stufen sowie fünf SchlüsselbereichenJe Stufe und Schlüsselbereich sind (abstrakt) Aktivitäten beschrieben
Ericson et al., 1997(eine Publikation)
TIMTest ImprovementModel
Beschreibt 20 Schlüsselbereiche (Test Strategie, Werkzeuge, Metriken , ...)Erfüllungsgrad wird durch „Checkpoints“bestimmt
Koomen und Pol, 1999(ein Buch)
TPITest ProcessImprovement
An CMM angelehnt mit fünf Stufen; „Maturity goals“ enthalten die (abstrakten) Ziele je StufeFokus auf Organisationsstrukturen und Managementaktivitäten
Burnstein et al., 1996(einige Publikationen, ein Buch)
TMM(Test MaturityModel)
Test liegt nicht im Fokus (SPICE: einige Testaktivitäten werden bei den Engineering-Disziplinen gefordert)
SEI, 1991ISO, 1998
CMM / CMMI SPICE / ISO 15504
KurzbeschreibungErscheinungsjahr und Urheber
Reifegradmodell
120
Folie 239se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ISO 15504 (SPICE)
Engineering Process Group (ENG)ENG.1 Requirements elicitationENG.2 System requirements analysisENG.3 System architectural designENG.4 Software requirements analysisENG.5 Software designENG.6 Software construction
ENG.7 Software integrationENG.8 Software testingENG.9 System integrationENG.10 System testingENG.11 Software installationENG.12 Software and system maintenance
Spice ist ein Prozessreifegradmodell und prüft Prozesse, definiert aber keine!
Abfolge im „V“
Folie 240se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Spice - Software testing
As a result of successful implementation of this process:1) a strategy is developed to test the integrated software according to the priorities and categorization of the software requirements;2) a test specification for software test of the integrated software is developed that demonstrates compliance to the software requirements;3) the integrated software is verified using the test cases;4) results of software testing are recorded;5) consistency and bilateral traceability are established between software requirements and software test specification including test cases; and6) a regression test strategy is developed and applied for re-testing the integrated software when a change in software items occur.NOTE 1: The test specification for software testing includes the test design specification, test procedure specification and test case specifications.NOTE 2: The verification is performed according to the test casesNOTE 3: The test results for software testing include the test logs, test incident reports and test summary reports.
Process Outcomes
The purpose of the Software testing process is to confirm that theintegrated software meets the defined software requirements.
Process Purpose
Software testingProcess Name
ENG.8Process ID
121
Folie 241se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TMM
Level 1 : Initial
Level 2 : Phase-Definition
Level 3 : Integration
Level 4 : Management and Measurement
Level 5 : Optimization, DefectPrevention and Quality Control
Folie 242se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TMM Level 2 „Phase Definition“Trennung von Test- und „Debugging“-Zielen
Siehe Definition „Test“Testmanagement
Aufwands- und RessourcenplanungZuständigkeiten
Institutionalisierung grundlegender TesttechnikenUnit-, Integrations-, System- und AkzeptanztestsAnforderungs- und Codebasierter Test
Aber: Im Detail sind Rollen, Aktivitäten und Dokumente sowie der Workflow nicht beschrieben.
122
Folie 243se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TPI Automotive Automotive-Variante des „Test ProcessImprovement“ von Sogetti21 Key AreasDie Grundlagen von TPI sind allerdings nicht (z. B. empirisch) belegtDas Modell von TPI „ähnelt“ CMM
Folie 244se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TPI Automotive Key Areas
Beispiel: Checkpoint für die Key Area „Test Stategy“
123
Folie 245se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
TPI Test Maturity Matrix
A, B, C, D stehen für einen „MaturityLevel“Je Key Area sind die Checkpoints für den jeweiligen Level definiertD subsumiert C subsumiert B …
Folie 246se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
RUP: Test-Rollen
Quelle: www.rational.com
124
Folie 247se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Literatur – 1Beizer, B. (1995). Black-Box Testing. New York, etc.: John Wiley & SonsFrühauf, K., J. Ludewig, H. Sandmayr (1991). Software-Prüfung. Eine Fibel. Zürich: vdf und Stuttgart: TeubnerGraham, D. et al. (2007) Foundations of Software Testing, Thomson LearningIEEE (1987). Standard for Software Unit Testing. ANSI/IEEE Std 1008-1987. IEEE Computer Society PressIEEE (1998a). IEEE Standard for Software Test Documentation. ANSI/IEEE Std 829-1998. IEEE Computer Society Press
Folie 248se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Literatur – 2Liggesmeyer, P. (2002). Software-Qualität: Testen, Analysieren und Verifizieren von Software. Berlin: Spektrum Akademischer VerlagMyers, G.J. (1979). The Art of Software Testing. New York, etc.: John Wiley & Sons. [in dt. Übersetzung: Methodisches Testen von Programmen. 4. Auflage. Oldenbourg, München, 1991.]Pol, M., T. Koomen, A. Spillner (2000). Management und Optimierung des Testprozesses. Heidelberg: dpunkt.verlagSpillner, A., T. Linz (2002). Basiswissen Softwaretest. Heidelberg: dpunkt.VerlagZeller, A. (2006). Why Programs Fail: A Guide to Systematic Debugging. San Francisco: Morgan Kaufmann und Heidelberg: dpunkt.verlag
125
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Statische Prüfungen
Statische Prüfungen ohne RechnerRechnergestützte statische Prüfungen
Folie 250se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Statische AnalysenStatische Analyse wird oft als Obergriff für alle Prüfverfahren verwendet, bei denen keine Ausführung des Testobjekts erfolgtAchtung: Viele Defekte werden erst bei der Ausführung erkennbar (dynamischer) Test
Statische Analyse
Prüfung durch Menschen
Prüfung mit Werkzeugen
Aufwändig, teuerStruktur und Semantik kann geprüft werden
Prüfling (Dokument) muss eine formale Struktur habenIn der Regel nur Strukturprüfungen
126
Folie 251se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Strukturierte GruppenprüfungenWalkthrough
Präsentation (oft durch den Autor) mit kritischen Zuhörern, wenig formaler Ablauf
InspektionFormaler Ablauf, Checklisten, Gutachter, Prüfkriterien
Technisches ReviewGeregeltes, dokumentiertes Verfahren zur Bewertung eines DokumentsVorbereitung, Reviewsitzung, NachbereitungRollen: Moderator, Gutachter, Protokollant, Autor
Informelles ReviewAbgeschwächte Form des Reviews (wenig/keine Vorbereitung, Autor übernimmt die Moderatorenrolle)
Folie 252se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Vorteile von ReviewsReviews lassen sich auf alle Dokumente anwenden, wenn sie für die beteiligten Personen lesbar sindMängel können frühzeitig, direkt nach ihrem Entstehen, erkannt und beseitigt werden.Die Prüflinge werden einem größeren Kreis an Personen bekannt
127
Folie 253se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Statische (werkzeugbasierte) AnalysenÜberprüfung, Vermessung und Darstellung eines Dokuments bzw. eines Programms oder einer KomponenteDokumente müssen eine formale Struktur habenTypischerweise wird Quelltext analysiert
Z.B. Prüfung auf „toten“ Code oder KlonePrüfung auf Einhaltung von Konventionen und Standards
Schachtelungstiefe, Kommentierungsgrad, ....Datenflussanalyse
Anomalien z. B. ur-, du-, dd- (u: undefiniert, d: definiert, r: referenziert)
Erhebung von Metriken
Folie 254se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Datenflussanalyse: Anomalien ur-Anomalie: Ein undefinierter Wert (u) einer Variablen wird auf einem Programmpfad gelesen (r).du-Anomalie: Die Variable erhält einen Wert (d), der allerdings ungültig (u) wird, ohne dass er zwischenzeitlich verwendet wurde.dd-Anomalie: Die Variable erhält auf einem Programmpfad ein zweites Mal einen Wert (d), ohne dass der erste Wert (d) verwendet wurde.
128
Folie 255se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel: Axivion Bauhaus Suite
Quelle: www.axivion.com
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ÜbungTessy
ProduktübersichtEinführendes Beispiel „quadrat“Beispiel CoEng: Interface-Analyse, Testfall erstellen, Test ausführen, Testbericht
129
Folie 257se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ÜbersichtTessy ist ein Unit-Test-Werkzeug für in C geschriebene ProgrammeIn Tessy können externe Compiler integriert werden; der gcc wird standardmäßig mitgeliefertFunktionen
Automatische Interface-Analyse von C-FunktionenErfassung und Verwaltung von Testfällen für C-FunktionenAusführung von TestfällenFlexible Berichtserstellung (HTML, Word, …)
Tessy stammt wie der CTE aus der Daimler-Forschungwww.hitex.de
Folie 258se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel „quadrat“ - AnalyseEine einfache Funktion „quadrat“ wird mit Tessy analysiert
int quadrat(int wert){return wert * wert;
}
130
Folie 259se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel „quadrat“ - TestfallEingabewerte werden spezifiziertFür Ausgabewerte wird ein Soll-Resultat spezifiziert
Folie 260se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Beispiel „quadrat“ - ReportserstellungFormate
HTMLWordExcel
InhaltStandardinhalteKonfigurations-möglichkeit über Python Skripte
131
se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ÜbungRational Test RealTime
Produktübersicht, Komponenten-TestKomponenten-Test erstellenSkriptspracheAusgaben
Folie 262se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Component TestingEinzelne C-Funktionen können getestet werdenÜbergabewerte und Rückgabe-werte sowie globale Variablen können gesetzt und evaluiert werden
132
Folie 263se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
ÜbersichtDie Verbindung zu Compiler und Linker wird über sogenannte „Target Deployment Ports“ eingerichtet
Gängige Entwicklungsumgebungen sind bereits vorbereitet (z.B. MS Visual C++)
Für UTE17 gibt es bei DS/ESQ1 bereits viel ErfahrungEine Ausführliche Dokumentation ist hierzu verfügbar; zudem umfangreiche Standardisierungen und Tipps
Komponenten-TestEinfache Skriptsprache zur Erstellung der TestfälleUmfangreiches ReportingGlassbox-Test-Metriken
Folie 264se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Komponenten-Test Assistent zur Generierung eines Testskripts
133
Folie 265se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testskript – StrukturHEADER: Testskriptname und Versionsangabe. Für Dokumentationszwecke, Angaben erscheinen im Testbericht.SERVICE: Enthält die Testfälle, üblicherweise für eine C-FunktionTEST: Beschreibt den Testfall, hat einen eindeutigen BezeichnerFAMILY: Testfall-Typ. Liste kann frei festgelegt werden. Beispiele: nominal, structureELEMENT: Umfasst einen Testfall. Kann durch NEXT_TEST erweitert werden
HEADER Testskript, 28.08.2008, Version 1.0<Variablendeklarationen für das Test Script>BEGIN
SERVICE Testskript<Lokale Variablendeklarationen># variable1, variable2, variable3: integer;
TEST Testfall1FAMILY nominalELEMENT
VAR variable1, INIT=0, EV=0VAR variable2, INIT==, EV=0VAR variable3, INIT=1, EV=INIT#<call to the procedure under test>
END ELEMENTEND TEST
END SERVICE
Beispiel.ptu
Folie 266se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testskript – Funktionsweise
/* extern */ int a;
int testFunktion(int b){/* nur ein Beispiel */if(b == 2) {a = 1;
}return b * b;
}
TEST 1FAMILY nominal
ELEMENTvar a, init = 0 , ev = 1var b, init=2, ev=2var ergebnis, init=0, ev=4
#ergebnis=testFunktion(b);
END ELEMENT
END TEST -- TEST 1
Testskript (.ptu) Testobjekt: C-Funktion
134
Folie 267se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Testskript – Editor
Rechte Maustaste:Kompilieren und Test ausführen
Folie 268se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ausgaben: Runtime Tracing Viewer
135
Folie 269se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ausgaben: Test Report – 1
Folie 270se-rt www.se-rt.de - © 2008-2009 Software-Engineering Rat&Tat - TTI GmbH Version 1.10
Ausgaben: Test Report – 2