Testkonzept - Teststufe Modultest

Der Modultest, auch als Unit-Test bekannt, stellt eine der grundlegendsten und wichtigsten Stufen im Softwaretestprozess dar. Es handelt sich hierbei um die Überprüfung einzelner Softwarekomponenten – wie Klassen, Module oder Skripte – auf ihre Funktionalität und Konformität mit den vorgegebenen Spezifikationen. Diese Tests sind entscheidend für die frühe Identifikation von Fehlern innerhalb einer Komponente, bevor diese in eine größere Systemumgebung integriert wird.

Modultests sind darauf ausgerichtet, jede einzelne Komponente isoliert von anderen zu testen, um ihre korrekte Funktionsweise sicherzustellen. Dies schließt funktionale und nichtfunktionale Aspekte ein, wobei insbesondere die Fehlerbehandlung und die Reaktion auf Grenzwerte oder unerwartete Eingaben von besonderer Bedeutung sind. Durch die Fokussierung auf einzelne Module können Entwickler Fehler effizient korrigieren, ohne die Risiken von Seiteneffekten in anderen Teilen des Systems.

Wichtige Schritte im Modultest

Vorbereitung und Planung
- Definition der Zielkomponenten für die Modultests basierend auf der Systemarchitektur und Technologie.
- Festlegung von klaren und messbaren Testkriterien, die aus der Software-Spezifikation abgeleitet werden.
Testfallerstellung
- Entwicklung von Testfällen, die alle Funktionspfade der Komponente abdecken.
- Einbeziehung von Tests zur Überprüfung der Fehlerbehandlung und der Reaktion auf außergewöhnliche oder ungültige Eingabewerte.
Testdurchführung
- Ausführung der Modultests in einer isolierten Entwicklungsumgebung, um Interferenzen mit anderen Komponenten zu vermeiden.
- Nutzung spezialisierter Tools und Frameworks wie JUnit für Java, NUnit für .NET oder andere entsprechende Tools je nach Programmiersprache.
Überprüfung und Analyse
- Bewertung der Testergebnisse im Hinblick auf das Erfüllen der spezifizierten Anforderungen.
- Identifizierung und Dokumentation von Diskrepanzen und Fehlverhalten.
Dokumentation und Bericht
- Umfassende Dokumentation der Testergebnisse, einschließlich einer Beschreibung der durchgeführten Tests und festgestellten Fehler.
- Erstellung von Berichten, die den Entwicklern klare Informationen über erforderliche Korrekturen bieten.
Fehlerbehebung und Nachtest
- Behebung identifizierter Probleme basierend auf den Testergebnissen.
- Wiederholung der Tests zur Verifikation der durchgeführten Korrekturen.

Komponenten Test

Ein Modultest wird häufig auch als Komponenten Test bezeichnet. Unter dem Begriff Komponente ist also der Test einer einzelnen Komponente (Modul) in einer komplexen - aus mehreren Komponenten bestehenden – Software zu verstehen.

Der Komponententest sollte erfolgreich abgeschlossen sein, bevor das Zusammenspiel der Komponente mit anderen Komponenten im Integrationstest überprüft wird.

Der Komponententest ist das Testen einer (einzelnen) Komponente, also der kleinste Softwareeinheit, die für sich getestet werden kann [= erste Teststufe des V-Modells nach ISTQB (International Software Testing Qualifications Board)].

Ziele der Teststufe

Beim Modultest wird aus Entwicklersicht geprüft, ob die technischen Vorgaben (funktionale als auch nicht-funktionale Anforderungen, Architektur, Programmierrichtlinien) korrekt umgesetzt wurden und die formalen Aspekte (Feldlänge, Syntax, etc.) der Benutzerschnittstelle den Anforderungen entsprechen.

Primär wird hierbei die technische Realisierung, also der Programmcode und dessen Konsistenz zum DV-Konzept, und weniger die fachliche Korrektheit der implementierten Funktionen betrachtet.

