Testkonzept - Teststufe Modultest

Der Modultest des Entwicklers ist die Basis für alle weiteren Teststufen und überprüft Einzelkomponenten (Klassen, Module, Skripte) auf ihre funktionalen und nichtfunktionalen Eigenschaften, wobei die spezifikationsgetreue Funktion (inkl. Fehlerbehandlung) der Komponente im Vordergrund steht.
Der Zuschnitt der zu testenden Komponenten sollte architektur- und technologiespezifisch im Testkonzept definiert werden.

Die Ergebnisse des Modultests sind zu dokumentieren.


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

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

» Alle Operationen werden mindestens einmal ausgeführt

Zustandsübergangstest-modell

» Alle Zustandsübergänge werden mindestens einmal ausgeführt

» Alle nicht spezifizierten Zustandsübergänge werden mindestens

   einmal ausgeführt

Ausnahmetestmodell

» Alle spezifizierten Ausnahmen werden überdeckt

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

Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH

Hettwer UnternehmensBeratung

Hettwer UnternehmensBeratung GmbH - Spezialisierte Beratung - Umsetzungsdienstleistungen im Finanzdienstleistungssektor – Experte im Projekt- und Interimsauftragsgeschäft - www.hettwer-beratung.de

H-UB ERFOLGSGESCHICHTE

Auszeichnung:

Gold-Partner-Zertifikat

Hettwer UnternehmensBeratung GmbH wurde aufgrund der erbrachten Beraterleistungen in den exklusiven Kreis der etengo Gold-Partner aufgenommen.

H-UB EXPERTENWISSEN

Hettwer UnternehmensBeratung GmbH – Expertenprofil Klaus Georg Hettwer (Geschäftsführer): Beratungskompetenz, Fachliche Kompetenz, Methodische Kompetenz, Soziale Kompetenz, Kommunikationskompetenz; Sonderthemen: SEPA, EMIR, TARGET2, MiFID, T2S

- Eine Beratung mit PROFIL -

H-UB Leistungskatalog

H-UB Leistungskatalog.pdf
Adobe Acrobat Dokument 89.4 KB

Projekt:

Hanseatische Container Logistik GmbH

Spedition, Logistik

Projekt:

WERDER BAU Bremen GmbH

Bauunternehmen

Projekt: Vino Bello

„La Dolce Vita“

 

H-UB SOCIAL MEDIA PRÄSENZ

© 2010-2024 Hettwer UnternehmensBeratung GmbH