6 Softwaretest und Qualitätssicherung

Dieses Kapitel soll die Einsatzfähigkeit des fertig gestellten Prototypen „Uni-

Stat Version 0.8.1-beta“ testen. Die folgenden Tests und Analysen werden je-

doch keine Qualitätssicherung im engeren Sinne vornehmen, da der Auf-

wand für diesen Prototypen nicht gerechtfertigt wäre. Die Schwerpunkte der

Tests liegen vielmehr in der Überprüfung eines ordnungsgemäßen Program-

mablaufs, in der Validierung der Ergebnisse und in einer vollständigen Über-

prüfung der zu sendenden Steuersignale.

„Das Ziel jeglichen Testens ist es, möglichst alle im Testobjekt vorhandenen

Fehler zu entdecken und zu lokalisieren. Testen kann nur die Anwesenheit,

aber nicht die Abwesenheit von Fehlern und Mängeln feststellen. Testen zielt

daher darauf ab, möglichst viele Fehler zu entdecken, um der Restfehlerzahl

Null möglichst nahezukommen. In der Praxis ist das Testen die populärste

analytische Maßnahme, um die Qualität von Software nachzuweisen.“

[TRAU, S.200]

Das Testobjekt (hier „UniStat Version 0.8.1-beta“) muss innerhalb einer be-

stimmten Testumgebung und versehen mit entsprechenden Testeingangsda-

ten lauffähig sein. „Während des Testens wird diese Umgebung real, in ver-

einfachter oder in nachgebildeter simulierter Form bereitgestellt, damit das

Testobjekt wie in seiner späteren Betriebsumgebung reagieren kann.“

[TRAU, S.201]

Die Testumgebung [Abb. 32] wird analog zur Abbildung 1 aufgebaut. Hierbei

befindet sich der Prototyp „UniStat“ in seiner realen Umgebung und wird

62

Abb. 32, Testumgebung "UniStat"

IBM-kompatibel

Programm:Umsetzer.exe

IBM-kompatibel

Programm:UniStat.exe

Null-Modem-Kabel RS232C RS232C

über den RS232C-Anschluss (COM-Port) mit dem Umsetzer verbunden. Der

Umsetzer wird jedoch im Testaufbau durch die Software „Umsetzer.exe“

[Abb. 33] simuliert. „Umsetzer.exe“ stellt dabei die eingehenden Datenströ-

me (Befehle und Befehlsfolgen von „UniStat“) in einem Textfeld zur Kontrolle

dar und kann selbst den ausgehenden Datenstrom des Umsetzers simulieren.

Die Datenströme werden in hexadezimaler Form dargestellt.

63

Abb. 33, Simulator "Umsetzer.exe"

Der Prozess des Testens gestaltet sich wie folgt [TRAU, S.201]:

– Das Testobjekt wird mit Testeingangsdaten versorgt. Dies beinhaltet auch

die Initialisierung des Testobjektes.

– Das Testobjekt wird mit diesen Testdaten ausgeführt.

– Das Verhalten des Testobjektes wird an ausgewählten programminternen

Punkten und an den Ausgängen beobachtet beziehungsweise gemessen.

– Die beobachteten Testergebnisse werden mit Referenzwerten verglichen.

Fällt der Vergleich innerhalb vorgegebener Toleranzen negativ aus, so

liegt ein Fehler vor, der sofort dokumentiert werden muss.

Die sorgfältig geplanten Tests müssen wiederholbar, nachvollziehbar und

vollständig sein sowie klare Ziele verfolgen. Ein Test sollte, wie auch das

Softwareprodukt selbst, vollständig und lesbar dokumentiert sein. [TRAU,

S.202]

Welchen Charakter die Tests haben müssen, ist von Fall zu Fall unterschied-

lich. „Ein Testobjekt kann je nach Betrachtungsweise auf zwei Arten ins Tes-

ten einbezogen werden.“ Betrachtet man das Objekt von außen, wird dessen

Reaktion auf die Testeingangsdaten nur an den Ausgängen beobachtet. Es

wird an diesem „schwarzen Kasten“ („Black-Box“) untersucht, inwieweit das

