Systemen - Teststufen. Teststufen. Teststufen. Komponenten-/Modultest. Teststufen im V-Modell. Komponenten-/Modultest

Transkript

1 2007 Dr. Klaudia Dussa-Zieger Teststufen Teststufen Testen von Software-Systemen Systemen - Teststufen Komponenten-/ Modultest Integration und Testen von Software-Systemen SS 2007 (1) Testen von Software-Systemen SS 2007 (2) Einordnung ins V-Modell Anforderungsdefinition Funktionales Technisches 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (3) Testen von Software-Systemen SS 2007 (4) Teststufen im V-Modell Definition: Komponente/Modul Testaspekte Funktionen der Komponente/des Moduls Komponenten-/Modulstruktur Ausnahmebedingungen Nicht-funktionale (wie z.b. Performanz, Wartbarkeit) Fehlerklassen Fehlende Pfade Falsche Pfade Berechnungsfehler Voraussetzungen Komponenten-/Modulspezifikation liegt vor ggfs. Programmcode liegt vor Softwareeinheit mit wohldefinierter Schnittstelle für bereitgestellte Dienste mit Spezifikation der zur Verfügung gestellten Dienste. Hier sind nur explizite Abhängigkeiten gestattet. i.a. ein interner Zustand (Daten) Funktionalität wird ausschließlich über die definierte Schnittstelle angefordert (Datenkapselung) Mehrere Instanzen sind möglich Der allgemeine Ausdruck Komponente beschreibt u.a. Module (strukturierte Programmierung) Einheiten (z.b. kompilierte Einheiten), oder Klassen (OO-Entwicklung) Testen von Software-Systemen SS 2007 (5) Testen von Software-Systemen SS 2007 (6)

2 Testtreiber, Platzhalter und Testrahmen Testrahmen Testtreiber (Haupttestprogramm) stellt die Umgebung für den Test eines Testobjekts zur Verfügung Platzhalter (Stub, Dummy) simuliert (beim Top-down-Test) die Funktionalität noch nicht implementierter Bausteine main Testobjekt Testtreiber Testobjekt Test output Testrahmen enthält die für den Test benötigten Testtreiber und Platzhalter Funk # 1 Funk #2 Testlobjekt in Zielumgebung Platzhalter Testobjekt in Testumgebung Testen von Software-Systemen SS 2007 (7) Testen von Software-Systemen SS 2007 (8) Testfälle Robustheitstest / Negativtest Quellen zur Testfallfindung Modulspezifikation Erfahrung Grundlegende Verfahren Black-box-, White-box-Tests Techniken, z.b. Äquivalenzklassenanalyse Grenzwertanalyse Erfüllung von Überdeckungskriterien siehe Testfallentwurfsverfahren Beim Robustheitstest wird geprüft, ob das Testobjekt auf fehlerhafte Eingabewerte robust reagiert, d.h. es muss diese Situation ohne Beeinträchtigung des restlichen Systems geordnet behandeln, etwa indem es die unzulässigen Werte erkennt und entweder einen entsprechenden Status zurückmeldet oder eine entsprechende Ausnahmebehandlung durchführt. Ein anderer Name für Robustheitstest ist Negativtest: nämlich ein funktionaler Testfall mit Eingabewerten, die laut Spezifikation des Testobjekts unzulässig (d.h. negativ ) sind. Testen von Software-Systemen SS 2007 (9) Testen von Software-Systemen SS 2007 (10) Wer sollte testen? Wer sollte testen? Der Autor des Codes? kennt kritische Stellen im Code kann einfach Testrahmen realisieren kann Fehler sehr effizient lokalisieren und korrigieren, aber: ist oft betriebsblind (!!) testet häufig unsystematisch, sofern Testfälle nicht vorgegeben Unabhängiges Testen : Darf nicht alleine verantwortlich für den Test sein Ein anderer Entwickler des Teams? kennt typische Fallstricke aber testet oft mit niedriger Priorität Ein Testexperte? plant Teststrategien und Testfälle systematisch (!!) testet systematisch aber: hat ggfs. hohen Aufwand, um sich in das System einzuarbeiten Aber: Kann natürlich auch Entwickler-Know-how besitzen (siehe auch Testmanagement ) Testen von Software-Systemen SS 2007 (11) Testen von Software-Systemen SS 2007 (12)

