Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten

Transkript

1 main {GRUPPE} Seite 1 Jürgen Nicolai Geschäftsführender Gesellschafter Liebknechtstrasse Stuttgart Tel : Fax : Mail : j.nicolai@main-gruppe.de Web: Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten Niederlassung Leipzig Reudnitzer Str Leipzig Tel : Fax: V1.0

2 Seite 2 Inhalt & Ziel Einordung und Grundlagen Begriffe und Definitionen Welcher Bereich des Software-Tests wird in diesem Vortrag angesprochen? xunit: Vor und Nachteile Ein kritischer Blick auf xunit Tests Praxis Health4J: Grundprinzipien Statische Code Analyse: Möglichkeiten und Grenzen Praxis Health4J: Wie kann der Test unterstützt werden? Wie kann Health4J bei UNIT Tests unterstützen?

3 Seite 3 Software-Testen im Schnelldurchlauf

4 Seite 4 Begriffe Software-Tests Bei der Herstellung eines Produktes wird üblicherweise kontrolliert, ob das Produkt den gestellten Anforderungen genügt. Bei der Herstellung von Software wird geprüft, ob die Software den gestellten Anforderungen genügt. Die Anforderungen an Software können vielfältig und sich widersprechend sein. Maximale Performance bei maximaler Wartbarkeit Ein nicht anforderungskonformes Verhalten wird als Fehler bezeichnet. Ein Fehler ist eine Abweichung zwischen Ist-Verhalten und Soll-Verhalten. Testen ist die Analyse und Ausführung eines Programmes mit dem Ziel, Fehler zu finden. (Angelehnt an Schneider, Abenteuer Softwarequalität, dpunkt Verlag) Der Test wird über einen Testprozess gesteuert. Der Testprozess ist reproduzierbar.

