Software Tests (2) Quellcode Reviews

Transkript

1 Software Tests (2) Quellcode Reviews

2 Was ist? 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 Dynamische Tests / Testlings z.b. JUnit Tests Statische Tests / Analytische Tests z.b. Software-Messtechniken

3 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. Oberstes Ziel der industriellen Software-Entwicklung ist es, ein Software-Produkt zu erstellen, das den Qualitätszielen gerecht wird.

4 Was ist? Was ist der Software Review? Das Software-Review ist laut dem IEEE Standard (729) ein mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozess.

5 Maßnahmen im Qualitätsmanagement nach Baltzert [Bal98]: Qualität

6 In der Software-Qualitätssicherung wird zumindest zwischen folgenden zwei Qualitäts-Begriffen unterscheidet [ISO ]: Qualität

7 Qualität Interne Qualität statische Tests bzw. Analysen Analysentypen: Statische Analysen nur aufgrund des Quellcodes Dynamische Analysen aus der Beobachtung der Programmausführung

8 Qualität Statisch vs. Dynamisch? statische Tests können die dynamischen Tests nicht ersetzen beide bieten gute Ergänzung statische Tests sind gute Vorab-Tests Welche Eigenschaften? Statische Tests bzw. Analysen: statische Tests beschränken sich nicht auf Code/Programme Test (größtenteils) schon während Entwicklungsphase möglich statische Tests auch ohne Computer durchführbar vollständige Aussagen über Korrektheit und Zuverlässigkeit nicht möglich oft unterschätzte Prüfmethoden

9 Qualität Welche Ziele? Statische Tests bzw. Analysen: Fehlern und potentiellen Fehlerquellen Verstößen gegen Spezifikation/Standards Verletzung der Projektplanung... und zwar so früh wie möglich (Prävention). Weitere Unterschiedskriterien? Statische Tests bzw. Analysen: Interpretierende Analysen dienen der Ableitung von Aussagen über das Verhalten Strukturelle Analysen dienen der Aufdeckung der Struktur des Systems

10 Formaler Review Formaler Review laut IEEE? Planung Auswahl der beteiligten Personen und Besetzung der Rollen, Dokumente, Verfahren, Aufwand. Einführung / Kick-Off Verteilung der Dokumente, Erläuterung der Ziele und des Prozesses. Vorbereitung Notierung von potentiellen Fehlern, Fragen und Kommentaren, Auseinandersetzung mit Prüfling. Inspektionssitzung Diskussion und Protokollierung der Ergebnisse. Abarbeitung bzw. Überarbeitung Durchführung von Fehlerkorrekturen. Wiedervorlage bzw. Nacharbeitung Überprüfung von Korrekturen und Anfertigung der Inspektionsberichte.

11 Formaler Review Ziele bzw. Vorschriften? Ziele Steigerung von Effektivität und Effizienz der Fehlerfindung durch formal definierten Prozess Vorschriften definierte Inspektionsphasen festgelegte Ein- und Ausgangskriterien geschulte Teilnehmer mit festgelegten, verteilten Rollen explizite Dokumentation von Fehlern Vorgaben für die Vorbereitungsraten und Inspektionsgeschwindigkeit Zielvorgaben für Ergebnisse

12 Formaler Review Rollen? Manager / Projektleiter Moderator Autor Inspektoren Protokollant Leser

13 Formaler Review Vorteile bzw. Nachteile? Vorteile anwendbar auf alle Arten von formalen Dokumenten in der Softwareentwicklung leistungsfähigste manuelle und werkzeuggestützte Technik Nutzen der menschlichen Denk- und Analysefähigkeiten anwendbar auf alle Dokumente in der Softwareentwicklung kostengünstige Fehlerbeseitigung Nachteile jedoch zeitaufwendig und teuer in der Durchführung Kosten: 10%-15% vom Entwicklungsbudget Einsparung: 14%-25% bei konsequenter Anwendung werden 70% der Fehler entdeckt daher nur auf kleine bis mittlere Teilprodukte anwendbar

