Datum: 08. Dez. 2017, WS 2017
 
 
Dozent: Roy Meissner
Softwaretechnik - Seminar
 
Softwaretests und Testautomatisierung
  • Testen von Software
    • Code-Conventions und Metriken
    • Gebräuchlichste Arten von Tests
    • Schreiben von Integrationstests unter NodeJS
  • Testautomatisierung (Continuous Integration)
    • Was ist Testautomatisierung
    • Übersicht zu CI Pipelines
    • Beispiel anhand von Gitlab CI
    • Workflows
  • Auslieferung
    • Was ist Continuous Delivery/Deployment?
    • Wann sollte es eingesetzt werden?
    • Beispiel anhand von Gitlab CI
Lernziele
Übersicht mit hervorgehobenen Seminarthemen
Unit-Tests testen konkrete Funktionen und nur diese Funktionen. Bei Funktionsabhägigkeiten muss Mocking verwendet werden. Mocking ersetzt Funktionen durch einfachere Konstrukte (bspw. feste  Datenstrukturen).

Integration-Tests testen Funktionen und Interfaces (APIs). Mocking ist nicht notwendig, da das Gesamtkonstrukt getestet wird.

Interface-Tests (UI) testen UI-Komponenten und werden typischerweise von Nutzern aufgezeichnet (recorded) um später automatisch abgespielt werden zu können. Das ist sehr fehleranfällig bei UI-Veränderungen (bspw. style changes).
Arten von Tests
Es existieren Programme um Code-Conventions zu testen, sowie Metriken zu berechnen und auszuwerten.

Im Scriptsprachenumfeld heißen Code-Convention checker ”Linter” und testen den Code auf versch. Regeln ab. Beispiel:

- Die Einrücken beträgt je Einrückungsebene immer zwei Leerzeichen
- If/else-Statements sind immer mit Klammern zu schreiben

Metriken können beliebig komplexe Werte errechnen, sind jedoch oft auf statische Analysen beschränkt. Vorsicht vor metrikbasierten Regeln! Diese haben zur Folge das die Metrik erfüllt wird, verbessern aber nicht unbedingt das zugrundeliegende Problem. Beispiel:
 
- Code-Coverage muss bei über 75% liegen -> Das heißt nicht, dass die
Tests sinnvoll sind!
 
 
Code-Conventions und
Metriken
CI führt bei jedem hochgeladenem Commit eines Repositories (bspw. aufGitlab) festgelegte Scripte aus, die den Zustand des Commits bewerten. Beispiele:
 
  • Check von Code-Conventions
  • Ausführen aller Arten von Tests (Unit, Integration, Interface, ...)
  • Statische Analyse des Codes, Metrikbestimmung und Regeltests
  • Kompilieren der Software
  • ...
 
Bei Fehlschlag eines Scripts wird sofort gewarnt (bspw. per E-Mail). Damitgeht eine Art Instant-Feedback einher, das die Qualität der
Softwareentwicklung nachhaltig verbessert.

Continuous Integration

Übung
CD verpackt die Software nach erfolgreicher (!) CI. Nachfolgend wird diese ausgeliefert (Delivery) und ggf. auch gestartet (Deployment). Dabei gibt es kaum Standards und es müssen eigens Scripte Beschrieben werden.
Beispiel:

Eine Anwendung hat alle Tests und metrikbasierten Regeln durch CI bestanden. Nachfolgend werden von der Anwendung Installer-Pakete für den Windows, Mac und einige Linux Stores/Paketmanager gebaut und in die Verteilzentren (Paket-Repositories) hochgeladen  Continuous Delivery). Letzteres ist darauf beschränkt, dass ein Release Tag im Git Repository erzeugt wird.

Das Linux Paket wird immer (also auch ohne Release Tag) per SSH auf einen Server übertragen und installiert. Nachfolgend wird die noch laufende Software beendet und mit dem Update neu gestartet  Continous Deployment).

Continuous Deployment(CD)
Es existieren verschiedene Arten von Dokumentation. Bspw.:
 
  • API Dokumentation
  • Code Dokumentation
  • Installer Dokumentation
  • Architektur Dokumentation
  • u.v.m.
 
Oft kann Dokumentation direkt aus Kommentaren oder Ergänzungen am Code generiert werden, wie beispielsweise mit JavaDoc über Code-Kommentare die Java Dokumentation erzeugt wird. Die API Dokumentation im verlinkten Repository auf Folie 6 wird über Ergänzungen in der Datei routes.js automatisch erzeugt.

Dokumentation
Software wird zu Ausflieferungszwecken für gewöhnlich packetiert. Das kann erfolgen als:
 
  • Archiv des Kompilats oder Quellcodes (bspw. ZIP)
  • Installer Pakete
    • Microsoft - .msi, .exe, ...
    • Linux - .rpm, .deb, ....
    • Mac - .pkg
  • WAR files für Webserver (bspw. Apache Tomcat oder RedHat JBoss)
 
Bei OSS Entwicklung finden sie oft die oben erwähnten Formate in der Releases/Tag Sektion von Github/Gitlab.
 
Elaborierte Paketformate (bspw. Installer) integrieren sich nahtlos in das System und liefern bspw. eine Liste mit zu installierenden Abhängigkeiten, optionalen Erweiterungen und möglichen Sprachen aus.

Packetierung