3 Exkurs: Extreme Programming Exkurs: Extreme Programming Schreibe Testcode, bevor du eine Schnittstellenfunktion implementierst! (Test-First Ansatz) Mache den Testcode öffentlich verfügbar und verwendbar! Führe alle Tests aus, bevor du den Code nach Änderungen eincheckst! Falls Fehler beim Test auftreten: korrigiere fehlerhaften Code sofort bzw. veranlasse, dass die Korrektur sofort ausgeführt wird Ergänze die Tests fortlaufend bei Neuerstellung/Änderung von Schnittstellen falls die bestehenden Tests Fehler durchlassen Pflege die Tests Beachte Mit Test ist hier - Extreme Programming Debugging gemeint, nicht Test! Keine expliziten und keine explizite Testspezifikation D.h. die Qualität der Tests hängt stark vom Verständnis des Entwicklers für sinnvolle und notwendige Tests ab Vorteile Entwickler beachten Testbarkeit bereits beim Entwurf Stabilität von Schnittstellen Testen von Software-Systemen SS 2007 (13) Testen von Software-Systemen SS 2007 (14) an die Entwicklung an die Entwicklung Testbarkeit ist wichtig! Keine Wegwerftests oder 1-Entwickler-Only-Tests akzeptieren! for Testability Akzeptiere angemessenen Overhead an Code und Laufzeit Beispiele für Maßnahmen Echte Komponenten/Module bilden: starke Kohäsion und schwache Komponenten-/Modulkopplung for Testability Schwache Komponenten-/ Modulkopplung Starke Kohäsion Zusatzfunktionalität für Test gut schlecht Stellenwert von Codeteilen für die Verbesserung der Testbarkeit so hoch wie der der eigentlichen Produktsoftware! HW-abhängige Teile kapseln Simulation (von Teilen) der Umgebung für bessere Reproduzierbarkeit in die Entwicklungsrichtlinien übernehmen! Checklisten dazu erstellen! Testen von Software-Systemen SS 2007 (15) Testen von Software-Systemen SS 2007 (16) Ergebnisse Verbesserung des Tests Bewusstmachen der an die Testbarkeit von Systemen Keine Wegwerftests erhöhter Nutzen der stests Verpflichtung für Entwickler und Nutzer Integration und Ein verbessertes Debugging ergänzt den Test sinnvoll aber er ist kein Ersatz dafür! Effizienteres Zusammenspiel zwischen Entwicklung und Test Testen von Software-Systemen SS 2007 (17) 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (18)

4 Integration und Integration und Einordnung ins V-Modell Merkmale des s Funktionales Technisches Anforderungsdefinition Komponenten- Testaspekte Procedure interface (Verwendung richtiger Funktionen) Parameter interface (Korrekte Parameterverwendung) Message passing interface (Nachrichtenreihenfolge) Shared memory interface (Gemeinsamer Datenzugriff) Fehlerklassen Falsche Benutzung einer Schnittstelle Falsches Verständnis einer Schnittstelle Synchronisationsprobleme Voraussetzungen Technisches liegt vor Mindestens 2 Komponenten/Module sind implementiert und bereits komponenten-/modul-getestet und integriert Getestete, korrekt arbeitende, integrierte Komponenten Voraussetzung für! Testen von Software-Systemen SS 2007 (19) Testen von Software-Systemen SS 2007 (20) Integration und Integration und Achtung: Schnittstellen zu externen Systemen Trotz bestandenem höheres Risiko Externe Schnittstelle hat 2 Seiten, nur eine davon ist unter Kontrolle des Entwicklungsteams! Integration Zusammenfügen von Teilen des Systems (Aufgabe von Entwicklern und Systemintegratoren) vs. Test, der sich auf die Überprüfung des Zusammenwirkens von Systemteilen konzentriert (erfolgt nach erfolgreicher Integration) Integrationsstrategie Legt die Reihenfolge der Integrationsund der schritte fest. Testen von Software-Systemen SS 2007 (21) Testen von Software-Systemen SS 2007 (22) Integrationsstufen Integration und Verschiedene Integrationsstufen möglich: Komponentenintegrationstest: prüft das Zusammenspiel von Softwarekomponenten wird nach dem durchgeführt Systemintegrationstest: prüft das Zusammenspiel zwischen verschiedenen (Teil-) Systemen Testtreiber, Platzhalter und Testrahmen Sind beim ebenso nötig wie beim Komponenten- /Modultest, um noch nicht implementierte bzw. noch nicht integrierte Bausteine zu simulieren. Hardware-: prüft das Zusammenspiel von Software und (Elektronik-) Hardwareplattform in der Entwicklung von Embedded Systemen relevant wird in der Praxis kontinuierlich durchgeführt, da Embedded Software oft nur in der Zielhardware lauffähig ist Testen von Software-Systemen SS 2007 (23) Testen von Software-Systemen SS 2007 (24)

