9. Konstruktive Qualitätssicherung

9. Konstruktive Qualitätssicherung
•
•
•
•
Idee
Coding Guidelines
Werkzeugeinstellungen
weitere Maßnahmen
Software-Qualität
Stephan Kleuker
394
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
Software-Qualität
Stephan Kleuker
395
Coding Guidelines
• Detailliertes Beispiel: Taligent-Regeln für C++
(http://root.cern.ch/TaligentDocs/TaligentOnline/Document
Root/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äfixRegeln),
– zum Aufbau eines Programms (am schwierigsten zu
formulieren, da die Programmarchitektur betroffen ist
und es nicht für alle Aspekte „die OO-Regeln“ gibt)
Software-Qualität
Stephan Kleuker
396
Beispiel-Coding-Regel
• Ausschnitt aus „Java Code Conventions“, Sun, 1997
• Inhalt soll sich nicht nur auf Formatierung beziehen
Software-Qualität
Stephan Kleuker
397
Einheitliche Werkzeugeinstellungen
• Vor Projekt einheitliche Formatierung festlegen
• Styleguide für verwendete Werkzeuge
Software-Qualität
Stephan Kleuker
398
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)
Software-Qualität
Stephan Kleuker
399
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
Software-Qualität
Stephan Kleuker
400
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
Software-Qualität
Stephan Kleuker
401
10. Performance und Speicherauslastung
•
•
•
•
•
Java-Parameter mit Performance-Einfluss
Versteckte Speicherlecks
Direkte Zeitmessung in Java
Konzept von Performance-Messwerkzeugen
Netbeans-Profiler
Software-Qualität
Stephan Kleuker
402
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
Software-Qualität
Stephan Kleuker
403
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 memory
allocation pool. (-Xms6144k -Xms6m)
-Xmxn
Specify the maximum size, in bytes, of the
memory allocation pool. (-Xmx81920k -Xmx80m)
-Xssn
Set thread stack size.
http://download.oracle.com/javase/8/docs/technotes/tools/w
indows/java.html
Software-Qualität
Stephan Kleuker
404
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 class
loaded 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 specified
version 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/win
dows/javac.html
Software-Qualität
Stephan Kleuker
405
Verstecktes Speicherleck (1/3)
package boese;
import
import
import
import
import
java.io.File;
java.io.FileWriter;
java.io.IOException;
java.util.ArrayList;
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
} Software-Qualität
406
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
Software-Qualität
Stephan Kleuker
407
Verstecktes Speicherleck (3/3)
Programmstart
Software-Qualität
Stephan Kleuker
408
Java hat eigenen Profiler
• Option der JavaVM -Xprof (Ausgabe wird auch von
Werkzeugen genutzt)
Software-Qualität
Stephan Kleuker
409
Zeitmessung selbst gestrickt (1/9)
• Szenario: Abteilung mit mehreren Mitarbeitern
• Frage nach passenden Typ für mitarbeiter
Software-Qualität
Stephan Kleuker
410
Zeitmessung selbst gestrickt (2/9) - Ausschnitte
public 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
// ...Software-Qualität
}
411
Zeitmessung selbst gestrickt (3/9) – Abteilung 1/2
public 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;
Software-Qualität
Stephan Kleuker
}
412
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
413
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
} Software-Qualität
414
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();
Software-Qualität
Stephan Kleuker
415
Zeitmessung selbst gestrickt (7/9) - Testszenario
private 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));
}
} Software-Qualität
Stephan Kleuker
}
416
Zeitmessung selbst gestrickt (8/9) - Testszenario
public 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");
} Software-Qualität
Stephan Kleuker
}
417
Zeitmessung selbst gestrickt (9/9) - Ergebnisse
Klasse
HashSet
LinkedHashSet
TreeSet
CopyOnWriteArraySet
ConcurrentSkipListSet
einfuegen iterieren
suchen
loeschen
344
338
322
9725
9713
5089
62
57
57
72
71
69
326
77
75
5122
9272
9421
67
14
15
73
10
9
6302
6322
137
4272
4224
5716
1883
1903
26
241
249
13
133
5852
25
14
in Millisekunden
Software-Qualität
Stephan Kleuker
418
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)
Software-Qualität
Stephan Kleuker
419
Beispiel: Netbeans Profiler (1/5)
Software-Qualität
Stephan Kleuker
420
Beispiel: Netbeans Profiler (2/5)
siehe z. B.
https://www.youtube.com/watch?v=
DI4EFkzqCCg
Software-Qualität
Stephan Kleuker
421
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
422
Beispiel: Netbeans Profiler (4/5) - Speicherverbauch
wichtig: auch Anzahl erzeugter Objekte analysierbar
Software-Qualität
Stephan Kleuker
423
Beispiel: Netbeans Profiler (5/5) -Telemetry
auch besonders für Web-Applikationen interessant (beobachtbar)
Software-Qualität
Stephan Kleuker
424
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
Software-Qualität
Stephan Kleuker
425
11. Testautomatisierung
•
•
•
•
•
•
Automatisierungsidee
Beispiele für Werkzeuge
Build-Server
Idee von Build-Werkzeugen
Einführung in Ant
Tests aus Ant starten
Software-Qualität
Stephan Kleuker
426
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
Software-Qualität
Stephan Kleuker
427
Warum Automatisierung? Gefahr
Lines of
Code pro
Monat
schneller
Einstieg
in die
Programmierung
kontinuierliches
Wachstum,
Erweiterung
des Marktsegments
Produktivität ohne
systematische Prozesse
verschiedene Kunden
erwarten Produktvarianten
SW-Architektur für
Varianten nicht geeignet
verlangsamte
Entwicklung
durch immer
aufwändigere
Fehlerbehebung
Versuch des Refactorings
(unter starkem Zeitdruck)
SWM, 15.11.2012
Software-Qualität
Stephan Kleuker
Fehler mit verteilten
Quellen können
nicht beseitigt
werden (z. B.
mangelnde
SW-Architektur)
Entwicklungseinstellung
(oder Re-Implementierung)
Zeit
428
Warum Automatisierung? Optimierter Prozess
Lines of
Code pro
Monat
Zeit
angestrebte Produktivität bei
kontinuierlicher Optimierung
kontinuierliche Analyse, ob
Prozess mittelfristig erfolgreich
Entwicklungsbeginn, mit
einfachem
Prozess und
Werkzeugen
Verbesserungen in Prozessen,
Werkzeugen und Ausbildung
ursprüngliche
Produktivität
Zeit
Software-Qualität
Stephan Kleuker
429
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
430
Fallstudie: Werkzeugauswahl nach Analyse (1/2)
JUnit
QF-Test (kommerziell)
JaCoCo
Sonar
Software-Qualität
Stephan Kleuker
431
Fallstudie: Werkzeugauswahl nach Analyse (2/2)
Jenkins
Sikuli (Capture & Replay)
Weitere Werkzeuge:
• Ant
• Hyper-V
• Jython
• PostgreSQL
• Tomcat
Software-Qualität
Stephan Kleuker
432
Fallstudie: Überblick: Prozess und Konzept
• JUnit
• JaCoCo
Build
Schnelle
Tests
Analysen
Restliche
Tests
• Sonar
Software-Qualität
• QF-Test
• JaCoCo
• Sikuli
Stephan Kleuker
433
Fallstudie: Gesamtablauf
Benachrichtigung
Werkzeug:
- Jenkins
Auslöser:
- Benutzer
- SVN
- Event
Warten auf Buildauftrag
Produkte:
- Codeanalyse Ergebnisse
- Auswertung Überdeckungsmessungen
- Auswertung Testergebnisse
Werkzeug:
- Jenkins
Speicherort:
PostgreSQL DB
Build
Werkzeuge:
- Ant
- SVN
Sonar Untersuchung
Werkzeuge:
- Ant
- Sonar
[Build fehlgeschlagen]
[keine weiteren Tests]
[Build erfolgreich]
Produkte:
- GUI Test Ergebnisse
- JaCoCo Messdaten
[Unit-Tests gescheitert]
Produkt:
admileo
[Klassen]
Werkzeuge:
- Ant
- JUnit
- JaCoCo
Unit Tests
Software-Qualität
GUI-Tests
Produkte:
- JUnit Ergebnisse
- JaCoCo Messdaten
[Unit-Tests OK]
Stephan Kleuker
[weitere Tests]
Systeme:
virtuelle Rechner
Werkzeuge:
- Ant
- JaCoCo
- Jenkins
- QF-Test
434
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
Software-Qualität
Stephan Kleuker
435
Teststufen (grober Ablauf)
Klassentest
entwicklungsintern
Integrationstest
Systemtest
entwicklungsextern (mit Kunden)
Software-Qualität
Abnahmetest
Stephan Kleuker
436
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
Software-Qualität
Stephan Kleuker
437
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
Software-Qualität
Stephan Kleuker
438
Systemtest
• Orientierung an den spezifizierten Systemaufgaben (z.B. Use
Cases)
• Interaktion mit den (simulierten) Nachbarsystemen
• (endgültige) Validierung der nicht-funktionalen
Anforderungen, z. B. Skalierbarkeit, Verfügbarkeit,
Robustheit, ...
• möglichst interne Vorwegnahme des Abnahmetests
Software-Qualität
Stephan Kleuker
439
Testansätze zusammengefasst
White-Box-Test
Anweisungen
Entscheidungen
Pfade
Gray-Box-Test
Black-Box-Test
Paket/
Komponente
Eingaben
Schnittstellen
System
Ausgaben
Methoden-/Klassentest
Integrationstest
Software-Qualität
Stephan Kleuker
Systemtest
440
Testfälle und die UML
Entwicklung in der UML
Testen
Use Case Diagramme
Systemtestfälle
Aktivitätsdiagramme
Komponentendiagramme
Integrationstestfälle
Sequenzdiagramme
Klassentestfälle
Klassendiagramme
Zustandsdiagramme
Software-Qualität
Stephan Kleuker
441
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
Software-Qualität
Stephan Kleuker
442
Prinzip des Regressionstests
Software
Version n
Testfallspezifikation
Version n
Test
Testarchivierung
der Iteration n
Referenztestfälle
Testfallergebnisse
Software
Version n+1
Regressionstest
Testfalldatenbank
Vergleich der
Testergebnisse
Software-Qualität
Stephan Kleuker
443
Regressionstests im Entwicklungszyklus
Testfallentwicklung
erste Entwicklung
Version 1
Test
Testfallentwicklung
Weiterentwicklung
Test
Testfallentwicklung
Weiterentwicklung
Test
Software-Qualität
Stephan Kleuker
Regressionstestfälle
Version 2
Regressionstestfälle
Version n
444
Wartung und Testen
• Der Test ist geteilt in Änderungstest (White-Box) und
Regressionstest (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
Software-Qualität
Stephan Kleuker
445
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)
Software-Qualität
Stephan Kleuker
446
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
Software-Qualität
Stephan Kleuker
447
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«).
Software-Qualität
Stephan Kleuker
448
Iterativ inkrementelle Werkzeugauswahl
Werkzeugmöglichkeiten evaluieren
aktuelle
Werkzeuge
aktueller
Prozess
Sinn der W-möglichkeiten verstehen
Frage ob W-möglichkeiten hohen
Mehrwert liefern
Frage ob Werkzeug in Wlandschaft integrierbar
Werkzeugkandidaten
aktualisierte
Werkzeuge
aktualisierter
Prozess
Frage ob Prozessanpassung
notwendig und sinnvoll
Stephan Kleuker
449
Testverfahren nach ANSI/IEEE-829
Testplan
Testkonzept
Testfallspezifikation
TestprozedurSpezifikation
Testobjekte
Übergabebericht
Testausführung
Testprotokoll
Testvorfallsbericht
Testabschlussbericht
Software-Qualität
Stephan Kleuker
450
Dokumentation der Qualitätssicherung (Tests)
Software-Qualität
Stephan Kleuker
451
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
Software-Qualität
·
·
·
·
·
·
Stephan Kleuker
Testumgebung
Zuständigkeiten
Personal
Zeitplan
Risiken und
Risikomanagement
Genehmigungen
452
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
Software-Qualität
Stephan Kleuker
453
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
Software-Qualität
Stephan Kleuker
454
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
Software-Qualität
Stephan Kleuker
455
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
Software-Qualität
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
456
...
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
Software-Qualität
Stephan Kleuker
457
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.
Software-Qualität
Stephan Kleuker
458
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
Software-Qualität
Stephan Kleuker
459
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
Software-Qualität
Stephan Kleuker
460
Organisation und Rollen (1/3)
Abteilungsleiter
Qualitätsbeauftragter
informiert
beauftragt
Software-Qualität
Projektleiter
Teilteamleiter/
Entwickler
Chefdesigner
(Querschnittsrollen)
Anmerkung: Q-Sicht, Qualitätssicherung
nicht dem Projektleiter unterstellt
Stephan Kleuker
461
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
Software-Qualität
Stephan Kleuker
462
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?
Software-Qualität
Stephan Kleuker
463