Software Testen 2.0 VL

Transkript

1 Software Testen 2.0 VL Software Testen VO4 2009W INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien

2 Folie: 2 Lernziele Testdokumentation Testaufwandsschätzung Testprozessverbesserung Testunterstützungswerkzeuge

3 Folie: 3 Testpolitik Definition: Die Testpolitik ist ein Dokument, welches auf einem hohen Abstraktionsniveau die Prinzipien, Vorgehensweisen und wichtigsten Ziele einer Organisation in Bezug auf das Testen zusammenfasst Darstellen des Testprozesses Evaluieren des Testens Zu erreichende Qualitätsniveaus Verfahrensansatz zur Testprozessverbesserung

4 Testhandbuch Basis zur Ableitung eines Testplanes in den Projekten Beschreibung der durchzuführenden Teststufen und auszuführenden Testaktivitäten Zwei Hauptbereiche werden unterschieden: die Beschreibung der Risiken, die durch das Testen abgedeckt werden sollen, die Beschreibung der Testaktivitäten, die durchgeführt werden sollen, um die identifizierten Risiken abzudecken 4

5 Testhandbuch II Für jede Teststufe werden folgende Aspekte beschrieben Eingangs- und Ausgangskriterien Testansatz Testendekriterien Grad der Unabhängigkeit des Testens Einzuhaltende Standards Umgebungen, in der Softwaretests durchgeführt werden Anzuwendende Testspezifikationstechniken (Testfallentwurfsmethoden) Ansatz zur Testautomation Grad der Testautomation 5

6 Testplan Das Dokument Testplan enthält die konkrete Umsetzung des Testhandbuches auf die Projektsituation Es ist erweitert um die generelle Zeit- und Ressourcenplanung des Projektes. Legt die Prozesse innerhalb des Testvorgehens fest Testfallerstellungsprozess Übergabe von Entwicklung an Test Behandlung von Abweichungen, Change Request Herstellen der Testumgebungen Grundlage für die Abstimmung mit anderen am Projekt Beteiligten. Konkretisiert die Projektrisiken und erforderliche Gegenmaßnahmen. 6

7 Teststufenplan Er beschreibt die Implementierung des Testplans für eine bestimmte Teststufe, ist also eine Verfeinerung des Testplans Der Teststufenplan enthält: eine Abfolge der Testaktivitäten einen taggenauen Plan der Aktivitäten verknüpfte Meilensteine 7

9 Testplanung und Testkontrolle: Testaufwandschätzung Aktivitäten pro Testobjekt Testspezifikation Testfallermittlung Testdatendefinition und -erstellung Testprozedurerstellung Testausführung und -aufzeichnung Testendebewertung Aktivitäten pro Teststufe z.b. Aufbau der Testumgebung Teststufenübergreifende Aktivitäten z.b. Testmanagement / Testplanung 9

10 Schätzmethoden Intuition, Raten, Erfahrung, vergleichbare Testprojekte Voraussetzungen Befragte sind Experten. Es existiert eine Projektdefinition (Grobkonzept vorhanden). Erfahrungen / Analogiematerialien liegen vor Anwendung Schätzungen im Vorprojektstadium Cross-Checks der Größenordnung Risikoarme Projekte Probleme / Herausforderungen Subjektivität Keine definierte Genauigkeit 10

11 Schätzmethoden II Hochrechnung aus vorhergehenden Testdurchlaufen Detaillierte Aufschlüsselung für alle Testaktivitäten Formelbasiert Function Point Methode COCOMO (Constructive Cost Model) Metriken LOC (Lines of Code) Komponentenmethode Bewertung und Gewichtung der Qualitätsmerkmale, Risiko und Komplexität 11

12 Schätzmethoden III In der Praxis oft Verwendung mehrere verschiedener Verfahren Beispiel Erstschätzung: Testobjekte bestimmen Risikoklasse zuordnen Komplexität zuordnen Gemeinsame Bewertung von Risiko und Komplexität Beispiel Aufwandsschätzung der einzelnen Teststufen anhand von Qualitätskriterien 12

13 Festlegen der Risikoklassenkategorien 13

14 Risikoklassen zuordnen 14

15 Komplexitätskriterien festlegen 15

16 Komplexität zuordnen 16

17 Gemeinsame Bewertung von Risiko und Komplexität 17

18 Qualitatsmerkmale (ISO 9126, DIN 66272) 18

