Testkonzept - Testmethoden Statische Tests

Statische Test können mit unterschiedlichen Methoden durchgeführt werden. Zumeist handelt es sich hierbei um Code-Analysen.

Mit diesem methodischen Vorgehen kann eine Software getestet werden, ohne dass diese tatsächlich abläuft.

Unter einem statischen Test ist die Prüfung eines Testobjekts ohne Ausführung der Software zu verstehen.

Analytische Maßnahmen ohne einen Programmlauf sind zum Beispiel: White Box Test, Code Review, Walkthrough, Checklistenprüfung und Inspektion.

White Box Test

Beim White-Box-Test erfolgt die Testfallermittlung für eine Software unter der vorgegebenen Verwendung von Information über die interne Struktur des zu testenden Programms.

Augrund einer bestehenden Kenntnis über zulässige Eingabe- und Ausgabewerten können für jedes Modul Äquivalenzklassen gebildet werden.

Mögliche Testaufgaben	Erläuterung
Fokussiertes Testen	Für den Test werden einzelne Module ausgewählt, die entweder neu sind und/ oder bei denen viele Probleme vermutet werden.
Messung Testüberdeckung	Prüfung, welche Pfadabdeckung (Teile des Codes) durch die erstellten Testdaten gegeben ist.
Test von internen Programmbeschränkungen	Systematische Identifizierung von interne Beschränkungen (zum Beispiel: Feldlänge zu klein, zu wenig Speicherplatz)
Test Datenintegrität	Lokalisierung möglicher Probleme auf Modulebene

Kontrollflussanalyse

Bei der Kontrollflussanalyse wird der Programmcode mit einen Startknoten und einen Endknoten sowie dazwischen mit einem möglichen Programmverlauf (Nacheinanderausführung von Anweisungen und Schleifen in der Form einer Kontrollflussgrafik) dargestellt.

Bedingungsabdeckung

Die Bedingungsabdeckung betrachtet atomare Entscheidungspunkte, bei dem ein System oder eine Applikation in Abhängigkeit vom Ergebnis der Entscheidung unterschiedliche Wege einschlägt.

Wahrend atomare Entscheidungspunkte regelmäßig zwei Testsituationen mit den Ergebnissen TRUE oder FALSE zur Folge haben, führen zusammenverknüpfte Kombination von Bedingungen stets exponentielle Menge an Testsituationen. Jede Reduzierung von möglichen Testsituationen erhöht zwar die Testgeschwindigkeit, senkt aber gleichzeitig die Testgenauigkeit.

Datenflussanalyse

Eine Datenflussanalyse prüft innerhalb eines Programmcode die Verwendung von Daten auf lokale und globale Sichtbarkeit von Variablen oder Objekten.

Zustände von Variablen
Undefiniert	Variable hat keinen definierten Wert
Definiert	Variable wird ein Wert zugewiesen
Ermittelt	Wert der Variable wird gelesen

Insbesondere wird im Rahmen einer Datenflussanalyse untersucht, zwischen welchen Programmpfaden eines Programmsystems die Daten weitergegeben werden und welche Abhängigkeiten hieraus entstehen.

Arten von Datenflussanomalien

Undefinierter Wert einer Variable wird auf einem Programmpfad gelesen

Variable enthält ungültigen Wert, ohne dass dieser zwischenzeitlich verwendet wurde

Variable erhält zweites Mal einen Wert, ohne dass der erste Wert verwendet wurde

Checklistenprüfung

Mit einer vollständigen und klar formulierten Checkliste – welche auch für Reviews einsetzbar ist - kann für das Prüfobjekt sicher gestellt werden, dass alle relevanten und zu prüfenden Anforderungen beachtet werden.

Die Entscheidung, ob jede einzelne Anforderung erfüllt wird, wird in der Checkliste eingetragen.

Zweck von Checklisten	Erläuterung
Inspektion	Überprüfung der Einhaltung von Richtlinien sowie Dokumentations- oder Programmierrichtlinien
Vorgehensweise	Überprüfung der vollständigen Ausführung aller (in der Regel komplexeren) erforderlichen Tätigkeiten, jedoch nicht der inhaltlichen Qualität von Arbeitsergebnissen
Orientierung	Begutachtung des Prüfobjektes aus ausgewählten Blickwinkeln.

Inspektion

