Testen von Software-Systemen. Systemen Testmanagement. Organisation. Organisation. Organisation. Wer testet? Typische Konstellationen:

Transkript

1 P r a k t I s c h e P r a k t I s c h e Testen von Software-Systemen Systemen Testmanagement 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (1) 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (2) Wer testet? Typische Konstellationen: Entwickler sind für den Test ihres eigenen Produktes verantwortlich. Entwickler sind für den Test eines Produktes verantwortlich, das von einem anderen Entwicklerteam entwickelt wurde. Ein Team ist für den Test verantwortlich, ein Tester ist Mitglied dieses Teams. Ein dediziertes Testteam ist für den Test verantwortlich. Entwickler sind für den Test verantwortlich Entwickler sind für den Test ihrer eigenen Ergebnisse verantwortlich Das Prinzip der Unabhängigkeit wird nicht beachtet: Testverantwortlichkeit sollte unabhängig sein von Entwicklungsverantwortlichkeit Fehler, die von den Entwicklern übersehen wurden, werden im Test u. U. nicht gefunden Ein interner Berater unterstützt Projekte im Hinblick auf den Test. Ein externer Berater ist für den Test verantwortlich. Der Test wird ausgegliedert und von einem externen Testdienstleister durchgeführt. Testen von Software-Systemen SS 2007 (3) Testen von Software-Systemen SS 2007 (4)

2 Entwickler sind für den Test verantwortlich Entwickler sind für den Test eines Produktes verantwortlich, das von einem anderen Entwickler entwickelt wurde Besser als die erste Situation Der Rollenwechsel (von der Rolle Entwickler zur Rolle Tester ) ist jedoch schwierig Unter Umständen fehlt besonderes Testerwissen Ein Team mit einem oder mehreren Testern - ist für den Test verantwortlich Ein Mitglied des Entwicklungsteams der Tester ist für den Test verantwortlich Der Tester ist nur für das Testen zuständig Auf der einen Seite unterstützt die enge Kommunikation zwischen Entwicklern und Testern das Verständnis und die Klärung von Problemen Auf der anderen Seite kann die Nähe zu Interessenskonflikten führen Testen von Software-Systemen SS 2007 (5) Testen von Software-Systemen SS 2007 (6) Ein Team mit einem oder mehreren Testern - ist für den Test verantwortlich Ein dediziertes Testteam ist für den Test verantwortlich Keine direkte Einflussnahme durch Entwickler Der Test eines Produktes wird als eigenes (Teil-)Projekt gesehen Wachsendes Wissen der Testexperten Ein interner Berater unterstützt Projekte im Hinblick auf den Test Das Testen wird den Projektteams als Dienstleistung angeboten Durchgehende Zusammenarbeit im Projekt Wissenstransfer zwischen unterschiedlichen Projekten Mehrwert für das Team In jedem dieser Modelle ist es vorteilhaft, (interne) Testberater verfügbar zu haben, die mehreren Projekten beratend zur Seite stehen. Testen von Software-Systemen SS 2007 (7) Testen von Software-Systemen SS 2007 (8)

