Idee Coding Guidelines Werkzeugeinstellungen weitere...

Stephan Kleuker 394Software-Qualität

9. Konstruktive Qualitätssicherung

• Idee

• Coding Guidelines

• Werkzeugeinstellungen

• weitere Maßnahmen


Ansatz

• die analytische Qualitätssicherung greift erst, wenn ein Produkt erstellt wurde

• interessant ist der Versuch, Qualität bereits bei der Erstellung zu beachten

• typische konstruktive Qualitätsmaßnahmen sind

– Vorgabe der SW-Entwicklungsumgebung mit projekteigenem Werkzeughandbuch, was wann wie zu nutzen und zu lassen ist

– Stilvorgaben für Dokumente und Programme (sogenannte Coding-Guidelines)

• Die Frage ist, wie diese Maßnahmen überprüft werden


Coding Guidelines

• Detailliertes Beispiel: Taligent-Regeln für C++ (http://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/index.html)

• Sun hat auch Regeln für Java herausgegeben (nicht ganz so stark akzeptiert)

• z. B. Eclipse-Erweiterung Checkstyle

• Generell gibt es Regeln

– zur Kommentierung,

– zu Namen von Variablen und Objekten (z.B. Präfix-Regeln),

– zum Aufbau eines Programms (am schwierigsten zu formulieren, da die Programmarchitektur betroffen ist und es nicht für alle Aspekte „die OO-Regeln“ gibt)

http://pcroot.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/index.html


Beispiel-Coding-Regel

• Ausschnitt aus „Java Code Conventions“, Sun, 1997• Inhalt soll sich nicht nur auf Formatierung beziehen


Einheitliche Werkzeugeinstellungen

• Vor Projekt einheitliche Formatierung festlegen

• Styleguide für verwendete Werkzeuge


Fehlerfindung bei der Syntaxanalyse

In Eclipse kann „Schärfe“ der Syntaxprüfung eingestellt werden. Grundsätzlich sollte die schärfste Version eingestellt werden (solange es keinen wesentlichen Mehraufwand beim Beheben potenzieller Fehler gibt)


Anti-Pattern verbieten• Pattern dienen zur sinnvollen Strukturierung komplexer, aber

gleichartiger Systeme

• Anti-Pattern sind wiederkehrende schlechte Lösungen, die man an Strukturen erkennen kann, z. B.

– Spaghetti-Code, viele if, while und repeat-Schleifen gemischt, intensive Nutzung der Möglichkeiten mit break, früher: goto

– Cut-and-Paste-Programmierung: „was oben funktionierte, funktioniert hier auch“

– allmächtige Klassen, kennen jedes Objekt, sitzen als Spinne im Klassendiagramm, immer „gute“ Quelle für Erweiterungen

– Rucksack-Programmierung: bei vergessenem Sonderfall in allen betroffenen Methoden

if (Sonderfall){ Reaktion } else { altes Programm}

• Literatur (z. B.): W. J. Brown, R. C. Malveau, H. W. McCormick III, T. J. Mowbray, AntiPatterns, Wiley, 1998


weitere Maßnahmen

hierzu gehören einige Maßnahmen des proaktiven Risikomanagements

• Berücksichtigung von Standards

• richtiges Personal mit Erfahrungen und potenziellen Fähigkeiten finden (evtl. Coaching organisieren)

• frühzeitig Ausbildungen durchführen (niedriger Truckfaktor)

• frühzeitig passende Werkzeuge finden (Nutzungsregeln)

• Vorgehensmodell mit Reaktionsmöglichkeiten bei Problemen (generell: gelebtes flexibles Prozessmodell)

• Unabhängigkeit der Qualitätssicherung

• Erfahrungen im Anwendungsgebiet


10. Performance und Speicherauslastung

• Java-Parameter mit Performance-Einfluss

• Versteckte Speicherlecks

• Direkte Zeitmessung in Java

• Konzept von Performance-Messwerkzeugen

• Netbeans-Profiler


Typische Probleme

• Programme zur Zeit- und Speichermessung beeinflussen Laufzeit und verbrauchten Speicher

• Gerade bei Laufzeitbetrachtungen können durch langsamere Abläufe neue Effekte entstehen

• Testszenario muss in realistischer Zeit messbar sein

• generell sollten auf Testrechner wenig oder einfach bzgl. Speicher- und Rechenzeitverbrauch zu kalkulierende Programme laufen

• oftmals ist mehrmalige Messwiederholung sinnvoll

• bei Nutzung von Zufallswerten muss man Werte entweder speichern oder Versuche häufig wiederholen

• Java VM kann recht flexibel bzgl. Speicher gestartet werden; entspricht ggfls. Optimierungsaufgabe für Applikation

• man kann Strategie für Java VM Garbage Collector ändern


Parameter von java mit Performance-Einfluss

Direkte Parameter für die Java VM:

-Xbatch Disables background compilation so that compilation of all methods proceeds as a foreground task until completed.

-Xdebug Start with the debugger enabled.

-Xnoclassgc Disable class garbage collection.

-Xincgc Enable the incremental garbage collector.

-Xmsn Specify the initial size, in bytes, of the memoryallocation pool. (-Xms6144k -Xms6m)

-Xmxn Specify the maximum size, in bytes, of thememory allocation pool. (-Xmx81920k -Xmx80m)

-Xssn Set thread stack size.

http://download.oracle.com/javase/8/docs/technotes/tools/windows/java.html

http://download.oracle.com/javase/8/docs/technotes/tools/windows/java.html


Parameter von javac mit Performance-Einfluss

Direkte Parameter für den Java-Compiler:

-g Generate all debugging information, including local variables.

-verbose This includes information about each classloaded and each source file compiled.

-verbose:class Display info about each class loaded.

-verbose:gc Report on each garbage collection event.

-target version Generate class files that target a specifiedversion of the VM. (1.1 1.2 1.3 1.4 1.5 (also 5) 1.6 (also 6) …)

-Xlint Enable all recommended warnings. (Passt hier nicht hin, ist aber wichtig für QS )

http://download.oracle.com/javase/8/docs/technotes/tools/windows/javac.html

http://download.oracle.com/javase/8/docs/technotes/tools/windows/javac.html


Verstecktes Speicherleck (1/3)

package boese;

import java.io.File;

import java.io.FileWriter;

import java.io.IOException;

import java.util.ArrayList;

import java.util.List;

public class MachAuf {

public List<FileWriter> fwl = new ArrayList<FileWriter>();

public void steuern() throws IOException {

int anzahl = 0;

while (anzahl != 42) {

System.out.print("Anzahl: ");

anzahl = Eingabe.leseInt();

System.out.print("Datei: ");

oeffnen(Eingabe.leseString(), anzahl);

}

}



public void oeffnen (String name, int anzahl)

throws IOException {

for (int i = 0; i < anzahl; i++){

FileWriter fw = new FileWriter(

new File(".\\bah\\"+name + i + ".dof"));

fw.write(42);

fwl.add(fw);

}

}

public static void main(String[] arg) throws IOException {

new MachAuf().steuern();

}

}

// Verzeichnis .\bah muss vorher existieren



Programm-start


Java hat eigenen Profiler

• Option der JavaVM -Xprof (Ausgabe wird auch von Werkzeugen genutzt)


Zeitmessung selbst gestrickt (1/9)

• Szenario: Abteilung mit mehreren Mitarbeitern• Frage nach passenden Typ für mitarbeiter


Zeitmessung selbst gestrickt (2/9) - Ausschnittepublic class Mitarbeiter implements Comparable<Mitarbeiter> {

private int id;

private String vorname;

private String nachname;

private double[] aktivitaeten = new double[100];

public Mitarbeiter(int id, String vorname, String nachname) {

this.id = id;

this.vorname = vorname;

this.nachname = nachname;

for (int i = 0; i < Mitarbeiter.GROESSE; i++) {

this.aktivitaeten[i] = Math.random();

}

}

@Override

public int compareTo(Mitarbeiter other) {

return this.id - other.getId();

}

// ...

}


Zeitmessung selbst gestrickt (3/9) – Abteilung 1/2public class Abteilung {

private Set<Mitarbeiter> mitarbeiter;

public Abteilung(Set<Mitarbeiter> mitarbeiter) {

this.mitarbeiter = mitarbeiter;

}

public void einfuegen(Mitarbeiter m) {

this.mitarbeiter.add(m);

}

public Mitarbeiter suchen(int minr) { // vollstaendig

Mitarbeiter mi = null; // durchiterieren

for (Mitarbeiter m : this.mitarbeiter) {

if (m.getId() == minr) {

mi = m;

}

}

return mi;

}

Stephan Kleuker 413

Zeitmessung selbst gestrickt (4/9) – Abteilung 2/2

public boolean enthaelt(Mitarbeiter m) {

return this.mitarbeiter.contains(m);

}

public boolean loeschen(Mitarbeiter m) {

return this.mitarbeiter.remove(m);

}

}

Software-Qualität


Zeitmessung selbst gestrickt (5/9) - Testszenario

public class PerformanceAnalyse {

public static int ANZAHL = 10000;

private List<Mitarbeiter> mitarbeiter = new ArrayList<>();

private List<Integer> einfuegen = new ArrayList<>();

private List<Integer> loeschen = new ArrayList<>();

private List<Integer> suchen = new ArrayList<>();

private List<Set<Mitarbeiter>> testobjekte = new ArrayList<>();

public PerformanceAnalyse() {

this.testobjekte.add(new HashSet<>());

this.testobjekte.add(new LinkedHashSet<>());

this.testobjekte.add(new TreeSet<>());

this.testobjekte.add(new CopyOnWriteArraySet<>());

this.testobjekte.add(new ConcurrentSkipListSet<>());

for (int i = 0; i < ANZAHL; i++) {

this.mitarbeiter.add(new Mitarbeiter(i, i+ "vor", i + "nach"));

}

ArrayList<Integer> nummern = new ArrayList<>(); // 5000 Nummern

for (int i = 0; i < ANZAHL / 2; i++) {

nummern.add(i * 2);

}


Zeitmessung selbst gestrickt (6/9) - Testszenario

while (!nummern.isEmpty()) {

Integer wahl = nummern.get((int) (Math.random() * nummern.size()));

this.einfuegen.add(wahl); // 5000 einzufuegende Mitarbeiter

nummern.remove(wahl);

}

for (int i = 0; i < ANZAHL; i++) { // 10000 Nummern

nummern.add(i);

}

while (!nummern.isEmpty()) {

Integer wahl = nummern.get((int) (Math.random() * nummern.size()));

this.loeschen.add(wahl); // 10000 Mitarbeiter in zufälliger Folge

nummern.remove(wahl);

}

for (int i = 0; i < ANZAHL * 10; i++) { // 100000 zu löschende MA

this.loeschen.add(0, (int) (Math.random() * ANZAHL));

}

for (int i = 0; i < ANZAHL * 10; i++) { // 100000 MA suchen

this.suchen.add((int) (Math.random() * ANZAHL));

}

analyse();

}


Zeitmessung selbst gestrickt (7/9) - Testszenarioprivate void loeschen(Abteilung abteilung) {

for (int i : this.loeschen) {

abteilung.loeschen(this.mitarbeiter.get(i));

}

}

private void suchen(Abteilung abteilung) {

for (int i : this.suchen) {

abteilung.enthaelt(this.mitarbeiter.get(i));

}

}

private void iterieren(Abteilung abteilung) {

for (int i : this.suchen) {

abteilung.suchen(i);

}

}

private void einfuegen(Abteilung abteilung) {

for (int anz = 0; anz < ANZAHL / 100; anz++) {

for (int i : this.einfuegen) {

abteilung.einfuegen(this.mitarbeiter.get(i));

}

}

}


Zeitmessung selbst gestrickt (8/9) - Testszenariopublic void analyse() {

long zeit;

for (int i = 0; i < this.testobjekte.size(); i++) {

Set<Mitarbeiter> testobjekt = this.testobjekte.get(i);

System.out.println("Analyse von: " + testobjekt.getClass());

Abteilung abteilung = new Abteilung(testobjekt);

zeit = System.currentTimeMillis();

this.einfuegen(abteilung);

System.out.println(" einfuegen:\t"

+ (System.currentTimeMillis() - zeit) + " ms");


this.iterieren(abteilung);

System.out.println(" iterieren:\t"



this.suchen(abteilung);

System.out.println(" suchen:\t"



this.loeschen(abteilung);

System.out.println(" loeschen:\t"


}

}


Zeitmessung selbst gestrickt (9/9) - Ergebnisse

Klasse einfuegen iterieren suchen loeschen

HashSet 344 9725 62 72

338 9713 57 71

LinkedHashSet 322 5089 57 69

326 5122 67 73

TreeSet 77 9272 14 10

75 9421 15 9

CopyOnWriteArraySet 6302 4272 1883 241

6322 4224 1903 249ConcurrentSkipListSet 137 5716 26 13

133 5852 25 14in Millisekunden


Konzept von Performance-Messwerkzeugen

• ähnlich zum letzten Beispiel wird Java-Code erweitert

• java -agentlib:hprof (hprof als Beispiel)

• Erweiterungen melden Informationen an Messerwerkzeug, welches protokolliert

• Meldungen sollen erlauben, das Verhalten des Messwerkzeugs heraus zu rechnen, genauer:

– Java hat Java Virtual Machine Tool Interface (JVMTI)

– ermöglicht als Aufrufargument einen Java Agent

– Java Agent ist spezielle Klasse

• aufgerufen bevor irgendwas passiert (vor main)

• Java Agent kann Filter installieren; bekommt mit, wenn Klassen geladen werden und kann diese verändern

• http://docs.oracle.com/javase/8/docs/technotes/guides/jvmti/

• (Ansatz vergleichbar mit Aspect-opriented Programming)

http://docs.oracle.com/javase/8/docs/technotes/guides/jvmti/


Beispiel: Netbeans Profiler (1/5)


Beispiel: Netbeans Profiler (2/5)

siehe z. B.

https://www.youtube.com/watch?v=DI4EFkzqCCg

https://www.youtube.com/watch?v=DI4EFkzqCCg

Stephan Kleuker 422

Beispiel: Netbeans Profiler (3/5) - Methods

typischerweise analysiert man Zeiten selbst geschriebener Methoden; man erkennt auch, wo Zeitverbrauch gegebener Klassen

Software-Qualität


Beispiel: Netbeans Profiler (4/5) - Speicherverbauch

wichtig: auch Anzahl erzeugter Objekte analysierbar


Beispiel: Netbeans Profiler (5/5) -Telemetry

auch besonders für Web-Applikationen interessant (beobachtbar)


Zusammenfassung

• Definition des Testszenarios ist hier sehr komplexe Aufgabe

• Testergebnisse können von vielen kleinen Parametern (Objektgrößen, Systemeinstellungen) abhängen

• Kleine Änderungen können große Effekte haben

• Performance- und Speicherverbrauchsmessung oft nicht ganz exakt durchführbar

• Zentrale Frage: welche Methode wird wie oft aufgerufen und verbraucht wieviel Zeit

• Zentrale Frage: Welche Objekte verbrauchen wieviel Speicherplatz

• Werkzeugunterstützung ist vorhanden


11. Testautomatisierung

• Automatisierungsidee

• Beispiele für Werkzeuge

• Build-Server

• Idee von Build-Werkzeugen

• Einführung in Ant

• Tests aus Ant starten


Was meint hier Automatisierung

• klassische Testansätze

– Entwicklung einer Testspezifikation (Vorbedingung, Ausführung, erwartete Ergebnisse)

– manuelle Testausführung

– manuelle Erfassung und Auswertung der Testergebnisse

• erste Automatisierungsstufe

– Werkzeuge wie JUnit, Marathon erlauben die automatische Testausführung und Protokollierung (teilweise Auswertung)

– Werkzeuge müssen einzeln gestartet werden

• zweite Automatisierungsstufe

– mehrere Werkzeuge laufen nacheinander / zusammen

– Ergebnisse werden zentral protokolliert

Stephan Kleuker 428SWM, 15.11.2012

Lines ofCode proMonat

Zeit

Entwicklungs-beginn, mit einfachemProzess und Werkzeugen

kontinuierliche Analyse, ob Prozess mittelfristig erfolgreich

Verbesserungen in Prozessen,Werkzeugen und Ausbildung

schneller Einstiegin die Program-mierung

kontinuierlichesWachstum,Erweiterung des Marktsegments

verschiedene Kundenerwarten Produktvarianten

SW-Architektur fürVarianten nicht geeignet

Versuch des Refactorings(unter starkem Zeitdruck)

verlangsamte Entwicklungdurch immer aufwändigereFehlerbehebung

Fehler mit verteilten Quellen können nicht beseitigt werden (z. B. mangelnde SW-Architektur)

Entwicklungs-einstellung(oder Re-Imple-mentierung)


Zeit

ursprüngliche Produktivität

angestrebte Produktivität bei kontinuierlicher Optimierung

Produktivität ohne systematische Prozesse

Warum Automatisierung? Gefahr

Software-Qualität

Stephan Kleuker 429

Warum Automatisierung? Optimierter ProzessLines ofCode proMonat

Zeit

Entwicklungs-beginn, mit einfachemProzess und Werkzeugen

kontinuierliche Analyse, ob Prozess mittelfristig erfolgreich

Verbesserungen in Prozessen,Werkzeugen und Ausbildung

schneller Einstiegin die Program-mierung

kontinuierlichesWachstum,Erweiterung des Marktsegments

verschiedene Kundenerwarten Produktvarianten

SW-Architektur fürVarianten nicht geeignet

Versuch des Refactorings(unter starkem Zeitdruck)

verlangsamte Entwicklungdurch immer aufwändigereFehlerbehebung

Fehler mit verteilten Quellen können nicht beseitigt werden (z. B. mangelnde SW-Architektur)

Entwicklungs-einstellung(oder Re-Imple-mentierung)


Zeit

ursprüngliche Produktivität

angestrebte Produktivität bei kontinuierlicher Optimierung

Produktivität ohne systematische Prozesse

Software-Qualität

Stephan Kleuker 430

Fallstudie: Ziele der QS - Optimierung

• Konzeption und Implementierung der Automatisierung:

– Unit-Tests

– GUI-Tests

– Messung der Codeüberdeckung

– Statische Codeanalyse

– Softwaremetrik

• Integrierbarkeit in das bisherige Verfahren

Software-Qualität

Stephan Kleuker 431

Fallstudie: Werkzeugauswahl nach Analyse (1/2)

JUnit QF-Test (kommerziell)

JaCoCo Sonar

Software-Qualität

Stephan Kleuker 432

Fallstudie: Werkzeugauswahl nach Analyse (2/2)

Jenkins Sikuli (Capture & Replay)

Weitere Werkzeuge:• Ant• Hyper-V• Jython• PostgreSQL• Tomcat

Software-Qualität

Stephan Kleuker 433

Fallstudie: Überblick: Prozess und Konzept

• Sonar • QF-Test

• JaCoCo

• Sikuli

• JUnit

• JaCoCo

BuildSchnelle

Tests

Restliche Tests

Analysen

Software-Qualität

Stephan Kleuker 434

Fallstudie: Gesamtablauf

Warten auf Buildauftrag

Build

Produkt:admileo [Klassen]

[Build erfolgreich]

[Build fehlgeschlagen]

Produkte:- JUnit Ergebnisse- JaCoCo Messdaten

Unit Tests

GUI-Tests

[weitere Tests]

[Unit-Tests gescheitert]

Produkte:- GUI Test Ergebnisse- JaCoCo Messdaten

Sonar Untersuchung

Produkte:- Codeanalyse Ergebnisse- Auswertung Überdeckungsmessungen- Auswertung Testergebnisse

Benachrichtigung

[Unit-Tests OK]

[keine weiteren Tests]

Werkzeug:- Jenkins

Auslöser:- Benutzer- SVN- Event

Werkzeuge:- Ant- SVN

Werkzeug:- Jenkins

Werkzeuge:- Ant- JUnit- JaCoCo

Werkzeuge:- Ant- JaCoCo- Jenkins- QF-Test

Systeme:virtuelle Rechner

Speicherort:PostgreSQL DB Werkzeuge:

- Ant- Sonar

Software-Qualität


12. Organisation des QS-Prozesses in IT-Projekten

• Teststufen

• Regressionstest

• manuelle Prüfmethoden

• Testverfahren nach ANSI/IEEE-829

• Organisation der QS

siehe auch:

• H. M. Sneed, M. Winter, Testen objektorientierter Software, Hanser, München Wien

• A. Spillner, T. Roßner, T. Linz, Praxiswissen Softwaretest, ab 2. Auflage, dpunkt Verlag, Heidelberg


Teststufen (grober Ablauf)

Klassentest

Integrationstest

Systemtest

Abnahmetest

entwicklungs-

intern

entwicklungs-

extern (mit Kunden)


Klassentest (Modultest)

• Varianten:

– Unit-Test: einzelne Methoden und/oder Klassen

– Modultest: logisch-zusammengehörige Klassen,z.B. ein Package in Java

• Testziel: Prüfung gegen Feinspezifikation

– Architektur, Design, Programmierkonstrukte

• Testmethode: White-Box-Test

• Alle Module müssen getestet werden

– eventuell mit unterschiedlicher Intensität


Integrationstest

• Module werden zu einem System integriert und getestet

• Testziele:

– Werden Schnittstellen richtig benutzt?

– Werden Klassen bzw. ihre Methoden richtig aufgerufen?

• Konzentration auf (Export-) Schnittstellen

– Interne Schnittstellen können nicht mehr direkt beeinflusst werden

– Geringere Testtiefe als beim Modultest

– Grey-Box-Test (oder auch Black-Box)

• Techniken ähnlich wie bei Modultest

– Pfadanalyse über die komplette Interaktion der Module oft nicht mehr sinnvoll

• Mit minimaler Systemkonfiguration beginnen, Integrationsstrategie spielt eine Rolle


Systemtest

• Orientierung an den spezifizierten Systemaufgaben (z.B. Use Cases)

• Interaktion mit den (simulierten) Nachbarsystemen

• (endgültige) Validierung der nicht-funktionalenAnforderungen, z. B. Skalierbarkeit, Verfügbarkeit, Robustheit, ...

• möglichst interne Vorwegnahme des Abnahmetests


Testansätze zusammengefasst

Anwei-

sungen

Entschei-

dungen

Pfade

White-Box-Test

Methoden-/Klassentest

Gray-Box-Test

Schnittstellen

Paket/

Komponente

Integrationstest Systemtest

System

Eingaben

Ausgaben

Black-Box-Test


Testfälle und die UML

Use Case Diagramme

Komponentendiagramme

Aktivitätsdiagramme

Sequenzdiagramme

Klassendiagramme

Zustandsdiagramme

Entwicklung in der UML Testen

Systemtestfälle

Integrationstestfälle

Klassentestfälle


Regressionstest

• Änderungen an bereits freigegebenen Modulen sind notwendig

• Gibt es Auswirkungen auf die alten Testergebnisse?

• Wenn ja, welche?

• Wiederholbarkeit der Tests

• Wiederherstellung der Testdaten

• Der Testprozess muss automatisierbar sein

• Testfälle müssen gruppiert werden können, damit man sie wegen der untersuchten Funktionalität (oder auch Testdauer) gezielt einsetzen kann


Prinzip des Regressionstests

Testfalldatenbank

Referenz-

testfälle

Testfall-

ergebnisse

Software

Version n

Testfallspezifikation

Version n

Test

Software

Version n+1

Testarchivierung

der Iteration n

Regressionstest

Vergleich der

Testergebnisse


Regressionstests im Entwicklungszyklus

erste Entwicklung

Test

Weiterentwicklung

Testfallentwicklung

RegressionstestfälleTestfallentwicklung

Test

Weiterentwicklung RegressionstestfälleTestfallentwicklung

Test

Version 1

Version 2

Version n


Wartung und Testen

• Der Test ist geteilt in Änderungstest (White-Box) undRegressionstest (Black-Box)

• Änderungstest vom Entwickler, er schreibt die Testfälle fort.

• Regressionstest von unabhängiger Testgruppe mit den alten plus neuen Testfällen durchgeführt

• Testgruppe ist für Pflege und Fortschreibung der Systemtestfälle verantwortlich


Lasttest

• Geforderte Performance

– Durchsatz bzw. Transaktionsrate

– Antwortzeiten

• Skalierbarkeit

– Anzahl Endbenutzer

– Datenvolumen

– Geografische Verteilung

• Zugriffskonflikte konkurrierender Benutzer

• Entspricht dem Zeitraum nach der Inbetriebnahme

• Simulation von

– Anzahl Endbenutzer,

– Transaktionsrate , ...

– Über einen signifikanten Zeitraum (mehrere Stunden)


Manuelle Prüfmethoden berücksichtigen

• Produkte und Teilprodukte werden manuell analysiert, geprüft und begutachtet

• Ziel ist es, Fehler, Defekte, Inkonsistenzen und Unvollständigkeiten zu finden

• Die Überprüfung erfolgt in einer Gruppensitzung durch ein kleines Team mit definierten Rollen

• Jedes Mitglied des Prüfteams muss in der Prüfmethode geschult sein

• notwendigen Aufwand und benötigte Zeit einplanen

• Vorgesetzte und Zuhörer sollen an den Prüfungen nicht teilnehmen

• Inspektionen, Reviews und Walkthroughs (in abnehmender Formalität), in der Literatur ist „Reviews“ teilweise der Oberbergriff


Vor- und Nachteile manueller Prüfmethoden

+ Oft die einzige Möglichkeit, Semantik zu überprüfen+ Notwendige Ergänzung werkzeuggestützter Überprüfungen+ Die Verantwortung für die Qualität der geprüften Produkte

wird vom ganzen Team getragen+ Durch Gruppensitzung, wird die Wissensbasis der

Teilnehmer verbreitert+ Autoren bemühen sich um verständliche Ausdrucksweise,

da mehrere Personen das Produkt begutachten+ Unterschiedliche Produkte desselben Autors werden von

Prüfung zu Prüfung besser, d.h. enthalten weniger Fehler- In der Regel aufwändig (bis zu 20 Prozent der

Erstellungskosten des zu prüfenden Produkts)- Autoren geraten u.U. in psychologisch schwierige Situation

(»sitzen auf der Anklagebank«, »müssen sich verteidigen«).

Stephan Kleuker 449

Iterativ inkrementelle Werkzeugauswahl

Werkzeugmöglichkeiten evaluieren

Sinn der W-möglichkeiten verstehen

Frage ob W-möglichkeiten hohen Mehrwert liefern

Frage ob Werkzeug in W-landschaft integrierbar

Frage ob Prozessanpassung notwendig und sinnvoll

aktuelleWerkzeuge

aktuellerProzess

Werkzeug-kandidaten

aktualisierteWerkzeuge

aktualisierterProzess


Testverfahren nach ANSI/IEEE-829

TestplanTestkonzept

Testfall-spezifikation

Testprozedur-Spezifikation

TestprotokollTestvorfalls-

berichtTestabschluss-

bericht

Testausführung

TestobjekteÜbergabebericht


Dokumentation der Qualitätssicherung (Tests)


Testplanungsphase

• Festlegung der Testziele• Planung der Testaktivitäten• Gewünschte Testergebnisse• Zuweisung der Testressourcen• Übersicht über alle Kapitel eines Testplans:

· Testplan ID · Einführung · Zu testende Komponenten · Zu testende Funktionen · Nicht zu testende Funktionen · Vorgehensweise · Pass / Fail Kriterien · Produkte· Testtätigkeiten

· Testumgebung · Zuständigkeiten · Personal · Zeitplan · Risiken und

Risikomanagement · Genehmigungen


Testendekriterien

• Teil der Planung sind Angaben, wann eine Testaktivität abgeschlossen werden kann

• Beispiele:– Zweigüberdeckung >= 0.85– Methodenüberdeckung >= 0.95– Schnittstellenüberdeckung >= 0.99– Anwendungsfallüberdeckung = 1– Oberflächenüberdeckung >= 0.95– Ausnahmeüberdeckung >= 0.80

• Angaben müssen später für einzelne Testfälle herunter gebrochen werden

• Angaben können unerwünschte „Seiteneffekte“ auf Entwickler haben

• anderer Indikator: Anzahl der gefundenen Fehler pro Zeiteinheit


Testentwurfsphase

• Konzipierung der Testansätze für die verschiedenen Testarten

• Welche Tests/Testwerkzeuge sollen für welche Testart genutzt werden?

• Wie sollen die Tests aufgebaut sein, welche inhaltliche Vorgehensweise wird festgelegt?

• Wie soll die Integration getestet werden?

• Welche Umgebungsinformationen (angebundene Komponenten, zu berücksichtigende Datenformate) müssen wie in die Tests einfließen?

• Das Ergebnis ist ein Testkonzept


Testfallspezifikation

• Überlegungen, wie Komponente getestet werden soll

• Prüfung der Spezifikation durch Endanwender möglich

– alle relevanten Bereiche durch Tests abgedeckt

– Tests fachlich korrekt

• Testspezifikationen Entwicklern vorlegen, deren Anmerkungen einarbeiten

Eine Testspezifikation sollte die folgenden Abschnitte enthalten:

– Testspezifikation ID

– Zu testende Funktionen

– Testverfahren

– Testskripte und Testfälle

– Pass / Fail Kriterien


Testvorschrift• Testvorschrift enthält alle für die Durchführung des Tests

benötigten Angaben (u.a. die ausgewählten Testfälle, die zu Testsequenzen gruppiert werden)

1. Einleitung 1.1 Zweck des Tests 1.2 Testumfang 1.3 Referenzierte Unterlagen 2. Testumgebung 2.1 Überblick 2.2 Test Software/Hardware 2.3 Testdaten, Testdatenbank 2.4 Personalbedarf 3. Abnahmekriterien 3.1 Kriterien für Erfolg und

Abbruch 3.2 Kriterien für eine

Unterbrechung 3.3 Voraussetzung für

Wiederaufnahme 4. Testabschnitt 1 4.1 Einleitung

4.1.1 Zweck, Referenz zur Spezifikation

4.1.2 Getestete Software-Einheiten 4.1.3 Vorbereitungsarbeiten für

Testabschnitt 4.1.4 Aufräumarbeiten nach

Testabschnitt 4.2 Testsequenz 1-1 4.2.1 Testfall 1-1-1: Eingabe, Anweisung, Soll-- und Istausgabe, Befund 4.2.2 Testfall 1-1-2: Eingabe, Anweisung, Soll-- und Istausgabe, Befund ... 4.3 Testsequenz 1-2 4.n Ergebnis des Abschnitts 1 5. Testabschnitt 2 ...


Testaufbau

• Zur Beschreibung eines Tests gehört die eindeutige Identifizierung der Testumgebung (des Testbeds)

• Dazu muss die vollständige Konfiguration der Testumgebung festgehalten werden, damit Tests später nachvollziehbar sind

• zum Testbed, gehört der/die Rechner mit Konfiguration (Betriebssystem, weitere Software), Version der eingesetzten Testsoftware, Spezifikation der Umgebung (z.B. Datenbanken)

• typisch ist der Einsatz von Testrechnern, in größeren Projekten von Testlaboren

• aus den Rahmenbedingungen folgt, dass der Einsatz eines Testrechners für mehrere Projekte schwierig ist


Testdurchführung

• alle in Testvorschrift spezifizierten Testfälle werden ausgeführt

• alle Ergebnisse in dem Testprotokoll aufgezeichnet

• Durchführung der Tests sollte, falls keine allzu gravierenden Fehler auftreten, nicht unterbrochen werden

• Festgestellte Fehler sollten nur notiert, aber nicht behoben werden

• Das Ergebnis der Testausführung steht im Testprotokoll

– Bezeichnung Prüfling und Version

– verwendetes Testbed

– welche definierten Testfälle wurden ausgeführt

– Ergebnis der Prüfung

• Das Testprotokoll kann Testvorschrift kombiniert sein.


Testauswertung

• Testprotokoll enthält Ergebnisse der Testausführung• Ergebnisse werden mit den in der Spezifikation definierten

erwarteten Ergebnisse verglichen• Das Ergebnis der Testauswertung ist Testdokumentation:

– administrative Angaben– Verweise auf alle den Test betreffenden Dokumente– Testzusammenfassung; präzise Identifizierung des

Prüflings, des Testbeds, benutzte Testvorschrift, alle Anlagen und Teilnehmer; die Bewertung des Testteams muss von allen Teilnehmern unterschrieben sein.

– festgestellte Abweichungen; diese dienen später zur Planung und Kontrolle der Fehlerbehandlung

– Testprotokoll; Angaben, ob Ist-- und Soll--Resultate sich entsprechen; kann zusammen mit der Testvorschrift realisiert sein, muss aber das Testergebnis enthalten,

– die Schlussbewertung


Erstellung von Testdokumenten

• Der beschriebene Ansatz ist relativ formal und fordert die Erstellung vieler Dokumente

• Dieser Ansatz ist für größere Projekte (ab 6 Leute), länger laufende Projekte (mehr als ein Jahr) und Projekte deren Ergebnis langfristig gepflegt werden soll, unerlässlich

• Die Testdokumentation, die beschriebenen Tests und die Testergebnisse sollten möglichst eng in der benutzten Software-Entwicklungsumgebung verwoben sein (so können z.B. Referenzen automatisch aufdatiert werden)

• Testergebnisse sind automatisch zu verwalten, durchgeführte Tests und ihre Ergebnisse sollten möglichst automatisch in Datenbanken verwaltet werden


Organisation und Rollen (1/3)

informiert

beauftragt

Projektleiter

Teilteamleiter/Entwickler

Qualitäts-beauftragter

Chefdesigner (Querschnittsrollen)

Abteilungsleiter

Anmerkung: Q-Sicht, Qualitätssicherung nicht dem Projektleiter unterstellt



• Abteilungsleiter

– hat Gesamtverantwortung für das Projekt

– stellt Ressourcen zur Verfügung (Mitarbeiter, Budget, ...)

– kontrolliert Budget

– hält Kontakt zu den Entscheidungsträgern beim Kunden

• Projektleiter

– hat Ergebnisverantwortung für Projekt einschl. Qualität

– leitet die Teilteams und damit die Projektmitarbeiter

– verantwortlich für inhaltlichen Kontakt zum Kunden

– berichtet an den Abteilungsleiter



• Qualitätsbeauftragter

• wird vom Abteilungsleiter ernannt

• hat die Verantwortung für die QS und Durchführung von QS-Maßnahmen

• berichtet an den Abteilungsleiter und den Projektleiter über den Stand der QS

• QS-Maßnahmen sind sehr wichtige Aufgaben im Projekt

• haben konkrete Ergebnisse

• sind Grundlage für die Beurteilung des Projektfortschritts

• Drückt den “roten Knopf“, um eine Auslieferung zu stoppen

• Frage: Was spricht für, was gegeben eigene Q-Abteilung?

Idee Coding Guidelines Werkzeugeinstellungen weitere...

Documents

Transcript of Idee Coding Guidelines Werkzeugeinstellungen weitere...