Testobjekt seine in der Spezifikation geforderten Funktionen erfüllt. Bei die-

sem so genannten „Black-Box-Test“ ist dem Tester die innere Struktur des

Programms nicht bekannt. Er geht vielmehr davon aus, dass bei fehlerfreiem

Betrieb der Software die gültigen Eingangsdaten durch gültige Programm-

funktionen in gültige Ausgangsdaten transformiert werden. Mit der Auswahl

der Testfälle und damit der Testeingangsdaten sollte eine hohe Wahrschein-

lichkeit für die Aufdeckung von Fehlern erreicht werden. „Der Funktionstest

kann das Fehlen von Funktionen beziehungsweise Qualitätseigenschaften

des Testobjekts erkennen; dagegen kann er das Vorhandensein unerwünsch-

ter Funktionen bzw. Eigenschaften nicht mit Sicherheit nachweisen. [...] Zur

gezielten Auswahl von Testeingangsdaten, zur Berücksichtigung interner Zu-

stände [...] sind die Kenntnis und Nutzung der inneren Struktur des Testob-

jekts notwendig. Dies wird beim „White-Box-Testen“ herangezogen.“ Für die

Vorbereitung solcher Tests werden Steuer- und Datenflussgraphen ermittelt

64

und analysiert. Unter ihrer Beachtung werden dann die Testeingangsdaten

ermittelt, die zu bestimmten Zuständen des Testobjekts führen sollen. Im Ge-

gensatz zum „Black-Box-Test“ kann der „White-Box-Test“ das Vorhandensein

nicht erwünschter Funktionen beziehungsweise Eigenschaften der Software

aufdecken. „Dagegen kann er das Fehlen erforderlicher Funktionen im allge-

meinen nicht erkennen.“ Beide Verfahren ergänzen sich gegenseitig und sind

„für den Erfolg der Testaktivitäten von äußerster Wichtigkeit.“ [TRAU,

S.203/204]

In Vorbereitung der Testdurchführung ist es des Weiteren unabdingbar, das

auch das Testpersonal entsprechend geschult wird. Zum Testpersonal zählen

beispielsweise versierte Anwender, Leitungspersonal, Entwicklungsingenieu-

re, Softwareentwickler oder gar fachfremde Anwender (Laien). Der Umfang

der Schulung ergibt sich unter anderem aus dem Wissenspotential der Tes-

ter und dem Schwierigkeitsgrad der durchzuführenden Tests. Prinzipiell soll-

ten aber die Personen zu den Tests „passen“, denn es ist sicher nicht sinn-

voll, einen Anwender beispielsweise interne Funktionen (Quelltext) eines

Programmes testen zu lassen. Angemessen ist es aber, fachfremde Personen

die Software bedienen zu lassen, um beispielsweise die Stabilität der Anwen-

dung bei extremen Fehleingaben untersuchen zu können.

Grundsätzlich sollten die Testpersonen je nach Bedarf zu folgenden Themen

geschult werden:

– Notwendigkeit des Testes

– Art und Weise der Fehlerdokumentation

– Allgemeiner Umgang mit dem realen oder simulierten Systemaufbau, ins-

besondere Sicherheitshinweise

– Hinweis zu verfügbaren Fehlerdokumentationen

Die Testpersonen für dieses Projekt wurden zu den oben genannten Themen

hinreichend geschult, so dass die folgenden Testprotokolle repräsentativen

Charakter haben. Die verwendeten Testeingangsdaten „*.hex“ befinden sich

auf der beiliegenden CD im Verzeichnis „<CDROM>\Umsetzer\dat\“. Diese

Dateien sind mit einem gewöhnlichen Texteditor lesbar.

65

6.1 Überprüfung der Steuersignale

Testprotokoll: Steuersignale Nr: 1.1

Aufgabe:

Überprüfen Sie in der Testumgebung „UniStat“ [Abb. 32] ob das Programm „UniStat Version 0.8.1-beta“ nach Aufruf der unten angeführten Funktionen die unter „Soll“ angegebenen hexadezimalen Werte sendet. Der Test umfasst alle Teilbereiche und Modi der Software:

