Die geeignete
Vollständiges Testen ist i.a. nicht möglich und auch unwirtschaftlich.
Getestet werden sollte u.a:
Änderungen an einem Softwaremodul haben oft Auswirkungen auf den benachbarten Modulen. So können sich bei schlechten Design Fehler durch das gesamte System fortpflanzen. D.h. bei einer Änderung im System sollten die vorherigen Tests wiederholt werden. Deshalb sollten die Tests programmatisch erfolgen.
Um den Aufwand gering zu halten, benötigt der Entwickler ein
Ein
Testfall besteht meistens aus einem BlackBoxTest . Dabei wird nur das Testobjekt und das zu erwartete Ergebnis der zu testeten Operation erzeugt. Beim Ausführen des Tests wird die Operation auf das Testobjekt angewendet, und das tatsächliche Ergebnis mit dem erwarteten Ergebnis verglichen. Das Testframework protokolliert den (Miss -) Erfolg des Tests automatisch.Als problematisch erweist sich die Synchronisation der Softwareumgebung mit der
Testumgebung. Im Idealfall erzeugen kleine Änderungen in der Softwareumgebung nur kleine Änderungen in der Testumgebung ( Regressionstest). Die Erfahrung zeigt aber, daß der Programmierer nicht jede Änderung in der Testumgebung nachvollzieht. (Es hemmt auch die Kreativität). Es empfiehlt sich daher während der Entwicklung einen Softwareteil mit einfachen konventionellen Mitteln zu testen. Erst wenn der Softwareteil in einem stabilen Zustand ist, wird die Testumgebung ergänzt.In der objektorientierten Programmierung ist das kleinste Testobjekt i.a. die Klasse. Die Funktionalität der Klasse wird durch
Testfälle abgedeckt. Pro Klasse gibt es einen TestSuite, der diese Testfälle zusammenfaßt. Das Zusammenspiel der Klassen wird durch Integrationstest überprüft. Integrationsteste sind meistens auf Applikations (Package) Ebene. Der Zusammenspiel der Packages wird durch einen Integrationstest auf Systemebene überprüft.
Eine wichtige Bemerkung zum Schluss:
Einen schlechten Design kann man nicht durch qualitativ hochwertige Tests gutmachen.
Glossar:
BlackBoxTestEin Test, bei dem nur das Endergebnis mit dem zu erwarteten Ergebnis verglichen wird. Die Zwischenschritte werden nicht beachtet.
Ein Tool, das überwacht welche Softwareteile wie oft und ggf. mit welchen Parametern aufgerufen wurde. Dies ergibt ein Indiz welcher Teil des Codes ausreichend oder weniger ausreichend getestet wurde.
Testet ob (schon erfolgreich getestete) Einzelmodule korrekt zusammenarbeiten.
Enthält Fehlerauswirkung, wer den Fehler wann entdeckt hat, wie er erzeugt wird, sowie die Soft- und Hardwareumgebung. Sinnvollerweise wird dies ergänzt durch folgende Einträge: Lokalisierung des Fehlers im Code, verantwortlicher Programmierer, Skizze der Lösung sowie Referenz auf Testroutine die das Vorhandensein des Fehlers kontrolliert.
Die ausgeführten Testfälle werden gespeichert und können nach Fehlerkorrekturen, aber auch für den Auftraggeber beim Abnahmetest oder bei der Wartung - wiederholt werden.
Aktivität in der Analysephase. Es werden die Anforderungen an ein Softwareprodukt festgelegt.
Ein Einzeltest der gezielt eine Anforderung, oder früher aufgetretener Fehler überprüft.
Erleichtert dem Programmierer das Erstellen geeigneter Testsuiten , und steuert die Ausführung.
Teil des Projektplans, in dem festgelegt wird, wer wann welche Tests durchführt.
Wird im Idealfall vom TestFramework automatisch ausgeführt. Es wird protokolliert wann welche Tests unter welcher Testumgebung mit welchen (Zwischen-) Ergebnissen durchlaufen worden sind.
Es werden die Tests und Testumgebung für die Softwareteile festgelegt.
Zusammenfassung von Testfällen.
Hard- und Softwareumgebung bei der Ausführung der Tests