Software Tests (1) Unabhängige ngige Tests

Transkript

1 Software Tests (1) Unabhängige ngige Tests

2 Was ist? Was ist Software Qualität? DIN ISO 9126: Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Was ist Testen? G. J. Myers, 79: "Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. Hetzel 83: "Messung der Softwarequalität" Systematische Überprüfung des Verhaltens von Software im Vergleich mit ihrer Spezifikation

3 Ziele? Ziele des Testprozesses Fehler finden auch: Fehler vermeiden (B. Beizer) nicht: Fehler korrigieren (Debugger) nicht: Korrektheitsnachweis Testen hilft bei schlechtem Design auch nicht weiter. Testen hilft aber, dies frühzeitig zur erkennen. Qualität der Software zu verbessern / steigern funktionale Qualität fehlerfreie Funktionalität strukturelle Qualität Design und Codestruktur für die nahlose Weiterentwicklung bessere Kunden Akzeptanz zu erreichen und gewährleisten

4 Warum? Softwareentwicklung/Fehlerentstehung Software weist Fehler auf Starke Typisierung entdeckt/verhindert grobe Fehler (Compiler) Syntaktisch korrekter Quellcode kann trotzdem fehlerhaft sein DESHALB: Testen

5 Warum? Motivation für SW Test (Bugs Report) Wenn irgendein Teil einer Maschine falsch eingebaut werden kann, so wird sich immer jemand finden, der das auch tut. Nach dem Auseinander- und Zusammenbauen einer Vorrichtung bleiben immer einige Teile übrig. Bei einer beliebigen Berechnung wird die Zahl, deren Richtigkeit für alle offensichtlich ist, zur Fehlerquelle. Murphy's Law

6 Wie? Techniken zur Qualitätskontrolle: Spezifikation: formale Konsistenzprüfung (Dokumenten-) Review Software (bei vorliegender Spezifikation): Test (Code-) Review mathematische Verifikation Entwicklungsprozess: Qualitäts-Audit Zertifizierung

7 Psychologie Psychologie des Testens Fehlerlokalisierung als Ziel des Testens; Verhältnis zwischen Tester und Entwickler; Unabhängigkeit Testen wird eher mit dem primären Ziel des Findens von Fehlern in der getesteten Software als mit dem Ziel der Prüfung auf Korrektheit ausgeführt. Die Einstellung eines Testers unterscheidet sich von der eines Entwicklers: Entwickler -> erstrebt fehlerfreies Programm Tester -> sucht nach Fehlern im Programm Es gibt richtige und falsche Arten, Fehler an Autoren oder an das Management zu präsentieren. Die Kommunikation zwischen Tester und Entwickler ist wichtig: z.b. über Änderungen an der Applikation oder an Menüstrukturen, welche den Test beeinflussen; über Stellen, an denen der Entwickler den Code für fehlerhaft hält; bei Schwierigkeiten, einen gemeldeten Fehler zu reproduzieren.

8 Psychologie Generell wird objektives und unabhängiges Testen als effektiver angesehen. Falls der (Code-) Autor testet, überträgt er seine Annahmen auf den Test (man sieht, was man sehen will), es gibt emotionale Einflüsse und viele Autoren haben ein natürliches Interesse daran, keine Fehler zu finden. Beispiele für Stufen der Unabhängigkeit sind: Testfälle werden von Personen erstellt, welche die zu testende Software entwickeln, Testfälle werden von anderen Personen erstellt, Testfälle werden von Personen aus anderen Abteilungen erstellt, Testfälle werden von Personen aus anderen Organisationen erstellt (externe Unternehmen), Testfälle werden nicht von Personen erstellt.

9 Grundlagen Grundlagen des Testprozesses Testprozess; erfolgreiche Tests decken Fehler auf; Bedeutung von Test-Ende und Testabbruch Kriterien, Testabdeckungs-Kriterien Der grundlegende Testprozess umfasst Planung, Spezifikation, Durchführung, Aufzeichnung und Test-Bewertung & -Auswertung.

10 Planung Testplanung Der Testplan soll festlegen, wie die Teststrategie und der Projekt-Testplan für die zu testende Software Anwendung finden. Die Testplanung soll enthalten: Testumfang, Ressourcen- und Zeitplanung, Test-Ende Kriterien die Identifikation aller Ausnahmen von der Teststrategie und alle Softwarekomponenten, welche mit der getesteten Software während der Testdurchführung wechselwirken (Treiber, Platzhalter (Stubs),...).

