Softwarequalitätsmanagement

Testing

Softwaretesting beschreibt den Prozess des verifizierens einer Anwendung, oder Teile davon, gegenüber einer gewissen Spezifikation, oder gegen ein erwartetes Verhalten. Durch Testing kann ein hohes Maß an Softwarequalität gewährleistet werden, natürlich nur wenn Tests gut spezifiert und auch ausgeführt werden. Gerade im Bereich des automatisierten Testens kann durch eine hohe Testabdeckung des Quellcodes, Regression, verhindert werden.

Eine hohe Testabdeckung, beschreibt, wieviel Code durch Testfälle auch wirklich erreicht wird. Werden alle Verzweigungen in Methoden erreicht? Werden überhaubt alle Methoden getestet?

Unter Regression wird eine Verschlechterung des Quellcodes verstanden. Im Laufe des Entwicklungsprozesses funktioniert Code, der zuvor funktionert hat, auf einmal nicht mehr.

Anhand von folgendem Beispiel soll die Testabdeckung einer Java Klasse mit dem Testframework JUnit veranschaulicht werden:

public class DateUtils {
  public String getDayOfWeekName(int month) {
    if(month == 1) {
      return "Montag";
    } else if(month == 2) {
      return "Dienstag";
    } else if(month == 3) {
      return "Mittwoch";
    } else if(month == 4) {
      return "Donnerstag";
    } else if(month == 5) {
      return "Freitag";
    } else if(month == 6) {
      return "Samstag";
    } else if(month == 7) {
      return "Sonntag";
    }
    return "Unbekannt";
  }
}

Das Programm verfügt über eine Methode, welche 8 verschieden Verzweigungen hat.
Testabdeckung von 50%:

@Test
public void testDayOfWeekName() {
  DateUtils utils = new DateUtils();
  assertEquals("Montag", utils.getDayOfWeekName(1));
  assertEquals("Dienstag", utils.getDayOfWeekName(2));
  assertEquals("Mittwoch", utils.getDayOfWeekName(3));
  assertEquals("Donnerstag", utils.getDayOfWeekName(4));
}

Testabdeckung von 100%:

@Test
public void testDayOfWeekName() {
  DateUtils utils = new DateUtils();
  assertEquals("Montag", utils.getDayOfWeekName(1));
  assertEquals("Dienstag", utils.getDayOfWeekName(2));
  assertEquals("Mittwoch", utils.getDayOfWeekName(3));
  assertEquals("Donnerstag", utils.getDayOfWeekName(4));
  assertEquals("Freitag", utils.getDayOfWeekName(5));
  assertEquals("Samstag", utils.getDayOfWeekName(6));
  assertEquals("Sonntag", utils.getDayOfWeekName(7));
  assertEquals("Unbekannt", utils.getDayOfWeekName(8));
}

Testabdeckung von 0%:

@Test
public void testDayOfWeekName() {
  DateUtils utils = new DateUtils();
}

Testansätze

Es gibt verschiedene Ansätze wie Tests entwickelt und ausgeführt werden können. Im folgenden sollen die Box Ansätze kurz erläutert werden.

White Box

Der zu testende Quellcode ist bekannt, das Test Design kann sich am Code orientieren um alle Verzweigungen zu erreichen. Weiters können auch Teile des Codes, welche nicht nach außen hin Sichtbar sind, getestet werden. Unit Tests fallen Normalerweise in diese Kategorie. Durch White Box Tests kann eine hohe Testabdeckung des Codes erreicht werden.

Black Box

Über den Quellcode sind keine Informationen bekannt. Die Tests richten sich lediglich nach den nach außenhin sichtbaren Schnittstellen, die ein Programm bereitstellt. Dieser Ansatz ist für alle Teststufen geeignet.

Grey Box

Informationen über den Quellcode sind vorhanden, beispielsweise über Reverse Engineering. Zum Testen werden jedoch wie bei den Black Box Tests, lediglich die nach außenhin sichtbaren Schnittstellen werden verwendet.

Teststufen

Testing kann in verschiedene Stufen unterteilt werden, die im folgenden Angeführt werden. Im folgenden von fein bis grob:

Unit Test

Beschreibt das Testen auf Modul- oder Komponentenebene. Hierbei sollen abgrenzbare Teile eines Programmes getestet werden. Ein einfaches Beispiel dafür wäre das Testen von einer Klasse.

Integration Test

Beim Integrations Test wird das zusammenspiel unterschiedlicher Komponenten miteinander getestet.

System Test

Beim System Test wird das gesamte System gegen alle Anforderungen getestet. Beim Test soll die Produktivumgebung des Kunden simuliert werden.

Abnahme Test

Der Abnahme Test ist das testen des gesamten Systems durch den Kunden.

Continous Integration

Continous Integration beschreibt einen kontinuierlichen, automatisierten Prozess der im wesentlichen aus zwei Bestandteilen besteht:

1. Dem kontinuierlichen Bauen der Software - Der Quellcode wird automatisch kompiliert, zusammengebaut. Dadurch können schwere Fehler, die das erstellen des Programmes verhindern direkt erkannt werden.
2. Dem kontinuierlichen Testen der Software - Automatisierte Tests werden automatisch ausgeführt. Somit können effektiv Regressionen verhindert werden und die Softwarequalität bleibt hoch.

Unter kontinuierlich wird in diesem Kontext immer fortwährend oder andauernd verstanden. Natürlich läuft die Continous Integration nicht immer, sondern wird durch gewissen Ereignisse getriggert (gestartet). 

Dieser kontinuierliche Prozess wird sehr oft in Kombination mit Git verwendet. Über Git Hooks, kann der Integrationsprozess gestartet werden, z.B. wenn Änderungen auf einen gewissen Branch gepusht werden.
Schlägt die Continous Integration nach einer Änderung fehl, so kann der Entwickler der für diese Änderung verantwortlich ist, beispielsweise via Email automatisch informiert werden.

Anwendungen

• Gitlab
• Jenkins
• Github

Continous Delivery

Continous Delivery beschreibt den automatisierten Prozess des Deployments. In diesem Kontext beschreibt Deployment das ausliefern der Software. Gleich wie Continous Integration wird Continous Delivery durch gewisse Ereignisse getriggert, und steht meist in der Pipeline hinter der Continous Integration.
Zuerst wird die Software gebaut, dann ausgeliefert.
Die Auslieferung der Software kann je nach Anwendung und Szenario variieren. Dies könnte Beispielsweise sein:

• Hochladen auf den Playstore/Appstore
• Versenden der Software per Email
• Hochladen der Software auf eine Webseite
• Eine neue Webseite zur Verfügung stellen
• Einen Docker Container mit einem neuen Image aktualisieren

Anwendungen

Anwendungen die Continous Integration anbieten, sind meist auch für Continous Delivery geeignet, deswegen sind die Beispiele gleich wie hier: Continous Integration