- Kalibrierung- Härteprüfung mit N0=0 (Anzahl Werte N0, vgl. Abb. 23 und 22)- Härteprüfung mit N0=5 und Testeingangsdaten

Spezifikation: Tab. 1, Befehlssatz "Umsetzer",Tab. 2, Datenformat "Umsetzer",Tab. 4, Schema - erweiterter Binärcode,Abb. 20, Aktivitätsdiagramm "Kalibrierung durchführen",Abb. 21, Aktivitätsdiagramm "Härteprüfung durchführen"

Teststrategie: Black-Box-Test

Testeingangs-daten:

pro Funktionstest mit N0=5 an „UniStat“ zu senden:„testeingang-5-werte.hex“

Testperson:

Position:

Kontakt:

Funktion / Aufgabe Ergebnis

Soll Ist

Kalibrierung: „Start“ BF BF

Kalibrierung: „Stopp“ BB BB

Kalibrierung: „Abbrechen“ nach „Start“ BB BB

Kalibrierung: „Ergebnisse übernehmen“

Hierzu in Tabelle „Korrekturfaktor für Y“ in die Spalte „Signal“ für jede Zeile beliebige Werte [0 .. 4094] eintragen.

BFA0****A1****

[...]A9****BB

BFA0****A1****

[...]A9****BB

66

Testprotokoll: Steuersignale Nr: 1.1

Funktion / Aufgabe Ergebnis

Soll Ist

Härteprüfung (N0=0, 5kp ... 250kp): „Test beginnen“ A0 ... A9BA

A0 ... A9BA

Härteprüfung (N0=0, *kp): „Test unterbrechen“ BBBA

BBBA

Härteprüfung (N0=0, *kp): „Test beenden“ BBBC

BBBC

Härteprüfung (N0=0, manuell): „Test beginnen“- kein Passwort nötig

AFBA

AFBA

Härteprüfung (N0=5, 5kp ... manuell): „Test beginnen“Alle Werte dürfen erst nach Empfang der Testein-gangsdaten gesendet werden.

A0 ... AFBA

A0 ... AFBA

Tab. 24, Testprotokoll "Steuersignale"

Die Testeingangsdaten „testeingang-5-werte.hex“ sind konstruierte Werte

gemäß der Spezifikation aus Tabelle 2 und dem „Schema – erweiterter Bi-

närcode“ [Tab. 4]. Im Test „Steuersignale“ [Tab. 24] traten keine Fehler auf.

Alle aufgeführten Steuersignale konnten nach Ausführung der angegebenen

Funktionen bestätigt werden. Eine Fehlbedienung der Härteprüfmaschine

durch falsche Steuersignale der Software kann ausgeschlossen werden.

67

6.2 Evaluation der Implementierung anhand von Beispielen

Testprotokoll: Evaluation UniStat Nr: 2.1

Aufgabe:

Unter Verwendung der Testumgebung gemäß Abbildung 32 und den Testeingangsdaten sollen Sie das Programm speziell zu den nachfolgend aufgeführten Funktionen und Aufgaben prüfen. Die Ausführung einzelner Programmfunktionen entnehmen Sie bitte der Nutzeranleitung. Die „Automatik“ des Umsetzers (Reaktion auf Steuerbefehle) ist durch manuelles Einsteuern der Testeingangsdaten zu simulieren.

Spezifikation: Abb. 20, Aktivitätsdiagramm "Kalibrierung durchführen",Abb. 21, Aktivitätsdiagramm "Härteprüfung durchführen"

Teststrategie: Black-Box-Test

Testeingangs-daten:

„testeingang-kalibrierung.hex“,„testeingang-kalibrierung-30min.hex“,„testeingang-kalibrierung-500-werte.hex“,„testeingang-kompletter-wertebereich.hex“,„versuch1_druckmaschine_125kp.hex“,„versuch2_druckmaschine_125kp.hex“,„versuch3_druckmaschine_125kp.hex“,„versuch4_druckmaschine_125kp.hex“

Testperson:

Position:

Kontakt:

Funktion / Aufgabe Ergebnis

Ja Nein

Führen Sie eine „Kalibrierung“ durch.Verlief die „Kalibrierung“ fehlerfrei? Wenn „Nein“, dann geben Sie bitte eine kurze Begründung im Anhang an.

