1. Einführung 1.1. Definitionen

Transkript

1 1

2 1. Einführung 1.1. Definitionen Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und Unterschiede zwischen tatsächlichem und erforderlichen Zustand aufzuzeigen Charakteristiken von guten Tests - Vollständigkeit: Kombinationen (Werten, Zahlen), Funktionen - Tests können nur Fehler nachweisen, nicht deren Abwesenheit - ein guter Test findet viele Fehler - ein guter Test hat einen definierten Ablauf, ein definiertes Ergebnis und ist reproduzierbar - Tests sollten wieder verwandt werden - Erfahrungen der Tester und Benutzer fließen ein 1.3. Fehler und Begriffe - Fault/Defekt/innerer Fehler/Fehlerursache/Fehlerzustand: Irrtum bei der Softwareentwicklung, z.b. fehlerhafte Programmierung einer Anweisung - Error/Fehlerhandlung: Ursache für Fehlerzustand - Failure/Fehlfunktion/äußerer Fehler/Ausfall/Fehlerwirkung: Nach außen sichtbare Fehlerverhalten bei der Anwendung der Software In fett markiert die Begriffe für die ISTQB Prüfung 2

3 2. Fehlervermeidung: - Prozessorientiertes Vorgehen - Architektur: Komponentenorientierung, - Implementierung: Kodierrichtlinien Tests Klassifizierung - Testziel: Wartbarkeit, Benutzbarkeit, Funktionalität, Robustheit, Effizienz, Portierbarkeit - Testmethode - Testobjekt - Testperson 3.1. Modultests (Komponententest, Klassentest, Unittest) Eigenschaften - Testperson: Entwickler - Testziel: Funktionalität, Robustheit - Testmethode/Testwerkzeuge: JUnit, NUnit - Testobjekt: Klasse, Methode 3

4 3.1.2 Vorgehen Funktionalität: z.b. Korrektheit (z.b. Rückgabewerte) Stabilität/Robustheit: z.b. gegen falsche Eingabewerte Um beide zu testen, setzt man die Methode der Äquivalenzklassen ein => Exkurs 1 Die Vollständigkeit der Tests bestimmt man über Abdeckungsgrade (Code Coverage) => Exkurs Reviews: Prüfen des Codes durch einen Dritten - Kodierrichtlinien > Metriken: Zeilenlängen, zyklomatische Komplexität > Namenskonventionen - Verständlichkeit - Dokumentation: JavaDoc, inline Kommentare - Laufzeitfehler: NullPointer, Div_by_0,... - Unabhängigkeit von (Mutter-)Sprache und Plattform (kein "c:\") - Rundungsfehler - Modultests vorhanden (Code coverage prüfen, Äquivalenzklassen) - Code reflektiert Architektur/Design 4

5 Exkurs 1: Äquivalenzklassen Problem: Es können nicht alle Wertekombinationen getestet werden. Beispiel: 3 Integerwerte á 2^16 Möglichkeiten benötigen 89 Jahre bei Tests/s Äquivalenzklassen sind Mengen von Werten, von denen angenommen wird, dass sich alle deren Werte im Test gleich verhalten. Beispiel: Student student = new Student("Andy Becker", ); Zwei Parameter: int (Matrikelnummer, 6-stellige Zahl) Namen: Zwei oder mehr Wörter, die durch Leerzeichen getrennt sind Äquivalenzklassen für Matrikelnummer (als Beispiel für Zahlen) Unendlich bis Unendlich NaN - bei vielen (Skript-) Sprachen: Nichtzahlen Werte ("kfk",...) 5

6 Äquivalenzklassen für Namen (als Beispiel für Zeichenketten) - Zeichenkette mit Leerzeichen "in der Mitte" - Zeichenkette mit mehreren Leerzeichen - Zeichenkette mit Leerzeichen am Anfgang/Ende - nur Leerzeichen - Zeichenkette ohne Leerzeichen - Sonderzeichen: ',', '-', ä, ö, é, - Andere Zeichensätze: - Zahlen - "" - null - Sehr lange Zeichenketten - SQL-Injection - Schlüsselworte: DROP, DELETE, EXIT, FOR, BREAK 6

7 Exkurs 2: Abdeckungsgrade ("Code coverage") 7

8 Anweisungsabdeckung (Statement coverage): Anzahl der durchlaufenen Anweisungen in Prozent (!) Zweigabdeckung (Branch coverage): Anzahl der durchlaufenen Zweige in Prozent (!) (ist stärkeres Maß als Anweisungsabdeckung) Einfache Bedingungsabdeckung (condition coverage): Anzahl der atomaren Teilbedingungen, die im Test die Werte true und false annehmen in Prozent Mehrfache Bedingungsabdeckung (multi condition coverage): Jede Kombination aus atomaren Teilbedingungen, die getestet wird, in Prozent (ist stärkes Maß als einfache Bedingungsabdeckung) Pfadabdeckung: 8

9 3.2 Integrationstests Eigenschaften - Testobjekte: Mehrere Komponenten, Module im Zusammenspiel - Tester: Entwickler, Tester - Testziel: Funktionalität, Effizienz - Werkzeuge: JUnit, Vorgehen - Persistenz, Transaktionen, CRUD (Create Read Update Delete) - Benutzerschnittstelle: Usability, Elemente sichtbar, Übersetzung,. - Kommunikation zwischen Komponenten (Performance, Schnittstellen) Strategien 9

10 10

11 Integrationsstrategien - Buttom-up > Vorteil: Keine Mockobjekte, frühes Finden von Fehlern > Nachteil: Später Tests eine vertikalen Prototypen - Top-Down > Vorteil: Früher Eindruck der Gesamtapplikation > Nachteil: Notwendigkeit, Mockobjekte *) zu schreiben - Big-Bang: > Vorteil: Kein Mockobjekte, keine Testtreiber > Nachteil: Fehler sind schwer zu lokalisieren *) Mockobjekte sind Objekt-Attrappen (Pseudoobjekte), die dem zu testenden Programmcode bestimmte Funktionalität vorgaukeln (z.b. Persisitierung in Datenbank). Mockobjekte dienen während des Tests als Ersatz für reale Objekte. 11

