Software Engineering. 12. Qualitätssicherung. Franz-Josef Elmer, Universität Basel, HS 2012

Transkript

1 Software Engineering 12. Qualitätssicherung Franz-Josef Elmer, Universität Basel, HS 2012

2 Software Engineering: 12. Qualitätssicherung 2 Qualitätssicherung Qualitätssicherung (engl. Quality Assurance QA) umfasst alle Tätigkeiten, die die Qualität der zu entwickelnden Software gewährleisten. Qualitätssicherung ist mehr als nur Testing: Es geht auch um die Qualität Qualitätsmanagement kümmert sich darum der Anforderungen der Spezifikationen der Architektur und des Design des GUI Design des Quellcodes der Dokumentation das Qualitätsstandards angewendet werden das Qualität regelmässig überprüft wird

3 Software Engineering: 12. Qualitätssicherung 3 Was ist Qualität? Einige Qualitätsmerkmale Gewichtung dieser Merkmale hängt von der Software ab Brauchbarkeit Effizienz Flexibilität Korrektheit Modularität Performanz Robustheit Testbarkeit Verständlichkeit Sicherheit Wartbarkeit Wiederverwendbarkeit Zuverlässigkeit sicherheits- oder lebenskritische Software Massenprodukt GUI Applikation oder Datenverarbeitung im Hintergrund eingebettetes System

4 Software Engineering: 12. Qualitätssicherung 4 Kann man Qualität messen? Teilweise, abhängig vom Qualitätsmerkmal: z.b. Performanz lässt sich sehr gut messen aber für Brauchbarkeit, Zuverlässigkeit und viele andere gibt es kein objektives Qualitätsmass Software Metriken: Statistiken über den Quellcode kein Mass der Codequalität geben Hinweise auf Schwachstellen im Code

5 Software Engineering: 12. Qualitätssicherung 5 Qualitätsüberprüfung Allgemeines Schema der Qualitätsüberprüfung: Artefakt produzieren /überarbeiten Qualität überprüfen [else] [gravierende Mängel festgestellt] Artefakte: Dokumente, Sourcecode und ausführbarer Code Überprüfung: Dokumente und Sourcecode: Review mit Checkliste Ausführbarer Code: Programmverifikation Testing Sourcecode und ausführbarer Code: Code Metriken statische Code Analyse

6 Software Engineering: 12. Qualitätssicherung 6 Code Review Review des Quellcodes durch einen oder mehrere Programmierer, die nicht die Autoren sind. Code Review nach Fagan (1976): Es treffen sich der Autor des Codes die Reviewers ein Moderator ein Protokollschreiber Die Rolle des Protokollschreibers kann vom Moderator übernommen werden. Minimale Zahl der Beteiligten ist 3 (Autor, Reviewer, Moderator). Mehr als 6 Personen ist Verschwendung von Zeit (und Geld) Vor dem Meeting: Moderator und Reviewers haben genügend Zeit sich den Code anzuschauen. Während des Meetings: Code wird Zeile für Zeile anhand einer Checkliste durchgegangen. Im Protokoll werden die Defekte festgehalten. Der Autor beantwortet Fragen und begründet seinen Code. Der Moderator leitet die Sitzung. Nach dem Meeting: Autor verbessert den Code.

7 Software Engineering: 12. Qualitätssicherung 7 Code Review Code Reading: Einer oder mehrere Programmierer bekommen denn Code. Ausgedruckt oder elektronisch. Jeder Programmierer liest für sich den Code und macht Anmerkungen. Mit Rotstift auf dem Papier oder als markierter Kommentar im Code. Der Autor bekommt den Code von jedem Programmierer zurück und verbessert den Code. Code Selektion für Review: Den ganzen Code zu begutachten ist in der Regel zu teuer. Selektionskriterien: Code, der oft die Quelle von Bugs ist. Sicherheitsrelevanter Code. Code, für den es schwierig ist, potentielle Fehler durch Tests zu finden. Komplexer Code (z.b. Implementierung eines Algorithmus). Code, der wichtige Kernfunktionalität abdeckt.

