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"
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"
Top Related