idee coding guidelines werkzeugeinstellungen weitere...
TRANSCRIPT
Stephan Kleuker 394Software-Qualität
9. Konstruktive Qualitätssicherung
• Idee
• Coding Guidelines
• Werkzeugeinstellungen
• weitere Maßnahmen
Stephan Kleuker 395Software-Qualität
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
Stephan Kleuker 396Software-Qualität
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)
Stephan Kleuker 397Software-Qualität
Beispiel-Coding-Regel
• Ausschnitt aus „Java Code Conventions“, Sun, 1997• Inhalt soll sich nicht nur auf Formatierung beziehen
Stephan Kleuker 398Software-Qualität
Einheitliche Werkzeugeinstellungen
• Vor Projekt einheitliche Formatierung festlegen
• Styleguide für verwendete Werkzeuge
Stephan Kleuker 399Software-Qualität
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)
Stephan Kleuker 400Software-Qualität
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
Stephan Kleuker 401Software-Qualität
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
Stephan Kleuker 402Software-Qualität
10. Performance und Speicherauslastung
• Java-Parameter mit Performance-Einfluss
• Versteckte Speicherlecks
• Direkte Zeitmessung in Java
• Konzept von Performance-Messwerkzeugen
• Netbeans-Profiler
Stephan Kleuker 403Software-Qualität
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
Stephan Kleuker 404Software-Qualität
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
Stephan Kleuker 405Software-Qualität
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
Stephan Kleuker 406Software-Qualität
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);
}
}
Stephan Kleuker 407Software-Qualität
Verstecktes Speicherleck (2/3)
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
Stephan Kleuker 408Software-Qualität
Verstecktes Speicherleck (3/3)
Programm-start
Stephan Kleuker 409Software-Qualität
Java hat eigenen Profiler
• Option der JavaVM -Xprof (Ausgabe wird auch von Werkzeugen genutzt)
Stephan Kleuker 410Software-Qualität
Zeitmessung selbst gestrickt (1/9)
• Szenario: Abteilung mit mehreren Mitarbeitern• Frage nach passenden Typ für mitarbeiter
Stephan Kleuker 411Software-Qualität
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();
}
// ...
}
Stephan Kleuker 412Software-Qualität
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
Stephan Kleuker 414Software-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);
}
Stephan Kleuker 415Software-Qualität
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();
}
Stephan Kleuker 416Software-Qualität
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));
}
}
}
Stephan Kleuker 417Software-Qualität
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");
zeit = System.currentTimeMillis();
this.iterieren(abteilung);
System.out.println(" iterieren:\t"
+ (System.currentTimeMillis() - zeit) + " ms");
zeit = System.currentTimeMillis();
this.suchen(abteilung);
System.out.println(" suchen:\t"
+ (System.currentTimeMillis() - zeit) + " ms");
zeit = System.currentTimeMillis();
this.loeschen(abteilung);
System.out.println(" loeschen:\t"
+ (System.currentTimeMillis() - zeit) + " ms");
}
}
Stephan Kleuker 418Software-Qualitä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
Stephan Kleuker 419Software-Qualität
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)
Stephan Kleuker 420Software-Qualität
Beispiel: Netbeans Profiler (1/5)
Stephan Kleuker 421Software-Qualität
Beispiel: Netbeans Profiler (2/5)
siehe z. B.
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
Stephan Kleuker 423Software-Qualität
Beispiel: Netbeans Profiler (4/5) - Speicherverbauch
wichtig: auch Anzahl erzeugter Objekte analysierbar
Stephan Kleuker 424Software-Qualität
Beispiel: Netbeans Profiler (5/5) -Telemetry
auch besonders für Web-Applikationen interessant (beobachtbar)
Stephan Kleuker 425Software-Qualität
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
Stephan Kleuker 426Software-Qualität
11. Testautomatisierung
• Automatisierungsidee
• Beispiele für Werkzeuge
• Build-Server
• Idee von Build-Werkzeugen
• Einführung in Ant
• Tests aus Ant starten
Stephan Kleuker 427Software-Qualität
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)
Lines ofCode proMonat
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)
Lines ofCode proMonat
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
Stephan Kleuker 435Software-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
Stephan Kleuker 436Software-Qualität
Teststufen (grober Ablauf)
Klassentest
Integrationstest
Systemtest
Abnahmetest
entwicklungs-
intern
entwicklungs-
extern (mit Kunden)
Stephan Kleuker 437Software-Qualität
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
Stephan Kleuker 438Software-Qualitä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
Stephan Kleuker 439Software-Qualität
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
Stephan Kleuker 440Software-Qualität
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
Stephan Kleuker 441Software-Qualität
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
Stephan Kleuker 442Software-Qualität
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
Stephan Kleuker 443Software-Qualität
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
Stephan Kleuker 444Software-Qualität
Regressionstests im Entwicklungszyklus
erste Entwicklung
Test
Weiterentwicklung
Testfallentwicklung
RegressionstestfälleTestfallentwicklung
Test
Weiterentwicklung RegressionstestfälleTestfallentwicklung
Test
Version 1
Version 2
Version n
Stephan Kleuker 445Software-Qualität
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
Stephan Kleuker 446Software-Qualität
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)
Stephan Kleuker 447Software-Qualität
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
Stephan Kleuker 448Software-Qualität
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
Stephan Kleuker 450Software-Qualität
Testverfahren nach ANSI/IEEE-829
TestplanTestkonzept
Testfall-spezifikation
Testprozedur-Spezifikation
TestprotokollTestvorfalls-
berichtTestabschluss-
bericht
Testausführung
TestobjekteÜbergabebericht
Stephan Kleuker 451Software-Qualität
Dokumentation der Qualitätssicherung (Tests)
Stephan Kleuker 452Software-Qualität
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
Stephan Kleuker 453Software-Qualität
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
Stephan Kleuker 454Software-Qualität
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
Stephan Kleuker 455Software-Qualität
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
Stephan Kleuker 456Software-Qualität
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 ...
Stephan Kleuker 457Software-Qualität
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
Stephan Kleuker 458Software-Qualität
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.
Stephan Kleuker 459Software-Qualität
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
Stephan Kleuker 460Software-Qualität
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
Stephan Kleuker 461Software-Qualität
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
Stephan Kleuker 462Software-Qualität
Organisation und Rollen (2/3)
• 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
Stephan Kleuker 463Software-Qualität
Organisation und Rollen (3/3)
• 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?