8 Software Engineering: 12. Qualitätssicherung 8 Code Review: Checklisten und Tools Checklisten helfen dem Reviewer beim Suchen von Schwachstellen und Defekte. Checklisten sind nie komplett. Nicht alle Punkte einer Checklisten sind für eine konkreten Review gleich wichtig: Ergänzend: Für API Code sind andere Kriterien wichtig als für ad-hoc Code. Unterstützung des Code Review durch Tools moderne IDEs erlauben schnelle Navigation und Suche Tools für statische Code Analysen Code Metriken

9 Software Engineering: 12. Qualitätssicherung 9 Code Review: Checkliste für Java 1. Lesbarkeit und Coding Standards 1. Sind die Namen von Klassen, Attribute, Methoden und Parameter sinnvoll (d.h., selbsterklärende und nicht zu lang)? 2. Ist der Code übersichtlich strukturiert? 3. Werden die Codingstandards eingehalten? 2. Kommentare 1. Kommentar sollte erläutern warum und nicht wie etwas programmiert wurde. 2. Ist komplexer Code ausreichend kommentiert? 3. Ist der Kommentar kurz und bündig? 4. Ist der Javadoc Kommentar sinnvoll für die Anwendungsprogrammierung, d.h. kann die Klasse als Black-Box benutzt werden? 5. Werden nicht offensichtliche Vor- und Nachbedingungen ausreichend kommentiert? 6. Ist die Benutzung von HMTL Code im Javadoc Kommentar korrekt und sinnvoll? 3. OO Prinzipien, Fehlerbehandlung, Codekomplexität und -korrektheit 1. Werden wichtige OO Designprinzipien eingehalten? 2. Werden mögliche Fehlerquellen erkannt und behandelt? 3. Werden Spezialfälle (null pointers, empty strings, empty arrays) korrekt behandelt? 4. Sind konstante Zahlen und Zeichenketten auch als Konstanten deklariert? 5. Sind die Methoden vom Zeilenumfang her noch überschaubar (< 50 Zeilen)? 6. Ist der Code zu komplex (z.b. zu viele Verzweigungen)? 7. Ist der Code korrekt? 8. Ist multi-threading Code thread-safe?

10 Software Engineering: 12. Qualitätssicherung 10 Bug = Software Fehler Definition: Wenn sich die Software nicht so verhält wie in den Anforderungen bzw. Spezifikationen beschrieben. Bug oder Feature? Implizite Annahmen in den Anforderungen Ungenaue Anforderungen und Spezifikationen Bug Klassifizierung nach Schweregrad. Z.B. Schwerwiegend: System oder wichtiges Teilsystem arbeitet nicht. Kritisch: Wichtige Anforderung kann nicht erfüllt werden. Normal: Anforderung kann nicht erfüllt werden, aber es gibt einen Workaround. Unbedeutend: Kleine Abweichungen von den Anforderungen, Tippfehler, GUI Layout Probleme, etc. Bug Tracking Tools (z.b. Bugzilla, Jira) Registrierung von Bugs. Jeder Bug hat einen Zustand. Suchfunktion Reporting Automatische s wenn Bug Zustand sich ändert.

11 Software Engineering: 12. Qualitätssicherung 11 Bug Lifcycle in Bugzilla

12 Software Engineering: 12. Qualitätssicherung 12 Testing und Programmverifikation Zwei Strategien zur Überprüfung der Software, ob diese die Anforderungen und die Spezifikationen erfüllt. Inputdatenraum Verifikation Tests

13 Software Engineering: 12. Qualitätssicherung 13 Testing versus Programmverifikation Tests überprüfen die Software anhand von typischen Input Daten Tests können nicht die Abwesenheit von Fehler beweisen. Sie können nur die Präsenz von Fehler aufzeigen. Grund: Tests überprüfen nur wenige Beispiele aus einer riesigen Menge von möglichen Inputs. Programmverifikation versucht mathematisch die Korrektheit des Programm zu beweisen. Voraussetzung: Mathematisch präzise Spezifikationen z.b. Interface mit math. formulierten Vor- und Nachbedingungen. Halteproblem: Verifikation nicht immer möglich. Nachteil: Grosser Aufwand Konsequenz: In der Regel Testing statt Programmverifikation