5 2007 Dr. Klaudia Dussa-Zieger Reihenfolge der Integrationsschritte Bottom-up... Top-down... Ad-hoc Hardest first... integrieren Funktionsorientiert Transaktionsorientiert Ein früher Prototyp liegt vor je nach Verfügbarkeit Kritische Komponenten/Module zuerst Nichtinkrementell oder Big-bang... Viele (oder gar alle) Komponenten/Module gleichzeitig integrieren Testen von Software-Systemen SS 2007 (25) Testen von Software-Systemen SS 2007 (26) Bottom-up Integration Bewertung der Bottom-up Integration Beginne auf der untersten Ebene der Aufrufhierarchie und arbeite dich nach oben HW-nahe oder Hilfsfunktionen zuerst integrieren Aufrufende Funktionen werden durch Testtreiber simuliert Keine Platzhalter benötigt Im Idealfall sehr effiziente Entwicklung Späte Präsentation Kein Prototyp vorhanden Höhere Komponenten müssen durch Testtreiber simuliert werden Wenn klar, Projektdauer kurz und kein Prototyp benötigt wird Testen von Software-Systemen SS 2007 (27) Testen von Software-Systemen SS 2007 (28) Top-down Integration Bewertung der Top-down Integration Beginne auf der obersten Ebene der Aufrufhierarchie und arbeite dich nach unten Aufrufende Funktionen werden vor den aufgerufenen Funktionen integriert Aufgerufene Funktionen werden simuliert Früher Prototyp Frühe Präsentation des Fortschritts Frühes gemeinsames Verständnis der Hauptfunktionalität Frühe Validierung der Bedienlogik Eventueller Korrekturbedarf wird frühzeitig bemerkt Aufwand für die Erstellung der Platzhalter oder Simulatoren für die aufgerufenen Funktionen Für Evaluierung der Bedienlogik (für Tester, Installateur, Anwender, Wartungsservice) Bei ungeduldigen Auftraggebern Bei mittleren und langen Projektlaufzeiten Testen von Software-Systemen SS 2007 (29) Testen von Software-Systemen SS 2007 (30)

6 Hardest-first Integration Bewertung der Hardest-first Integration Die schwierigste/kritischste Aufgabe zuerst Kritische oder fehleranfällige Komponenten/Module oder für die weitere Integration besonders wichtige Komponenten/Module werden früh integriert Aufrufende Funktion wird durch Testtreiber simuliert Aufgerufene Funktionen werden durch Platzhalter simuliert Kritische Komponenten/Module werden früh geprüft. Falls nötig, können selbst umfangreiche Änderungen noch termingerecht realisiert werden. Machbarkeit wird frühzeitig untersucht. Eventuell schon Nutzen/Einsatz vor Fertigstellung des Gesamtsystems. Kritische Komponenten/Module müssen frühzeitig vorliegen ( Planung). Zusätzlicher Aufwand für die Erstellung von Simulatoren und Treibern. Testen von Software-Systemen SS 2007 (31) Falls es kritische/extrem fehleranfällige Komponenten/Module gibt. Testen von Software-Systemen SS 2007 (32) Integration bei Verfügbarkeit Bewertung der Integration bei Verfügbarkeit Integration beginnt, sobald mindestens zwei Komponenten/Module mit einer gemeinsamen Schnittstelle die s bestanden haben Aufrufende Funktion wird simuliert, falls noch nicht verfügbar Aufgerufene Funktionen werden simuliert, falls noch nicht verfügbar Integration kann so früh wie möglich beginnen Kein Prototyp und daher keine frühe Präsentation Kritische Komponenten/Module werden eventuell sehr spät integriert Aufwand für die Erstellung von Simulatoren und Treibern Falls keine andere Strategie anwendbar Falls man nicht länger auf verspätet fertig gestellte Komponenten/Module warten kann Testen von Software-Systemen SS 2007 (33) Testen von Software-Systemen SS 2007 (34) Big-bang Integration Bewertung der Big-bang Integration Alle auf einmal (oder viele auf einmal ) Alle Komponenten/Module werden in einem Arbeitsschritt integriert nicht-inkrementell Kein Aufwand für die Erstellung der Simulatoren Lokalisierung von Fehlern sehr aufwändig Systematisches Testen aufgrund zu erwartender häufiger Unterbrechungen schwierig bis unmöglich Häufig können Integration und Test erst nach Fehlerkorrektur fortgesetzt werden Falls keine andere Strategie anwendbar (z.b. weil eine Teilintegration aufgrund der Testumgebung nicht realisierbar ist) In späten Phasen der Entwicklung, bei kleineren Fehlerkorrekturen Testen von Software-Systemen SS 2007 (35) Testen von Software-Systemen SS 2007 (36)