Der Modultest wird in der Regel vom Entwickler selbst durchgeführt.

Prinzipiell lassen sich für den Modultest sowohl statische als auch dynamische Softwaretest-Methoden anwenden. Statische Test-Methoden sollten jedoch stets ergänzend hinzugezogen werden (z.B. maschinelle Code-Inspektion auf Basis in Metriken abgebildeter Programmierregeln).

Unter Metriken versteht man die Messskala sowie das genutzte Messverfahren

Beim Modultest wird lediglich die Funktionalität eines einzelnen Moduls untersucht. In der Regel werden programmierte Modultests durchgeführt. Dabei codieren die Entwickler explizit die Testfälle, die sie auf die Funktionen der Module der Anwendung anwenden. Im Quelltext hinterlegte Zusicherungen werden geprüft und Abweichungen gemeldet. Hierbei müssen die erwarteten Ergebnisse genauso überprüft werden wie das korrekte Verhalten bei fehlerhaften Eingabe-Daten.

Es ist zu testen, ob die in den technischen Vorgaben beschriebenen Anforderungen richtig umgesetzt worden sind. Die Anforderungen umfassen sowohl das DV-Konzept als auch formale Prüfungen (z.B. Plausibilitätsprüfungen), ggf. Datenbankschnittstellen und gültige Programmierrichtlinien, wie beispielsweise Standards für das Layout von Benutzeroberflächen (z.B. Masken, Listen).

Aufgrund der unmittelbaren Entwicklungsnähe lassen sich im Modul-Test auftretende Abweichungen oft sofort lokalisieren und mit geringem Aufwand beheben. Die Ergebnisse der Tests sind zu dokumentieren.

Testobjektabgrenzung

Die Testobjektabgrenzung ist in Abhängigkeit des Projektes technologie-spezifisch festzulegen. Hierbei sind Aspekte der Software-Architektur, der benutzten Programmiersprachen sowie Erfahrungswerte aus vorherigen Tests zu berücksichtigen.

Es kann sich dabei handeln um:

» Steuerprogramme (Online / Batch)

