Sonntag, 14. Februar 2016

Musterlösung zur Aufgabe 7 Äquivalenzklassen

Anbei finden Sie eine mögliche Aufstellung der Äquivalenzklassen für die Aufgabe 7 aus der Beispiel Klausur. Zu jeder Klasse muss im nächsten Schritt ein Repräsentant gewählt werden.

knr:
gÄK1_01 = [100001 ... 999999]
gÄK1_02 = NULL

uÄK1_03 = [-MAX_LONG ... 100000]
uÄK1_04 = [1 000 000 ... MAX_LONG]

vorname:
gÄK2_01 = NULL
gÄK2_02 = [length(0) ... length(12)]

uÄK2_03 = [length() > 12]

nachname:
gÄK3_01 = [length(1) ... length(14)]

uÄK3_02 = NULL
uÄK3_03 = Empty
uÄK3_04 = [length() > 14]

typ:
gÄK4_01 = [0, 1, 9]

uÄK4_02 = NULL
uÄK4_03 = [-MAX_INT ... -1]
uÄK4_04 = [2 ... 8]
uÄK4_05 = [10... MAX_INT]

Schritt 2: Anbei die gewählten Repräsentanten für die einzelnen Klassen.

knr:
gÄK1_01 = [100001 ... 999999]              R = 100001
gÄK1_02 = NULL                                   R = NULL

uÄK1_03 = [-MAX_LONG ... 100000]        R = 100000
uÄK1_04 = [1 000 000 ... MAX_LONG]     R = 1 000 000

vorname
gÄK2_01 = NULL                                            R = NULL
gÄK2_02 = [length(0) ... length(12)]                R = „ABC“

uÄK2_03 = [length() > 12]                               R = „123456789ABCD“

nachname
gÄK3_01 = [length(1) ... length(14)]             R = „DEF“

uÄK3_02 = NULL                                            R = NULL
uÄK3_03 = Empty                                            R = „“
uÄK3_04 = [length() > 14]                               R = „123456789ABCDEF“

typ
gÄK3_01 = [0, 1, 9]                                          R = 1

uÄK3_02 = NULL                                            R = NULL
uÄK3_03 = [-MAX_INT ... -1]                        R = -1
uÄK3_04 = [2 ... 8]                                           R = 2
uÄK3_05 = [10... MAX_INT]                          R = 11

Schritt 3: Nun können die Positiv-Testfälle abgeleitet werden:

1. P-Testfall
knr = 100001
vorname = NULL
nachname = „DEF“
typ = 1

Nachbedingung:
Kunde wurde gespeichert und wird mit den entsprechenden Werten als Objekt zurückgeliefert.

2. P-Testfall
knr = NULL
vorname = „ABC“
nachname = „DEF“
typ = 1

Nachbedingung:
Kunde wurde gespeichert und wird mit den entsprechenden Werten als Objekt zurückgeliefert.

Schritt 4: Aus den ungültigen Klassen können die Negativen-Testfälle abgeleitet werden:

1. N-Testfall
knr = 100000
vorname = NULL
nachname = „DEF“
typ = 1

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

2. N-Testfall
knr = 1 000 000
vorname = NULL
nachname = „DEF“
typ = 1

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

3. N-Testfall
knr = 100001
vorname = „123456789ABCD“
nachname = „DEF“
typ = 1

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

4. N-Testfall
knr = 100001
vorname = NULL
nachname = NULL
typ = 1

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

5. N-Testfall
knr = 100001
vorname = NULL
nachname = „“
typ = 1

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

6. N-Testfall
knr = 100001
vorname = NULL
nachname = „123456789ABCDEF“
typ = 1

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

7. N-Testfall
knr = 100001
vorname = NULL
nachname = „DEF“
typ = NULL

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

8. N-Testfall
knr = 100001
vorname = NULL
nachname = „DEF“
typ = -1

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