14 Software Engineering: 12. Qualitätssicherung 14 Testing Testfall (engl.: Test Case): Genaue Beschreibung eines Tests. Testfälle sollen die Menge der Eingabedaten stichprobenartig gut abdecken: typische Situationen Randsituationen fehlerhafte Eingaben Ziel: Vollständige Testabdeckung: Testing erfolgt manuell oder automatisch. Manuell: Ein Tester arbeitet den Test Case ab. Automatisch: Ein Test Programm führt den Test Case durch. Agile Softwareentwicklung: Teste oft! Jedes Detail der Anforderungen und der Spezifikationen wird durch Test Cases abgedeckt. Jedes Statement im Code wird durch mindestens einen Test Case abgedeckt. D.h. dieses Statement wird ausgeführt, wenn der Test Case abgearbeitet wird. Je öfter getestet wird, desto schneller werden Fehler gefunden kleiner sind die Konsequenzen der Fehler Voraussetzung: Automatische Tests.

15 Software Engineering: 12. Qualitätssicherung 15 Testing: Automatisch versus Manuell Automatisches Testen: Vorteile: Um Grössenordnungen schneller als manuelle Test. Jeder Zeit ausführbar zu praktisch keinen Kosten. Nachteile: Grösserer Aufwand um den Test Case zu programmieren und zu warten Wartungsaufwand durch Änderungen im Code. Manuelles Testen: Vorteile: Jeder kann testen, nicht nur Entwickler. Exploratives ad-hoc Testing, um bisher verborgene Bugs zu entdecken. Nachteile: Langsam, kostenintensiv Keine langwierigen, komplexen Tests möglich wegen Fehleranfälligkeit des menschlichen Testers.

16 Software Engineering: 12. Qualitätssicherung 16 Arten von Tests Black-Box Test Kenntnisse des Quellcodes sind nicht notwendig. White (Glass) Box Test Quellcode ist bekannt. Akzeptanz Test GUI Test Usability Test Black-Box Test zur Überprüfung der Anforderungen. Black-Box Test zur Überprüfung des Verhaltens der GUI. Test der Brauchbarkeit der Software aus Sicht des Benutzers. Unit (Modul) Test White-Box Test eines Moduls, einer Komponente oder Klasse. Regressions Test Überprüfung des Verhaltens im Vergleich zu einem früheren Verhalten, welches als korrekt eingestuft wurde.

17 Software Engineering: 12. Qualitätssicherung 17 Arten von Tests Integrations Test System Test Stress Test Überprüfung des Gesamtsystems. Performance Test Untersuchung des Systemverhaltens unter hoher Belastung. Überprüfung bzw. Messung des Resourcenverbrauchs (Speicher, CPU Zeit, etc). Sicherheits Test Überprüfung der Zusammenarbeit des (Teil)Systems mit der Umgebung. Überprüfung auf Sicherheitslücken.

18 Software Engineering: 12. Qualitätssicherung 18 GUI Test Tools Ermöglichen automatisches Testen von GUI Applikationen Fat Client (abhängig von der Programmiersprache und der benutzten Widget Bibliothek) Web (HTML) Client Typische Eigenschaften Recorder: Zeichnet Benutzeraktivitäten auf. Replay: Benutzeraktivitäten können wieder abgespielt werden. Überprüfung von Ausgaben. Eigene (Skript)Sprache für Benutzereingabe, Ablaufsteuerung und Überprüfung von Ausgaben.

19 Software Engineering: 12. Qualitätssicherung 19 Probleme bei automatischen GUI Tests Automatische GUI Tests brauchen Interaktionspunkte (IP) wie Buttons, Eingabefelder etc. GUI Testing Tools erkennen die IP nach anderen Kriterien als der Mensch: IP wird zwar erkannt ist aber nicht sichtbar. Änderung im grafischen Layout: IP wird nicht mehr erkannt. Layout Tests sind praktisch nicht möglich. Zu stark von der Umgebung abhängig (aktuelle Fonts, Farben, Grössen etc.). Soll-Ist Vergleich von Screenshots: Kleinste Änderungen führen zu detektierten Fehlern, die keine sind.

