Variante: Klassen zur Browsersteuerung...

99
Stephan Kleuker 234 Variante: Klassen zur Browsersteuerung (1/2) public class GoogleTest { private WebDriver driver; // (auch Selenium) public GoogleTest() {} @Before public void setUp() { //Erzeugt neue Instanz des Browser Treibers //driver = new FirefoxDriver(); driver = new InternetExplorerDriver(); //driver = new HtmlUnitDriver(); //driver = new ChromeDriver(); } @After public void tearDown() { //beendet Browser driver.quit(); } Software-Qualität

Transcript of Variante: Klassen zur Browsersteuerung...

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 244Software-Qualität

Verstecktes Speicherleck (3/3)

Programm-start

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 255Software-Qualität

Beispiel: Netbeans Profiler (1/7)

Stephan Kleuker 256Software-Qualität

Beispiel: Netbeans Profiler (2/7)

Stephan Kleuker 257Software-Qualität

Beispiel: Netbeans Profiler (3/7)

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 259Software-Qualität

Beispiel: Netbeans Profiler (5/7)

Stephan Kleuker 260Software-Qualität

Beispiel: Netbeans Profiler (6/7)

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 281Software-Qualität

test-Task starten

Stephan Kleuker 282Software-Qualität

Beispiel: Protokoll und Ergebnis

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 320Software-Qualität

Dokumentation der Qualitätssicherung (Tests)

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?