9. N-Testfall
knr = 100001
vorname = NULL
nachname = „DEF“
typ = 2

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

10. N-Testfall
knr = 100001
vorname = NULL
nachname = „DEF“
typ = 11

Nachbedingung:
Operation wirft eine Ausnahme vom Typ IllegalArgumentException.

Samstag, 30. Januar 2016

Landkarte Software-Qualitätssicherung (Mindmap)

Anbei finden Sie eine Mindmap, als Landkarte der Themen bzw. Begrifflichkeiten die Sie für die Prüfung sich anschauen sollten.

Download Mindmap

Beispiel Aufgaben Klausur Software-Qualitätssicherung

Anbei finden zur Vorbereitung auf die Klausur einige Beispiel-Aufgaben. Die Klausur im WS15/16 wird andere Aufgaben umfassen, wie die angehängten Beispiele-Aufgaben. Den Aufbau der Klausur haben wir in der letzten Vorlesung besprochen.

Mittwoch, 27. Januar 2016

Testprozess Testmanagement und Testendekriterien

Download
Lernziele (Fragen zur Vorlesung)
  • Was enthält eine Testspezifikation? Wie spielt sie mit der Traceability Matrix zusammen?
  • Was enthält eine Fehlermeldung?
  • Wann ist es sinnvoll, mit dem Testen aufzuhören?
  • Welche Phasen hat der fundamentale Test-Prozess?
  • Was ist ein Fehler? Was ist ein Mangel?
  • Welche Vor- und Nachteile haben unabhängige Tester?
  • Wie sollten Fehler erfasst werden? 
  • Welche Testendekriterien kennen Sie?
Literatur
  • Andreas Spillner - Basiswissen Softwaretest - 2005

Donnerstag, 21. Januar 2016

Übung Last- und Performancetest

Schritt: 1 Einrichten der Demo in Eclipse
Laden Sie das Eclipse Projekt von hier herunter: download

Importieren Sie das Projekt mittels Gradle in Eclipse. Dazu erzeugen Sie sich die Eclipse Konfiguration über das Gradle Kommando gradlew eclipse

Schritt 2: Starten der Anwendung
Die Beispiel Anwendung kann über die Java Main Klasse “basar. BasarApplication“ gestartet werden. Anschließend kann die Web-Anwendung unter der folgenden URL aufgerufen werden http://localhost:8080/.

Schritt 3: Apache JMeter herunterladen
Laden Sie das Programm JMeter heruntern z.B über den folgenden Link
Apache JMeter Download.

Schritt 4: Aufzeichnen eines JMeter Tests für die Nutzerverwaltung
Zeichnen Sie mit JMeter einen Test für die Verwaltungsfunktion der Nutzer auf.

Schritt 5: Test durchführen
Führen Sie den JMeter Test mit unterschiedlichen Lastbedingungen aus.

Schritt 6: Test Auswertung
Werten Sie die Testergebnisse aus dem Schritt 5 mittels Excel aus.

Mittwoch, 20. Januar 2016

Weitere Testverfahren

Download Folien
Lernziele (Fragen zur Vorlesung)
  • Was verstehen Sie unter Skalierbarkeit?
  • Wie unterscheidet sich ein Performance-Test von einem Last-Test?
  • Wie kann man für ganze Webanwendungen Last simulieren?
  • Welche Ziele werden beim Stresstest verfolgt?
  • Was verstehen Sie unter Smoke-Tests?
  • Wann wird ein Wartungstest durchgeführt?
  • Welches Testziel wird beim Regressionstest verfolgt? 
  • Wie kann man die Benutzbarkeit einer Benutzeroberfläche prüfen?
  • Welche klassischen Angriffsszenarien kennen Sie?
  • Wie kann man sich gegen diese Angriffe schützen?
  • Wie kann man Anwendungen auf Security testen?
  • Was verstehen Sie unter Continuous Delivery?
Links