11 Spezifikation Testspezifikation Testfälle sollen gemäß der in der Planungsphase gewählten/spezifizierten Designtechniken entworfen werden VIEL ARBEIT

12 Durchführung hrung Testdurchführung Jeder (geplante und spezifizierte) Testfall muss gemäß seiner Priorisierung ausgeführt werden. Testzyklen Vorbereitung Testfälle festlegen für jeden Testfall, Testdaten festlegen Testrahmenerstellung Durchführung Auswertung Soll-Ist-Vergleich

13 Aufzeichnung Testaufzeichnung Testaufzeichnungen für jeden Testfall sollen enthalten: eindeutige Einträge zur Identität und Version der getesteten Software, eine Referenz auf den Testfall und die Testdaten das aktuelle Ergebnis (Ausgabe, Datensätze o.ä.), Abweichungen vom erwarteten Ergebnis. Alle spezifizierten Testaktivitäten sollen die Testaufzeichnungen referenzieren. Aktuelle Ergebnisse sind mit erwarteten Ergebnissen zu vergleichen. Diesbezügliche Diskrepanzen sind aufzuzeichnen und zu analysieren, um deren Ursachen festzustellen und die Korrektur des Fehlers festzulegen. Diesbezügliche Testfälle sind als erstes zu wiederholen, um die Bereinigung des Fehlers in der Testspezifikation oder der getesteten Software zu verifizieren. Das Maß der Testabdeckung ist aufzuzeichnen anhand derjenigen Metriken, welche das Testende- Kriterium festlegen.

14 Bewertung / Auswertung Test-Bewertung & -Auswertung Testaufzeichnungen werden bzgl. des spezifizierten Testende-Kriteriums untersucht. Falls das Testende nicht erreicht ist, werden die als erstes zu wiederholenden Testaktivitäten identifiziert und der Testprozess mit diesen Tests wiederholt. Unter Umständen ist es nötig, die Spezifizierung der Tests zu wiederholen/anzupassen, um das Ziel der Testabdeckung zu erreichen. Da es das Ziel von Tests darstellt, Fehler zu entdecken, findet ein erfolgreicher Test Fehler. Dies bedeutet, ein erfolgreicher Test verzögert den Projektfortschritt. Dafür werden aber (wesentlich höhere) Folgeaufwände aufgrund dieser Fehler in späteren Projektphasen eingespart. Der auf den ersten Blick nachteilige Effekt des Tests ist also auf lange Sicht von Vorteil.

15 Wiederholung / Regression Testwiederholung und Regressionstest Fehlerlokalisierung, Fehlerbehebung und Testwiederholung, Wiederholbarkeit von Tests; Regressionstest und Automatisierung; Auswahl von Testfällen für den Regressionstest Tests sollen wiederholbar sein, um Testwiederholung und den Regressionstest zu erlauben. Nach jeder Fehlerlokalisierung und Fehlerbehebung hat die Software einer Testwiederholung unterzogen zu werden um sicherzustellen, daß die Fehlerbehebung erfolgreich war. Man hat ebenfalls die Tests bzgl. ähnlicher und verknüpfter Fehler durchzuführen. Regressionstests haben das Ziel, zu verifizieren, dass Änderungen keine unerwünschten Seiteneffekte auf unmodifizierte Teile der Software haben (Regressions-Fehler) und dass das modifizierte System weiterhin die Anforderungen erfüllt.

16 Wiederholung / Regression Der Regressionstest wird immer dann durchgeführt, wenn die Software oder die Systemumgebung geändert werden: Wiederholung der Original-Tests bei jeder neuen Softwareversion. Wird in der inkrementellen Softwareentwicklung und in der Wartungsphase angewendet. Soll sicherstellen, dass die Modifikationen das gewünschte Ergebnis bringen. Soll ebenfalls sicherstellen, dass keine unerwünschten Nebeneffekte (Seiteneffekte auf unmodifizierte Teile) aufgetreten sind. Problematik des sicheren Regressionstests: Intention: Auswahl genau der Testfälle, die eine Änderung des Programmverhaltens in der neuen Version feststellen (ideale Selektion) Ist aufgrund der Nichtentscheidbarkeit der semantischen Gleichheit nicht möglich Statt dessen Selektion aller Testfälle, die eine Änderung im Programmverhalten feststellen könnten.