Testeingangsdaten:

- „testeingang-kalibrierung.hex“- „testeingang-kalibrierung-30min.hex“- „testeingang-kalibrierung-500-werte.hex“

X

siehe auch

[Abb. 34]

68

Testprotokoll: Evaluation UniStat Nr: 2.1

Funktion / Aufgabe Ergebnis

Ja Nein

Führen Sie eine „Härteprüfung“ durch.

Legen Sie bitte für jede Prüfung ein neues Diagramm an.

Verlief die „Härteprüfung“ ohne Fehler? Wenn „Nein“, dann geben Sie bitte eine kurze Begründung im Anhang an.

Testeingangsdaten:

- „testeingang-kompletter-wertebereich.hex“- „versuch1_druckmaschine_125kp.hex“- „versuch2_druckmaschine_125kp.hex“- „versuch3_druckmaschine_125kp.hex“- „versuch4_druckmaschine_125kp.hex“

X

siehe auch

[Abb. 26]

[Abb. 35]

Tab. 25, Testprotokoll "Evaluation UniStat"

Die Testeingangsdaten wurden wie folgt erzeugt beziehungsweise ermittelt:

„testeingang-kalibrierung.hex“, „testeingang-kalibrierung-500-werte.hex“

– Diese Werte wurden technisch mit Hilfe eines Oszilloskop erzeugt der die

Signale des Umsetzers simuliert hat.

– Die Datei „testeingang-kalibrierung-500-werte“ enthält exakt 500 Werte-

paare und kann damit einer genauen Überprüfung des Kalibrierungsfens-

ters dienen (beispielsweise für die Kontrolle der Anzahl der empfangenen

Werte).

„testeingang-kalibrierung-30min.hex“

– Die enthaltenen Werte wurden aus Originalsignalen des Umsetzers ermit-

telt.

– Der Inhalt dieser Datei kann aufgrund der Menge der Daten als Belas-

tungstest für die Kalibrierung der Programms genutzt werden. Der Daten-

strom dauert etwa 30 Minuten an.

69

„testeingang-kompletter-wertebereich.hex“

– Diese Testeingangsdaten wurden rechnerisch ermittelt und orientieren

sich an der Funktion f(x)=x mit dem Definitionsbereich [0 ... 4094] (siehe

Tabelle 4 und Abbildung 35).

„versuch[*]_druckmaschine_125kp.hex“

– Die in dieser Datei enthaltenen Werte entstammen aus Versuchen mit dem

Umsetzer. Die Belastung für diese Versuche wurde manuell an der Druck-

maschine abgelesen und lag bei ungefähr 125 Kilopond.

Der Test „Evaluation UniStat“ [Tab. 25] erhebt keinerlei Anspruch auf Voll-

ständigkeit. Aus den dargestellten Ergebnissen lässt sich jedoch schon er-

kennen, das der Prototyp „UniStat Version 0.8.1-beta“ einen hohen Reife-

grad erreicht hat und weitere Tests in einer realen Umgebung geplant wer-

den können.

70

Abb. 34, Testeingangsdaten "testeingang-kalibrierung-500-werte.hex"

71

Abb. 35, Testeingangsdaten "testeingang-kompletter-wertebereich.hex"

6.3 Validierung der Ergebnisse

Testprotokoll: Validierung der Ergebnisse Nr: 3.1

Aufgabe:

Unter Nutzung der Testumgebung gemäß Abbildung 32 und den Testeingangsdaten sollen Sie nachfolgend angegebenen Ergebnisse der Berechnungen überprüfen. Nutzen Sie hierfür bitte geeignete externe Werkzeuge wie zum Beispiel MS Excel und MS Access.

Spezifikation: Abb. 5, Formel für Korrekturfaktor Kanal X,Abb. 6, Formel für Korrekturfaktor Kanal Y,Abb. 7, Formel zur Kalibrierung für Kanal X,Abb. 8, Formel zur Kalibrierung für Kanal Y,Abb. 20, Aktivitätsdiagramm "Kalibrierung durchführen",Abb. 21, Aktivitätsdiagramm "Härteprüfung durchführen"