Donnerstag, 14. Januar 2016

Übung zum Systemtest - Zustandsbasierter Test

Schritt: 1 Einrichten der Demo in Eclipse
Laden Sie das Eclipse Projekt von hier herunter: download
Importieren Sie das Projekt mittels Gradle in Eclipse. Dazu erzeugen Sie sich die Eclipse Konfiguration über das Gradle Kommando gradlew eclipse

Schritt 2: Starten der Anwendung
Die Beispiel Anwendung kann über die Java Main Klasse “basar. BasarApplication“ gestartet werden. Anschließend kann die Web-Anwendung unter der folgenden URL aufgerufen werden http://localhost:8080/basar.html und http://localhost:8080/sellers.html

Schritt  3: Zustandsbasierter Test
Erstellen Sie für den Basar ein Zustandsdiagramm . Leiten Sie aus dem Diagramm über einen Baum die Testfälle ab.

Schritt: 4 JUnit Tests
Setzen Sie die Testfälle aus Schritt 3 mittels JUnit oder Spock um.

Schritt 5: Anbindung der Tests an die Benutzeroberfläche
Binden Sie die Testfälle aus Schritt 4 mittels WebDriver oder Geb an die Web-Oberfläche an.

Mittwoch, 13. Januar 2016

Systemtest und UI Tests

Download
Lernziele (Fragen zur Vorlesung)
  • Welche fünf spezifikationsorientierte Verfahren zur Ermittlung von Testfällen kennen Sie?
  • Wie lassen sich Oberflächen automatisiert Testen?
  • Welches Pattern sollte genutzt werden um Oberflächentests für Web-Anwendung zu strukturieren?
  • Wie kann ein Fluent Builder beim schreiben von Tests helfen?
  • Wie funktioniert das Fluent Builder Pattern?