17 Wiederholung / Regression Testsuiten für den Regressionstest werden viele Male durchgeführt und entwickeln sich langsam, so dass sie für die Testautomatisierung ideal sind. Unter Umständen muss der Umfang einer Testsuite reduziert werden: sich wiederholende Testfälle können entfallen, die Anzahl der Testfälle für gefundene Fehler kann reduziert werden, Testfälle können kombiniert werden, Testfälle können für periodisches Testen vorgesehen werden. Eine Untermenge der Test Suite aus dem Regressionstest kann auch für die Verifizierung von dringlichen Fehlerbehebungen herangezogen werden.

18 Kategorien Testkategorien Unterscheide Tests nach der Größe des zu testenden Bereichs: Testen einzelner Klassen oder Packages während der Entwicklung : Unit Test, Modulstest Komponenten individuell und unabhängig prüfen. relativ einfacher Umfang der Tests dafür aber sehr viele Tests Testen von Subsystemen : Integrationstest Schnittstellen der Komponenten prüfen Zusammenspiel der Komponenten prüfen Testen des gesamten Systems: Systemtest Prüfen gegen funktionale und nicht funktionale Benutzer-Anforderungen

19 Kategorien Unterscheide Tests nach den Testinhalten: Testen der Anforderungen und Spezifikationen im Requirement Test vor der Implementierung Methode: Strukturiertes Gruppengespräch Testen gegen die Anforderungen: Funktionstest in der Implementierungsphase klassisches Softwaretesten beinhaltet die oben genannten Verfahren Testen, ob das System aus Kundensicht fertig ist: Abnahmetest Test des gesamten Systems mit echten Daten des Kunden Testen nicht nur Funktion, sondern auch Performance, Lastverhalten, Benutzerfreundlichkeit usw.

20 Kategorien Zeitliche Abfolge Requirement Test Funktionstest mit unterschiedlicher Reichweite: Unit Test, Modultest Integrationstest Systemtest Abnahmetest - Systemtest Strategien für den Integrationstest Nicht-inkrementell: Big-Bang Geschäftsprozess-orientiert Inkrementell: Aufsteigend (bottom-up) Absteigend (top-down) Nach Verfügbarkeit

21 Kategorien Statisches Testen Strukturierte Gruppenprüfung, Review, Statische Analyse, Strukturelle Analyse Synonyme: manueller Test, manuelle Prüfung Im Allgemeinen keine Testdaten keine Ausführung des Codes durch Personen oder Werkzeuge

22 Kategorien Dynamisches Testen Man testet die Software durch Ausprobieren und benötigt Testfälle zur Ausführung der Testläufe Alle (theoretisch) möglichen Eingaben Sinnvolle Auswahl Wesentlich ist die systematische Erzeugung von Testfällen Ziel des dynamischen Testens Nachweis der Erfüllung der festgelegten Anforderungen Aufdecken von Abweichungen und Fehlerwirkungen Minimierung des Aufwands zum Testen durch systematische Erstellung von Testfällen Methodik In den unteren Teststufen (meist) ein Testrahmen notwendig, da ablauffähiges Programm (noch) nicht erstellt ist Das aufrufende Programm (Client-Klasse) wird evtl. durch einen Testtreiber simuliert. Weitere Programmteile (Server-Klassen) müssen evtl. durch Platzhalter (Stubs) simuliert werden.

23 Methodik Methodik der Testfallermittlung Unterschiedliche Verfahren: White Box Methoden für strukturelle Tests sind die codebasierten Teste Black Box Methoden für funktionale Tests sind die API basierten Teste Gray Box Methoden für funktionale und strukturelle Tests eine Mischung zwischen den White & Black Box Verfahren.

24 Methodik White Box Testmethoden Strukturelles Testen findet mit Kenntnis des zu testenden Programms und dessen (Kontroll-) Struktur statt, was zur Definition von Testkriterien und zur Auswahl von Testfällen genutzt wird. Die Testfallableitung beim White-Box Test orientiert sich an der Idee, möglichst viele Programmteile durch die Menge an Testfällen abzudecken, d.h. auszuführen. Die Struktur des Programmes wird berücksichtigt Verwandtschaft mit der Beweismethodik Testen gegen die Implementierung

25 Methodik Definition von Testkriterien: kontrollflussabhängig (z. B. Ausführung aller Programmanweisungen) Anweisungsüberdeckung Zweigüberdeckung Bedingungsüberdeckung Pfadüberdeckung datenflussabhängig (z. B. Benutzung von Variablen, Grenzwerte, Einhaltung von Feldgrenzen) Codebasierte Testverfahren werden vornehmlich im Komponententest verwendet. Wichtige Werkzeuge zur Unterstützung von automatisierten Komponententests sind Frameworks wie JUnit, CppUnit, DbUnit usw.. Diese Open Source Frameworks übernehmen die Funktion des Testtreibers für das Module im Test (MUT).