Teststrategie: Black-Box-Test

Testeingangs-daten:

„testeingang-kalibrierung-erstes-testsignal.hex“,„testeingang-kalibrierung-zweites-testsignal.hex“,„testeingang-kompletter-wertebereich.hex“

Testperson:

Position:

Kontakt:

Funktion / Aufgabe Ergebnis

Soll Ist

Führen Sie eine „Kalibrierung“ für alle Kanäle und die angegebenen Testsignale durch. und überprüfen Sie anschließend die vorgegebenen Sollwerte gemäß den Abbildungen 5 und 6.

Testeingangsdaten:

- „testeingang-kalibrierung-erstes-testsignal.hex“, 1. Testsignal („X“, „Y“)

- „testeingang-kalibrierung-zweites-testsignal.hex“, 2. Testsignal („X“, „Y“)

- 2. Testsignal: „X“ = 70 [µm] und „Y“ = 125 [kp]

Anzahl empfangener Werte 50 50

Additionsfehler für „X“ 2767,30 2767,30

Additionsfehler für „Y“ 607,18 607,18

Korrekturfaktor für „X“ 0,1923 0,3434

Korrekturfaktor für „Y“ 0,0707 0,0707

Signalwert für „Y“ 2376 2376

72

Testprotokoll: Validierung der Ergebnisse Nr: 3.1

Funktion / Aufgabe Ergebnis

Ja Nein

Führen Sie zwei „Härteprüfungen“ durch. Öffnen Sie im Anschluss die Projektdatenbank (mit MS Access) und bestätigen Sie durch Anwendung der Formeln aus den Abbildungen 7 und 8 stichprobenartig die Berechnung der kalibrierten Wertepaare. Beachten Sie bitte, dass sämtliche Testeingangsdaten von Ihnen manuell angepasst werden müssen.

Konnte die Berechnung der kalibrierten Wertepaare von Ihnen nachvollzogen werden? Wenn „Nein“, dann geben Sie bitte eine kurze Begründung im Anhang an.

Testeingangsdaten (1. Härteprüfung):

- Anzahl der Werte für N0 = 0- Korrekturfaktor: „X“ = 1; „Y“ = 1 [bei 125kp]- Additionsfehler: „X“ = 0; „Y“ = 0- Maximale Belastung: 125kp- „testeingang-kompletter-wertebereich.hex“

Testeingangsdaten (2. Härteprüfung):

- Anzahl der Werte für N0 = 0- Korrekturfaktor: „X“ = 0,5; „Y“ = 0,25 [bei 125kp]- Additionsfehler: „X“ = 100; „Y“ = 100- Maximale Belastung: 125kp- „testeingang-kompletter-wertebereich.hex“

X

siehe auch

[Abb. 36]

[Abb. 37]

Tab. 26, Testprotokoll "Validierung der Ergebnisse"

73

Die Testeingangsdaten für die Kalibrierung „testeingang-kalibrierung-erstes-

testsignal.hex“ und „testeingang-kalibrierung-zweites-testsignal.hex“ sind

konstruierte Beispiele mit je 50 Eingangssignalen für das Programm „Uni-

Stat“. Der Test „Validierung der Ergebnisse“ [Tab. 26] verlief erfolgreich und

zeigt im ersten Testabschnitt einen nahezu unscheinbaren Fehler auf.

Nach einer raschen Fehleranalyse durch den Softwareentwickler hat sich

herausgestellt, dass ein Fehler in der Berechnungsfunktion der Korrekturfak-

toren vorliegt (siehe Modul „uCalibration“ [Abb. 27], Tab. 14, Methode "Cor-

rection").

Der falsch berechnete Korrekturfaktor für Kanal „X“ kann jedoch jederzeit

manuell korrigiert werden und hat zudem keine zerstörerische Auswirkung

auf die Härteprüfmaschine. Aus diesem Grund kann die Notwendigkeit der

Fehlerbehebung recht gering priorisiert werden. Eine Fehlerkorrektur ist

erst für die nächste Programmversion geplant.

74

Abb. 36, Testeingangsdaten "Versuch 1"

Abb. 37, Testeingangsdaten "Versuch 2"