7 Funktionsorientierte Integration Bewertung der funktionsorientierten Integration Die Komponenten/Module integrieren, die eine gemeinsame Systemfunktion realisieren. Benutzerorientiertes, zielgerichtetes Vorgehen (oft risikominimierend) Wenig genutzte Funktionen werden selten getestet (Gefahr der Vernachlässigung risikoreicher Funktionen) Lokalisierung von Fehlern sehr aufwändig Unter Umständen sehr später Beginn der Tests In Kombination mit anderen Strategien (z.b. bottom-up) Testen von Software-Systemen SS 2007 (37) Testen von Software-Systemen SS 2007 (38) Transaktionsorientierte Integration Bewertung der transaktionsorientierten Integration Die Komponenten/Module integrieren, die eine gemeinsame Transaktion realisieren Eine Transaktion ist eine atomare Operation, meist im Zusammenhang mit Datenbanksystemen verwendet Datenorientiertes, zielgerichtetes Vorgehen (oft risikominimierend) Selten verwendete Transaktionen werden relativ selten aufgerufen Lokalisierung von Fehlern sehr aufwändig Unter Umständen sehr später Beginn der Tests In Kombination mit anderen Strategien Testen von Software-Systemen SS 2007 (39) Testen von Software-Systemen SS 2007 (40) Zusammenfassung Auswahl der richtigen Kombination von Strategien, zum Beispiel: Hardest-first-Integration für kritische Komponenten/Module Top-down- und funktionsorientierte Integration für GUI Bottom-up- und zum Teil datenorientierte Integration für die übrigen Komponenten/Module Projektplanung an die Reihenfolge der benötigten Komponenten/Module anpassen Frühzeitige Strategieauswahl und -planung zur rechtzeitigen Anpassung des Projektplans Management-Unterstützung einholen Testen von Software-Systemen SS 2007 (41) 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (42)

8 Teststufen im V-Modell Einordnung ins V-Modell Funktionales Technisches Testaspekte Vollständigkeit der funktionalen Eigenschaften Erfüllung der nichtfunktionalen Eigenschaften, z.b. nach ISO : Effizienz, Benutzbarkeit, Zuverlässigkeit, Änderbarkeit, Übertragbarkeit. Fehlerklassen Anforderung nicht erfüllt Anforderung falsch erfüllt Voraussetzungen Pflichtenheft liegt vor ist abgeschlossen Testen von Software-Systemen SS 2007 (43) Testen von Software-Systemen SS 2007 (44) - Testumgebung Ziel des s Verifikation des Systems gegen die Systemanforderungen mit Hilfe funktionaler und nichtfunktionaler Tests Testfallentwurfsverfahren sind hauptsächlich Blackbox-Tests, können aber auch strukturelle Tests sein Prüfung, dass das System bereit ist für die Abnahme Erwartet: Keine schwerwiegenden Fehler im System Möglichst große Fehlerfreiheit im ganzen System Erwartet: Vollständige Erfüllung aller wichtigen Möglichst gute Erfüllung aller Die Testumgebung sollte der späteren Betriebsumgebung so ähnlich wie möglich sein (mit Ausnahme der Testwerkzeuge) Jedoch nicht in der Produktivumgebung des Kunden, da sonst Systemausfälle und Datenverlust drohen. die Tester sonst nur eine geringe Kontrolle über das System haben. Beispiel: Testumgebung für Bankapplikationen Datenbank-basierte Systeme Replikation der Datenbank mit echten Daten Unterstützt durch z.b. VMWARE oder ähnliche Software Erlaubt beliebige Wiederholungen von Tests auf den gleichen Daten Testen von Software-Systemen SS 2007 (45) Testen von Software-Systemen SS 2007 (46) - Testumgebung Beispiel: Testumgebung für technische Systeme System = Steuergerät eines Automobils Die Testumgebung für das zu testende System (Steuergerät) besteht aus einer Simulation der realen Umgebung (Fahrzeug, Umwelteinflüsse) Testrechner Interface ( Sensor, Aktuator) Anforderungsdefinition Fahrzeugmodell Sensor- HW Regler Aktuator- HW Steuergerät Testen von Software-Systemen SS 2007 (47) Zusammenfassung ist der letzte Test vor der Abnahme Letzte Chance für die Qualitätssicherung, Mängel aufzuzeigen Letzte Chance vor der Abnahme, selbst Vertrauen in die SW zu gewinnen Prüfung der geforderten Eigenschaften ursprüngliche inklusive aller später vereinbarten Änderungen Vollständigkeit der funktionalen Eigenschaften Erfüllung der nichtfunktionalen Eigenschaften, z.b. nach ISO : Effizienz, Benutzbarkeit, Zuverlässigkeit, Änderbarkeit, Übertragbarkeit Großes Risiko bei Mängeln im Testprozess Tests risikobasiert planen und durchführen Tests möglichst nahe am späteren Einsatz ausrichten Testen von Software-Systemen SS 2007 (48)

