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.

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.

Download Beispiel-Aufgaben

Testprozess Testmanagement und Testendekriterien

Download

• Folien

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

Ü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.

Weitere Testverfahren

Download Folien

• hier

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

• Apache JMeter - http://jakarta.apache.org/
• OWASP - The free and open application security community - http://www.owasp.org/
• OWASP Top 10 - http://www.owasp.org/index.php/Top_10_2010-Main
• Liste mit XSS Testeingaben - http://ha.ckers.org/xss.html

Ü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.

Systemtest und UI Tests

Download

• Folien

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

• Selenium Web-Driver - http://www.seleniumhq.org/
• Fluent Builder - http://www.martinfowler.com/bliki/FluentInterface.html

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

Ü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

• Folien

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:

	import static org.junit.Assert.*;
	import org.junit.Before;
	import org.junit.Test;
	import org.junit.runner.RunWith;
	import org.springframework.beans.factory.annotation.Autowired;
	import org.springframework.test.context.ContextConfiguration;
	import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
	import basar.domain.Seller;
	@RunWith(SpringJUnit4ClassRunner.class)
	@ContextConfiguration(locations={"/spring/dao.xml"})
	public class SellerDaoIntegrationTest {
	@Autowired
	SellerDao sellerDao;
	@Before
	public void setup(){
	sellerDao.clear();
	}
	@Test
	public void testCreateSeller() throws Exception {
	Seller seller = new Seller();
	seller.setBasarNumber(100L);
	seller.setName("Tester");
	sellerDao.insertSeller(seller);
	Seller actualSeller = sellerDao.getSeller(100L);
	assertEquals(seller, actualSeller);
	}
	}

view raw SellerDaoIntegrationTest.java hosted with ❤ by GitHub

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:

	import static org.junit.Assert.*;
	import java.io.InputStream;
	import java.sql.Connection;
	import java.util.List;
	import java.util.Map;
	import javax.sql.DataSource;
	import org.dbunit.database.DatabaseConnection;
	import org.dbunit.database.IDatabaseConnection;
	import org.dbunit.dataset.IDataSet;
	import org.dbunit.dataset.xml.XmlDataSet;
	import org.dbunit.operation.DatabaseOperation;
	import org.junit.Before;
	import org.junit.Test;
	import org.junit.runner.RunWith;
	import org.springframework.beans.factory.annotation.Autowired;
	import org.springframework.jdbc.core.simple.SimpleJdbcTemplate;
	import org.springframework.jdbc.datasource.DataSourceUtils;
	import org.springframework.test.context.ContextConfiguration;
	import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
	import org.springframework.test.context.transaction.TransactionConfiguration;
	import org.springframework.test.jdbc.SimpleJdbcTestUtils;
	import basar.domain.Seller;
	@RunWith(SpringJUnit4ClassRunner.class)
	@TransactionConfiguration(defaultRollback=false)
	@ContextConfiguration(locations = { "/spring/dao.xml" })
	public class SellerDaoTest {
	@Autowired
	private SellerDao sellerDao;
	protected SimpleJdbcTemplate simpleJdbcTemplate;
	private DataSource dataSource;
	@Before
	public void setUp() throws Exception {
	DatabaseOperation.CLEAN_INSERT.execute(getConnection(), getDataSet());
	}
	@Test
	public void testInsertSeller() throws Exception {
	Seller seller = new Seller();
	seller.setBasarNumber(new Long(130));
	seller.setName("Baranowski");
	sellerDao.insertSeller(seller);
	int countRowsInSellerTable = SimpleJdbcTestUtils.countRowsInTable(
	simpleJdbcTemplate, "seller");
	assertEquals(3, countRowsInSellerTable);
	List<Map<String, Object>> result = simpleJdbcTemplate
	.queryForList("select * from seller where basarnumber=130");
	assertEquals("Baranowski", result.get(0).get("NAME"));
	}
	@Autowired
	public void setDataSource(DataSource dataSource) {
	this.dataSource = dataSource;
	this.simpleJdbcTemplate = new SimpleJdbcTemplate(dataSource);
	}
	protected IDatabaseConnection getConnection() throws Exception {
	Connection connection = DataSourceUtils.getConnection(dataSource);
	return new DatabaseConnection(connection);
	}
	public IDataSet getDataSet() throws Exception {
	String name = "/" + getClass().getName().replace('.', '/')
	+ "DataSet.xml";
	InputStream resourceAsStream = getClass().getResourceAsStream(name);
	return new XmlDataSet(resourceAsStream);
	}
	}

view raw SellerDaoTest.java hosted with ❤ by GitHub

Literatur und Links

• Continuous Integration: Improving Software Quality and Reducing Risk - Paul M. Duvall, Steve Matyas, Andrew Glover - 2007
• Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation - Jez Humble, David Farley - 2010 
• Layer Test Pattern - http://xunitpatterns.com/Layer%20Test.html
• Back Door Manipulation - http://xunitpatterns.com/Back%20Door%20Manipulation.html
• Continuous Integration - http://www.martinfowler.com/articles/continuousIntegration.html
• Wikipedia Enterprise Service Bus - http://de.wikipedia.org/wiki/Enterprise_Service_Bus

Ü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

Integrationstests Teil II und TDD

Folien und Übungen

• Folien

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:

•  Continuous Testing plugin for Eclipse https://infinitest.github.io/

Literatur

• Test Driven Development. By Example - Kent Beck 2002
• xUnit Test Patterns: Refactoring Test Code - Gerard Meszaros 2007
• Andreas Spillner - Basiswissen Softwaretest - 2005
• Documentation Spring Testing Framework - http://static.springsource.org/spring/docs/current/spring-framework-reference/html/testing.html#integration-testing
• Integration Testing with Spring - http://www.infoq.com/presentations/system-integration-testing-with-spring

Musterlösung Übung zu Test-Doubles

Dependency Injection (DI) und Integrationstests

Folien

• 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

Ü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:

http://www.sonarqube.org/downloads/

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

Folien

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

• Tool um Code Konvention zu prüfen - http://checkstyle.sourceforge.net/
• Eclipse Plugin für Checkstyle - http://eclipse-cs.sourceforge.net/
• Eclipse Plugin für Metrics - http://metrics.sourceforge.net/
• McCabe Paper - http://www.literateprogramming.com/mccabe.pdf
• Findbugs - http://findbugs.sourceforge.net/
• javancss Werkzeug um Metriken für java code zu bestimmen - http://www.kclee.de/clemens/java/javancss
• Code Conventions for the Java Programming Language - http://www.oracle.com/technetwork/java/codeconv-138413.html

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

Ü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/ 

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

• JUnit - http://www.junit.org/
• Mockito - https://code.google.com/p/mockito/
• EclEmma - http://eclemma.org
• Code Cover - http://codecover.org/

Einführung Software Qualitätssicherung

Download

• Folien als PDF

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

• JUnit Homepage - http://www.junit.org/
• Linksammlung zu bekannten Software Fehlern -  http://www5.in.tum.de/lehre/seminare/semsoft/unterlagen_02/

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