19 Schätzung Testaufwand: Gewichtung Beispiel: Robustheit: Für eine 7 Tage / 24-Stunden Anwendung muss die Verfugbarkeit stets gewährleistet sein, daher Gewichtung = hoch. Für eine laufend genutzte kommerzielle Anwendung, die wahrend der üblichen Geschäftszeiten verfugbar sein muss, ist die Gewichtung = mittel. Für eine Statistikauswertung anlässlich der Jahresabschlussarbeiten ist die Gewichtung = gering. 19

20 Festlegung der Teststufen 20

21 Festlegung der Teststufen 21

23 Qualitätsmanagementstandards Qualitätsmanagement beinhaltet aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität Sollen die Entwicklung eines Unternehmens hin zu einem hohen Qualitätslevel und zu Kontinuität unterstützen Standards verbessern zudem das wechselseitige Verständnis und die Koordination unterschiedlicher Entwicklungsteams, speziell aber auch zwischen Entwicklung und Wartung Durch eine höhere Transparenz und Berechenbarkeit eines Qualitätssicherungssystems kann der Kunde von einem gewissen Qualitätsniveau ausgehen und bleibt so eher von unerwünschten Überraschungen verschont als bei intuitiver Vorgehensweise Grundsätzlich können Qualitätsmanagementstandards in Zertifizierungs- und Assessmentstandards (Bewertungsstandards) unterschieden werden

24 Überblick 24

25 CMM and CMMI CMM-Modell wurde in den 80er Jahren, auf Initiative des US- Verteidigungsministerium, vom SEI (Software Engineering Institute) entwickelt Ziel, die Vergleichbarkeit und Qualität von Softwareprozessen im Rahmen der Vergabe an externe Lieferanten zu verbessern Mit der Zeit jedoch verbreitete sich das Modell wurden für diverse Entwicklungsdisziplinen weitere Modelle entwickelt, wie z.b. SE-CMM 2003 ein vereinheitlichter und modularer Nachfolger, das CMMI (Capability Maturity Model Integrated), entwickelt CMMI Liefert eine Analyse des Ist- Zustandes eines Unternehmens und ist kein international anerkanntes Zertifikat wie ISO Ein CMM-Assessment beurteilt die Fähigkeit einer Organisation, Software unter bestimmten Rahmenbedingungen erstellen zu können

26 CMMI Reifegradstufen

27 SPICE ISO/IEC SPICE (Software Process Improvement for Capability Determination) wurde Anfang der 90er Jahre als gemeinsame Initiative von ISO und IEC entwickelt Grundsätzlich sind SPICE und CMMI sehr ähnlich aufgebaut. Zielsetzungen und Forderungen dieser beiden Modelle überdecken sich zu ca %. Somit kann SPICE als Konkurrent zum US-dominanten CMMI gesehen werden SPICE besteht, genauso wie CMMI, aus einem zweidimensionalen Referenzmodell. Zu diesem Referenzmodell gehören eine Prozessdimension und eine Fähigkeitsdimension zur Reifegradbestimmung der einzelnen Prozesse

28 SPICE ISO/IEC Prinzipien und Ziele Zusammenführung verschiedenster existierender Assessment- Methoden zu einem zusammenhängenden Systemmodell Universelle Einsetzbarkeit, um alle Kategorien von Softwareprojekten sowie deren Kunden und Zulieferer zu unterstützen Hohe Professionalität Erreichung hoher internationaler Akzeptanz als weltweiter Standard

29 SPICE ISO/IEC Reifegradstufen

30 SPICE ISO/IEC Erfüllungsgrade nicht erreicht (not achieved) 0 15 % teilweise erreicht (partially achieved) % weitestgehend erreicht (largely achieved) % vollständig erreicht (fully achieved) %

31 Testprozessverbesserung Standardisierung bringt Sicherheit in der Bewertung und Vergleichbarkeit der Ergebnisse Aber der Testprozess spielt in den Modellen heute nur eine untergeordnete Rolle Die Modelle TMM (Testing Maturity Model) und TPI (Test Process Improvement) versuchen diese Lücke zu füllen. 31

32 Test Maturity Model - TMM Berücksichtigt die besonderen Aspekte des Testens. Inspiriert durch CMM und SPICE. Entwickelt und registriert durch das Illinois Institute of Technology (IIT) Basiert auf dem Modell von Gelperin und Hetzel. 4 historische Perioden des Testens identifiziert: Debugging (Fehlerbehebung). Destruction (Fehlerfindung). Evaluation (Integration in den Software-Lebenszyklus). Fehler in den Anforderungen. Fehler im Design. Fehler in der Implementierung. Prevention (Optimierung). 32

