Upload
lamduong
View
212
Download
0
Embed Size (px)
Citation preview
Stephan Kleuker 234
Variante: Klassen zur Browsersteuerung (1/2)
public class GoogleTest {
private WebDriver driver; // (auch Selenium)
public GoogleTest() {}
@Beforepublic void setUp() {//Erzeugt neue Instanz des Browser Treibers//driver = new FirefoxDriver();driver = new InternetExplorerDriver();//driver = new HtmlUnitDriver();//driver = new ChromeDriver();
}
@Afterpublic void tearDown() {//beendet Browserdriver.quit();
}Software-Qualität
Stephan Kleuker 235
Variante: Klassen zur Browsersteuerung (2/2)
@Testpublic void testGoogle1() {
//google aufrufen. "http://" nicht vergessendriver.get("http://www.google.de/");//findet das Eingabefeld fuer SuchbegriffeWebElement element = driver.findElement(By.name("q"));//gibt Suchbegriff "Selenium" ein und bestätigtelement.sendKeys("Selenium");element.submit();
// statt "submit" auf "Google-Suche" button zu clicken:// element = driver.findElement(By.name("btnG"));// element.click();
//Gibt Seitentitel auf Konsole aus//Ueberprueft ob die Seite "Google" im Titel enthaeltAssert.assertTrue(driver.getTitle().contains("Google"));
}} Software-Qualität
Stephan Kleuker 236Software-Qualität
Grenzen typischer Capture & Replay - Werkzeuge
• Aufzeichnungsprobleme möglich, da nicht alle Events sauber erkannt werden (zu viele, Pixelangabe ungenau)
• Gerade bei unterschiedlichen Web-Browsern kann es durch wenige Pixel zu Bedienproblemen kommen
• Reaktionszeiten von GUIs müssen beachtet werden
• Die Prüfung, ob Texte vollständig angezeigt werden, oder sich GUI-Elemente teilweise überlappen, ist oft nicht möglich
• Innovative, jetzt noch unbekannte Bedienelemente (z. B. Multi-Touch) werden meist noch nicht unterstützt
• Generell: Automatische Prüfung der Software-Ergonomie nicht möglich (-> Usability-Tests)
Stephan Kleuker 237Software-Qualität
Fazit
• GUI-Tests sind generell möglich
• GUI-Tests erst planen, wenn GUI relativ festgelegt ist
• Werkzeuge kritisch evaluieren, ob sie für Projekt bzw. typische Unternehmensaufgaben geeignet sind
• freie GUI-Werkzeuge können auf jeden Fall Einstieg in GUI-Testansätze sein
• Evaluation von kommerziellen Werkzeugen in diesem Bereich oft sinnvoll
• generell wird Teststrategie benötigt, was wann getestet wird (botton up, top down, middle out)
Stephan Kleuker 238Software-Qualität
7. Performance und Speicherauslastung
• Java-Parameter mit Performance-Einfluss
• Versteckte Speicherlecks
• Direkte Zeitmessung in Java
• Konzept von Performance-Messwerkzeugen
• Netbeans-Profiler
Stephan Kleuker 239Software-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 240Software-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 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/6/docs/technotes/tools/windows/java.html
Stephan Kleuker 241Software-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 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) and 1.6 (also 6))
-Xlint Enable all recommended warnings. (Passt hier nicht hin, ist aber wichtig für QS ☺)
http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html
Stephan Kleuker 242Software-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 243Software-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();}
}
Stephan Kleuker 245Software-Qualität
Java hat eigenen Profiler
• Option der JavaVM -Xprof (Ausgabe wird auch von Werkzeugen genutzt)
Stephan Kleuker 246Software-Qualität
Zeitmessung selbst gestrickt (1/6)
• Szenario: Abteilung mit mehreren Projekten, Projekte mit mehreren Mitarbeitern
• Frage nach passendem Typ für projekte, mitarbeiter
Stephan Kleuker 247Software-Qualität
Zeitmessung selbst gestrickt (2/6) - Ausschnitte
public class Abteilung extends Orgeinheit {
// hier verschiedene Set-Implementierungen testbar
// analog auch in Projekt
private Set<Projekt> projekte = new HashSet<Projekt>();
public List<String> mitarbeiterInProjekten(int nr){
List<String> ergebnis = new ArrayList<String>();
for(Projekt p:projekte)
if(p.suchenBeiNr(nr)!=null)
ergebnis.add(p.getName());
return ergebnis;
}
// ...
}
Stephan Kleuker 248Software-Qualität
Zeitmessung selbst gestrickt (3/6) - Ausschnitte
public class Projekt extends Orgeinheit{
private Set<Mitarbeiter> mitarbeiter
= new HashSet<Mitarbeiter>();
public Mitarbeiter suchenBeiNr(int nr){
for(Mitarbeiter m:mitarbeiter)
if(m.getNr()==nr)
return m;
return null;
}
public class Mitarbeiter extends Orgeinheit { ... }
Stephan Kleuker 249Software-Qualität
Zeitmessung selbst gestrickt (4/6) - Testszenario
public Lastdaten() {int anzahl=10000;long vorher = System.currentTimeMillis();long summe = 0;long gestoppt;
List<Mitarbeiter> m = new ArrayList<Mitarbeiter>();List<Projekt> p = new ArrayList<Projekt>();List<Abteilung> a = new ArrayList<Abteilung>();for (int i = 0; i < anzahl; i++)m.add(new Mitarbeiter(new Date().toString()));
for (int i = 0; i < anzahl/10; i++) {Projekt pr = new Projekt(new Date().toString());for (int j = 0; j < anzahl/100; j++)pr.mitarbeiterHinzu(m.get((int) (m.size()* Math.random())));p.add(pr);
} for (int i = 0; i < anzahl/100; i++) {Abteilung ab = new Abteilung(new Date().toString());for (int j = 0; j < anzahl/1000; j++)ab.projektHinzu(p.get((int) (p.size() * Math.random())));a.add(ab);
}
Stephan Kleuker 250Software-Qualität
Zeitmessung selbst gestrickt (5/6) - Testszenario
gestoppt=System.currentTimeMillis();summe +=(gestoppt-vorher);System.out.println("verbraucht erstellen: "+(gestoppt - vorher));vorher = System.currentTimeMillis();
for(int i=0;i<anzahl;i++)for(Abteilung ab:a)ab.mitarbeiterInProjekten(i);
gestoppt=System.currentTimeMillis();summe +=(gestoppt-vorher);System.out.println("verbraucht auslesen: "+(gestoppt - vorher));vorher = System.currentTimeMillis();
for(int i=0;i<anzahl;i++)for(Abteilung ab:a)ab.mitarbeiterEntfernen(i);
gestoppt=System.currentTimeMillis();summe +=(gestoppt-vorher);System.out.println("verbraucht loeschen: "+(gestoppt - vorher));System.out.println("gesamt verbraucht: " + summe);}
Stephan Kleuker 251Software-Qualität
Zeitmessung selbst gestrickt (6/6) - Ergebnisse
Klasse erstellen auslesen löschen gesamt
HashSet 170 37088 23664 60922
174 36925 23503 60602
LinkedHashSet 181 26444 14161 40786
180 24870 13478 38528
CopyOnWriteArraySet 230 15396 14252 29878
224 15253 14033 29510
private Set<Projekt> projekte = new Klasse<Projekt>();
private Set<Mitarbeiter> mitarbeiter
= new Klasse<Mitarbeiter>();
Stephan Kleuker 252Software-Qualität
Variante (1/2)
• Objekte werden sortierbar:public class Orgeinheit implements Comparable<Orgeinheit>{
@Override
public int compareTo(Orgeinheit o) {
return nr - o.nr;
} ...
• statt in Projekt:public void mitarbeiterLoeschen(int nr){
mitarbeiter.remove(suchenBeiNr(nr));
}
• neu in Projekt:public void mitarbeiterLoeschen(int nr){
Mitarbeiter m = suchenBeiNr(nr);
if(m!=null)
mitarbeiter.remove(m);
}
Stephan Kleuker 253Software-Qualität
Variante (2/2)
Klasse erstellen auslesen löschen gesamt
HashSet 159 37202 23375 60736
143 36965 23187 60295
LinkedHashSet 151 25944 13981 40076
150 25600 13662 39412
CopyOnWriteArraySet 210 15482 8263 23955
209 15589 8253 24051
ConcurrentSkipListSet 187 30882 15999 47068
177 32112 17194 49483
TreeSet 168 39322 20320 59720
162 37908 19453 57523
Stephan Kleuker 254Software-Qualität
Konzept von Performance-Messwerkzeugen
• ähnlich zum letzten Beispiel wird Java-Code erweitert
• java -agentlib:hprof (hprof als Beispiel)
• Erweiterungen melden Informationen an Messwerkzeug, 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://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/
• (Ansatz vergleichbar mit Aspect-oriented Programming)
Stephan Kleuker 258Software-Qualität
Beispiel: Netbeans Profiler (4/7)
• die vorletzten beiden Klassen sind thread-safe; dies kann Unterschied zu erster Messung erklären
• TreeSet, ConcurrentSkipListSet benötigten Comparable<T>
• Wieder: HashSet wie TreeSet; LinkedHashSet besser
• Test war mit kleinen Objekten (Einfluss?)
Klasse Hinzu InProjekten Entfernen gesamt
HashSet 133 46486 40577 88379
LinkedHashSet 128 38473 34285 74088
CopyOnWriteArraySet 3468 23752 24671 53088
ConcurrentSkipListSet 1617 48149 40914 91983
TreeSet 888 48805 39259 90200
Stephan Kleuker 261Software-Qualität
Beispiel: Netbeans Profiler (7/7)
Klasse Top 3 Speicherverbrauch
HashSet
LinkedHashSet
CopyOnWriteArraySet
ConcurrentSkipListSet
TreeSet
Stephan Kleuker 262Software-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 263Software-Qualität
8. Testautomatisierung
• Automatisierungsidee
• Beispiele für Werkzeuge
• Build-Server
• Idee von Build-Werkzeugen
• Einführung in Ant
• Tests aus Ant starten
Stephan Kleuker 264Software-Qualität
Was bedeutet 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 265Software-Qualität
Werkzeuge - Beispiele (1/3): Ant
• Build-Prozess ist XML-Datei
• Build-Prozess als Baumstruktur (project, target, task)
• in Tasks steht, was mit welchem Werkzeug (Compiler, JUnit, ...) wo gemacht werden soll
• für Java-Standardwerkzeuge sind Tasks bereits direkt in Ant enthalten
• einige Werkzeuge bringen eigene Tasks zur Nutzung in Ant mit (TestNG)
• Tasks selbst einfach in Java programmierbar
• Ant liefert keinen Standard-Build-Prozess (selbst schreiben)
• http://ant.apache.org/
Stephan Kleuker 266Software-Qualität
Werkzeuge - Beispiele (2/3): Maven
• alle Projekteigenschaften in zentraler Datei pom.xml
• Project Object Model (mitgeliefert oder von Herstellern geliefert)
• definiert Standard-Build-Prozess
• Artefakt-Repository (Verwaltung von Jars)
• Verwaltung der Projektabhängigkeiten (auch Beachtung abhängiger Versionsnummern, mit Nachlademöglichkeiten)
• Build-Report als Website
• einfach erweiterbar
• deutlich mehr Einarbeitungsaufwand als Ant
• dann deutlich einfacher nutz- und wartbar als Ant
• http://maven.apache.org/
Stephan Kleuker 267Software-Qualität
Build-Server
• Software-Erstellung und Testdurchführung kann eigenen Werkzeugen überlassen werden
• Möglichkeit zur kontinuierlichen Integration
• Führt Tests zu definierten Zeitpunkten aus; ermöglicht einfache Regressionstests (Wiederholung alter Testfälle)
• Misst Testüberdeckung (kann mehrere Testwerkzeuge zusammen nutzen)
• kann im Fehlerfall zuständige Personen benachrichtigen
• erstellt im Erfolgsfall auslieferbares Artefakt ( -> Artefakt-Repository)
Stephan Kleuker 268Software-Qualität
Werkzeuge - Beispiele (3/3): CruiseControl
• CruiseControl configuration-Dateien in XML
• Stößt Ant-, Maven- oder Batch-Builds an
• kann andere Werkzeuge anstoßen (XCode)
• Konsole als Web-Anwendung
• Build-Log
• Meldet Build-Ergebnis über Email, rss
• gibt graphische Konfigurationswerkzeuge
• http://cruisecontrol.sourceforge.net/
• Alternativen: Apache Gump, Anthill, Jenkins/Hudson, Continuum, ... http://de.wikipedia.org/wiki/Kontinuierliche_Integration
Stephan Kleuker 269Software-Qualität
Konzept von Ant (und make)
• Es gibt zentrales Ziel (project) , was erreicht werden soll (z. B. vollständige Kompilation)
• Jedes Ziel besteht aus Teilzielen (target), die vorher erreicht werden müssen (z. B. Übersetzung eines Teilpakets)
• Werkzeug stellt Regeln auf, was in welcher Reihenfolge gemacht werden muss, um zentrales Ziel zu erreichen
• Werkzeug bietet dabei u. a.
– Reaktionsmöglichkeiten bei Fehlern
– Varianten bei der Ausführung
– Möglichkeit, Ordner zu löschen und anzulegen, Dateien zu kopieren, verschieben und löschen
Stephan Kleuker 270Software-Qualität
Erinnerung an make
all : file1.o file2.o file3.o
gcc -o prog file1.o file2.o file3.o
file1.o : file1.c
gcc -Wall -c file1.c
file2.o : file2.c
gcc -Wall -c file2.c
file3.o : file3.c
gcc -Wall -c file3.c
Stephan Kleuker 271Software-Qualität
Beispiel für Abhängigkeiten
<target name="init"/>
<target name="preprocess" depends="init"/>
<target name="compile" depends="init,preprocess"/>
<target name="package" depends="compile"/>
• Die Reihenfolge der Ziele (target) in der Datei hat keine Bedeutung, nur „depends“ dabei wichtig
• Neben einem default-Ziel kann man beim Start ein Ziel auswählen, z. B. compile
• alle depends betrachtet und schrittweise vom Werkzeug in mögliche Reihenfolge gebracht, hier:
– init hat keine Abhängigkeiten, wird zuerst ausgeführt (was, hier nicht sichtbar)
– preprocess benötigt init, da schon ausgeführt, wird nur preprocess ausgeführt
Stephan Kleuker 272Software-Qualität
Ant-Basisskript (erzeugt von Eclipse)
<?xml version="1.0"?><!-- =============================================
Projekt, Datum, Aufgabe Autor,============================================= -->
<project name="project" default="default"><description>
description</description><!-- =================================
target: default================================= -->
<target name="default" depends="depends" description="--> description">
</target><!-- - - - - - - - - - - - - - - - - -
target: depends- - - - - - - - - - - - - - - - - -->
<target name="depends"></target>
</project>
Stephan Kleuker 273Software-Qualität
Skript-Konstanten (Eigenschaften, Properties)
• <property name="eigen" value = "Wert" />
• Nutzung von Property-Werten mit ${eigen}
<property name= "db" value = "${eigen}.db"/>
• Bei Pfaden wird statt „value“ dann „location“ genutzt, dabei werden / und \ automatisch angepasst
<property name="ziel" location="${p}/bla/fas"/>
<property name="ziel" location="${p}\bla\fas"/>
• Laufwerksbuchstaben, wie „C:“ sind verboten (möglichst mit relativen Pfaden arbeiten)
• Es gibt vordefinierte Properties, z. B. ${user.home}, ${basedir}
Stephan Kleuker 274Software-Qualität
Properties in Hilfsdatei build.properties
# Properties für den JUnit-Testfall
# Basis-Verzeichnisse
src=${basedir}/src
build=${basedir}/build
lib=${basedir}/../../lib/fest-swing-1.2
report=${basedir}/report
# Quell-Verzeichnisse
src.junit=${src}/junit
# Verzeichnisse für generierte Artefakte
build.junit=${build}/junit
• in build.xml: <property file="build.properties" />
Stephan Kleuker 275Software-Qualität
Hilfsmittel: Zeitstempel
• Einfachste Form: Task <tstamp/> , dann nutzbare Variablen:– DSTAMP: aktuelles Datum, Default-Format yyyymmdd– TSTAMP: aktuelle Uhrzeit, Default-Format hhmm– TODAY: aktuelles Datum als String
• konfigurierbar über format-Property<target name="zeigeZeit"> <tstamp> <format property="TODAY"
pattern="dd.MMMM.yyyy" locale="de,DE"/></tstamp><echo message="DSTAMP = ${DSTAMP}"/> <echo message="TSTAMP = ${TSTAMP}"/><echo message="TODAY = ${TODAY}"/> </target> [echo] DSTAMP = 20070209
[echo] TSTAMP = 1234[echo] TODAY = 09.Februar.2007
Stephan Kleuker 276Software-Qualität
Umgang mit Files und Dateien
• <mkdir dir="${builddir}"/>
– legt auch fehlende Unterverzeichnisse z. B. bei /dist/nase/simpel/billig an
– übersprungen, falls Verzeichnis existiert• <delete dir="${builddir}"/>
• <copy file="src/Hai.java" tofile="back/Hai.java"/>
• <move file="src/Hai.java" tofile="back/Hai.java"/>
• Pattern / Wildcards / reguläre Ausdrücke– * für beliebig viele Zeichen– ? für genau ein Zeichen– ** alle Unterverzeichnisse, z. B. **/*.java
• häufig Property fileset zum Ein- und Ausschließen nutzbar<copy todir="archive"><fileset dir="src"><include name="*.java"/></fileset>
</copy>
Stephan Kleuker 277Software-Qualität
Beispiel-target: Kompilieren
<!-- classpath in der Form besser weglassen! --><target name="compile" depends="start" description="kompiliere"> <javac srcdir="src" destdir="build" classpath="." debug="on"> </javac> <echo message="in compile"/>
</target>
• weitere Parameter können der Ant-Dokumentation entnommen werden (...\ant\docs\manual\index.html)
• classpath nur nutzen, wenn weitere Pakete genutzt werden
• echo hier als Spielerei
• Übersetzung aller Klassen in Verzeichnis src und Unterverzeichnissen
Stephan Kleuker 278Software-Qualität
Einbinden externer Bibliotheken
<path id="ExternalLibs">
<pathelement location="${lib}/junit-4.8.2.jar" />
<pathelement location="${lib}\extensions\junit\fest-swing-
junit-4.5-1.2\fest-swing-junit-4.5-1.2.jar"/>
<pathelement location="${lib}/lib/fest-assert-1.2.jar" />
<pathelement location="${lib}/fest-mocks-1.0.jar" />
<pathelement location="${lib}/lib/fest-reflect-1.2.jar" />
<pathelement location="${lib}/fest-swing-1.2.jar" />
<pathelement location="${lib}/lib/fest-util-1.1.2.jar" />
</path>
<target name="compile" description="Sourcen kompilieren">
<javac srcdir="${src}" destdir="${build}">
<classpath refid="ExternalLibs" />
</javac>
</target>
Stephan Kleuker 279Software-Qualität
Beispiel-target: Packen
<!-- existierendes Manifest mit Attribut file="" -->
<target name="pack"
depends="compile"
description="packe">
<jar destfile="dist/gepackt.jar" basedir="build">
<manifest>
<attribute name="Main-class" value="de.kleuker.XStarter">
</attribute>
</manifest>
</jar>
<echo message="in pack"/>
</target>
• hier wird Manifest-Datei direkt erzeugt, zu nutzende Datei kann auch angegeben werden
Stephan Kleuker 280Software-Qualität
Beispiel-target: JUnit ausführen
<target name="test" depends="compile"
description="JUnit-Test ausführen">
<junit printsummary="on" fork="yes">
<!-- classpath für die Ausführung setzen -->
<classpath>
<pathelement location="${build}" />
<path refid="ExternalLibs" />
</classpath>
<test name=„klicker.klickerTest" todir="${report}">
<formatter type="plain" usefile="true" />
</test>
</junit>
</target>
Stephan Kleuker 283Software-Qualität
9. Metriken
• Idee von Maßsystemen
• Live Variables
• Variablenspanne
• McCabe-Zahl
• LCOM*
Stephan Kleuker 284Software-Qualität
Nutzung von Maßsystemen
• bisherigen Prüfverfahren sind aufwändig, Wunsch besteht, schneller zu Qualitätsaussagen zu kommen
• Ansatz: Nutzung von Maßsystemen, die Zahlenwerte generieren, deren Werte Indiz für Qualität der SW sind
• Werden Maße automatisch berechnet, kann man Qualitätsforderungen stellen, dass bestimmte Maßzahlen in bestimmten Bereichen liegen
• Wichtig ist, dass man weiß, dass nur Indikatoren betrachtet werden, d.h. gewonnene Aussagen müssen nachgeprüft werden
• Ähnliche Ansätze in der Projektverfolgung und Analyse der Firmengesamtlage (-> Balanced Scorecard)
-> siehe Qualitätsmanagement
Stephan Kleuker 285Software-Qualität
Metriken zur Ermittlung des Projektstands
Use Cases
Pakete C1-Über-deckung
C2-Über-deckung
programmiert/überdeckt
0%
50%
100%
Stephan Kleuker 286Software-Qualität
Grobe Metriken (Min, Max, Schnitt, Abweichung)
• Lines of Code pro Methode (LOC)
mögliche Grundregel: maximale Zahl unter 20
• Methoden pro Klasse
Die Zahl sollte zwischen 3 und 15 liegen
• Parameter pro Methode
Die Zahl sollte unter 6 liegen
• Exemplarvariablen pro Klasse
Die Zahl sollte unter 10 liegen [Entitäten ?]
• Abhängigkeiten zwischen Klassen
Keine Klasse sollte von mehr als vier Klassen abhängen
• weitere Maßzahlen z. B. Anzahl von Klassenvariablen und Klassenmethoden
Stephan Kleuker 287Software-Qualität
Live Variables
• Ansatz: Erstellung/Prüfung einer Anweisung umso schwieriger, je mehr Variablen beachtet werden müssen
• Eine Variable heißt zwischen der ersten und der letzten Nutzung lebendigpublic static int mach(boolean a, boolean b){int x=0; // a,b,x lebendig if (a) // a,b,x lebendig x=2; // b,x lebendig
elsex=3; // b,x lebendig
if (b) // b,x lebendig return(6/(x-3)); // x lebendig
elsereturn(6/(x-2)); // x lebendig }
• Interessant sind maximale und mittlere Zahl (Gesamtzahl lebendiger Variablen durch Anzahl ausführbarer Anweisungen) lebendiger Variablen
Stephan Kleuker 288Software-Qualität
Variablenspanne
• Für Variable x: maximaler Abstand (in Code-Zeilen) zwischen ihren Nutzungen. (Zeilennummer in der x zum (i+1)-ten Mal minus Zeilennummer in der x zum i-ten Mal vorkommt.)public static int mach(boolean a, boolean b){ //1
int x=0; //2
if (a) //3
x=2; //4
else
x=3; //5
if (b) //6
return(6/(x-3)); //7
else
return(6/(x-2)); //8
}
• Wieder durchschnittlicher und maximaler Wert interessant
a: 3-1=2b: 6-1=5x: 4-2=7-5=2
Maximum: 5Durchschnitt: 3
Stephan Kleuker 289Software-Qualität
Zyklomatische Zahl nach McCabe
1. Man konstruiere die Kontrollflussgraphen
2. Man messe die strukturelle Komplexität:
Die zyklomatische Zahl z(G) eines Kontrollflussgraphen G ist:
z(G) = e – n + 2 mit
e = Anzahl der Kanten des Kontrollflussgraphen
n = Anzahl der Knoten
Zyklomatische Komplexität gibt Obergrenze für die Testfallanzahl für den Zweigüberdeckungstest an
In der Literatur wird 10 oft als maximal vertretbarer Wert genommen (für OO-Programme geringer, z. B. 5)
für Java: #if + #do + #while + #switch-cases+ 1
Stephan Kleuker 290Software-Qualität
Beispiele für die zyklomatische Zahl
Anzahl
Kanten
Anzahl
Knoten
McCabe
Zahl
0 2 4 3 6
1 3 4 3 5
1 1 2 2 3
Stephan Kleuker 291Software-Qualität
Erweiterte McCabe-Zahl
• Komplexität von Verzweigungen berücksichtigen
• gezählt werden alle Booleschen Bedingungen in if(<Bedingung>) und while(<Bedingung>): anzahlBedingung
• gezählt werden alle Vorkommen von atomaren Prädikaten: anzahlAtome
z. B.: ( a || x>3) && y<4 dann anzahlAtome=3
• erweitere McCabe-Zahl
ez(G) = z(G) + anzahlAtome - anzahlBedingung
• wenn nur atomare Bedingungen, z. B. if( x>4), dann gilt ez(G) = z(G)
Stephan Kleuker 292Software-Qualität
Lack of Cohesion in Methods (LCOM*) - Ansatz
• Frage: Gibt es Maß für gute Objektorientierung?
• Ansatz (Indikator): Exemplarvariablen sollten in mehreren Methoden genutzt, möglichst kombiniert sein
• Hinweis: Es muss vorher festgelegt werden, ob Klassenvariablen und Klassenmethoden berücksichtigt werden sollen
• Was passiert, wenn man konsequent exzessiv OO macht und auch in den Exemplarmethoden get() und set() Methoden nutzt? Wie ist LCOM* dann rettbar?
Stephan Kleuker 293Software-Qualität
Lack of Cohesion in Methods (LCOM*) - Berechnung
LCOM* = (avgNutzt–m) /(1-m)
• nutzt(a) die Zahl der Methoden, die eine Exemplarvariable a der untersuchten Klasse nutzen
• sei avgNutzt der Durchschnitt aller Werte für alle Exemplarvariablen
• sei m die Anzahl aller Methoden der untersuchten Klasse
• Ist der Wert nahe Null, handelt es sich um eine eng zusammenhängende Klasse
• Ist der Wert nahe 1, ist die Klasse schwach zusammenhängend, man sollte über eine Aufspaltung nachdenken
Stephan Kleuker 294Software-Qualität
LCOM*-Beispiel
public class LCOMSpielerei {
private int a;private int b;private int c;
public void mach1(int x){a=a+x;}
public void mach2(int x){a=a+x;b=b-x;}
public void mach3(int x){a=a+x;b=b-x;c=c+x;}
}
nutzt(a)=3 nutzt(b)=2 nutzt(c)=1 avgNutzt=6/3=2LCOM*= (2-3) /(1-3)
= -1/-2= 0.5
für Eclipse gibt es Plugin Metricshttp://sourceforge.net/projects/metrics/berechnet u. A. erweiterte MCCabe-Zahl und LCOM*
Stephan Kleuker 295Software-Qualität
Beispiel eines Kivat-Diagramms
Maßzahlen können graphisch dargestellt werden, im Kivat-Diagramm steht jede Achse für eine Metrik, der weiße Bereich ist ok, die anderen Bereiche kritisch
Variablenspanne
LOC LCOM*
zyklomatischeZahl
Live Variables
Stephan Kleuker 296Software-Qualität
10. Konstruktive Qualitätssicherung
• Idee
• Coding Guidelines
• Werkzeugeinstellungen
• weitere Maßnahmen
Stephan Kleuker 297Software-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 298Software-Qualität
Coding Guidelines
• Detailliertes Beispiel: Taligent-Regeln für C++ (http://pcroot.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 299Software-Qualität
Beispiel-Coding-Regel
• Ausschnitt aus „Java Code Conventions“, Sun, 1997• Inhalt soll sich nicht nur auf Formatierung beziehen
Stephan Kleuker 300Software-Qualität
Einheitliche Werkzeugeinstellungen
• Vor Projekt einheitliche Formatierung festlegen
• Styleguide für verwendete Werkzeuge
Stephan Kleuker 301Software-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 302
Werkzeuge zur statischen Quellcodeanalyse
• Jeweils unterschiedliche Menge überlappender Regeln
• Alle auch als Eclipse-Plugins nutzbar
• Genutzte Regelmengen konfigurierbar
• Gibt einige weitere WerkzeugeSoftware-Qualität
Werkzeug
Verwendung
mit Ant und
Maven
Kommando
zeileEigene GUI
eigene
Regeln
erstellbar
Checkstyle Ja Ja Nein Ja, mit Java
FindBugs Ja Ja Ja Ja, mit Java
PMD Ja Ja NeinJa, mit Java
oder XPath
Lint4j Ja Ja Nein Nein
Stephan Kleuker 303Software-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 304Software-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 305Software-Qualität
11. 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 306Software-Qualität
Teststufen (grober Ablauf)
Klassentest
Integrationstest
Systemtest
Abnahmetest
entwicklungs-intern
entwicklungs-extern (mit Kunden)
Stephan Kleuker 307Software-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 308Software-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 309Software-Qualität
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
Stephan Kleuker 310Software-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 311Software-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 312Software-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 313Software-Qualität
Prinzip des Regressionstests
Testfalldatenbank
Referenz-testfälle
Testfall-ergebnisse
SoftwareVersion n
TestfallspezifikationVersion n
Test
SoftwareVersion n+1
Testarchivierungder Iteration n
Regressionstest
Vergleich der Testergebnisse
Stephan Kleuker 314Software-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 315Software-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 316Software-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 317Software-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 Oberbegriff
Stephan Kleuker 318Software-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 319Software-Qualität
Testverfahren nach ANSI/IEEE-829
TestplanTestkonzept
Testfall-spezifikation
Testprozedur-Spezifikation
TestprotokollTestvorfalls-
berichtTestabschluss-
bericht
Testausführung
TestobjekteÜbergabebericht
Stephan Kleuker 321Software-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 322Software-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 323Software-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 324Software-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 325Software-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 326Software-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 327Software-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 ist mit Testvorschrift kombinierbar
Stephan Kleuker 328Software-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 329Software-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 330Software-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 331Software-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 332Software-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 gegen eigene Q-Abteilung?