Literatur
  • Der Systemtest. Anforderungsbasiertes Testen von Software-Systemen, Harry M. Sneed, Manfred Baumgartner, Richard Seidl - 2008
    Links

    Montag, 4. Januar 2016

    Nächste Vorlesung am 14.01.2016

    Ich wünsche Ihnen allen noch ein friedliches, gesundes und erfolgreiches Jahr 2016.

    Die nächste Vorlesung Software-Qualitätssicherung findet am Donnerstag 14.01.2016 statt. Für den Ausfall vor Weihnachten wird es einen Ersatztermin geben, diesen Termin stimmen wir am 14.01 ab.

    Viele Grüße
    Christian Baranowski

    Mittwoch, 9. Dezember 2015

    Übung Spock und Groovy

    Übung Spock und Groovy 

    Schritt 0: Installieren Sie das Eclipse Groovy Plugin

    Beziehen Sie über den Eclipse Maketplace die Groovy IDE.

    Update Site 4.4 (Luna):
    http://dist.springsource.org/release/GRECLIPSE/e4.4/

    Schritt 1: Demo Projekt herunterladen 

    Laden Sie das Demo Projekt von hier herunter und entpacken Sie die ZIP Datei.

    Schritt 2: Projekt importieren 

    Erzeugen Sie über Gradle die Eclipse Projekt Konfiguration.
    gradlew eclipse

    Importieren Sie das Projekt in Eclipse

    Schritt 3: Spock Tests schreiben

    Schreiben Sie für das Interface Basar (Komponente) eine Reihe an Tests mittels Spock.
    Hilfe zu Spock finden Sie unter:  http://spockframework.github.io/spock/docs/1.0/index.html

    Schritt 4:  Data Driven Test

    Schreiben Sie einen Data Driven Test mit dem Spock Werkzeug für die Basar Komponente.

    Systemtest und Akzeptanztest

    Folien und Übungen
    Lernziele (Fragen zur Vorlesung)
    • Was wird beim Systemtest getestet?
    • Wie werden beim BDD die Testfälle beschrieben?
    • Wer führt den Systemtest durch?
    • Was sind Äquivalenzklassen?
    • Was versteht man unter Grenzwertanalyse? Welche Werte würde Sie ausprobieren, falls Sie ganzzahlige Werte in einem Intervall 23 <= x < 102 testen wollen?
    • Welche Zustände und Zustandsübergänge testet man beim zustandsbasierten Testen?
    • Wann hört man beim zustandsbasierten Testen auf zu testen?
    Literatur
    • Der Systemtest. Anforderungsbasiertes Testen von Software-Systemen, Harry M. Sneed, Manfred Baumgartner, Richard Seidl - 2008
    • Andreas Spillner - Basiswissen Softwaretest - 2005

    Integrationsstrategien und Integrationstestmuster

    In der letzen Vorlesung haben wir die folgenden verschiedene Integrationsstrategien und Integrationstestmuster kennengelernt. Diese sind hier im vorliegenden Blog Eintrag nochmals knapp dargestellt.

    Integrationsstrategien
    Big-Bang Integration
    Es werden alle Komponenten auf einmal in Betrieb genommen. Es findet eigentlich keinen wirklich Integration statt. Diese Integrationsstrategie gilt es um jeden Preis zu vermeiden!!!

    Bottom-Up Integration
    Es werden schrittweise von unten in der Architektur die Komponente integriert. Beispielweise wird im ersten Schritt die Datenzugriffslogik und die Datenbank integriert und getestet. Im nächsten Schritt wird dann die Komponente mit der Geschäftslogik dazu genommen, dies bedeutet es wird nun das Zusammenspiel Geschäftlogik, Datenzugriffsschicht und Datenbank integriert und anschließend getestet.

    Top-Down Integration
    Hier wird in der umgekehrten Reihenfolge wie bei der Bottom-Up Integration, schrittweise die Komponente von oben nach unten in der Architektur integriert und geprüft. Bei einer Anwendung mit einer GUI könnte im ersten Integrationsschritt die GUI und die Geschäftlogik integriert werden. Bei einer Bottom-Up Integration muss immer die letzte Komponente die nicht mehr mit integriert wird simuliert werden (außer im letzten Integrationsschritt wenn alle Komponenten integriert werden im Systemtest) dazu können Beispielweise Mock Objekte genutzt werden.

    Back-Bone Integration
    Bei dieser Strategie gibt es zur Integration der einzelnen Komponenten eine fertige Komponente das Backbone über die man die einzelnen Komponenten integriert (über diese erfolgt i.d.R. die Kommunikation der Komponenten z.B. über einen sogenannten Bus). Ein Beispiel aus der Java Welt ist der Einsatz eines ESB (Enterprise Service Bus) z.B. OpenESB mit einer solchen Lösung kann eine Back-Bone Integration umgesetzt werden. Auch ein Applikationsframework wie z.B. OSGi kann zur Umsetzung einer Back-Bone Integration genutzt werden.

    Continuous Integration
    Bei jeder Codestandänderung wird automatisch integriert und die Komponenten und Integrationstests werden durchgeführt. Einen Schritt weiter geht das Pattern Continuous Delivery wo die gesamte Anwendung bei einer Codestandänderung unter bestimmten Umständen sogar komplett an den Kunden ausgeliefert wird (siehe auch Literatur Verweise unten).

    Bottom-Up Integrationstest Patterns
    Praktisch betrachtet haben wir in der Vorlesung die Integrationsstrategie Bottom-Up. Dabei haben wir zwei Patterns zum Implementierten von Integrationstests für die Bottom-Up Integrationsstrategie kennengelernt. Diese sind mit dem Quelltext aus der Vorlesung im Folgenden noch mal knapp dargestellt.

    Layer Test 

    Bei diesem Integrationstest  Muster wird für jeden Layer (dazu muss die Anwendung nach einem Schichten Modell z.B. 3-Tier Architekturmodell aufgebaut worden sein) ein Integrationstest geschrieben. Zur Implementierung dieses vier Phasen Tests (Setup, Execute, Verify, Tear-Down) wird nur die Funktionalität des höchsten Layer genutzt.

    Vorteil
    Der Test hat keine Abhängigkeit zu den Technologien der untern Schichten. Daher kann der Test wiederverwendet werden wenn sich die Technologien dieser untern Schichten ändern. Beispielsweise der Test wird für das Layer der Geschäftlogik geschrieben, die Anwendung wird von einer SQL Datenbank auf eine Non-SQL Datenbank umgestellt, der Test kann ohne Änderung immer noch genutzt werden.

    Nachteil
    Der Test prüft nicht wirklich die Integration der Komponenten, es wird nicht sichergestellt dass die Eingaben auf dem höchsten Layer tatsächlich auch in die Komponenten gelangen und in die niedrigen Layer wo sie evtl. hin sollen.

    Beispiel
    Das Sequenz Diagramm unten zeigt einen beispielhaften Ablauf eines Layer Tests wie wir ihn in der Vorlesung umgesetzt haben.

    Es wird im Test die Integration Datenbank und Datenzugriffsschicht einer Geschäftsanwendung geprüft. Hier der Quelltext für den Test aus der Vorlesung:



    Back Door Manipulation Test


    Bei diesem Integrationstest  Muster wird über eine Hintertür z.B. eine Test eigene Datenbank-Verbindung die Infrastruktur-Komponenten in einen definierten Zustand gebracht. Und nach der Testausführung wird über diesen Weg ebenfalls der Zustand der Infrastruktur-Komponenten geprüft.

    Vorteil
    Der Test stellt sicher dass tatsächlich die Komponenten wie spezifiziert integriert sind.

    Nachteil
    Bei einer Änderung der Infrastruktur Komponenten muss auch der Test angepasst oder sogar neu geschrieben werden.

    Beispiel
    Das Sequenz Diagramm unten zeigt einen beispielhaften Ablauf eines Back Door Manipulation Tests wie wir ihn in der Vorlesung umgesetzt haben.


    Es wird im Test die Integration Datenbank und Datenzugriffsschicht einer Geschäftsanwendung geprüft. Hier der Quelltext für den Beispiel Test aus der Vorlesung:



    Literatur und Links

    Donnerstag, 26. November 2015

    Übungen Dependency Injection und Integrationstests


    Schritt 1: Laden Sie das Projekt Download Spring 4 Version herunter

     

    Schritt 2: Importieren Sie das Projekt direkt in Eclipse

     

    Schritt 3: Den JUnit DependencyInjectionTest ausführen

     

    Schritt 4: Spring Objekt-Netz in XML Konfiguration
    (/META-INF/core-context.xml) einarbeiten

    Erstellen Sie für das im Modell unten skizzierte Objektnetz eine Spring XML Konfiguration.

    Siehe dazu Spring Dokumentation: hier


     

    Schritt 5: Spring Objekt Netz als Java Konfiguration anlegen

    Überführen Sie die XML Konfiguration in eine Java basierte Konfiguration.

    Anmerkung: Dazu kann der Test ClassConfigurationTest genutzt werden.


    Schritt 6: Top-Down Integration 

    (ShoppingController - BasarService - SimplePositionRepository - SimpleUserRepository)

    Siehe auch Mockito Doku:
    http://mockito.github.io/mockito/docs/current/org/mockito/Mockito.html


    Mittwoch, 25. November 2015

    Integrationstests Teil II und TDD

    Folien und Übungen
    Inhalt
    • Wiederholung Integrationstests
    • Integrationsstrategien
    • Test Driven Development
    • Black-Box Testverfahren

    Lernziele (Fragen zur Vorlesung) 
    • Was sind die Testziele beim Integrationstest?
    • Was ist der Unterschied zwischen White-Box und Black-Box Testing?
    • Nennen Sie drei typische Integrationsfehler.
    • Welche Integrationsstrategien kennen Sie? Welche Vor- und Nachteile haben diese?
    • Was ist der Unterschied zwischen White-Box und Gray-Box Testing?
    • Aus welchen Schritten besteht der Prozess zur Testgetriebene Entwicklung (Test Driven Development Prozess)?
    • Welche Vorteile bietet die Testgetriebene Entwicklung?
    • Was sind Äquivalenzklassen?

    TDD - Werkzeug:

    Literatur

    Musterlösung Übung zu Test-Doubles

    Mittwoch, 11. November 2015

    Dependency Injection (DI) und Integrationstests

    Folien
    Inhalt
    • Wiederholung Statische-Tests
    • Refactoring
    • Dependency Injection (Einführung in Spring u. Spring Boot)
    • Integrationstests
    • Integrationsstrategien
    Lernziele (Fragen zur Vorlesung) 
    • Was sind die Testziele beim Integrationstest?
    • Was verstehen Sie unter äußere & innere Software-Qualität?
      (Ordnen Sie die Attribute der ISO-9126 entsprechend zu.)
    • In welche Teststufen können Integrationstests aufgeteilt werden?
    • Was ist der Unterschied zwischen White-Box und Black-Box Testing?
    • Was versteht man unter einem unabhängigen Tester?
    • Nennen Sie drei typische Integrationsfehler.
    • Welche Integrationsstrategien kennen Sie? Welche Vor- und Nachteile haben diese?
    • Wer führt den Integrationstest durch?
    • Wie schreibt man Komponenten, bei denen die damit verbundenen Komponenten gut austauschbar sind?
    Literatur
    • xUnit Test Patterns: Refactoring Test Code - Gerard Meszaros 2007
    • Andreas Spillner - Basiswissen Softwaretest - 2005

    Mittwoch, 4. November 2015

    Übung zu Test-Doubles und statischen Tests

    Aufgabe zu Mocking und Stubbing


    Schritt 1: Laden Sie das Projekt swqs.mocking.keywords.analyzer.zip herunter.

    Schritt 2: Importieren Sie das Projekt direkt in Eclipse

    Schritt 3: Machen Sie die Klasse KeyWordAnalyzer testbar ohne die  Existenz einer Implementierung des Interface KeyWordRepository vorauszusetzen. 

    Schritt 4: Schreiben Sie für die Klasse KeyWordAnalyzer einen JUnit Test 
    Nutzen Sie dazu Stubbing und Mocking Möglichkeiten des Werkzeugs Mockito.

    Anmerkung: Eine ausführlich Dokumentation zu Mockito finden Sie unter:
    http://mockito.github.io/mockito/docs/current/org/mockito/Mockito.html

    Schritt 5: Prüfen Sie ob Sie alle Anweisungen der Klasse KeyWordAnalyzer mit Ihrem Test geprüft haben.

    Aufgabe zu Statischen Testverfahren


    Schritt 1: Einrichten des Sonar Servers auf Ihrem System

    Dazu laden Sie sich den Sonar Server in der Version 5.2 herunter von der Projektseite unter:

    Entpacken Sie den Server und starten Sie den Server über das Skript:
    "sonarqube-5.2/bin/windows-x86-32/StartSonar.bat" 
    Anmerkung: Linux und Mac OSX Nutzer verwenden die entsprechenden Skripte unter Mac OSX z.B. "sonarqube-5.2/bin/macosx-universal-64/sonar.sh console"

    Anschließend können Sie unter der URL "http://localhost:9000/" den Sonar Server aufrufen. Für den Login können Sie den Nutzer mit dem Nutzernamen: admin und dem Passwort: admin nutzen.

    Schritt 2: Laden Sie das Projekt swqs.statictests.tennis herunter.

    Schritt 3: Importieren Sie das Projekt direkt in Eclipse

    Schritt 4: Tests ausführen und Ergebnisse auf den Sonar Server übertragen
    Öffnen Sie eine Kommandozeile und wechseln in den Ordner des Projekts swqs.statictests.tennis.
    Dort rufen Sie das Build Werkzeug Gradle wie folgt auf "gradlew.bat sonarqube" (unter Linux und MacOSX ./gradlew sonarqube). Nach dem erfolgreichen Build wechseln Sie in den Sonar Server dort finden Sie nun ein entsprechendes Projekt mit den Ergebnissen der statischen Tests.

    Schritt 5: Refactoring mit statische Tests
    Versuchen Sie durch Refactorings die Fehler und Probleme die der Sonar Server anzeigt zu lösen. Anschließend können Sie über einen erneuten Gradle Build prüfen ob Ihre Maßnahmen zu einer Verbesserung geführt haben.



    Statische Testverfahren

    Download

    Lernziele (Fragen zur Vorlesung)
    • Wie können Code Reviews durchgeführt werden? 
    • Welche Review Verfahren kennen Sie?
    • Welches Review Verfahren bietet sich für Code Reviews an?
    • Welche Java Namenskonventionen kennen Sie?
    • Wie können die Java Namenskonvention geprüft werden?
    • Welche Codemetriken sollten beachtet werden?
    • Was versteht man unter dem McCabe-Maß? Wie berechnet es sich? Wie nennt man es noch?
    • Was versteht man unter dem Begriff Refactoring?
    • Aus welchen Schritten besteht der Prozess für ein Refactoring?

    Links

    Freitag, 23. Oktober 2015

    Musterlösung Übung Komponententests und Testabdeckung

    Hier finden Sie eine Musterlösung in Form von zwei JUnit Tests für die erste Übungsaufgabe zum Thema Komponententests, geprüft wird die Klasse Quicksort:
    Link zur Musterlösung

    Donnerstag, 22. Oktober 2015

    Übungsaufgabe zu Komponententests

    Für die Komponente "quicksort" im Java Package "swqs.quicksort" soll ein Komponententest (Unit-Test) geschrieben werden. Die Komponente umfasst alle Klassen im Java Package.

    Schritt 0: Importieren des Beispiel-Projekts in Eclipse

    Dazu laden Sie sich die ZIP Datei herunter: DOWNLOAD

    Anschließend entpacken Sie das Archive und rufen das folgende Gradle Kommando auf:

      gradlew.bat eclipse



    (Linux und OSX Benutzer können das Kommando wie folgt aufrufen ./gradlew eclipse)

    Nun können Sie das Projekt in Eclipse importieren als existierendes Projekt.

    Hinweis für den Import in Eclipse:
    Für den Import die Funktion File > Import aufrufen.
     Das Verzeichnis mit dem entpackenten Projekt (ZIP) auswählen und den Finsh Button klicken.



    Schritt 1: Erstellen einer Unit Test Klasse 



    Geben Sie der Klasse den Namen QuicksortTest geprüft werden soll die Komponente Quicksort, die Test-Klasse sollte im Source-Folder "src/test/java" abgelegt werden


    Schritt 2: Schreiben eines Tests zum Sortieren des folgenden Arrays:


      new Integer[]{5, 6, 3};

    Schritt 3: Markieren Sie die 4 Phasen in Ihrer Unit Test Klasse

    Nutzen Sie dazu einfache Java Kommentare.


    Schritt 4: Messen der Abdeckung mittels Gradle oder Eclipse Plugin. 


    Dazu kann das Gradle Skript wie folgt aufgerufen werden:

      ./gradlew.bat

    Der Report mit der Abdeckung kann dem folgenden Ordner entnommen werden:
    swqs.quicksort\build\reports\tests\index.html

    Oder Sie installieren ein entsprechendes Eclipse Plugin z.B. EclEmma (http://eclemma.org/)

    Schritt 5: Erstellen eines Tests zum Sortieren des folgenden Arrays:


      new String[]{"xy", "aa", "bb"};



    Schritt 6: Identifizieren Sie weitere Testfälle 


    Versuchen Sie 100 % Anweisungsabdeckung zu erreichen und 100 % Zweigabdeckung.


    Optional Schritt 6: FEST Asserts 

    Nutzen Sie anstelle der JUnit Assertion API die FEST asserts
    siehe dazu https://github.com/alexruiz/fest-assert-2.x/wiki/Using-fest-assertions




    Hinweis - Eclipse Tooling für Coverage

    Um Coverage in Eclipse messen zu können müssen Sie eine Erweiterung installieren z.B. Code Cover oder EclEmma. Die Links zu den Eclipse Update Sites finden Sie hier.

    Installieren von Code Cover in Eclipse
    (siehe http://codecover.org/documentation/install.html)
    Name: CodeCover Update Site
    URL:  http://update.codecover.org/

    Installieren von EclEmma Eclipse Plugin
    (siehe auch http://www.eclemma.org/)
    Name: EclEmma
    URL:  http://update.eclemma.org/ 



    Mittwoch, 21. Oktober 2015

    Komponententests und Testabdeckung

    Download Folien (als PDF) hier.

    Lernziele:
    • Beschreiben Sie die Phasen in die ein Unit-Test aufgeteilt werden kann.
    • Welchen Teil einer Anwendung testet ein Komponententests?
    • Welche Qualitätskriterien sollten bei Komponententests (Modultests) geprüft werden?
    • Was bezeichnet der Begriff Testabdeckung?
    • Warum ist eine vollständige Testabdeckung i.d.R. nicht möglich?
    • Welche Methoden zur Bestimmung der Testabdeckung für White-Box (bzw. Gray-Box) Tests kennen Sie?
    • Wie bestimmen Sie die mögliche Anzahl der Pfade in einer Schleife? 
    • Was sind "Test Doubles" und wozu braucht man sie?
    • Welche unterschiedlichen Typen von "Test Doubles" kennen Sie?
    • Wann sollte man ein Mocking Werkzeug wie Mockito zum testen einsetzten?
    Werkzeuge Links

    Mittwoch, 7. Oktober 2015

    Einführung Software Qualitätssicherung

    Download

    Lernziele

    • Was ist Software-Qualität?
    • Was sind die Kriterien guter Software?
    • Wie kommt man zu guter Software?
    • Was versteht man unter konstruktive und analytischer Qualitässicherung?
    • Unterscheiden Sie die Begriffe Fehlerwirkung, Fehlerzustand, Fehlhandlung.
    • Was ist der Unterschied zwischen Testen und Debuggen?
    • Beschreiben Sie das Vier Phasen Test Muster. Welche Phasen gibt es und wozu dienen sie?
    • Wozu setzt man bei JUnit die Methoden setUp() und tearDown() ein?
    • Wie muss man vorgehen, um aus einer "normelen" Klasse eine Testklasse zu machen?
    • Welche Java Sprachfunktionen werden in JUnit 4 verwendet um eine Methode als Test zu markieren?

    ISO-9126 Attribute

    ISO-25010 Attribute

    Links

    Blog Software-Qualitätssicherung

    Herzlich Willkommen zur Vorlesung Softwarequalitätssicherung. Hier auf diesem Blog finden Sie alle Informationen (Folien, Hinweise zu Bücher, Links, etc.) zu der SWQS Vorlesung des WS1516. Es wird zur jeder Vorlesung ein Blogeintrag geben über den ich Ihnen alle Unterlagen zur Vorlesung bereitstelle.

    Am besten Sie abonnieren einfach den News-Feed dann bekommen Sie immer mit wenn es was neues rund um die Vorlesung gibt.

    Viele Grüße

    Christian Baranowski