Im folgenden sollen einige Maßnahmen erläutert werden, welche der Erhöhung der Softwarequalität dienen.

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.

Beispiel mit JUnit

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

public class DateUtils {
  public String getDayOfWeekName(int day) {
    if(day == 1) {
      return "Montag";
    } else if(day == 2) {
      return "Dienstag";
    } else if(day == 3) {
      return "Mittwoch";
    } else if(day == 4) {
      return "Donnerstag";
    } else if(day == 5) {
      return "Freitag";
    } else if(day == 6) {
      return "Samstag";
    } else if(day == 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. Dies wäre Beispielsweise das Testen von einer Klasse. Ein konkretes Beispiel hierfür ist hier zu finden.

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.

CI/CD

Continous Integration und Continous Delivery sind eng verknüpft miteinander. Durch Continous Integration wird ein höheres maß an Qualität erreicht, Continous Delivery bietet durch automatisiertes ausliefern der Software hohen Komfort und Zeitersparnis, da dies nicht mehr manuell gemacht werden muss.

Continous Integration

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

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.
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 gewisse 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. Anwendungen für Continous Integration verfügen oft über ein integriertes Git und bieten die Möglichkeit, Repositories anzulegen und zu verwalten.
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

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 die Continous Integration anbieten, sind meist auch für Continous Delivery geeignet, deswegen sind die Beispiele gleich wie hier.

Versionskontrolle - Git

Git ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die durch Linus Torvalds initiert wurde.^[1] Git wurde entwickelt um die Versionsverwaltung BitKeeper, die zuvor für den Quellcode des Linux Kernels verwendet wurde, zu ersetzen.

Eine Versionsverwaltung von Dateien soll es ermöglichen die Änderungen, die an Dateien vorgenommen wurden, nachzuvollziehen. Weiters sollen diese unterschiedlichen Versionen abgerufen oder wiederhergestellt werden können. So kann bei einem Auftreten eines Fehlers, vorallem wenn Continous Integration eingesetzt wird, sehr schnell festgestellt werden, wo der Fehler seinen Weg in den Quellcode fand.

Git ist eine verteilte Versionsverwaltung da das Repository selbst, nicht nur auf dem Server der dieses bereitstellt sondern, auch auf jedem Client der das Repository verwendet, vorhanden ist. Ein Repository kann somit, ohne große Probleme, durch den Client von einem Remote, zu einem anderen Remote gewechselt werden.

Remote

Ein Git Repository kann mit einem oder mehreren Remotes verknüpft sein. Ein Remote ist ein Server der das Repository erstellt hat und dieses bereitstellt. Die Verbindung zum Remote vom Client aus, findet meist über die Protkolle HTTP oder SSH statt. Der initiale Remote wird als origin (Ursprung) bezeichnet. Weitere Remotes können mit beliebigen Namen hinzugefügt werden:

#Fügt ein weiteres Remote mit dem Namen 'backup' hinzu
git remote add backup https://gitlab.drlue.at/root/webservice.git

Soll bei einer Aktion nun das Remote backup angesprochen werden, so wird im Befehl anstatt origin backup verwendet:

#Holen der änderungen von 'origin' (vom Ursprung)
git pull origin main
#Holen der änderungen von 'backup'
git pull backup main

Arbeitsverzeichnis

Die Dateien im Git Repository entsprechen immer dem Stand des aktuell aktiven Commits inklusive der lokalen Änderungen, welche noch zu keinem Commit gehören, die gemacht wurden. Wird beispielsweise mit dem Befehl reset das Repository auf einen anderen Commit zurückgesetzt, so ändern sich auch die Dateien im Verzeichnis.

Branch

Wird ein neues Repository geklont so gibt es initial noch keinen Branch. Mit dem ersten Commit wird der Master (jetzt Main) Branch erzeugt. Wird ein neuer Branch erstellt, so zweigt die Code Basis vom aktuellen Branch ab. Der letzte Commit des aktuellen Branches bildet somit die Basis des neuen Branches. Somit ist ein Branch eine Abzweigung weg vom aktuellen Branch: Main Branch. Folgende Abbildung zweig wie so eine Verzweigung aussehen kann:

Nach dem Branches abgezweigt wurden, so können sich diese natürlich (bzgl. ihrer Commits) unterschiedlich weiter entwickeln. Sollen sie wieder zusammengeführt werden, so gibt es zwei Möglichkeiten:

Mergen - Verschmelzen
Rebasen - Die Basis von der abgezweigt wurde, wird auf eine andere Basis geändert.

Wird ein Repository (mit bestehenden Branches) geklont, so kann es initial so aussehen:

git branch -a
>>* master
>>  remotes/origin/HEAD -> origin/master
>>  remotes/origin/feature_login
>>  remotes/origin/feature_logout
>>  remotes/origin/master

Alle Zeilen beginnend mit remotes beschreiben einen Branch der auf dem Remote, also auf dem Server, vorhanden ist. Die anderen Zeilen sind Branches welche lokal verfügbar sind, in diesem fall nur der master Branch. Diese spiegeln den Stand des Servers bei der letzten Aktualisierung wieder. Mit git fetch, siehe fetch, können diese Remote Branches aktualisiert werden. Soll nun einer dieser Branches verwendet werden, so geschieht dies mit git checkout, siehe checkout. Mit dem Befehl git checkout feature_login wird nun eine lokale Version des Remote Branches erstellt:

git checkout feature_login
>>Branch 'feature_login' folgt nun Remote-Branch 'feature_login' von 'origin'.
>>Zu neuem Branch 'feature_login' gewechselt
git branch -a
>>* feature_login
>>  master
>>  remotes/origin/HEAD -> origin/master
>>  remotes/origin/feature_login
>>  remotes/origin/feature_logout
>>  remotes/origin/master

Der lokale Branch ist nun ersichtlich in Zeile 1.

Feature Branch Modell

Commit

Ein Commit beschreibt eine Abgeschlossene Einheit von Veränderungen. In einem Commit können neue, geänderte, oder gelöschte Dateien enthalten sein. Ein Commit enthält einen Schnappschuss aller geänderten Dateien zum Vorhergehenden Commit. Ein Commit enthält zusätzlich zu den geänderten Dateien noch weitere Daten:

Autor
Datum
Eindeutiger Hash Wert. Über diesen kann ein Commit angesprochen bzw. referenziert werden

Im folgenden Beispiel ist das zurücksetzen der lokalen Dateien auf einen bestimmten Commit ersichtlich, weiters wird ein Beispiel Output von git log gezeigt:

git log
>>...
>>commit 29b645bf9c1a4dd54dcb51026390231729287cc8
>>Author: Luke <luke@luke.at>
>>Date:   Tue Feb 2 08:44:33 2021 +0100
>>
>>    - Fastlane update.
>>...
//Zurücksetzen des lokalen Codes auf obigen commit
git reset --hard 29b645bf9c1a4dd54dcb51026390231729287cc8

Wichtige Befehle

Folgend sollen einige wichtige Git Befehle erläutert werden. Diese beginnen immer mit git und sind somit eigentlich nur Parameter des Programmes git.

clone

Um ein Repository zu clonen wird der Befehl git clone verwendet. Gefolgt von der URL und optional kann auch ein Name für den lokalen Ordner des Repositories angegeben werden, wird kein Name angegeben, so wird der Ordner von der URL abgeleitet. Folgender Befehl wird das Repository in den Ordner webservice clonen:

git clone https://gitlab.drlue.at/root/webservice.git

Folgend soll das clonen des Repositories in den Ordner backup erfolgen:

git clone https://gitlab.drlue.at/root/webservice.git backup

add

Um gelöschte, geänderte oder neue Dateien einem Commit hinzuzufügen, müssen diese zuerst gestaged, also der Staging Area hinzugefügt, werden. Dies geschieht mit dem Befehl git add. Den kann man sich wie ein Packet vorstellen, zuerst werden Dinge hineingegeben git add, ist alles gewünschte drinnen, wird das Packet mit git commit verschlossen. git add nimmt als Parameter reguläre Ausdrücke (*.txt), mehrere Dateinamen (a.txt b.txt c.txt) oder auch einen . (alle Änderungen hinzufügen).

commit

Mit dem Befehl git commit werden alle Änderungen in der Staging Area in einen Commit verpackt und mit einem Text versehen.

checkout

Der Befehl git checkout hat mehrere Funktionen:

Änderungen von Dateien können rückgängig gemacht werden. Dies betrifft nur die Änderungen die passiert sind seit dem letzten Commit. Gleich wie bei add, kann dies ein regulärer Ausdruck, mehrere Dateinamen oder ein . sein.
Neue Branches können mittels git checkout -b [Branchname] erstellt werden, oder es kann zu einem anderen Branch mit git checkout [Branchname] gewechselt werden.

fetch

git fetch optional mit nachgestelltem Parameter, holt alle Änderungen vom Server und aktualisiert damit die Remote Branches, also die Kopie der Branches auf dem Server. Die lokal verwendeten Branches werden jedoch nicht verändert.

push

Mittels git push können lokale Commits an einen Branch auf einem Remote gesendet werden.
Angenommen es wurden Commits im Branch feature_login gemacht, und diese Commits sollen an den Remote origin gesendet werden:

git push origin feature_login

Die Änderungen sollen weiters an den Remote backup gesendet werden:

git push backup feature_login

Existiert der Branch noch nicht auf dem Remote, so wird dieser erstellt.

branch

Der Befehl git branch -a zeigt alle Branches in einem Repository an. Die lokalen und die Remote Branches. git branch zeigt nur die lokalen Branch an.

pull

Mit dem Befehl git pull werden Änderungen von einem Remote Branch in den aktiven lokalen Branch geholt. Kann der lokale Branch nicht vorgespult werden, so findet ein Merge statt. Folgendes Beispiel illustriert das holen vom Remote origin feature_login Branch:

git pull origin feature_login

Im folgenden werden die neuen Commits vom Remote backup geholt:

git pull backup feature_login

merge

Siehe Merge.

rebase

Siehe Rebase.

log

Der Befehl git log zeigt die Commit History an. Also die Geschichte der Commits sortiert von neu bis alt.

status

Der Befehl git status, zeigt den aktuellen Status des Arbeitsverzeichnisses an:

Welche Dateien wurden gelöscht oder verändert
Welche Dateien sind neu hinzugefügt worden, also nicht nicht mit dem Git Repository verbunden
Welche Dateien wurden bereits getstaged und befinden sich somit in der Staging Area, siehe add
In welchem Branch befindet man sich gerade

reset

git reset hat mehrere Funktionen:

Wird gleich wie bei add oder checkout ein Regulärer Ausdruck, mehrere Dateinamen, oder . als Parameter verwendet, so werden Dateien aus der Staging Area (siehe add) entfernt.
Wird ein Commit Hash angegeben, so wird der aktuelle lokale Branch auf diesen Commit zurückgesetzt.

diff

git diff ohne zusätzliche Parameter, listet alle Änderungen im Arbeitsverzeichnis auf. Anstatt git diff kann auch git difftool verwendet werden, dann wird das aktive Difftool gestartet. Weiters kann git diff mehrere Parameter erhalten:

Eine spezielle Datei, dann werden nur die Änderungen dieser Datei angezeigt
Zwei Commit Hashes, es werden die Unterschiede zwischen den Commits angezeigt
Zwei Branches, es werden die Unterschiede zwischen den Branches angezeigt
HEAD HEAD~11, Unterschied zwischen dem obersten Commit (HEAD) und 11 Commits zurück.

Hooks

Mittels Git Hooks kann auf gewisse Git Aktionen auf dem Server, welcher das Git Repository hostet, gehorcht werden.

Es gibt auch Client-Side Hooks. Diese ermöglichen auch das Horchen auf Aktionen auf dem Rechner des Clients, hierbei werden aber nicht alle Aktionen unterstützt. Beispielsweise Post Push (nach dem gepusht wurde), da Änderungen nur auf ein Remote gepusht werden.

Tritt eine solche Aktion ein, so kann beispielsweise ein Programm ausgeführt werden. Git Hooks sind sehr nützlich für Continous Integration und Continous Delivery. Durch ein pushen von Änderungen, können diese gestartet werden.

Branches zusammenführen

Wenn Branches immer weiter auseinander gehen, so wird es dann auch irgendwann mal Zeit, diese wieder zusammenzuführen. Dafür gibt es zwei Varianten, die im folgenden erklärt werden sollen.

Merge

git merge ist im Gegensatz zu git rebase eine nicht inversive Methode um Branches zusammenzuführen. Die Commit History wird nicht beschädigt. Branches werden mit einem einzelnen Merge Commit angeglichen. Bildet ein Branch die Basis eines Anderen, so kann ein Fast Forward erfolgen, und es gibt keinen Merge Commit. Durch das verwenden von Merge erhält man eine etwas komplexere Commit History mit vielen Ausbuchtungen. Der Vorteil ist, dass alle Änderungen, die durch den Merge gemacht wurden, nachvollzogen werden können. Folgende Grafik illustriert das mergen von Änderungen des Feature Branch in den Master Branch:

Folgendes Beispiel soll das das Mergen vom feature Branch in den Master Branch wie in der Abbildung veranschaulichen:

#Wir befinden uns aktuell im feature Branch
#Wechsel in den master Branch
git checkout master
#Merge starten
git merge feature
#Treten Konflikte auf, so müssen diese über
git mergetool
#und ein anschließendes
git merge --continue
#behoben werden
#Nun kann der Push auf den Remote master Branch erfolgen
git push origin master -f

Rebase

git rebase eignet sich nur wenn an einem eigenen Branch gearbeitet wird und die Änderungen von einem anderen Branch geholt werden sollen. Rebase ist nur geeignet für einen eigenen Branch, da die Commit History umgeschrieben wird. Die Commits des anderen Branches werden unter die eigenen Commits geschoben, die Basis des Branches wird geändert. Durch Rebasing erhält man eine sehr geradlinige Commit History:

Soll nach einem Rebase erneut auf den eigenen Branch gepushed werden so ist ein git push -f, ein force push nötig, da der lokale Branch nicht mehr mit dem Branch auf dem Remote zusammenpasst. Folgendes Beispiel soll das das Rebasen vom feature Branch mit dem Master Branch wie in der Abbildung veranschaulichen:

#Wir befinden uns aktuell im feature Branch
#Wechsel in den master Branch
git checkout master
#Änderungen holen
git pull origin master
#Zurückwechseln in Feature Branch
git checkout feature
#Rebase starten
git rebase master
#Treten Konflikte auf, so müssen diese über
git mergetool
#und ein anschließendes
git rebase --continue
#behoben werden
#Nun kann der Push auf den Remote feature Branch mit force push erfolgen
git push origin feature -f

Hier sei Angemerkt, dass die Konfliktlösung theoretisch für jeden Commit über der Basis (in der Grafik sind es zwei) durchgeführt werden muss (Zeile 11-13), wenn dies nicht automatisch erfolgen kann.

Rebase/Merge

Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem Feature gearbeitet, so erfolgt zuerst ein Rebase mit dem Zielbranch und dann wird in den Zielbranch gemerged. Dadurch bleibt die History geradlinig, jedoch gehen die Information was im Feature Branch gemacht wurde verloren:

1) Ausgangssituation^[3]
2) Feature Branch wird mit Master Branch rebased^[3]
3) Merge von Feature Branch in den Master Branch^[3]