9 2007 Dr. Klaudia Dussa-Zieger Einordnung ins V-Modell Anforderungsdefinition Funktionales Technisches Testen von Software-Systemen SS 2007 (49) Testen von Software-Systemen SS 2007 (50) Teststufen im V-Modell Testaspekte Vertrauensbildende Maßnahme Einsatzfähigkeit/Benutzbarkeit Vollständigkeit Fehlerklassen Anforderung nicht erfüllt Anforderung falsch erfüllt Voraussetzungen Anforderungsdefinition liegt vor ist abgeschlossen Kunde ist am beteiligt bzw. führt den durch Test eines Systems oder einer Software vor der Auslieferung Anwender- Letzte Stufe der Validierung: Kunde prüft Einsatztauglichkeit Prüfung erfolgt in der Einsatzumgebung oder in einer möglichst ähnlichen Modellumgebung Feldtest Prüfung vor der Auslieferung wird von Repräsentanten der Zielgruppe durchgeführt Situation, als ob das Produkt bereits gekauft wäre (Kundenumgebung!) Feedback-Schleife einplanen Alpha- und Beta-Test Alphatests finden beim Hersteller statt Betatests finden beim Kunden statt (auch als Feldtest, s.o.) Testen von Software-Systemen SS 2007 (51) Testen von Software-Systemen SS 2007 (52) Test eines Systems oder einer Software vor der Auslieferung Betrieblicher Stellt die Abnahme des Systems durch den Systemadministrator dar und umfasst z.b.: Test des Erstellens und Wiedereinspielens von Sicherungskopien (Backup/Restore) Wiederherstellbarkeit nach Ausfällen Wartungsaufgaben und periodische Überprüfungen von Sicherheitslücken. Test eines Systems oder einer Software vor der Auslieferung Vertragsabnahmetest Das kundenindividuelle System oder die Software wird explizit gegen die vertraglichen Abnahmekriterien geprüft. Abnahmekriterien sollten definiert werden, wenn der Vertrag abgeschlossen wird. Regulative s Es werden s gegen alle Regularien durchgeführt, denen das System entsprechen muss, z.b. staatliche, gesetzliche oder Sicherheitsbestimmungen. Testen von Software-Systemen SS 2007 (53) Testen von Software-Systemen SS 2007 (54)