3 Externe Beratung oder Ausgliederung Zwei grundsätzlich unterschiedliche Testrollen: Unabhängigkeit garantiert Neue Ideen und Ratschläge von Externen Nötig: Gute Kenntnis der Arbeitsabläufe und Vorgehensweisen beim Kunden Enge Zusammenarbeit mit den Abteilungen des Kunden Wenn der Test ausgegliedert und von einem externen Testdienstleister durchgeführt wird, können Testumfang und -kosten im Vornhinein festgelegt werden besteht die Möglichkeit, eigene Ressourcen für andere Aufgaben frei zu setzen Aber: Dokumentation muss vorhanden und vollständig sein! 1. Testleiter (auch Testmanager oder Testkoordinator) Die Rolle des Testleiters kann auch ausgeübt werden von 2. Tester einem Projektleiter, einem Entwicklungsmanager, einem Qualitätsmanager oder dem Manager einer Testgruppe Eine Person, die das System oder eine Komponente testet Anmerkung: Die Rolle Testers kann weiter aufgeteilt werden (s.u.) Testen von Software-Systemen SS 2007 (9) Testen von Software-Systemen SS 2007 (10) Übersicht über die Aufgaben des Testleiters Grundlegende Aufgaben des Testleiters (1) Der Testleiter ist für die Durchführung des Testprojekts verantwortlich Die Hauptaufgaben sind: Planung Überwachung Steuerung Berichterstattung ans Management Erstellung des Testkonzepts inkl. Testvorgehensweise und Testrichtlinie Schätzung von Aufwand und Zeitbedarf der Testarbeiten Planung und Beschaffung der nötigen Ressourcen Entscheidung, welche Testfälle durchgeführt werden: von welchem Tester? in welcher Reihenfolge? zu welchem Zeitpunkt? Entscheidung über Umfang und Art der Testautomatisierung Anpassung des Testkonzepts an die Testergebnisse und den Testfortschritt ( ggfs. Neu-Planung, um die übrigen Testzyklen abzudecken ) Aufbau des Konfigurationsmanagements für die Testmittel Testen von Software-Systemen SS 2007 (11) Testen von Software-Systemen SS 2007 (12)

4 Grundlegende Aufgaben des Testleiters (2) Der Testleiter (ggf. zusammen mit Projektleiter) eines Testprojekts ist zuständig für die Überwachung und Steuerung des Testprozesses bezüglich der Projektziele Budgettreue Termintreue (Freigabe bzw. Auslieferung des Produkts) Einhaltung der geforderten Qualitätsanforderungen Information der Verantwortlichen, falls im Testprojekt die gesetzten Ziele nicht erreicht werden können Der Testleiter muss Änderungen im Testkonzept dokumentieren und kommunizieren: Die Änderungen führen üblicherweise zu erhöhten Risiken bzgl. der Freigabe Der Testleiter muss diese Risiken den Verantwortlichen (Management) gegenüber deutlich machen. Aufgaben des Testleiters: Gründe für Testüberwachung Einen Überblick über den aktuellen Stand des Testfortschritts bekommen Status des Testkonzepts Status der Testspezifikationen Status der Testdurchführung Status der Testauswertung Bekannte Abweichungen und Status der Fehlerbehebung Diese Informationen ermöglichen es dem Testleiter einzuschätzen, wie lange und wie viel noch getestet werden muss. Testen von Software-Systemen SS 2007 (13) Testen von Software-Systemen SS 2007 (14) Aufgaben des Testleiters: Metriken für Testüberwachung Metriken für die Testüberwachung (Beispiele): Anzahl der Tests, die keine Fehler finden Anzahl der Fehlermeldungen (je Kategorie) Anzahl der Wiederholungen von Tests Anzahl der Testfälle, die nicht durchgeführt werden konnten Testüberwachung zeigt auf: Abweichung zwischen Istergebnis und Sollergebnis Auffälligkeiten (z.b. je mehr Fehler korrigiert werden, desto mehr neue Fehler werden gefunden ) Aufgaben des Testleiters: Berichte Regelmäßige Berichte (in festen Abständen) Zusammenfassung für das Management Liste der zu erledigenden Aufgaben Offene Punkte Status der Teilprojekte Auswertung der Änderungsanfragedatenbank (Change Request-Datenbank) Bisheriger Aufwandsverbrauch und Budgetausschöpfung Abschlussbericht Zusammenfassung für das Management Metriken oder Klassifizierungen (für das Gesamtprojekt und die Teilprojekte) Erfahrungsbericht (Erfahrungsdatenbank) Testen von Software-Systemen SS 2007 (15) Testen von Software-Systemen SS 2007 (16)