Qualitätskontrolle Pull/Merge Requests

Für eine leichtere Lesbarkeit wird im Folgenden nur noch von Merge Request gesprochen. Je nach verwendetem Git System wird ein anderer Begriff dafür verwendet:

System	Bezeichnung
Github	Pull Request
Bitbucket	Pull Request
Gitlab	Merge Request

In größeren Softwareprojekten, erfolgt die Qualitätskontrolle sehr oft über Merge Requests. Wird ein neues Feature entwickelt, so erfolgt eine Abzweigung vom aktuellen Entwicklungsbranch development Branch (natürlich ist auch das Abzweigen von anderen Branches möglich). Der Entwickler programmiert, commitet und pusht, solange an dem Feature gearbeitet wird, nur im eigenen Branch. Von Zeit zu Zeit kann es nötig sein, dass der eigene Branch mit den Änderungen aus dem development Branch aktualisiert werden muss, dies kann über merge oder rebase stattfinden. Ist das Feature abgeschlossen, so startet der Merge Request. Dieser wird meist über die Webseite des verwendeten Git Systems gestartet. Ein anderer Entwickler erhält den Merge Request und übernimmt die Qualitätskontrolle, den Peer Review. Dabei wird die Funktionalität, Coding Conventions, usw. geprüft. Gibt es nichts zu beanstanden, so erfolgt, der eigentliche Merge in den gewünschten Branch. Ansonsten wird der Merge Request für weitere Verbesserungen zurückgewiesen und muss dann erneut gestellt werden.

