Methode : Software-Tests
Start - Index - Inhaltsverzeichnis - Evaluation
letzte Aktualisierung: 16. Juli 2004
Dieser kurze Beitrag befasst sich mit dem Testen von Software, wie er im Informatikbereich beim Qualitätsmanagement durchgeführt wird. Er soll einen kurzen Überblick über mögliche Methoden und Ansatzpunkte für technische Evaluationen bieten. Vertiefende Informationen bitte der entsprechenden Fachliteratur entnehmen.
_____
Einführung
Thaller definiert einen Test als die systematische Fehlersuche mit dem Ziel, das Vorhandensein eines Fehlers zu beweisen. Debugging hingegen ist die Suche nach der Ursache eines Fehlers, nachdem dieser eindeutig festgestellt wurde. (Thaller 1997, S. 106)
Als problematisch sind in diesem Zusammenhang nichtreproduzierbare Fehler einzustufen, da deren Ursache kaum auffindbar sind. Diese Probleme verringern allerdings den Wert eines Produktes.
Aufgabe eines Evaluierenden ist i.d.R. nur das Testen, und somit das Auffinden von Fehlern, während das Debugging (Beseitigung von Fehlern) den SoftwareentwicklerInnen überlassen wird.
_____
Tests ohne Computer
Thaller nennt zwei Testmethoden, mit denen der Quellkode einer Software ohne Computer geprüft werden kann. Bei beiden Verfahren handelt es sich um Peer Reviews, an denen sich ProgrammiererInnen beteiligen (Thaller 2000, 37). Da diese im Vorfeld / am Beginn einer Entwicklung stattfinden, tragen sie zu einer frühzeitigen Problemaufdeckung bei (preformative Evaluation).
- Fagan Inspections
- Hier wird das Programm ExpertInnen vorgestellt, die dann auf Fehler hinweisen sollen (Thaller 2000, 34ff.). (S.a. Inspektion als Vorstellung der Software bei KollegInnen; Balzert 2000, 305ff.)
- Walkthroughs
- Diese sind Testfälle (sog. Paper Test Cases), die mit der ausgedruckten Programmierung durchgespielt werden (Thaller 2000, 39ff.). (Balzert beschreibt Walkthrough anders, und zwar stellt der Autor bzw. die Autorein seine bzw. ihre Arbeit vor und wird dabei von GutachterInnen befragt; Balzert 2000, 321ff.)
Balzert nennt zwei weitere Methoden:
- Review
- Überprüfung durch eine Gutachterin bzw. einen Gutachter (Balzert 2000, 317ff.).
- Stellungnahme
- Kollege bzw. Kollegin gibt Kommentare zu dem Produkt (Balzert 2000, 323).
(Linktipps: http://www.reviewtechnik.de/einfuehrung.html Stand: 07.2004,
Formal Technical Review (FTR) http://www2.ics.hawaii.edu/~johnson/FTR/ Stand: 07.2004.)
_____
Tests von Einzelmodulen (Modultest)
Hier geht es um das Testen von einzelnen Bausteinen eines Softwareproduktes.
- White Box Test
- Bei der Programmierung kann mensch einzelne Module auf die Qualität des Quellcodes hin untersuchen. Der Test erfolgt am Computer, der mit unterschiedlichen Testwerten gefüttert wird. Die Ergebnisse werden dann auf Ihre Richtigkeit überprüft (Thaller 2000, 53). Der Test wird von der Entwicklerin bzw. vom Entwickler durchgeführt, welche/r die Programmlogik kennt (Thaller 2000, 220).
- Black Box Test
- Hier testen externe Personen die Funktion eines Programms. Extern bedeutet, das die Testperson nicht an der Entwicklung beteiligt war, sie kann aber aus der selben Firma stammen wie die entwickelnde Person (Thaller 2000, 75ff.). Sie kennt nicht den Quellcode der Software (Thaller 2000, 215).
Weitere Modultests sind:
- Equivalence Partitioning
- Tests mit typischen Werten (gleichwertigen Variablen), wie sie in der Praxis vorkommen (Thaller 2000, 82ff.).
- Boundary Analysis (Analyse von Grenzwerten)
- Tests mit Grenzwerten und deren unmittelbaren Nachbarn, inklusive falschen Werten (Thaller 2000, 84ff.).
- Error Guessing
- Kreation von Testfällen aus der Praxiserfahrung des Experten bzw. der Expertin, die auf Problemen anderer Software basiert (Thaller 2000, 87ff.).
_____
Tests von Systemen (Systemtest)
Nach der Entwicklung von Einzelmodulen werden diese zu einem System zusammengefügt. Dieses muss dann wieder getestet werden.
- Funktionstest
- Prüfung der Zusammenarbeit der Module im Gesamtsystem (Thaller 2000, 112ff.).
- Volume-Test
- Durch eine große Datenmenge (Dummy-; Originaldaten) wird die Belastbarkeit des Systems getestet; dies geschieht auch um die Grenzen der Software finden (Thaller 2000, 115ff.). (s.a. Massentest bei Balzert 2000, 539). Dies ist z.B. interessant beim Einsatz von Logfile-Aufzeichnungen, da hier große Datenmengen anfallen können.
- Lasttest
- Dabei prüft die Zuverlässigkeit der Software unter hohen Anforderungen über einen längeren Zeitraum (Balzert 2000, 540). Dies kann z.B. durch einen paralleren Zugriff mehrerer Rechner auf eine Videodatei geschehen.
- Stress-Test
- Hier wird eine hohe Belastung in einem kurzen Zeitraum erzeugt (Thaller 2000, 118; Balzert 2000, 540).
- Speicherverbrauch und Auslastung des Prozessors
- Prüfen, ob durch eine extreme Spitzenbelastung eine Überlastung des Prozessors und des Hauptspeichers möglich ist (Thaller 2000, 119).
- Recovery Testing
- Probleme klären, die nach einem Programmabsturz / Computerabsturz auftreten (Thaller 2000, 119f.).
- Mutationstest
- Dies ist ein Prüfung der Testmethoden durch Änderung der Software (Thaller 2000, 120f.).
- Test der Mensch-Maschinen-Schnittstelle
- Subjektive Beurteilungen durch Testpersonen erstellen lassen (Thaller 2000, 121f.). (s.a. Benutzbarkeitstest (usability test): Dieser prüft die Nutzungsfreundlichkeit des Systems (Balzert 2000, 540).
- Benchmark-Test
- Test der Leistungsfähigkeit der Software per Messungen vornehmen (Thaller 2000, 122ff.).
- Test von Prozeduren und Verfahren
- Eine Nutzungsanalyse und und das Aufdecken von Vorgehensweisen vor Ort durchführen (Thaller 2000, 125).
- Zeittest
- Hier wird die Reaktionszeit auf Benutzereingaben geprüft (Balzert 2000, 539). Dies ist besonders sinnvoll bei der Nutzung von Simulationen, bei denen umfangreiche Berechnungen durchgeführt werden müssen.
- Interoperabilitätstest
- Dieser prüft die Zusammenarbeit mit dem verwendeten Betriebssystem und sonstiger installierter Software (Balzert 2000, 541).
- Installationstest
- Dieser prüft, ob das System ohne Probleme und komplett installiert werden kann (Balzert 2000, 542).
- Wiederinbetriebnahmetest
- Dieser prüft das Verhalten des Systems nach einem Absturz des Computers bzw. nach einem Stromausfall (Balzert 2000, 542).
- Facility Testing
- Prüfung, ob geforderte Eigenschaften vorhanden sind (Thaller 1997, 109). (s.a. Funktionstest, welcher prüft, ob alle vorgesehen Funktionen vorhanden sind (Balzert 2000, 537).
- Configuration Test
- Tests auf verschiedenen Rechnerplattformen / -zusammenstellungen durchführen (Thaller 1997, 110).
- Security Testing
- Test auf Datensicherheit vor unerlaubtem Zugriff, ggf. Prüfung ob Datenschutzbestimmungen eingehalten wurden (Thaller 1997, 111). (s.a. Sicherheitstest. Dieser prüft die Sicherheitsmaßnahmen des Systems (Balzert 2000, 541). Dazu gehören Passwörter, der Schutz vor Hacker-Angriffen und die Änderungen von Systemeinstellungen.)
- Compatibility / Conversion Testing
- Prüfung des Ergebnisses eines Updates (Thaller 1997, 111).
- Integrationstest (integration test)
- Prüfung der zugesicherten Eigenschaften der Schnittstellen zwischen der Software und anderen Programmen (Heinrich 1992, 185).
- Leistungstest (performance test)
- Prüfung der Einhaltung zugesicherter Eigenschaften bei der Leistung einer Software über einen bestimmten Zeitraum (Heinrich 1992, 185).
_____
Tests am Ende einer Entwicklung (Endtest)
Balzert (2000, 537, 542) unterscheidet beim Endtest zwischen einem System- und einem Abnahmetest.
Beim Systemtest (Balzert 2000, 537) wird die Software in der realen Umgebung ohne d. Auftraggeber/in getestet. Beim Abnahmetest (Balzert 2000, 542) ist d. Auftraggeber/in anwesend. Dabei werden ein Teil der bei Systemtests genannten Methoden eingesetzt.
_____
Hinweis:
Das Testen von objektorientiert-programmierten Software-Produkten unterscheidet sich vom Testen anderer Produkte (Winter 1999, 37-40), so dass teilweise neue Methoden benötigt werden (Winter 1999, 40).
_____
Literatur:
Balzert, H. (1998): Lehrbuch der Software-Technik : Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Heidelberg, Berlin, Spektrum Akademischer Verlag.
Heinrich, Lutz J. (1992): Informationsmanagement : Planung, Überwachung und Steuerung der Informations-Infrastruktur. 4., vollständig überarbeitete und ergänzte Auflage. München, Wien, Oldenbourg.
Thaller, G. E. (1997): Der Individuelle Software-Prozess : DIN EN ISO 9001 für Klein- und Mittelbetriebe. Kaarst, bhv.
Thaller, G. E. (2000): Software-Test : Verifikation und Validation. Hannover, Heise.
Erstes Kapitel der Auflage von 2002:
http://www.dpunkt.de/leseproben/3-88229-198-2/Kapitel_1.pdf Stand: 07.2004
Winter, Mario (1999): Qualitätssicherung für objektorientierte Software - Anforderungsermittlung und Test gegen die Anforderungsspezifiktion.
ftp://ftp.fernuni-hagen.de/pub/fachb/inf/pri3/papers/winter/diss.pdf Stand: 07.2004, Dissertation
Linktipp:
Schirmacher, Arne (2001/2002): Testdokumentation nach ANSI/IEEE 829.
http://www.softwaretesting.de/article/articleprint/1/ Stand: 07.2004 Teil 1
http://www.softwaretesting.de/article/articleprint/50/ Stand: 07.2004 Teil 2
Start - Index - Inhaltsverzeichnis - Evaluation
© 2002-2004 Marc Jelitto, marc@evaluieren.de