33 Test Maturity Model TMM II Reifegradstufen 1. Initial 2. Phasendefinition 3. Integration 4. Steuerung, Messung und Kontrolle 5. Optimierung, Fehlervermeidung und Qualitätskontrolle Jeder Reifegrad hat Ziele Unterziele Aktivitäten, Aufgaben und Verantwortlichkeiten Bewertungsmodell mittels Assessement Im Assessement wird das erreichen der Ziele überprüft. 33

34 Test Maturity Model Phase Initial 1. Initial Charakteristika: Keine Trennung von Debugging und Test Ad Hoc Test nach Codierung Produkt-Freigaben ohne Test Keine Ressourcen verfügbar für Test Testziel: Software funktioniert 34

35 Test Maturity Model Phase Definition 2. Definition Charakteristika: Test und Debugging sind in verschiedene Phasen getrennt Test ist geplant Basistechniken und Methoden kommen zur Anwendung aber: Test zu spät keine Reviews Testziel Software entspricht der Spezifikation 35

36 Test Maturity Model Phase Integration 3. Integration Charakteristika: Steuerung und Überwachung des Testprozesses Testen ist im Software-Lebenszyklus integriert Technisches Ausbildungsprogramm existiert Testorganisation existiert Testziel Software entspricht den Anforderungen 36

37 Test Maturity Model Steuerung, Messung und Kontrolle 4. Steuerung, Messung und Kontrolle Charakteristika: Der Test ist ein gemessener und quantifizierter Prozess. Reviews in allen Entwicklungsphasen. Qualitätsmerkmale werden geprüft. Testziel Messen der Qualität 37

38 Test Maturity Model -. Optimierung, Fehlervermeidung und Qualitätskontrolle 5. Optimierung, Fehlervermeidung und Qualitätskontrolle Charakteristika: Testprozess ist optimiert Qualitätskontrolle Fehlerprävention Testziel Kontrolle der Qualität 38

39 Test Process Improvement - TPI Bewertungsmodell zur Bestimmung von Stärken und Schwächen im Bereich des Software-Testens TPI ist eine Entwicklungsmatrix bestehend aus 20 Kerngebieten, 4 Level und Kontrollpunkten für die Levelerreichung Die Entwicklung der einzelnen Kerngebiete lässt sich aus der Matrixablesen Die Weiterentwicklung der Testorganisation erfolgt nicht für alle Kerngebiete gleichzeitig 39

40 TIP Levels Level stellen qualitative Verbesserungen dar Die Anforderungen eines höheren Levels umfassen auch die Anforderungen der untergeordneten Level 40

41 Entwicklungsmatrix Liefert Übersicht, auf welchem Niveau sich der Testprozess befindet Wird von links nach rechts abgearbeitet, damit gering entwickelte Kerngebiete als erstes verbessert werden Die Weiterentwicklung erfolgt schrittweise, d.h. nicht für alle Kerngebiete zugleich 41

42 Entwicklungsmatrix II 42

44 Testunterstützungswerkzeuge 44

45 Werkzeugauswahl Die Wahl des richtigen Werkzeuges ist sehr wichtig: es muss seine Funktion erfüllen und leicht bedienbar sein es stellt eine große Investition dar finanziell und bezogen auf die benötigten Ressourcen Unterschiedliche Anwender haben unterschiedliche Anforderungen Wenn es das falsche Werkzeug ist folgen gegenseitige Schuldzuweisungen, wird das Werkzeug wird nicht genutzt (Schrankware), verliert das Management das Vertrauen Daher ist die Implementierung eines Prozesses zur Bewertung und Auswahl des Werkzeuges notwendig 45

46 Aktivitäten des Bewertungs- und Auswahlprozesses 1. Problemumfeld identifizieren und quantifizieren 2. Betrachtung möglicher Alternativlösungen 3. Kosten- / Nutzenanalyse 4. Identifikation von Lizensierungsmodellen und alternativen 5. Identifikation von Kosten, die mit dem Besitz des Werkzeugs verbunden sind 6. Identifikation von Einschränkungen 7. Identifikation der gewünschten Funktionalität und Eigenschaften des Werkzeugs 8. Identifikation von Werkzeugen für die detaillierte Evaluierung 9. Durchführung der detaillierten Evaluierung 10.Bei Bedarf Durchführung eines parallelen Probelaufes von konkurrierenden Testwerkzeugen 46