» Klassen (SAP-Objects, C#-Klassen, .net-Komponenten, etc.)

» Makros

» Module/ Views, die der Datenversorgung dienen (Datenbankschnittstellen)

» Module, die fachliche oder technische Funktionen ausführen

» Masken/ Listen oder Datenobjekte wie z.B. DB-Tabellen, Schnittstellen etc.

Ob ein Modul ein separates Testobjekt wird oder zusammen mit anderen Modulen zu einem Testobjekt zusammengefasst wird, richtet sich nach der Modularisierungstiefe und der daraus abgeleiteten Testtiefe innerhalb des Modulbaumes. Mehrfach verwendbare Komponenten sollten immer separat getestet werden.

Die Strukturierung und Auswahl der Testobjekte liegt grundsätzlich in der Verantwortung von einem Testmanager bzw. Testkoordinator und soll die korrekte Umsetzung des DV Konzeptes sicherstellen.

Risikoanalyse

Das Risiko kann generell methodisch, aber auch über vorhandene Erfahrungswerte ermittelt werden.

Bei der Risikoanalyse für den Modultest sind neben der technischen Sicht auch fachliche Aspekte, wie Kritikalität und Erfahrungswerte zu berücksichtigen. Hierbei sind neben den technischen Komplexitätsbetrachtungen auch Risiko-Betrachtungen wie kritische Methoden oder Module der Kernprozesse aufzunehmen. Zusätzliche Hilfen können Auswertungen aus dem Bugtracking-System sein. Häufig befinden sich in 20 % des Codes zirka 80 % der Fehler.

Das Gesamtrisiko setzt sich aus der Risikoklasse (fachlich) und Komplexität (technisch) zusammen. Die Risikoanalyse im Modultest kann sich allerdings oft auf eine reine Komplexitätsbewertung beschränken.

Je komplexer ein Testobjekt ist, desto höher sind die Aufwände für die Durchführung der Testaktivitäten.

Schaubild Kriterien für die Risikobewertung im Modultest

Einzelkriterium

Komplexität des Einzelkriteriums

Hohe Ausfall-

wahrscheinlichkeit

Mittlere Ausfall-

wahrscheinlichkeit

Geringe Ausfall-

wahrscheinlichkeit

Anzahl der

aufrufende Objekte

Viele

Wenige

Aufrufende

Objekte

Viele

Mehr als

Durchschnitt

Wenige bis

Durchschnitt

Objektart

Neu

Merklich geändert

Gering verändert

Geänderte

Codelänge

Mehr als 80% des

Ursprungcodes

Mehr als 60% des

Ursprungcodes

Restliche

Änderungen

Risiko

Hohes betriebs-

wirtschaftliches

Risiko

Mittleres betriebs-

wirtschaftliches

Risiko

Geringes betriebs-

wirtschaftliches

Risiko

Die Komplexität wird hier im Wesentlichen bestimmt durch die Anzahl und Art der Zugriffe auf Objekttypen, womit alle Arten von DV-Objekten gemeint sind, auf die zugegriffen werden kann, z.B. Datenbanktabellen, Schnittstellen oder Attribute.

Eine Komplexitätsanalyse des Programmsystems kann der Detektion fehleranfälliger Bereiche dienen, denn eine komplexere Struktur wird in der Regel auch mit einer höheren Fehlerwahrscheinlichkeit einhergehen.

Kriterien zur Bewertung der Komplexität können sein:

» Gesamtzahl der Attribute

» Anzahl der Objekttypen

» Anzahl der Klassenattribute

» Anzahl der Methoden

» Anzahl der codierten Zeilen

» Anzahl der Übergabeparameter

» Anzahl der Rückgabeparameter

» Anzahl der Datenzugriffe

» Zyklomatische Komplexität

Die Auswertung der Beurteilung der Kriterien erfolgt beispielsweise nach folgenden Entscheidungsregeln:

Komplexität	Bewertungsregel
1	Mindestens 2 Kriterien mit hoher Komplexität führen zu dieser Gesamtkomplexität
2	Ein Kriterium mit hoher und mindestens ein Kriterium mit mittlerer oder mindestens zwei mit mittlerer Bedeutung führen zu dieser Gesamtkomplexität
3	Sonstige Kombinationen führen zu dieser Gesamtkomplexität

Die Testobjekte im Modultest müssen mindestens nach ihrer Komplexität klassifiziert werden. Wenn eine ABC Analyse unter Einbeziehung der Kritikalität durchgeführt wird, kann anhand verschiedener Kriterien eine Klassifizierung des Risikos vorgenommen werden.

Beispiel:

Einzelkriterium	Risikoklasse des Einzelkriteriums
Einzelkriterium	A = hohes Risiko	B = mittleres Risiko	C = geringes Risiko
Häufigkeit der Verwendung	Täglich	Monatlich	Jährlich
Umfang der durchgeführten Änderungen	Neu	Merklich geändert	Gering verändert
Auswirkung im Fehlerfall (z.B. Kosten, Betrieb)	Groß	Mittel	keine

Im Anschluss wird jedes Einzelkriterium für jedes Testobjekt bewertet, sodass sich ein Gesamtrisiko ergibt. Die Regeln hierfür stellen sich beispielhaft in der folgenden Tabelle dar (Grundregel: eine Funktion ist immer so stark wie ihr kritischstes Einzelkriterium):

Gesamtrisikoklasse		Bewertungsregel
A	hoch	Mindestens 1 Einzelkriterium hat den Wert hoch
B	mittel	mindestens 1 Einzelkriterium hat den Wert mittel und kein
C	gering	Einzelkriterium hat den Wert hoch

Testmethoden

Je nach Risikoklasse und Komplexität sind verschiedene Testmethoden einsetzbar. Generell gilt, dass die gefundene Risiko-/Komplexitätsklasse nur einen Anhaltpunkt auf die zu verwendende Testmethodik liefert und durch den Verantwortlichen geändert werden kann.

Zunächst lassen sich die Verfahren in statische und dynamische Tests unterscheiden.

Bei statischen Tests wird eine Untersuchung des Testobjektes vorgenommen, ohne dass die Software zur Ausführung gebracht wird. Für Code-Analysen sind häufig Hilfsmittel sinnvoll einsetzbar (programmiersprachenabhängig).

Folgende Testmethoden lassen sich für den Modultest sinnvoll verwenden:

» Code Review

» Walkthrough

» Inspektion

Werden die statischen Code-Analysen toolgestützt mit abgestimmten Metriken für die eingesetzten Programmiersprachen ausgeführt, könnten sich hieraus zusätzliche Hinweise auf kritische Bereiche im Quellcode ergeben.

Es könnten hierbei folgende Fehler aufgedeckt werden:

» Abweichungen von Standards

» Fehler in Anforderungen oder Design

» Unzureichende Wartbarkeit

» Falsche Implementierung der Schnittstelle (Abweichung von der Spezifikation)

Bei dynamischen Tests wird die Funktion des Moduls durch Eingabe von Testdaten geprüft, um aufgerufene Module oder Funktionen zu simulieren.

Testfallermittlung

Die Methode zur Testfallermittlung richtet sich nach dem Risiko, das man bereit ist einzugehen, d.h. je geringer das Risiko bei der Einführung der Software sein soll, desto höher muss die Abdeckung im Test sein.

Die Ermittlung der Testfälle orientiert sich an den zu erstellenden Modulen. Grundsätzlich ist jeder Entwickler verpflichtet, seine neuen oder geänderten Module einem dedizierten Test zu unterziehen. Hierbei muss eine ausreichende Testabdeckung in Abhängigkeit von der Risikoanalyse erreicht werden.

Folgende Testmethoden lassen sich für den Modultest sinnvoll verwenden:

» Entscheidungstabellentest

» Klassifikationsbaum-Methode

» Error-Guessing

Testdatendefinition

Eine Testdatendefinition ist prinzipiell nur für die dynamischen Tests erforderlich. Die Testdaten werden üblicherweise zu den jeweiligen Testfällen erstellt. Die Auswahl der Testdaten ist in der Regel von der benutzten Testmethode abhängig.

Für die Testdatendefinition sind je nach Komplexität und Kritikalität die Methoden Standardwert oder Grenzwertbetrachtung empfehlenswert.

Testausführung und -auswertung

Die genutzten Techniken in der Testausführung müssen gewährleisten, dass der Test nachvollziehbar, Re-Test fähig und wenn möglich automatisiert abläuft.

Die Nachvollziehbarkeit ist eine Grundvoraussetzung für die Fehlerfindung. Denn wenn nicht bekannt ist, wie der Fehler entstanden ist, ist es sehr schwer herauszufinden, wo dieser im Code steckt.

Re-Test fähig sollte die Testausführung sein, damit nach der Fehlerbehebung gewährleistet werden kann, dass der Fehler korrigiert wurde und sich nicht neue Fehler eingeschlichen haben.

Die Automatisierung entlastet den Tester bei der Testdurchführung, indem verschiedene Prozesse durch Hilfsmittel oder Prozeduren – sofern die Kosten/Nutzen-Relation vertretbar ist unterstützt werden.

Die Prozeduren können helfen bei:

» Bereitstellung von Testdaten in der Testumgebung

» Testausführung Online und Batch

» Sicherung der Testergebnisse

» Aufbereitung von Testergebnissen für die Auswertung

» Vergleich von Soll und Ist Ergebnissen

Im Anschluss an die Testausführung erfolgt die Auswertung der erzielten Ergebnisse.

Hierbei kann man nach verschiedenen Ergebnistypen unterscheiden, z.B:

» Ablaufprotokolle

» Auskunft- und Anzeigemasken

» Druckoutputs

» Schnittstelleninhalte/-protokolle

» Datenbankinhalte

Im Testkonzept sollte festgelegt werden, welche Ergebnisse in welchem Umfang (Stichproben, vollständige Testabdeckung) für die Auswertung herangezogen werden sollen.

Die erforderliche Dokumentation der Testergebnisse bezieht sich nicht auf alle zwischenzeitlich durchgeführten Tests sondern vorrangig auf die Testaktivitäten, die den Stand der übergebenen Software widerspiegeln.

Testeingang Kriterien

Für den Beginn des Tests müssen verschiedene Voraussetzungen erfüllt sein, insbesondere muss das zu testende Modul fertig gestellt sein und die benötigten Daten müssen für den Modultest zur Verfügung stehen.

Weitere Kriterien sind im Allgemeinen nicht notwendig, da der Modultest die erste Stufe im Test ist und in der Entwicklungsumgebung ausgeführt wird, so das auch keine gesonderten Anforderungen an eine Testumgebung bestehen.

Die Tests laufen in der Praxis oftmals parallel zur Realisierung. Die kritischen Module sind von daher möglichst frühzeitig zu testen.

Testende Kriterien

Die Testende Kriterien sind in Abstimmung mit Entwicklung und Fachbereich abzustimmen. Zusätzlich zu den allgemeinen Kriterien sollten weitere Kriterien für die Beendigung des Modultests berücksichtigt werden:

Testmodell	Testende Kriterien
Kontrollflusstestmodell	» Alle Zweige werden mindestens einmal ausgeführt
	» Alle Bedingungen werden mindestens einmal ausgeführt
	» Alle Bedingungskombinationen werden mind. einmal ausgeführt
Datenflusstestmodell	» Alle defuse Pfade werden mindestens einmal ausgeführt
	» Alle berechnende Zugriffe werden mind. einmalausgeführt
	» Alle prädikativen Zugriffe werden mind. einmal ausgeführt
	» Alle Definitionen werden mindestens einmal ausgeführt
Funktionstestmodell	» Alle Funktionen werden mindestens einmal ausgeführt
Funktionstestmodell	» Alle Operationen werden mindestens einmal ausgeführt
Zustandsübergangstest-modell	» Alle Zustandsübergänge werden mindestens einmal ausgeführt
Zustandsübergangstest-modell	» Alle nicht spezifizierten Zustandsübergänge werden mindestens einmal ausgeführt
Ausnahmetestmodell	» Alle spezifizierten Ausnahmen werden überdeckt
Ausnahmetestmodell	» Alle nicht spezifizierten Ausnahmen werden überdeckt (Überdeckung spezifizierter Fehlerklassen)

Die Sicherstellung der Qualität der Komponenten für den Testbetrieb obliegt grundsätzlich dem Fachbereich.

Regressionstest

Beim Regressionstest sind bevorzugt die Module zu testen, die die wichtigsten und kritischsten Verarbeitungsschritte durchführen. Für den Modultest sollte die Ausführung von Regressionstests möglichst automatisiert sein.

Ein Regressionstest wird durchgeführt, wenn eine Software oder deren Umgebung verändert wurde. Es ist also ein erneutes Testen einer bereits getesteten Software oder deren (Teil-) Funktionalität nach einer Modifikation, um nachzuweisen, dass durch vorgenommene Hard- oder Softwareänderungen in der Folgewirkung keine (auch übergreifenden) Fehlerzustände freigelegt wurden.

Die Auswahl der Regressionstests ist von Release zu Release kritisch zu hinterfragen und bei Notwendigkeit anzupassen.