10 Produktabnahme Produktabnahme [CTFL-LP05] Voraussetzung Abnahmekriterien sind definiert (bei Projektbeginn!) Abnahmeprotokolle verwenden Teilabnahme Gesamtabnahme Dokumentation Beginn der Gewährleistung Abnahmeprotokoll geht auch an die Buchhaltung Übergaben dokumentieren An wen? Datum? Übergaben in beide Richtungen dokumentieren Abnahmeresultate: Abnahme ohne Mängel bzw. mit unwesentlichen Mängeln ( Billigung des Werks als in der Hauptsache erfüllt ) Abnahme trotz wesentlicher Mängel Abnahme wird wegen wesentlicher Mängel zurückgestellt Abnahme ohne Prüfung Mängelbehebung bis... Testen von Software-Systemen SS 2007 (55) Testen von Software-Systemen SS 2007 (56) Mängelliste Produktabnahme Mängelliste für Projekt: [Projekt Name] Nr. Datum Inhalt Prio. Verantwortlich Bis wann Übliche Szenarien Kunde meldet berechtigterweise einen Fehler Kunde behauptet, es fehle geschuldete Funktionalität Kunde meldet immer wieder schwerwiegende Fehler, um die Abnahme zu verzögern Mängelliste sollte dieselben Attribute enthalten, die auch für die Abweichungsmeldungen definiert sind Keine Leistungen wegen offener Rechnungen verweigern (immer juristischen Rat einholen)! Bei ungerechtfertigter Leistungsverweigerung: Schadensersatzpflicht! Testen von Software-Systemen SS 2007 (57) Testen von Software-Systemen SS 2007 (58) Taktische Bemerkungen Taktische Bemerkungen Abnahmeprozedur sehr früh mit dem Kunden durchsprechen Wo wird abgenommen? Festlegen, ob am Testsystem Produktionssystem Planung Wer nimmt teil? Zeitliche Planung Kriterien müssen klar sein Abnahme ist eine gemeinsame Veranstaltung (Kunde und Lieferant bzw. Hersteller) Übereinkunft sollte schon früher getroffen sein Tipp: durch Stakeholder bereits einige Zeit vor der eigentlichen Abnahme durchführen (inkl. Protokoll und Unterschrift) Sollte nur noch ein formaler Akt sein Zeitliche Festlegung der Abnahme sollte bereits im Vertrag enthalten sein, z.b. das Produkt wird automatisch 30 Tage nach Übergabe abgenommen, das Produkt wird automatisch abgenommen, falls das Produkt bereits wirtschaftlich genutzt wird Testen von Software-Systemen SS 2007 (59) Testen von Software-Systemen SS 2007 (60)

11 2007 Dr. Klaudia Dussa-Zieger Ursprüngliche Version (1.0) a) Gewartete Version (1.1) (z.b. Fehler korrigiert, Update des Betriebssystems, der Datenbank oder der Umgebung, Migration auf neue Plattform) b) Neue Teilfunktionalität in Version (2.0) ( größere Änderung, geplante Erweiterungen) In beiden Fällen: Testen von Software-Systemen SS 2007 (61) Testen von Software-Systemen SS 2007 (62) Ideale Voraussetzungen Aufgabe: Durchführen aller (oder ausgewählter) Regressionstests Entwicklungsdokumente vorhanden Prüfdokumente vorhanden Entwicklungsdokumente vorhanden Prüfdokumente vorhanden Quellcode vorhanden Quellcode vorhanden Testen von Software-Systemen SS 2007 (63) Testen von Software-Systemen SS 2007 (64) Idealfall: nur wenige Änderungen in den Entwicklungsdokumenten Idealfall: Wiederholung weniger Tests Effiziente Anpassung: Was ist zu ändern? Ermittlung durch Impactanalyse: in Spezifikationen betroffenes betroffene Testspezifikationen betroffener Code: nur wenige Komponenten/Module (bei schwacher Kopplung) changed module main Effizienter Was ist zu wiederholen? (konzentriert) (konzentriert) Evtl. Datenmigration und Archivierung testen Testen von Software-Systemen SS 2007 (65) Testen von Software-Systemen SS 2007 (66)

12 Oft die Realität: Entwicklungsdokumente oft nicht oder nur rudimentär vorhanden Prüfdokumente nicht oder nur rudimentär vorhanden Aufgabe 1: Reengineering der Entwicklungsdokumente aus dem Code Aufgabe 2: Erstellen der entsprechenden Testspezifikationen Quellcode vorhanden Quellcode vorhanden Aufgabe 3: Nötige Tests durchführen Testen von Software-Systemen SS 2007 (67) Testen von Software-Systemen SS 2007 (68) Teststufen Zusammenfassung Testen sollte in den folgenden Stufen geschehen, die sich jeweils auf unterschiedliche Aspekte konzentrieren Grundlegende Funktionalität der einzelnen Komponenten bzw. Module Korrekte Zusammenarbeit von Modulen und Subsystemen Vollständigkeit der funktionalen und nichtfunktionalen Vertrauen des Kunden Einsetzbarkeit Zusätzlich gibt es den, der bei bereits abgenommenen Systemen bzw. Software Tests ausgewählter Stufen wiederholt, um sicherzustellen, dass das System auch nach den Änderungen korrekt arbeitet Testen von Software-Systemen SS 2007 (69)