5 Aufgaben des Testleiters: Teststeuerung stellt sicher, dass die Projektziele erreicht werden Teststeuerung nutzt die Informationen der Testüberwachung Falls nötig, werden über die Teststeuerung Gegenmaßnahmen im Testprozess eingeleitet: Der Ressourcenplan wird angepasst hinsichtlich Zeitplan Anzahl der Tester Testwerkzeugen Schritte gegen unerwünschte Nebenwirkungen werden unternommen Anpassung der Testumgebung Intensivierung der Testautomatisierung Änderung der Prioritäten Aufgaben des Testers: Das Prüfen von Testplänen und Mitarbeit an ihnen Analyse, Prüfung und Bewertung von Benutzeranforderungen, Spezifikationen und Modellen im Hinblick auf Testbarkeit Erstellen von Testspezifikationen Aufbau der Testumgebung (oftmals in Abstimmung mit System- und Netzwerkadministration) Vorbereitung oder Anforderung von Testdaten Testen von Software-Systemen SS 2007 (17) Testen von Software-Systemen SS 2007 (18) Aufgaben des Testers: Aufgaben des Testers: Implementierung von Tests auf allen Stufen, Durchführung der Tests und ihre Protokollierung Auswertung der Testergebnisse und Dokumentation der Abweichungen von erwarteten Ergebnissen Das Einsetzen von Testadministrations-, Testmanagementsowie Testüberwachungswerkzeugen wie gefordert Automatisierung von Tests (kann durch einen Entwickler oder einen Testautomatisierungsexperten unterstützt werden) Messung der Leistungsfähigkeit/Performanz von Komponenten und Systemen (wenn zutreffend) Prüfung der Tests, die von anderen entwickelt wurden Testen von Software-Systemen SS 2007 (19) Testen von Software-Systemen SS 2007 (20)

6 Qualifikation der Tester Weitere Spezialisten zur Unterstützung des Testers Test-spezifische Qualifikation Schulungen und Seminare Studium (Informatik) Training on-the-job Beispiele nützlicher technischer Qualifikationen Technische Experten mit Allgemeinwissen über die Fachdomäne, wie Ingenieure Informatiker Absolventen von IT-Ausbildungsberufen oder mit ähnlicher Qualifikation Spezialisten mit Wissen bezüglich der Fachdomäne Falls nötig, werden weitere Spezialisten benötigt, wie z.b.: Datenbankadministratoren Datenbankdesigner Netzwerkspezialisten Spezialisten für Benutzerschnittstellen Betriebssystemexperten aber auch Mitarbeiter mit Fähigkeiten zur Durchführung von Reviews (Moderator!) Testen von Software-Systemen SS 2007 (21) Testen von Software-Systemen SS 2007 (22) Sozialkompetenz (1) Sozialkompetenz (2) Wünschenswerte Fähigkeiten eines Testers Teamfähigkeit Durchsetzungskraft Sicheres Auftreten Exaktheit und Kreativität Analysefähigkeit Fähigkeit, sich schnell in komplexe Anwendungsgebiete und Applikationen einzuarbeiten Erfolgreiche Tester bringen Fehlermeldungen schlechte Nachrichten müssen überbracht werden, ohne persönlich zu werden Diplomatisches Verhalten wünschenswert Trotz unterschiedlicher Ziele ist eine gute Zusammenarbeit mit Projektmanagern und Entwicklern dringend erforderlich: ein gutes Produkt erzeugen ist die gemeinsame Aufgabe Siehe auch Psychologie des Testens Testen von Software-Systemen SS 2007 (23) Testen von Software-Systemen SS 2007 (24)