12 3.3 Systemtests Eigenschaften - Tester: Dezidierte Softwaretester - Testobjekte: Vollständiges System - Testziel: Alle Kriterien gemäß der ISO Vorgehen Überprüfung: - Portierbarkeit: Installation, Deinstallation, Upgrade auf verschienden Systemen (Betriebssysteme, Hardware, installierte Programme,...) - Funktionalität: End-to-End-Tests, beispielsweise mit Skripten, welche die Oberfläche ansteuern, Testen aller Use-Cases (Geschäftsprozesse) - Robustheit: Fehleingaben, Stresstests (Überlastung bis zum Systemkollaps), Dauertests (MemoryLeaks), Strom ausschalten, Aussschalten von Komponenten (Datenbank, Netzwerkkabel, Drucker,...) - Effizienz: Laden vieler Daten, Last mit vielen Benutzern (CPU, Netzwerklast, Speicher) - Benutzbarkeit: Benutzern Aufgaben stellen und Zeit messen, Usability labs, 12

13 3.4 Akzeptanztests Eigenschaften - Tester: Anwender - Testziel: Benutzbarkeit, Funktionalität - Werkzeuge: Manuell Vorgehen Überprüfung - Testen gegen Verträge und Anforderungen - Testen alles Usecases - Testen der Butzerdokumentation 3.5 Weitere Tests Statische Tests: Tests bei denen der Code nicht ausgeführt wird - Code review - Kompiler - Automatische Codanalyse mit Checkstyle Dynamische Tests: Tests bei denen Code ausgeführt wird - Modultests, - Integrationstests - Systemtests - Akkzeptanztests 13

14 Whitebox Tests: Tests bei denen die innere Struktur des Codes bekannt ist - Modultests Blackbox Test: Tests bei denen die Struktur nicht bekannt ist - Akkzeptanztests (- Systemtests) Regressionstests: Tests, die nachweisen, dass ein bereits getestetes Programm nach einer Änderung keine neuen Fehloer enthält. Die bisher beschriebenen Test können/sollten als Regressionstests wieder verwendet 14

15 4. Testprozess 4.1. Testplanung Übergreifende Planung innerhalb des Projekts, die Rahmenbedingungen festlegt - Ressourcen (Mitarbeiter, Schulung, Werkzeuge, Geräte) - Richtlinien (Code Coverage, Testmethoden, Risiken) 4.2. Testspezifikation - Vorbedingungen/Randbedingungen - Durchführung: Testschritte, Testdaten, Auswertung - Erwartetes Ergebnis 4.3. Testdurchführung und -protokollierung Reproduzierbarkeit (-> Konfigurationsmanagement) 4.4. Testauswertung und -bewertung Bei Abweichungen entscheiden, ob Software, Durchführung oder Testspezifikation falsch sind Ggf: - Test überarbeiten und Test wiederholen - Software überarbeiten und Test wiederholen - Entscheiden ob Tests beendet sind 15

16 Kriterien für das Beenden des Testens - Es werden keine Fehler mehr gefunden (auch nicht mit anderem Verfahren) - die Kosten übersteigen die Kosten, die durch fehlerhafte Software entstünde 16