26 Methodik Black Box Testmethoden Funktionales Testen wird ohne Kenntnis des zu testenden Programms bzw. dessen Struktur durchgeführt. Der Tester kennt nicht die innere Struktur und Funktionalität des Testobjektes. Testfälle können nur anhand extern sichtbarer Schnittstellen und der Spezifikation des Testobjekts abgeleitet werden. Testen des Ein-/Ausgabeverhaltens ohne Berücksichtigung der inneren Programmstruktur. Ermittlung der Testfälle aus der Spezifikation (Testen gegen die Anforderungen) Ziel ist eine möglichst umfassende Prüfung der spezifizierten Funktionalität. Wichtige Methoden: Äquivalenzklassenbildung, Grenzwertanalyse, Zustandsbezogener Test Intuitives Testen

27 Methodik OO Tests Probleme der Testbarkeit objekt-orientierter Programme: Strukturelle Merkmale Verkapselung - erschwert die Testauswertung. Vererbung Polymorphismus Dynamische Merkmale Zustand Identität

28 Management Test Management Zusammenfassung Entwicklungs- und Testaktivitäten sollen organisatorisch getrennt sein. Je klarer diese Trennung, umso wirksamer kann getestet werden. Je nach Aufgabenstellung innerhalb des Testprozesses werden Mitarbeiter mit rollenspezifischen Testkenntnissen benötigt. Neben fachlichen Fähigkeiten ist auch soziale Kompetenz gefragt. Zu den Aufgaben des Testmanagers gehören Planung, Überwachung und Steuerung der einzelnen Testzyklen. Fehlermanagement und Konfigurationsmanagement bilden die Basis für einen effizienten Testprozess. Fehlermeldungen müssen nach einem projektweit einheitlichen Schema erfasst und über alle Stadien des Fehleranalyse- und Korrekturprozesses verfolgt werden.

29 Management Normen und Standards enthalten Vorgaben und Empfehlungen zur fachgerechten Durchführung von Softwaretests. Eine Orientierung an solchen Standards macht auch dort Sinn, wo deren Einhaltung nicht verpflichtend vorgeschrieben ist.

30 Unabhängigkeit ngigkeit Unabhängigkeit Die Unabhängigkeit der Tests ist von zwei verschiedenen Sichten betrachtet: aus der Sicht einer Einheit/Klasse/Funktion, die getestet muss (Funktionstest) aus der Sicht eines Prozessteils (mehrere Klassen, die in Zusammenhang stehen und dadurch einen Teil oder einen gesamten Prozess abbildet) (Fachtest) Die Unabhängigkeit der Tests gegen das Umfeld bezieht sich auf die Testdaten, integrierte Fremdsystemen / externe Schnittstellen.

31 Unabhängigkeit ngigkeit Warum Unabhängigtests? Ein Unit Test soll eine Klasse, oder ein Objekt oder sogar Gruppe von Klassen und Objekten in Isolation testen. Probleme: Programmeinheiten arbeiten nicht isoliert Aufbau der Testumgebung sehr aufwendig Testen von Ausnahmesituationen Langsame Tests bei Überschreitung der Systemgrenzen

32 Unabhängigkeit ngigkeit Lösung: Für das Testen ist es wichtig, für jede Komponente lokale und unabhängige Tests zu erstellen. Ein Weg, um dem Ziel unabhängiger Tests näher zu kommen, führt über Dummy-, Stub- und Mock- Objekte. Dabei handelt es sich um "Objektattrappen", welche für die Dauer eines Tests die echten Objekte ersetzen. Herausforderungen: Schnittstellen für Akzeptanztests zu identifizieren

33 Unabhängigkeit ngigkeit Die allgemeine Softwarearchitektur Asynch. Schnittstellen LIB System Under Test (SUT) DB Schnittstellen Services

34 Unabhängigkeit ngigkeit Testevolution (Automatisierung der Testen) Start Test JUnit Test Testklasse für eine Klasse Eine Klasse Test Ergebnis Ziel: Entkopplung der Testdaten und der Logik von der Logik und Tests eines SUTs Testdaten JUnit Test Start Test Testklasse für eine Klasse Eine Klasse Test Ergebnis Testdaten Ziel: Discover, Match & Start der Test Patterns & Suites XML

35 Vielen Dank für f Ihre Aufmerksamkeit!