Eine formlose Inspektion kann bei sämtlichen Ergebnistypen einer Softwareentwicklung zum Einsatz kommen; insbesondere dann, wenn andere der genannten analytischen Qualitätssicherungsmaßnahmen nicht in Frage kommen.

Anforderungen an die Dokumentation
» Gegenstand der Inspektion
» Ziel der Inspektion
» Datum der Durchführung
» Durchführende Person
» Zusammenfassung des Inspektionsergebnisses
	o akzeptiert
	o akzeptiert nach Behebung von gefundenen Mängel
	o erneute Inspektion erforderlich

Code Review

Die Code Review Methode wird im Rahmen eines White Box Tests angewandt. Hierbei wird der Code in Form des Quelltextes einem anderen Entwickler zum Review gegeben. Mit dieser Methode kann bei relativ niedrigen Kosten ein hoher Wirkungsgrad erzielt werden.

In einem Review können beispielsweise folgende Aspekte betrachtet werden:

Fehler-Kategorie	Erläuterung der Fehlerüberprüfung/-suche
Logik	Formulierung von Bedingungen, Berechnungen
Schnittstellen	Schnittstellenkonventionen (Schnittstellenname, Parameteranzahl, Parameterreihenfolge, Parametertypen)
Performance	Antwort- und Restartzeit, Kapazität (Datenmenge, Benutzerzahl)
Wartbarkeit	Programmkomplexität, Programmstrukturierung
Design	Beachtung von Design-Prinzipien
Code-Kommentar	Formulierung, Umfang, Genauigkeit, Verständlichkeit
Verstoß gegen Standards	Einhaltung von Programmierrichtlinien
Sicherheitsrelevanz	Einhaltung von Datenschutzbestimmungen
Ergonomie	Benutzerfreundlichkeit
Zuverlässigkeit	Plausibilitätsprüfung

Walkthrough

Mit dieser Methode wird einem Entwickler die Gelegenheit geben, sein Arbeitsergebnis anderen Entwicklern und/oder den Usern zu präsentieren. Eine kritische Überprüfung mit Hilfe anderer Personen soll (ggf. anhand eines Fragekatalogs) im Rahmen einer Diskussion eventuelle Fehler, Unvollständigkeiten, Widersprüche und Unklarheiten aufdecken.

Es wird hier jedoch nicht das Ziel verfolgt, dass andere oder bessere Lösungswege aufgezeigt beziehungsweise Alternativen diskutiert werden soll. Von daher sind nur inhaltliche Fragen – aber keine Fehlerbehebung - erlaubt.

Die gefundenen Punkte werden in einem Protokoll zusammengefasst. Erst im Anschluss an der Präsentation werden Veränderungs- und Korrekturmaßnahmen durchgeführt.

Statische Code Analyse

Programmierrichtlinien beziehen sich in der Regel insbesondere vorrangig auf eine redundanzfreie Organisation des Quellcodes, auf eine einheitlichen Einsatz von Programmiersprachen und der Einhaltung von Namenskonventionen.

Die Statische Analyse von Software Artefakten wird in der Regel mit Werkzeugunterstützung durchgeführt, ohne das die Software Artefakten dabei ausgeführt werden.

Eine statische Code-Analyse kann in Bezug auf Technologie, Architektur, Design und Code durchgeführt werden.

Mögliche Aspekte der statischen Code-Analyse
Wartbarkeit	Änderbarkeit
Security	Zugriffsschutz
Stabilität	Zuverlässigkeit

Ausgangspunkt für die Identifizierung von statischen Qualitätsmerkmalen einer Software ist immer ihr Quellcode.

Im Gegensatz zu Qualitätseigenschaften ergeben sich Unterschiede zwischen Qualitätsmerkmalen also ausschließlich durch die Art eines Produktes. Qualitätsmerkmale sind im Gegensatz zu Qualitätseigenschaften von der Technik abhängig, die Betrachtung von Qualitätsmerkmalen ändert sich somit nicht über die Zeit.

Technologie

Eine Quelltextkommentierung ermöglicht die Angabe von quantitativ detaillierten und qualitativ hochwertigen Informationen über kodierten Passagen, die sich aus dem Quelltext selbst nicht direkt ableiten lassen. Eine zügige Einarbeiten und ein Verstehen des Quellcodes ist für die Wartbarkeit eines Systems von hoher Bedeutung.

Wichtige zu beachtende Aspekte für die Beschreibung in Kommentarzeilen