7 Qualifikation und Testebenen Zusammenfassung Modultest oft nötig: Tester mit Entwicklungserfahrung Integrationstest manchmal nötig: Tester mit Entwicklungserfahrung Systemtest nötig: Tester mit Kenntnis der Fachdomäne und typischer Anwendungen Abnahmetest nötig: Tester mit Kenntnis der Fachdomäne und typischer Anwendungen sowie Intuition und Bereitschaft, sich in den Kunden und seine Bedürfnisse hinein zu versetzen und zusammen mit dem Kunden diese zu überprüfen. Es gibt verschiedene sformen, die sich auszeichnen durch den Grad der Unabhängigkeit von der Entwicklung den Grad der Integration in die Abteilungen des - internen bzw. externen - Kunden Je nach Testling muss das Testteam durch Experten ergänzt werden mit benötigtem technischen Wissen mit Fachdomänen-spezifischem Wissen mit Review-Fähigkeiten Testen von Software-Systemen SS 2007 (25) Testen von Software-Systemen SS 2007 (26) P r a k t I s c h e Testen als Teil eines umfassenden QM-Plans Testen ist nur eine von mehreren QS-Maßnahmen Andere QS-Maßnahmen müssen auch zum Einsatz kommen: Konstruktive Maßnahmen (hauptsächlich während der Entwicklung) Organisatorische Maßnahmen (richtig realisiertes Anforderungsmanagement, Konfigurationsmanagement, Abweichungsmanagement, etc.) Weitere analytische QS-Maßnahmen (Reviews, Inspektionen, etc.) Das Zusammenwirken dieser Maßnahmen sollte in einem Qualitätssicherungsplan beschrieben werden (Gliederungsschema: siehe z.b. IEEE 730) 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (27) Testen von Software-Systemen SS 2007 (28)

8 Teststrategie Testkonzept (Englisch: test plan) Die Teststrategie enthält: Abstrakte Beschreibung der Teststufen Zugehörigen Ein- und Ausgangskriterien Aufteilung von Testaufwand über die zu testenden Teile des Testobjekts Auswahl und Bestimmung der Reihenfolge von einzelnen Testmethoden Festlegung der zu erreichenden Überdeckungsgrade bei jeder Testmethode Die Teststrategie kann auf mehrere Projekte angewendet werden Die Anwendung einer Teststrategie auf ein konkretes Projekt heißt Testvorgehensweise Die Testvorgehensweise sollte nur bei gravierenden Projektänderungen angepasst werden Testen von Software-Systemen SS 2007 (29) Das Testkonzept ist die Aufzeichnung des Testplanungsprozess (als Konkretisierung und Fortschreibung der Teststrategie innerhalb eines konkreten Projekts) Das Testkonzept enthält den Umfang der Testaktivitäten ordnet die Testfälle den Testern zu (Ressourcenzuordnung) legt die zeitliche Durchführung des Testprojekts fest enthält oder referenziert ein Verzeichnis aller Testfälle enthält die Testvorgehensweise Das Testkonzept wird je nach den Bedürfnissen des Projekts gepflegt, angepasst und geändert Testen von Software-Systemen SS 2007 (30) Testplanungsaktivitäten Testplanungsaktivitäten Definieren der allgemeinen Testvorgehensweise, inklusive Definition der Teststufen, Eingangs- und Testendekriterien. Integrieren und koordinieren der Testaktivitäten in die Aktivitäten des Softwarelebenszyklusaktivitäten: Beschaffung, Bereitstellung, Entwicklung, Betrieb und Wartung Entscheiden, was zu testen ist, welche Rollen die Testaktivitäten ausführen werden, wann und wie die Testaktivitäten auszuführen sind, wie die Testergebnisse bewertet werden und wann der Test endet (Testendekriterien) Zuordnen der Ressourcen zu den definierten Aufgaben Definieren der folgenden Eigenschaften der Testdokumentation: Umfang Detaillierungsgrad Struktur Vorlagen Testen von Software-Systemen SS 2007 (31) Testen von Software-Systemen SS 2007 (32)