Beispiel

Im folgenden Beispiel soll veranschaulicht werden wie zwei Branches zusammengeführt werden:

Das Repository: https://gitlab.drlue.at/root/webservice.git
Branch feature_login soll in development gemerged und anschließen gepusht werden

#Clonen des Repositories
git clone https://gitlab.drlue.at/root/webservice.git
#Wechseln in das Eigentliche Repository
cd webservice
#Initial befinden wir uns im Main Branch und wechseln auf feature_login.
#Dies ist nötig, da nach dem clonen noch keine lokale Version von feature_login vorhanden ist, nur die Remote Version
git checkout feature_login
#Wechseln auf development, damit auch dieser Branch lokal verfügbar ist
git checkout development
#Merge durchführen
git merge feature_login
#Treten Konflikte auf, so müssen diese über
git mergetool
#und ein anschließendes
git merge --continue
#behoben werden
#Nun kann der push erfolgen
git push origin development

[1] ttps://de.wikipedia.org/wiki/Git

[2] ttps://dzone.com/articles/feature-branching-using-feature-flags-1

[git_graphics-3] 3,0 ^3,1 ^3,2 ^3,3 ^3,4 https://gcapes.github.io/git-course/10-rebasing/

[1]

[2]

[3]

Softwarequalitätsmanagement