14 Formaler Review Konkrete Schritte? 1. Festlegung des Starts der QS Code Review Phase (zeitnah zu einem vordefinierten Meilenstein). Die Beteiligten stehen bereits fest und müssen nicht mehr identifiziert werden. Jede beteiligte Person hat eine präzise und vordefinierte Rolle. 2. Eine Reihe von automatisierten Auswertungen der aktuellen Version der Software. 3. Eine manuelle Auswertung der Software aufgrund von Warnings aus den automatisierten Auswertungen. Die Erstellung einer Zusammenfassung aller Auswertungsergebnisse in einem Dokument (z.b. Excel Tabelle). 4. Die Besprechung der oben erzielten Ergebnisse und die Zustimmung zwischen dem QS Code Reviewer und den Projektleitern. Die zugestimmten Ergebnisse (hier sind die gemeinsam abgestimmten Fehler, Warnungen, die abgearbeitet werden muss) werden z.b. in Change Synergy oder Bugzilla eingetragen. 5. Die Abarbeitung entstehender Fehler durch dem QS Code Reviewprozess. 6. Die Verfolgung des Bearbeitungsablaufsplan z.b. in Change Synergy oder Bugzilla.

15 Formaler Review Konkrete Rollen? Projektleiter des Auftragsgebers (IT und Fachbereich) Projektleiter des Auftragnehmers Technischer Ansprechpartner des Auftragnehmers (z.b. Hauptentwickler) QS Reviewer

16 Quellcode Review Ziele bzw. Eigenschaften? Ziele Aufdeckung von Fehlern und fehlerträchtigen Stellen vollständige Aussage in Bezug auf betrachtetes Kriterium kein Korrektheitsnachweis umfassende Automatisierbarkeit Eigenschaften Analyse durch Tools statt 100% menschliche Analyse- und Denkfähigkeit (vgl. Rechtschreibprüfung) Voraussetzung: Dokument hat formale Struktur (z.b. UML, XML, Sourcecode) meist Ausgabe Liste von Warnungen und Hinweisen Tool! Nutzung erfordert wenig Zeit und geringen Aufwand

17 Quellcode Review Warum? was will der Kunde damit erreichen? was verschafft sich der Kunde? warum jetzt? warum nicht für alle Projekte? welcher Hintergrund hat der Kunde?

18 Quellcode Review Stilanalyse? Vereinbaren von Programmierkonventionen semantische Konventionen (manuelle und werkzeuggestützte Prüfung) syntaktische Konventionen (werkzeuggestützte Prüfung) metrische Konventionen (werkzeuggestützte Prüfung) McCabe s cyclomatic complexity LOC lines of code Instabilität usw. Testen des Codes gegen syntaktische und metrischen Programmierkonventionen Analysieren die Trends der Qualität

19 Quellcode Review

20 Quellcode Review Best Practices CA Afferent coupling CE Efferent coupling RMI Instabitlity RMA - Abstracness RMD - Normalised Distance SIX Specialisation Index NOM Number of Methods NORM Number of overridden Methods DIT - Depth of Inheritance Tree

21 Quellcode Review Best Practices LOC Lines of Code (Methodenebene): Max 50 LOC Lines of Code (Klassenebene): Max 750 NOP Number of Parameters (Methodenebene): Max 5 NOM Number of Methods per Class: Max 20 NBD Nested Block Depth (Method Level): Max 5 VG McCabe Cyclomatic Complexity (Methodenebene): Max 10 DIT Depth of Inheritance Tree (Klassenebene): Max 6 NOC Number of Children (Klassenebene): Max 10 WMC Weigthed Methods per Class: Max 200 (VG * NOM)

22 Quellcode Review Open-Source Tools? Semantische Konventionen: Checkstyle, PMD, usw. Syntaktische Konventionen: Checkstyle, PMD, Findbugs, usw. Metrische Konventionen: Metrics, PMD, Checkstyle, Byecycle, JNCSS, usw. Trends XRADAR Checkstyle: PMD: Metrics: XRADAR: ByeCycle: Resource Standard Metrics:

23 Quellcode Review Weitere Artikels? Statischer Test - Methoden und Möglichkeiten der statischen Analyse, Matthias Böhmer, FH Münster NUI Maynooth - DYNAMIC COUPLING AND COHESION METRICS FOR JAVA PROGRAMS IBM - How the metrics of coupling can impact code quality IBM - Automate code quality analysis within Eclipse with five helpful plugins

24 Vielen Dank fürf Ihre Aufmerksamkeit!