9 Testplanungsaktivitäten Beispielgliederung eines Testkonzepts (IEEE 829 Test Plan): Selektieren der Metriken zur Überwachung und Steuerung von Testvorbereitung Testdurchführung Fehlerbehebung Risikofaktoren Bestimmen des Detaillierungsgrades für Testszenarien, um genügend Informationen in Hinblick auf eine reproduzierbare Testvorbereitung und -durchführung zu liefern Gliederung 1. Testkonzept-Kennung 2. Einleitung 3. Testobjekte 4. Zu testende Funktionen 5. Nicht zu testende Funktionen 6. Vorgehen 7. Pass/Fail-Kriterien für Testobjekte 8. Endekriterien und Wiederaufnahmekriterien 9. Testartefakte 10. Testaufgaben 11. Anforderungen an die Umgebung 12. Verantwortlichkeiten 13. Bedarf an Personal und Schulungen 14. Zeitplan 15. Risiken und Eventualitäten 16. Genehmigungen Testen von Software-Systemen SS 2007 (33) Testen von Software-Systemen SS 2007 (34) Testendekriterien Testendekriterien (prioritätsbasierte Kriterien) Testendekriterien sind ein wesentlicher Bestandteil des Testkonzepts Das Ziel von Testendekriterien ist zu definieren, wann mit dem Testen aufgehört werden kann Testendekriterien sind teststufen-spezifisch Sie sollten auf geeigneten Metriken basieren, die den Testfortschritt messen und bewerten Der Test darf nur beendet und die Freigabe des Systems oder der Software empfohlen werden, wenn es keine bekannten Fehler einer bestimmten vorgegebenen Schwere mehr gibt Beispiele: Testende nur, wenn alle bekannten Fehler der Prioritätsstufe hoch behoben sind, bzw. alle bekannten Fehler der Prioritätsstufen hoch und mittel behoben sind. Testen von Software-Systemen SS 2007 (35) Testen von Software-Systemen SS 2007 (36)

10 Weitere Testendekriterien (anzuwenden, wenn die prioritätsbasierten Kriterien erfüllt sind) Beispiele Eine definierte Testabdeckung ist erreicht. Eine definierte Restfehlerzahl wurde unterschritten (Achtung: die Restfehlerzahl kann nur geschätzt werden!) Pro (Test-) Zeiteinheit wird nur noch eine bestimmte Fehlerzahl gefunden. Der Ausliefertermin ist erreicht. Vorübergehendes Testende bzgl. von Teilen der Software Ein Entwickler hat viele Fehler zu korrigieren Suspendierung der Tests von Softwareteilen dieses Entwicklers; Fortsetzung erst, wenn der Entwickler die zu bearbeitenden Fehler deutlich reduziert hat Testschätzung Es gibt im wesentlichen folgende Ansätze, um den Testaufwand zu schätzen: Schätzung auf der Basis von Metriken früherer oder ähnlicher Projekte Schätzung auf der Basis von typischen Werten Schätzung der Aufgaben durch die Verantwortlichen für diese Aufgaben oder durch Experten Sobald der Testaufwand geschätzt ist, können Ressourcen identifiziert und ein Zeitplan erstellt werden. Testen von Software-Systemen SS 2007 (37) Testen von Software-Systemen SS 2007 (38) Testschätzung Testschätzung am Beispiel der Testbudgets (1) Der Testaufwand kann von folgenden Faktoren abhängen: Charakteristiken des Produkts: Qualität der Spezifikation und anderer Testbasen Größe des Produkts, Komplexität der Problembereiche, Anforderungen an Zuverlässigkeit und Sicherheit Anforderungen an die Dokumentation Charakteristiken des Entwicklungsprozesses: die Stabilität der, benutzte Werkzeuge, Testprozess, Kenntnisse der involvierten Personen Zeitdruck Den Testergebnissen: die Anzahl der Fehler und die Menge der erforderlichen Nacharbeiten Einflüsse Anzuwendende Methoden Erfahrung und Wissen der Tester im Projekt Größe des Testobjekts Komplexität des Testobjekts Zu erreichende Abdeckung Gelieferte Qualität Testen von Software-Systemen SS 2007 (39) Testen von Software-Systemen SS 2007 (40)

11 Testschätzung am Beispiel der Testbudgets (2) Zusammenfassung Der geschätzte Aufwand wird im Testkonzept beschrieben Der geschätzte Aufwand wird vor Beginn des Testprojekts ermittelt Gründe für Überarbeitung eines Testkonzepts werden beachtet Durchführung von Tests ist komplexer und teurer als erwartet Budgetierte Ressourcen stehen nicht wie geplant zur Verfügung Umfang von Testwiederholungen höher als erwartet Die Überarbeitung des Testkonzepts wird mit eingeplant Pufferzeiten Pufferressourcen Der Test ist nur ein wenn auch wichtiger Baustein der gesamten Qualitätssicherung. Die (statische) Teststrategie deckt die allgemeinen Bedingungen des Testprojekts ab. Das (dynamisch veränderliche) Testkonzept wird, in Übereinstimmung mit der Teststrategie, während des Testprojektes gepflegt und angepasst. Testen von Software-Systemen SS 2007 (41) Testen von Software-Systemen SS 2007 (42) P r a k t I s c h e und -steuerung Das Ziel der ist es, Feedback und Übersicht über Testaktivitäten zu erhalten. Zu überwachende Informationen können manuell oder automatisiert gesammelt werden. Sie können herangezogen werden, um Testende-Kriterien wie die erzielte Testüberdeckung zu messen, sowie den Fortschritt gegen den Zeitplan und gegen das Budget zu beurteilen Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (43) Testen von Software-Systemen SS 2007 (44)

12 Um ein effizientes Testmanagement zu ermöglichen, muss der aktuelle Stand der Testaktivitäten immer bekannt sein. Eine permanente Testüberwachung und -fortschrittskontrolle unter Verwendung von objektiven Testmetriken ist daher nötig: Fehler-basierte Metriken Testfall-basierte Metriken Testobjekt-basierte Metriken Der aktuelle Teststatus wird in Form von Testfortschrittsberichten an das Management kommuniziert. Fehler-basierte Metriken Neben den absoluten Zahlen Wie viele Fehler wurden gefunden? Wie viele sind zur Zeit in Bearbeitung? Wie viele werden getestet?... ist die Trend-Analyse wichtig: Können die Freigabe-, bzw. Liefertermine eingehalten werden? Sind die Test- oder Entwicklerkapazitäten ausreichend? Auf der Basis der fehler-basierten Metriken kann die Testdurchführung verlängert, Freigabe- oder Liefertermine verschoben oder Testbereiche neu priorisiert werden. Testen von Software-Systemen SS 2007 (45) SS 2007 (46) Fehler pro Status: Wie viele Fehler auf DONE, TEST, STUDY...? Macht die Korrektur Fortschritte? Fehler pro Fehler-Klasse: Wie schwerwiegend sind die Fehler? Neu Offen In Bearbeitung Test Flop Done Zurückgewiesen Fehlermetriken die nach Ende der Entwicklung und Auslieferung der Software erhoben werden Fehler pro NLOC: Wie viele Fehler treten pro 1000 Zeilen Code (ohne Leerzeilen, ohne Kommentare) auf? Ist eine Auslieferung tolerierbar? Fehler pro Software-Priorität: Wie viele Fehler müssen umgehend, in der nächsten Version, im nächsten Release,.. umgesetzt werden? Reihe1 DDP (Defect Detection Percentage): DDP = Anzahl der im Test gefundenen Fehler/Gesamtanzahl Fehler (inkl. Fehler in den ersten sechs Monate nach SW-Freigabe) Wieviele Fehler treten nach Freigabe und Auslieferung der Software noch auf? Fehler pro Software-Module: Ist ein Module schlecht oder missverständlich spezifiziert, oder sehr komplex? Gibt es Probleme mit einem Lieferanten? fatal bedeutend normal geringfügig vernachlässigbar SS 2007 (47) DFP (Defect Fix Percentage): DFP = Anzahl der korrigierten (ge fix ten) Fehler/Gesamtanzahl Fehler Wie effizient ist die Fehlerkorrektur? SS 2007 (48)