5 Seite 5 Begriffe Software-Tests Testen kann vorhandene Fehler finden, jedoch nicht die Fehlerfreiheit eines Programms belegen. Man geht in normalen Programmen von 1-7 Fehlern pro 1000 Lines Of Code (LOC) aus. Sicherheitskritische Programmen haben geringere Fehlerraten (Windows Server 2003 hat ca. 50 Mio LOC, Debian Linux hat über 50 Mio LOC, OpenOffice ca. 10 Mio. LOC ) ( Aus diesen Fehlerraten folgt, dass eine Teststrategie notwendig ist, um die Wahrscheinlichkeit zu erhöhen, die Fehler zu finden, die das größte Risiko bei der Nutzung der Anwendung darstellen (-> Risikobasiertes Testen) Testen darf nicht mit da clicken wir uns mal durch verwechselt werden. Dieses Error Guessing ist zwar eine Testmethode, führt aber nicht zu wiederholbaren Tests. Clicken ist nicht gleich testen!

6 Seite 6 Welche Arten des Tests gibt es? Software-Tests Abnahmetest Prüft, ob das System aus Kundensicht die vertraglich vereinbarten Leistungen erfüllt. Systemtest Prüft, ob das System als Ganzes die spezifizierten Anforderungen erfüllt. Integrations-Test Prüft, ob Gruppen von Komponenten wie vorgesehen zusammenarbeiten Komponententest Prüft, ob jede einzelne Komponente die Vorgaben seiner Spezifikation erfüllt. Modul oder Unit-Test Prüft, ob jedes einzelne Modul die Vorgaben seiner Spezifikation erfüllt. Ohne Definition der Anforderungen kein Test!!

7 Seite 7 Verschiedene Sichtweisen auf das System & den Test Software-Tests Abnahmetest Prüft, ob das System aus Kundensicht die vertraglich vereinbarten Leistungen erfüllt. Systemtest Prüft, ob das System als Ganzes die spezifizierten Anforderungen erfüllt. Integrations-Test Prüft, ob Gruppen von Komponenten wie vorgesehen zusammenarbeiten. Komponententest Prüft, ob jede einzelne Komponente die Vorgaben seiner Spezifikation erfüllt. Server Komponente uses Komp. 3 Komponente2 System2 Modul oder Unit-Test Prüft, ob jedes einzelne Modul die Vorgaben seiner Spezifikation erfüllt. Statische Code Analyse: Sind offensichtliche Codier-Fehler vorhanden? besteht aus Klasse 2 Module1 Klasse 1 besteht aus

8 Seite 8 Grundlegendes Vorgehen Software-Tests Test-Planung Es wird festgelegt, was getestet wird: Modul oder Oberflächen-Test? Was sind die Hauptfunktionen? Welche potentielle Fehler bergen das größte Risiko? Hauptfunktionen müssen intensiver getestet werden als Hilfsfunktionen. Risikobehaftete Funktionen müssen intensiver getestet werden. Testfälle und Testdaten werden festgelegt. Was ist das erwartete Ergebnis? Mit welchen Daten wird getestet? Wie werden die Testfälle intelligent strukturiert? Dies ist ein sehr anspruchsvolle Tätigkeit, die viel Erfahrung erfordert. Test-Durchführung Testumgebung und Testobjekt bereitstellen. Test ausführen. Testergebnis ermitteln. Test-Auswertung Testergebnis wird dem erwarteten (fachlichen und technischen) Ergebnis verglichen. Eventuell Kontrollprogramme laufen lassen, die das Testergebnis prüfen. ( ist das Ergebnis plausibel, gibt es unter Umständen false-positiv Ergebnisse?)

9 Seite 9 Modultests Software-Tests Jede Ebene des Gesamtsystems muss getestet werden. Jede Ebene durchläuft den Zyklus Planung, Durchführung, Auswertung. Bei einem Modultest werden andere Testverfahren anwendet als bei einem Abnahmetest Bei den Modultests kommen Testwerkzeuge zum Einsatz, die einen Test vollautomatisch ablaufen lassen z.b. xunit Frameworks. (x=sprache z.b. Junit, CUnit etc) JUNIT ist ein freies Testwerkzeug. Nähere Informationen unter Server Komponente uses Komp. 3 Komponente2 System2 Diese Werkzeuge arbeiten auf unterster Modul-Ebene und sind nicht für den Test von grafischen Oberflächen optimiert. Klasse 2 Module1 Klasse 1 besteht aus

10 Seite 10 xunit Test Software-Tests Die xunit-testverfahren laufen meist nicht auf der grafischen Oberfläche ab, sondern im Batch-Betrieb, oft nach einem erfolgreichen Compile-Lauf. Regressionstests (lat. Regression=Rückschritt) Unter Regressionstests versteht man die Wiederholung aller oder einer bestimmten Menge an Tests. Bei Änderungen wird geprüft, ob Funktionen, die bisher korrekt gelaufen sind, immer noch korrekt laufen. Hier ist eine Automatisierung zwingend notwendig. Die Automatisierung kann auch bereits im Code einbetten, d.h. die Testroutinen sind Teil des Codes. Findbugs, PMD Health4J JUNIT Test Diverse Testwerkzeuge Werkzeuge z.b. JUNIT Eigene Testtreiber testen die Komponenten Mit statischer Code-Analyse werden bestimmte Fehler gefunden ohne dass das Programm ausgeführt wird findet Fehler durch Source Code-und ByteCode Analyse Klasse 2 Module1 Klasse 1 besteht aus Startet das Programm und findet Fehler

11 Seite 11 Statische Code Analyse Software-Tests Statische Code Analyse Werkzeuge untersuchen den Code, ob bestimmte Regeln eingehalten werden. Der Code wird nicht ausgeführt. Fehlerhafter oder nicht sauberer Code wird dokumentiert. Tools sind: FindBugs, PMD, CheckStyle, Health4J

12 Seite 12 Test: Fazit Software-Tests Der Test des Systems sollte auf allen Ebenen erfolgen. Testen ist eine kontinuierliche Aufgabe während der Software-Entwicklung. Der Test muss geplant werden. Testen benötigt erheblichen Aufwand. ( bis zu Faktor 10 im Vergleich zum unsystematischen Test)

13 Seite 13 Test: Fazit Software-Tests Benennen Sie einen Test-Manager, der für die das Testkonzept verantwortlich ist. Er sollte mit Kompetenzen ausgestattet werden. (z.b. Nicht-Freigabe eines Releases) Schulen Sie die Projektbeteiligten im Bereich Software-Qualität. Schaffen Sie ein Problembewusstsein. Ohne Definition der Anforderungen kein Test!! Designen Sie die Software bereits so, dass sie testbar ist ( Design for Test ). Schreiben Sie zuerst die Testfälle, dann die Code Module (Testgetriebene Entwicklung) Verwenden Sie UNIT-Tests, verwenden Sie statische Code-Analyse von Beginn des Projektes an. Arbeiten Sie mit Regressions-Tests, automatisieren Sie diese Tests. Falls bei einem neuen Release alle Komponenten geändert werden, müssen Sie das Gesamtsystem komplett neu testen. Sie können Testaufwände reduzieren, indem Sie bestimmte Teile des Systems nicht ändern. Dann sind u.u. nur noch Integrations-Tests notwendig. Bei der Release Planung kann der Testaufwand bereits reduziert werden.

14 Seite 14 Kritischer Blick auf xunit Test

15 Seite 15 JUNIT Problembereiche Testabdeckung Werden die wirklich wichtigen Bereiche des Codes getestet oder nur einfach get/set Methoden? Werden neue, komplexe Methoden angemessen getestet? Der Grüne Balken sagt nichts über die Qualität der Testfälle aus (Wie wurden die Testfälle ermittelt? Zufall oder aufwändige Äquivalenzklassenmethode?) Hoher Aufwand bei komplexen Anwendungen Ablauf von tausenden JUNIT Test kann Stunden dauern Test von datengetriebenen Applikationen schwierig ( DB zurücksetzen, Testdatenbestand zurücksetzen) Großen Systeme, die parallel entwickelt werden, sind schwer zu testen Komplexe Methoden erfordern komplexen Testcode Wie können verteilte Systeme getestet werden? (z.b. SOA Architekturen)

16 Seite 16 JUNIT Problembereiche Überbewertung des grünen Balkens JUNIT testet oft auf unterster Modul-Ebene. Was ist mit Integrationstests? Abnahmetest? Lasttests? Security Tests? Welche Bedeutung hat der grüne Balken wirklich? Testmoral Oft degeneriert die Testmoral im Laufe des Projekts Wie können die Entwickler motiviert werden, auch unter Zeitdruck konsequent Tests zu schreiben?

17 Seite 17 Grundkonzepte von Health4j

18 Seite 18 Fehler im Code Motivation für Health4J Wo liegt der Fehler? 315 if (nr!= null) { 316 if (pcbneue.equals(const.false) NamePraefix.equals("") NamePraefix == null) { 317 new WarnungException( Fehler ) 318 } 322 pcontext.setflageintrag(true); 323 pcontext.setcondition(const.tt_nr); 324 }

19 Seite 19 Fehler im Code Motivation für Health4J Wo liegt der Fehler? 315 if (nr!= null) { 316 if (pcbneue.equals(const.false) NamePraefix.equals("") NamePraefix == null) { 317 new WarnungException( Fehler ) 318 } 322 pcontext.setflageintrag(true); 323 pcontext.setcondition(const.tt_nr); 324 }

20 Seite 20 Fehler im Code Motivation für Health4J Wo liegt der Fehler? 315 if (nr!= null) { 316 if (pcbneue.equals(const.false) NamePraefix.equals("") NamePraefix == null) { 317 new WarnungException( Fehler ) 318 } 322 pcontext.setflageintrag(true); 323 pcontext.setcondition(const.tt_nr); 324 } Diese Fehler könnten über JUNIT Tests oder statische Code-Analyse gefunden werden. Vorteil bei statischer Code-Analyse: Es muss kein Testcode geschrieben werden.

21 Seite 21 PMD, FindBugs & Co : State of the art Open Source Tools FindBugs PMD Checkstyle Integration in MAVEN

22 Seite 22 State of the art : Integration in HUDSON Motivation für Health4J -Tägliche Analyse über nightly build große Menge an nach Werkzeug getrennten Informationen Nach 1 Woche schaut sich die Reports keiner mehr an Fehler und Trends werden übersehen

23 Seite 23 State of the art : Integration in Eclipse Motivation für Health4J -Gute Integration in Eclipse Aber schaut der Entwickler sich das jeden Tag an? In realen Projekten werden die Fehler übersehen

24 Seite 24 State of the art : Integration in Eclipse Motivation für Health4J - Jedes Tool läuft isoliert Führt Entwickler jedes Tool jeden Tag aus? In realen Projekten eher nicht

25 Seite 25 State of the art Tools : Probleme Motivation für Health4J Integration in Eclipse: Entwickler vergisst, die Fehler anzuschauen Der Daily Build liefert zu viele Informationen Analyse der Reports ist aufwändig Keine Historisierung der Reports ( Habe ich weniger Fehler als letzte Woche? Wurden Fehler beseitigt? ) Keine Tool-übergreifende Markierung von Falschmeldungen möglich ( Ich weiß, dass das kein Fehler ist: Jedes Mal meldet sich das Tool wieder... ) Keine Rückmeldung an die Entwickler ( Ich sehe den Fehler im Report, aber wer ist für den Fehler verantwortlich? ) Ich habe bereits LinesOfCode. Wie gehe ich mit den Fehlern darin um? ( Ich habe keine Zeit all die alten Fehler raus zumachen. Mich interessieren nur die neuen Fehler ) Aufsetzen der Analyse aufwändig ( Ich brauche eine Woche, bis das rund läuft ) Reports sind für das Projekt-Management nicht verständlich ( Ich würde gerne wissen, wie es meinem Projekt geht ) Keine Analysen von UNIT Test Problemen

26 Seite 26 Health4j löst einige Probleme

27 Seite 27 Health4j: Health-Check für Ihren Code Health4j Sich selbst erhaltender Qualitäts-Kreislauf health4j Health4J

28 Seite 28 Health4J, Kern-Features Health4J kombiniert die Tools PMD, FindBugs, CheckStyle, JavaNCSS, JavaDoc, Maven JXR und aggregiert die Daten PMD findet Fehler, die FindBugs nicht findet CheckStyle analysiert JavaDoc Kommentare JavaNCSS analysiert Code-Größen Health4J kombiniert die Ergebnisse und zeigt alle komplexen Methoden an, die nicht dokumentiert sind Das Regelwerk (Rule-Set) der einzelnen Tools kann als eine Einheit behandelt werden Filter Mechanismen und ein zentrales //NOBUG Tag erlauben die zentrale Steuerung von mehreren OpenSource Tools Health4J historisiert und bewertet die Analyse-Ergebnisse

29 Seite 29 Health4j: Health-Check für Ihren Code Health4j Health4j liefert leicht verständliche Reports und historisiert diese über ein Dashboard : Live-Beispiel

30 Seite 30 Health4j: Health-Check für Ihren Code Health4j Health4j Reports sind auch für IT-Laien verständlich

31 Seite 31 Health4j: Eclipse Integration Health4j Health4j zeigt die Fehler in einer Eclipse-View an Die Fehler stammen von allen verwendeten Werkzeugen und entsprechen den Fehlern im Health4J Report

32 Seite 32 Reale Qualitäts-Verläufe, Dauer ca. 1 Jahr Health4j Ohne Qualitätskreislauf: Hinweis an Entwickler durch Projektleitung Mit Qualitätskreislauf Mit Qualitätskreislauf

33 Seite 33 Health4J unterstützt bei Test und Dokumentation Finde komplexe Methoden Erkenne komplexe Methoden Werden diese Methoden dokumentiert? Nicht trivialer Code ergibt nicht triviale Testfälle Werden komplexe Methoden über einen JUNIT Test angesprochen? Finde Abhängigkeiten Welche Auswirkungen haben Änderungen an einer Methode auf andere Klassen? Testmoral Entwickler werden zeitnah darauf hingewiesen, wenn neue komplexe Methoden nicht getestet werden

34 Seite 34 Die Details: Health4j und Test

35 Seite 35 Health4J: Die Details A) Analyse des Source Codes Finde offensichtliche Fehler und Stil-Probleme im Java Code (FindBugs, PMD, CheckStyle) Finde komplexe Methoden, ermittele zyklomatische Komplexität ( PMD) Finde nicht dokumentierte Methoden ( CheckStyle). Zeige nicht dokumentierte, komplexe Methoden Finde Source Code Änderungen und zeige sie an ( Guiffy) B) Analyse des compilierten Java Byte Codes Finde Ruft Beziehungen zwischen JAR-Moduln und Klassen ( ASM Toolkit) Finde wirkliche Code Änderungen auf ByteCode Ebene ( ASM Toolkit) Finde Ruft Beziehungen zwischen JUNIT TestCode und den zu testenden Klassen

36 Seite 36 Health4J: Die Details Kombination der Ergebnisse aus A) und B) Health4J liefert Antworten auf folgende Fragen: Welche Methoden haben sich seit dem letzten Health4J Lauf geändert? Zeige echte Code Änderungen ( ohne Kommentaränderung) Welche komplexen Methoden haben keinen passenden JUNIT Test? Welche Abhängigkeiten ( Ruft Beziehungen ) gibt es im Java Code? Welche abhängigen Klassen müssen unter Umständen neu getestet werden, wenn eine beliebige Methode f() geändert wird?

37 Seite 37 Vielen Dank für Ihre Aufmerksamkeit Quelle: