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