 |
|
|
|
Durch entsprechende konstruktive Maßnahmen
werden Fehler in der Softwareentwicklung so weit wie möglich von
vornherein ausgeschlossen. Bei den Testverfahren sollen verschiedene
analytische Methoden Fehler erkennen und Schwächen aufdecken, wobei
folgender allgemeiner Testprozess angewendet wird:
Dieser Ablauf wird sowohl für die Entwicklung von Software wie auch
für die Erstellung von Dokumenten verwendet und je nach der aktuellen
Aufgabenstellung im Rahmen der Testplanung adaptiert. Bei Dokumenten
wird etwa im Zuge des Modultests die Rechtschreibprüfung ausgeführt
und beim Integrationstests Inhaltsverzeichnisse oder der Index über
mehrere eingebundene Dateien geprüft und überwacht.
Der Testprozess ist in alle Phasen der Auftragsabwicklung und der
Softwareentwicklung integriert: Erste Festlegungen werden bereits bei
der Definition der Anforderungen getroffen, die im Zuge der weiteren
Entwicklung verfeinert und detaillierter geplant werden. Für alle
Ebenen der Softwareentwicklung werden verschiedene Prüfungen sowohl im
Entwicklungsplan wie auch im Testsystem UniTest eingerichtet. Auftrag
und Softwareentwicklung enden schließlich mit den von den jeweiligen
Auftraggebern vorgenommenen Abnahmetests.
Die Testverfahren beschränken sich nicht auf die Überprüfung der
festgelegten Testergebnisse, sondern beinhalten auch eine umfassende
Beurteilung aller Qualitätsmerkmale und Metriken für Software sowie
insbesondere die Überwachung aller für die Softwareentwicklung
festgelegten Regelungen wie etwa die Einhaltung von
Programmierrichtlinien.
Die einzelnen Prozeduren sind durch die hierarchische Gliederung
einem exzessiven Testverfahren unterworfen: Die Modulentwicklung testet
jede Funktion mit 100 % Abdeckung und führt mehrere Reviews durch.
Danach werden diese Funktionen von der Anwendungsprogrammierung in die
Programme eingebaut und dort auf ihre Verwendbarkeit und das
Zusammenwirken mit anderen Funktionen nach demselben Schema wie bei der
Modulentwicklung getestet. Anschließend prüft die
Anwendungssystementwicklung die gesamte Applikation. Bei der
Konfiguration eines Systems wird die Software von der Systemintegration
neuerlich getestet, worauf schließlich die Abnahmetests folgen, die
allerdings im allgemeinen denselben Umfang wie die von der
Systemintegration vorgenommenen Tests haben.
Grundsätzlich werden Softwaretests auf eigenen Testsystemen ausgeführt,
die einerseits frei von störenden Nebeneffekten (Computerviren, andere
nicht funktionsfähige Programme) sind und andererseits nicht als
Arbeitssysteme im Unternehmen genutzt werden. Diese Testsysteme sind
auch vollständig von den Echtdatenbeständen im Unternehmen isoliert.
Für den Test von Netzwerkanwendungen werden in derselben Weise eigene
Testnetze eingerichtet, die mit dem Firmennetz nicht in Verbindung
stehen.
|
Testplanung |
| Die Testplanung legt die erwarteten Ergebnisse fest
und bestimmt die Verfahren, mit denen diese Ergebnisse überprüft
werden.
Neben den Testdaten und den damit zu erzielenden Ergebnissen
müssen je nach Typ des Moduls die anzuwendenden Methoden und
entsprechende Richtlinien für die Entwicklung vorgegeben werden.
In den meisten Fällen sind dafür Standardchecklisten verfügbar.
Die wichtigste Aufgabe der Testplanung besteht darin, für neu
entwickelte Module beziehungsweise für alle Änderungen ein
vollständiges Testverfahren im Testsystem UniTest so
einzurichten, dass alle Tests vom Kontrollsystem für die
Softwareentwicklung automatisch ausgeführt werden können.
Sind dazu Testroutinen anzupassen, wird im Rahmen der
Entwicklung des zu testenden Moduls ein zweiter Arbeitsauftrag zur
Anpassung des Testsystems aufgestellt und die zugehörige
Testsoftware innerhalb des laufenden Projektes entwickelt oder
erweitert.
Das Testsystem und das zu testende System testen sich also
gegenseitig, weshalb bei einem Fehlschlagen der Tests immer auch
zu prüfen ist, ob das Testsystem korrekt arbeitet.
Jene Tests, die das Kontrollsystem automatisch ausführt,
werden vollständig mit allen Abläufen, Eingabedaten und
Ergebnissen aufgezeichnet. Bei händisch durchgeführten Tests,
die immer im Rahmen von Reviews ausgeführt werden, sind die
entsprechenden Aufzeichnungen zum Reviewprotokoll zu nehmen. |
|
Prüfungen während
der Entwicklung |
Eine Reihe von Tests führt der Programmierer schon
im Zuge der Entwicklung aus, um alle erkennbaren Fehler möglichst
noch vor dem Review zu beseitigen. Mängel, die noch in der
Entwicklungsphase behoben werden, gelten nicht als Fehler und
werden auch nirgends aufgezeichnet. Selbstverständlich gilt das
nur für Fehler am entwickelten Produkt selbst. Falls der
Entwickler bei der Programmierung einen Designfehler feststellt,
muss die Entwicklung abgebrochen und zum Entwicklungsprozess für
das Design zurückgegangen werden.
-
Der Entwickler führt eine Syntaxprüfung mit
dem Compiler aus und stellt zunächst einmal sicher, dass der
Modul fehlerfrei kompiliert werden kann.
-
In einer zweiten Stufe erfolgt mit eigenen
Tools eine statische Syntaxanalyse, welche die
Funktionsaufrufe und Schnittstellen analysiert, eine
Typüberprüfung vornimmt und die Initialisierung und
Verwendung aller Variablen sowie damit zusammenhängende
Anomalien überprüft. Diese Prüfungen überdecken sich
teilweise mit den vom Compiler vorgenommenen, sind jedoch je
nach dem verwendeten Tool meist deutlich umfassender.
-
Weiters erfolgt eine Codeinspektion mit
einem interaktiven Debugger, bei welcher der
Programmablauf Schritt für Schritt überprüft wird.
-
Schließlich kann der Entwickler die in
UniTest eingerichteten Prüffunktionen, die vom
Kontrollsystem automatisch ausgeführt werden, auch manuell
aktivieren und auf diese Weise noch während der Entwicklung
Fehlfunktionen feststellen.
Mit Hilfe dieser Tests ist schon vor dem ersten Review und vor
den automatisch ausgeführten Tests sichergestellt, dass das
Programm keinerlei syntaktische Fehler enthält und dass alle
Schnittstellen ordnungsgemäß verwendet werden. Zusätzlich ist
durch Codeinspektion und Modultest eine erste Prüfung der
spezifikationsgerechten Funktionalität erfolgt.
Die händische Ausführung der Tests liefert bei der
Modulentwicklung auch Informationen über die Testabdeckung. Falls
mit den Tests nicht 100 % des Sourcecodes abgedeckt sind, muss der
Entwickler zusätzliche Testfälle bei der Leitung der Entwicklung
beantragen und diese Vorgangsweise so lange wiederholen, bis die
Tests den gesamten Code abdecken. Damit wird vermieden, dass
Reviews wegen unvollständiger Tests unmittelbar nach ihrem Beginn
wieder abgebrochen werden müssen.
Da sich der Entwickler bei einem durchschnittlichen
Entwicklungsauftrag nur mit etwa zwei Seiten (130 Zeilen)
Sourcecode befassen muss, sind diese Aufgaben ebenso einfach wie
umfassend lösbar. Gleichzeitig wird durch die niedrige
Komplexität die Wahrscheinlichkeit außerordentlich hoch, dass
der Modul bereits in der Entwicklungsphase keinerlei Fehler mehr
enthält.
In höheren Ebenen der Softwareentwicklung (Anwendungsprogramme
und Anwendungssysteme) steigt natürlich die Gefahr eines
mangelhaften Zusammenwirkens von Komponenten, die in der
Entwicklungsphase kaum bekämpft werden kann. Bei diesen Systemen
verlagert sich daher der Schwerpunkt der Tests immer mehr in die
Integrationsphase. |
|
Automatische Tests |
| Das Kontrollsystem für die Softwareentwicklung
führt am Ende der Entwicklungsphase etliche Verarbeitungen
automatisch aus, die nicht nur das entwickelte Produkt testen,
sondern auch eine Reihe von Unterlagen zur Vorbereitung des
anschließenden Reviews erstellen.
Die meisten dieser Vorgänge werden allerdings nur mit
Sourceprogrammen ausgeführt, während automatische Verarbeitungen
mit Dokumenten derzeit nicht eingerichtet sind. Verschiedene Tests
und Aufbereitungsarbeiten mit Dokumenten wie Rechtschreibprüfung
oder die Erstellung von Indexeinträgen müssen manuell
vorgenommen werden.
Mit Sourceprogrammen werden am Ende der Entwicklung
standardmäßig folgende Verarbeitungen ausgeführt:
- Der Modul wird kompiliert.
- Der Modul wird mit UniTest getestet, wobei die Ergebnisse in
einer Datei gespeichert werden.
- Bei den Tests von Modulen und Anwendungsprogrammen werden
mit Hilfe entsprechender Werkzeuge Informationen erzeugt, in
welchem Ausmaß der Code durch die Testfälle abgedeckt ist
und welche Sourcezeilen bei den Tests nicht durchlaufen
wurden.
- Im Zuge der Tests wird ein Ausführungsprofil erstellt und
in einer Datei abgelegt.
- Es wird eine Crossreferenceliste und ein Diagramm der
Funktionsaufrufe erstellt.
- Die Tools zur Ermittlung der Softwaremetriken werden
ausgeführt und die Ergebnisse ebenfalls in Dateien
aufgezeichnet.
Tritt bei einer dieser Verarbeitungen ein Fehler auf, wird der
Entwickler entsprechend informiert und muss den Fehler beseitigen,
bevor das System einen Übergang in die Reviewphase zulässt. Alle
Fehler werden vom Kontrollsystem protokolliert. |
|
Prüfungen bei
Reviews |
| Die Prüfung der Software bei Reviews wird durch
die automatisch generierten Auswertungen zu den Sourceprogrammen
unterstützt.
Neben der Inspektion der Sourceliste werden bei den Reviews
daher zunächst alle automatisch erzeugen Informationen geprüft:
Die Testergebnisse müssen mit den vorgegebenen Werten
übereinstimmen und brauchen daher nur noch auf eine
hundertprozentige Testabdeckung geprüft werden. Die erfolgreiche
Absolvierung aller Tests sollte die semantische Korrektheit des
Codes sicherstellen, während die syntaktische Korrektheit schon
bei der Entwicklung geprüft wurde und bei den Reviews nur noch
durch eine Inspektion des Outputs der statischen Syntaxanalyse
kontrolliert wird.
Speziell zu prüfen sind bei Reviews alle Aspekte der Wiederverwendung.
Insbesondere darf der Modul keinerlei Verarbeitungen enthalten,
die bereits in anderen wiederverwendbaren Modulen verfügbar sind.
Bei Anwendungsprogrammen ist zusätzlich zu klären, ob die
Anweisungen nicht besser in wiederverwendbarer Form in einer
Bibliothek abgelegt sein sollten, was allerdings einen
Designfehler darstellen würde.
Im Zuge des Reviews wird die Dynamik der Verarbeitung
anhand der Ausführungsprofile studiert: Es ist zu prüfen, ob die
einzelnen Funktionsaufrufe in einer sinnvollen Reihenfolge
ausgeführt werden und ob unnötige oder doppelte Funktionsaufrufe
vorhanden sind.
Beim Review werden auch alle Tests ausgeführt und
aufgezeichnet, die automatisch nicht ausgeführt werden können.
Die automatisch erzeugten Auswertungen liefern umfassende
Informationen zur Qualität des Codes, die anhand der
Sourceliste verifiziert werden können. Gleichzeitig wird die
Einhaltung der Programmierrichtlinien überwacht. Der Reviewer
beurteilt diese Ergebnisse und veranlasst eventuell Korrekturen.
Sind im Review keine Mängel festgestellt worden, wird das
Produkt mit Hilfe des dafür vorgesehenen Formulars einer Bewertung
nach verschiedenen Qualitätskriterien unterzogen, in welche
auch die automatisch erzeugten Metriken übernommen werden.
Einzelheiten dazu sind im nächsten Kapitel zu finden. |
|
Integrationstests |
| Beim Integrationstest wird das fehlerfreie
Zusammenwirken von verschiedenen Komponenten getestet, wobei je
nach Entwicklungsebene unterschiedliche Verfahren eingesetzt
werden:
Auf der Ebene der Modultests sind keine Integrationstests
vorgesehen. Das Zusammenwirken mit bereits vorhandenen Funktionen,
die von den getesteten Modulen aufgerufen werden, wurde bereits
beim Modultest geprüft. Die Integration übernimmt daher Module
ohne weitere Tests in die Softwarebibliotheken.
Bei Anwendungsprogrammen - welche von der Softwareentwicklung
ohnehin als Module angesehen werden - ist die Situation nicht
anders. Alle von den Programmen verwendeten Funktionsaufrufe
müssen einwandfrei funktionieren, um den Modultest erfolgreich
bestehen zu können.
Die eigentliche Aufgabe der Integrationstest besteht darin, das
Zusammenwirken der einzelnen Programme innerhalb eines
Anwendungssystems und über mehrere Anwendungssysteme hinweg zu
prüfen. |
|
Regressionstests |
| Die Regressionstests haben wegen der Struktur der
Softwareentwicklung bei der Dialog Data eine zentrale Bedeutung:
Wegen des modularen Aufbaus und des hohen
Wiederverwendungsanteils werden sehr viele Module in einer großen
Zahl von Anwendungsprogrammen verwendet und bei der Kompilation
automatisch eingebunden. Das bringt vielfältige Vorteile, führt
jedoch auch dazu, dass sich die Änderung einer solchen
Bibliotheksfunktion auf 50 oder mehr Programme auswirken kann.
Durch die Einrichtung von Standardprüfprozeduren, die
jederzeit wiederholt werden können, kann die gesamte Software
nach jeder Änderung mit den seinerzeit bei der Neuentwicklung
festgelegten Testfällen überprüft werden. Damit können nicht
nur Änderungen von Bibliotheksfunktionen überwacht werden, es
wird auch geprüft, ob Programmanpassungen oder Erweiterungen
nicht vielleicht in anderen Bereichen Störungen verursachen.
Die Regressionstests werden nicht nur von der
Softwareentwicklung verwendet, sie stehen auch den Anwendern zur
Verfügung, die nach jedem Softwareupdate weitgehend
vollautomatisch die Funktionsfähigkeit des gesamten Systems -
jedoch zu einem großen Teil beschränkt auf die in UniTest
eingerichteten Testprozeduren und die dort verwendeten Testdaten -
überprüfen können. |
|
Interne
Akzeptanztests |
| Da praktisch die gesamte bei Kunden installierte
Software auch firmenintern von der Dialog Data genutzt wird,
können Akzeptanztests im Echtbetrieb mit Firmenmitarbeitern
jederzeit durchgeführt werden.
Alle Neuentwicklungen sowie wesentliche Softwaremodifikationen
werden daher vor der Freigabe intern in der praktischen Anwendung
getestet. Hier werden nicht nur Verarbeitungsfehler gesucht, es
werden insbesondere Aspekte der Softwareergonomie beobachtet und
Mängel wie unklares Verhalten der Software, umständliche
Bedienung der Programme oder Performanceprobleme beseitigt.
Wegen der intensiven internen Nutzung unterliegt
selbstverständlich auch die bereits freigegebene Software einem
permanenten Test durch alle Mitarbeiter der Dialog Data im Betrieb
mit Echtdaten. Damit werden Softwaremängel aufgedeckt, noch bevor
sie sich beim Kunden bemerkbar machen. |
|
Softwarebewertung |
| Einen Bestandteil des Testprozesses bildet die
Bewertung der Softwareprodukte nach verschiedenen Kriterien und
Metriken. Diese Bewertung wird in einem eigenen Kapitel
ausführlicher behandelt.
Es können sich jedoch auch im Zuge der Softwarebewertung
Mängel zeigen, die eine Wiederaufnahme des Designprozesses oder
des Entwicklungsprozesses nötig machen. |
|
Test des
Gesamtsystems |
| Falls im Rahmen eines Auftrages mehrere Produkte zu
liefern sind, deren Zusammenwirken sichergestellt sein muss,
erledigt die Systemintegration die Integration und Konfiguration
dieser Bestandteile und führt die entsprechenden Tests durch. |
|
Abnahmetest |
| Mit der Übergabe verbunden ist ein Abnahmetest,
mit dem die vereinbarten Systemleistungen mit den in den
Anforderungen festgelegten Testfällen überprüft werden. Dieser
Test sollte in den allermeisten Fällen völlig unproblematisch
ablaufen, da die Systemintegration bei Hardware und Software und
die Qualitätssicherung bei Dienstleistungen schon vor Beginn der
Abnahme alle vereinbarten Leistungen und Tests überprüft hat und
eine Abnahme nicht zulassen darf, so lange sich noch Abweichungen
von den Spezifikationen zeigen. |
|
Testdokumentation |
| Die Dokumentation der Tests wird ebenfalls bei der
Testplanung festgelegt und richtet sich nach der Aufgabenstellung
beziehungsweise dem damit verbundenen konkreten Testvorgang.
Für bestimmte Testvorgänge sind die Aufzeichnungen - wie das
Protokoll beim Abnahmetest - fix vorgegeben und können im Rahmen
der Testplanung nicht modifiziert werden. |
|
 |
Das Unternehmen |
|
 |
Qualitätswesen |
|
| Softwarebewertung |
 |
| Sicherung der
Dienstleistungsqualität |
|
|
|
|
Unternehmen 