Grad

der Kommentierung

Für die Wartung des Codes muss ein angemessener Umfang einer nachvollziehbaren Dokumentierung vorliegen.

Verständlichkeit

der Kommentierung

Der inhaltliche Wert der Dokumentierung eines Codes hängt von den vorhandenen Fachwissen und eventuellem Programmierkenntnisse ab.

Transparenz bei

der Änderungshistorie

Im Dokumentenkopf sind insbesondere zu beschreiben:

» Codename

» Was macht das Programm für welche Verwendung

» Wann wurde der Code von wem erstellt

» Welche Eingangsdaten (Parameter oder Daten) werden benötigt

» Welche Ausgangsdaten werden erzeugt

» Welche Code Änderung wurde vorgenommen (Wer, Wann, Warum)

Ein zu keiner Zeit ausgeführter Code erschwert in der Regel das Code-Verständnis und sollte entfernt werden. Selbige gilt für Task Notes, die während einer Entwicklung im Quelltext für unfertige Programmcodes gesetzt werden.

Namenskonventionen

Regeln zur systematischen Benennung von Entitäten sollten bereits an der Schreibweise einer Entität die wichtigsten Eigenschaften erkennen lassen können. Artefaktspezifische Namenskonventionen erlauben es dem Entwickler eine einheitliche Erwartungshaltung gegenüber Namen aufzubauen und somit den Quellcode effizienter lesen und verstehen zu können.

Code Duplikate (Clones)

Als Code Duplikat wird ein Code Fragment bezeichnet, welches an anderer Stelle identisch implementiert ist. Eine Ursache kann beispielsweise in der Vergabe verschiedener zu realisierender Teilbereiche an mehrere Programmierer ohne vorherigen Abgleich auf Dubletten. Dieses kann zu größten Wartungsrisiken führen, insbesondere dann, wenn die Stabilität eines Systems dadurch beeinträchtigt, dass global gültige Änderungen (Fehlerkorrekturen und Erweiterungen) nicht flächendeckend (in allen Duplikaten) umgesetzt wurden.

Architektur

Auf einer Architekturebene werden Komponenten betrachtet und bewertet, die dem System eine logische und stabile Struktur geben.

Die Stabilität bzw. Robustheit des Codes wird dadurch verbessert, wenn keine GOTO verwendet werden. Selbiges gilt auch beispielsweise dafür, wenn keine (Unter-) Programmaufrufe ohne Wiederkehr oder wechselgegenseitige Aufrufe vorhanden sind sowie jedes Programm nur einen Startpunkt und einen Endpunkt hat.

Da Datenbankzugriffe wesentlich zum Zeitverhalten von Programmen beitragen, ist ein genauer Zugriff dem Aspekt der Effizienz und Performanz unterzuordnen. Die Businesslogik eines Programms hat zudem weder in der GUI (Bedieneroberfläche) noch in den Datenbankzugriffen zu erfolgen.

Design

Auf einer Designebene wird die konkrete Umsetzung von Konzepten im Quelltext sowie die Verwendung von Dateien überprüft. Deklarationen und Definitionen haben im Kopfbereich der Programme zu erfolgen.

Je mehr Quellcodezeilen eine Datei besitzt, umso mehr verschlechtert sich prinzipiell die Verstehbarkeit (Analysierbarkeit, Transparenz) und damit die Wartung einer Datei.

Quellcodedateien sollten eine ausgewogene Prozedurgröße (Codelänge) haben, damit einerseits eine gewisse Menge an Funktionalität hinterlegt werden kann und andererseits die Prozedur für einen Entwickler nicht als zu komplex bzw. als kaum beherrschbar wirkt. Große Dateien sollten von daher Teilfunktionalitäten enthalten, die in andere Dateien ausgelagert werden.

Eine Trennung der Interfaces – die in Anwendungen typischerweise als Schnittstellen von Services dienen – von der Service-Implementierung, macht sowohl das Interface als auch den Service gegenüber Änderungen unempfindlicher.

Code

Bei einer Bewertung auf Codeebene obliegt der zu beurteilende Fokus der technischen Qualität auf einer Lesbarkeit und Analysierbarkeit sowie auf einer Konsistenz und Korrektheit des Quelltexts. Die Komplexität von Klassen und Methoden kann durch die Anzahl von Kontrollflussanweisungen gemessen werden.