13 Basierend auf erfassten oder abgeschätzten Aufwänden zur Fehlerbehebung (Korrekturaufwände) können in Zusammenhang mit den fehler-basierten Metriken Aussagen über die Einhaltung von Lieferterminen Personalkapazitäten (Entwickler und Tester) die Anzahl der erwarteten Regressionstest-Zyklen getroffen werden. Für eine realistische Planung sollten daher die Korrekturaufwände pro Fehler erhoben werden (als Aufwand oder Zeitdauer). Testfall-basierte Metriken Die Metrik Testfortschritt misst die erreichte Testabdeckung bezogen auf den Testplan. Bei der Messung des Testfortschritts kann man zwischen Testspezifikation und Testdurchführung unterscheiden. Testspezifikation Testdurchführung Anzahl zu spezifizierenden Tests: planned Anzahl spezifizierten Test: specified Anzahl durchzuführenden Tests: planned Anzahl durchgeführter, nicht Fehler-aufdeckender Tests: passed Anzahl durchgeführter, Fehler-aufdeckender Tests: failed Anzahl blockierter Tests: blocked SS 2007 (49) SS 2007 (50) Testfortschrittskontrolle während der Testdurchführung Testfall-basierte Metriken planned passed failed blocked Prozentsatz erfolgreicher Testfälle = Anzahl der Testfälle mit Urteil Passed/Gesamtanzahl der Testfälle Prozentsatz nicht erfolgreicher Testfälle = Anzahl der Testfälle mit Urteil Failed/Gesamtanzahl der Testfälle Anzahl erfolgreicher Testfälle gefiltert nach z.b. Testfall-Prioritäten (Prio-1 Testfälle, Regressionstestfälle) Software-Komponenten (Komponenten mit hoher Risikobewertung) Durchführungszeit pro Testfall Basis für eine fundierte Planung von Testdurchführungsaufwänden 0 KW30 KW31 KW32 KW33 KW34 KW35 KW36 KW37 KW38 KW39 SS 2007 (51) SS 2007 (52)

14 Testobjekt-basierte Metriken Testberichterstattung Funktionale Abdeckung anhand der Spezifikation: getestete Features / spezifizierte Features. z.b. für jedes Feature muss ein Testfall existieren Dialogabdeckung bei Test auf GUI-Ebene: getestete Dialoge / Gesamtzahl Dialoge z.b. jeder Dialog muss mindestens einmal aufgerufen werden Code-orientierte Abdeckung: getestete Anweisungen, Zweige,... / Gesamtzahl Anweisungen, Zweige,.. z.b. 70% Anweisungsabdeckung muss erreicht werden Testberichterstattung beschäftigt sich mit der Zusammenfassung der Informationen über die Testaktivitäten, inklusive: Was passierte während des Testzeitraums? Analysierte Informationen und Metriken zur Unterstützung von Empfehlungen und Entscheidungen über zukünftige Aktivitäten, wie Eine Beurteilung der verbleibenden Fehler, die ökonomischen Vorteile fortgesetzten Testens, offen stehende Risiken der Grad des Vertrauens in das getestete System Metriken sollten während des Testens und am Ende einer Teststufe zur Beurteilung folgender Aspekte gesammelt werden: Die Angemessenheit der Testziele für die Teststufe Die Angemessenheit des gewählten Testansatzes Die Effektivität des Testens in Relation zu seinen Zielen SS 2007 (53) Testen von Software-Systemen SS 2007 (54) Beispielgliederung eines Testberichts (IEEE 829 Testbericht): 1. Testberichts-Kennzahl 2. Einleitung 3. Abweichungen 4. Umfassende Bewertung 5. Zusammenfassung der Ergebnisse 6. Auswertung 7. Vorgehen 8. Genehmigungen Teststeuerung Teststeuerung beschreibt sämtliche Führungs- oder Korrekturmaßnahmen, die auf Grund gesammelter oder berichteter Informationen und Metriken ergriffen werden. Maßnahmen können jede Testaktivität betreffen und können jede andere Softwarelebenszyklusaktivität oder -aufgabe beeinflussen. Beispiele von Maßnahmen zur Teststeuerung sind: Repriorisierung von Tests, wenn identifizierte Risiken auftreten Änderung des Testzeitplans aufgrund der Verfügbarkeit der Testumgebung Setzen einer Eingangsbedingung mit der Maßgabe, dass Fehlerbehebungen durch einen Entwickler nachzutesten sind, bevor die Software an die nächste Teststufe übergeben wird Testen von Software-Systemen SS 2007 (55) Testen von Software-Systemen SS 2007 (56)