20 Software Engineering: 12. Qualitätssicherung 20 Arten der automatischen Analyse Code Metriken: Berechnung von Masszahlen, die (vielleicht) etwas über die Qualität des Codes aussagen. IEEE 1061: A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality. Verschiedene Typen von Metriken: Prozedurale Metriken Objektorientierte Metriken etc Report: Tabelle: Jede Zeile enthält alle gemessenen Metriken für eine Einheit des Codes. Granularität: Einheiten sind Module, Pakete, Klassen, Methoden, Funktionen etc. Überprüfung des Codes (engl. auditing): Aufspüren von Verstössen gegen Regeln. Kombiniert mit Code Metriken: Masszahl über- bzw. unterschreitet einen kritischen Wert. Report: Liste der Verstösse.

21 Software Engineering: 12. Qualitätssicherung 21 Einsatz automatischer Code Analysen Für die einzelnen Entwickler: Web Site mit den Reports. Integriert in IDE: Sofortige Warnung bei Regelverstössen. Für den Chefentwickler oder das Entwicklerteam: Übersicht Schnelles Auffinden von potentiellen Problemfeldern im Code. Für QA und Management: Status der aktuellen Codequalität im Projekt. Aber: Ergebnis muss korrekt interpretiert werden. Teil einer Analyse durch unabhängiger Gutachter.

22 Software Engineering: 12. Qualitätssicherung 22 Code Metriken Problem: Geeigneten Algorithmus finden, der es erlaubt aus dem (Quell-)Code eine Zahl zu berechnen, die die Qualität des Codes misst. Beispiel: Lines of Code (LOC): Zahl der Zeilen in Quellcode minus Zahl der Leerzeilen und Zeilen, die nur Kommentar enthalten. Fokus: Gesamtprojekt: Keine Qualitätsaussage möglich. Schätzung bzw. Validierung des Aufwands für Coding bzw. Testing. Voraussetzung: Erfahrung mit demselben Team, derselben Entwicklungsmethodologie und derselben Technologie. Fokus: Klasse, Methode: Hinweis auf Bad Smells grosse Klasse und lange Methode. Code Review der längsten Klassen und Methoden oder aller Klassen und Methoden für die LOC einen kritischen Wert überschreitet.

23 Software Engineering: 12. Qualitätssicherung 23 Prozedurale Metriken LOC: Lines of Code NCSS: Non-Commenting Source Statements: Zahl der Statements die keine Kommentare sind. Im Gegensatz zu LOC unabhängig von der Formatierung des Quellcodes. Beispiel: LOC: 7, NCSS: 4 /** Removes and returns the element * on the top of the stack. IllegalStateException * if the stack is empty. */ public Object pop() { if (isempty()) { throw new IllegalStateException( "Empty stack."); return _stack.remove(_stack.size()-1); Refactoring: Extract Method, Extract Class LOC: 9, NCSS: 4 /** Removes and returns the element * on the top of the stack. IllegalStateException */ public Object pop() { if (isempty()) { throw new IllegalStateException( "Empty stack."); return _stack.remove(_stack.size()-1);

24 Software Engineering: 12. Qualitätssicherung 24 Cyclomatic Complexity Number CCN: McCabe's Cyclomatic Complexity Number: Versuch, die prozedurale Komplexität einer Prozedur/Funktion/Methode zu messen. CCN = Zahl der Verzweigungen in Kontrollfluss Java: Jedes der folgenden Statements erhöht CCN um 1: if for while case catch Variante: CCN =Zahl der Verzweigungen + Zahl der Exit-Points Java: Jedes der folgendes Statements erhöht CCN auch um 1: return (auch implizites return beim Verlassen einer void Methode) throw

25 Software Engineering: 12. Qualitätssicherung 25 Cyclomatic Complexity Number: Beispiele CCN Variante in allen Beispielen LOC: 3, NCSS: 2, CCN: 1 void printhelloworld() { System.out.println("hello world"); 1: implizites return LOC: 15, NCSS: 19, CCN: 7 String[] getoperators(int[] codes) { String[] operators = new String[codes.length]; 1 for (int i = 0; i < codes.length; i++) { switch (codes[i]) { 2 case ADD: operators[i] = "add"; break; 3 case SUB: operators[i] = "sub"; break; 4 case MUL: operators[i] = "mul"; break; 5 case DIV: operators[i] = "div"; break; default: throw 6 new IllegalArgumentException( "unkown code: " + codes[i]); 7 return operators; LOC: 7, NCSS: 5, CCN: 2 void printhello(string name) { 1 if (name == null) { System.out.println("hello"); else { System.out.println("hello " + name); 2: implizites return

26 Software Engineering: 12. Qualitätssicherung 26 Cyclomatic Complexity Number Keine Aussage über Verständlichkeit des Codes Zwei Beispiele beide CCN = 9 String getoperator(int code) { switch (code) { case ADD: return "add"; case SUB: return "sub"; case MUL: return "mul"; case DIV: return "div"; default: throw new IllegalArgumentException( "unkown code: " + code); Regel: Auf alle Methoden mit CCN 10 sollte man einen Blick darauf werfen. Refactoring: Extract Method void execute(string text) { if (text == null) { throw new IllegalArgumentException( "Missing text"); StringTokenizer tokenizer = new StringTokenizer(text); while (tokenizer.hasmoretokens()) { String token = tokenizer.nexttoken(); if (token.equals(baq)) { int n = _borders.length; for (int i = 0; i < n; i++) { _borders[i].increment(); else if (token.equals(zop)) { if (_zone!= null) { _zone.reset(); else { _list.clear(); else if (_zone.isactive()) { _list.add(token);

27 Software Engineering: 12. Qualitätssicherung 27 Open Source Tools für Code Metriken CCCC: JavaNCSS: Tool in C geschrieben analysiert C, C++, Java Quellcode. Reports in XML und HTML Metriken: LOC, CCN und andere Tool in Java geschrieben analysiert Java Quellcode. Reports als Text, XML oder HTML. Metriken: NCSS, CCN und andere Für weitere Tools siehe

28 Software Engineering: 12. Qualitätssicherung 28 Classycle Open Source Tool Suite zur Analyse der Abhängigkeiten zwischen Java Klassen und Paketen: Analyser: In Java geschrieben analysiert kompilierte Java Klassen. Analyse der Klassen/Paket Abhängigkeiten. Reports in XML und HTML. Reports enthalten (unter anderem): Tabelle aller Klassen/Pakete: Grösse Zahl der Klassen/Pakete die dieses benutzen Zahl der Klassen/Pakete die von diesem benutzt werden (=CBO) Tabelle aller Zyklen (strong components) DependencyChecker: Findet unerwünschte direkte und indirekte Abhängigkeiten zwischen Klassen. Überprüft Schichtarchitektur. Regelbasiert

29 Software Engineering: 12. Qualitätssicherung 29 Classycle: Dependency Checker Überprüfung ob definierte Subgraphen voneinander direkt oder indirekt unabhängig sind. [set1] direkte Abhängigkeit [set2] indirekte Abhängigkeit Regeln (festgelegt in dependency definition files): check [set1] directlyindependentof [set2] check [set1] independetof [set2]

30 Software Engineering: 12. Qualitätssicherung 30 Classycle: Dependency Checker Überprüfung von Schichtarchitekturen: Layer C [set5] erlaubte direkte Abhängigkeit Layer B [set3] [set4] verbotene direkte Abhängigkeit bei strikter Schichtung Layer A [set1] [set2] Regeln: layer A = [set1] [set2] layer B = [set3] [set4] layer C = [set4] check layeringof A B C check strictlayeringof A B C

31 Software Engineering: 12. Qualitätssicherung 31 Links Jason Cohen: 11 proven practices for more effective, efficient peer code review