Testbeispiele (Softwaretest)

IchMagJava

Mitglied
Hallo,
kurze Frage zum oben genannten Thema:

Hier mal eine Definition zum Testen:
"Das Testen umfasst einen Prozess, in dem Unterschiede zwischen dem erwarteten Verhalten, das durch die Anforderungsspezifikation festgelegt ist, und dem beobachteten Verhalten eines implementierten Software-Moduls gefunden werden sollen."
oder
„Testen ist der Prozeß, ein Programm mit der Absicht auszuführen, Fehler zu finden.“

Quell: https://www.uni-marburg.de/fb12/arbeitsgruppen/swt/lehre/files/est1415/EST150113.pdf

Nun zur Frage: Angenommen ein einfaches Programm ist Fehlerfrei programmiert. Soll man dann alle Funktionen ausführen, um das zu beweisen?
Und wenn man tatsächlich einen Fehler gefunden hat, soll man ihn dann korrigieren und das in der Dokumentation angeben?
 

M.L.

Top Contributor
Weiterhin sollte man auch testen, ob der objektiv oder subjektiv fehlerhafte Code überhaupt erreicht und ausgeführt werden kann.
Und wenn man tatsächlich einen Fehler gefunden hat, soll man ihn dann korrigieren und das in der Dokumentation angeben?
Wenn Programmierer und Tester nicht gerade ein- und dieselbe Person sind, könnte man freundlich auf den Fehler hinweisen. Beim eigenständigen Korrigieren kann es an anderer Stelle zu unerwartetem Verhalten kommen. Und in der Doku könnte man das richtige Verhalten beim Bedienen der Software anführen (wobei man als Tester streng genommen nie umfassend weiss, was der Nutzer so alles (nicht) tut um ein bestimmtes Ziel zu erreichen).
 
K

kneitzel

Gast
Also Testen ist wichtig. Bei Unit Tests kann man dann oft auch die Abdeckung sehen und Ziel sollte natürlich sein, dass der Code komplett abgedeckt wurde durch Tests.

Wenn Tester und Programmierer nicht ein und die gleiche Person ist, dann gibt es da aber normalerweise auch entsprechende Abläufe. Oft gibt es da ja dann einen Ablauf, dass ein Arbeitspaket erst implementiert und dann getestet wird und dann geht das Arbeitspaket wieder zurück zur Implementation. (Anders herum muss es ja auch einen Prozess geben, denn der Tester muss ja auch wissen, was er zu testen hat....)

Ziel ist natürlich, dass der Fehler gefixt wird. In wie weit dieser Dokumentiert wird, ist dann natürlich offen:
- Wenn ein Arbeitspaket incl. Unit Tests entwickelt wird, dann ist das einfach nur ein 08/15 Arbeitsablauf. Dokumentation als solche gibt es da nicht. Der Unit Test selbst ist dann die Dokumentation.
- Wenn Fehler innerhalb des Entwicklungszyklus abgedeckt werden, dann ist die Dokumentation normalerweise im Ablauf dokumentiert. Ablauf ist dann halt: Produkt wurde entwickelt -> Geht zum QA -> Geht zurück zur Entwicklung mit Fehlerbeschreibung -> ....
- Wenn ein Fehler erst in Produktion gefixt wird, dann ist dies ein Fall für eine Dokumentation. Aus meiner Sicht gehört hier eine Dokumentation zum einen in ein Bug Tracking Tool und zum anderen in die Release Notes.

So viel einfach einmal zu meiner Sicht auf diese Dinge.
 

mihe7

Top Contributor
Angenommen ein einfaches Programm ist Fehlerfrei programmiert. Soll man dann alle Funktionen ausführen, um das zu beweisen?
Mit Tests wird nicht die Fehlerfreiheit bewiesen. Während des Tests wird lediglich überprüft, ob sich die Anwendung unter definierten Bedingungen so verhält, wie man es erwartet hat.

Und wenn man tatsächlich einen Fehler gefunden hat, soll man ihn dann korrigieren und das in der Dokumentation angeben?
Kommt darauf an, wer was zu welchem Zeitpunkt auf welche Weise testet.

Mal ein Überblick aus meinen Erfahrungen (ist mit Sicherheit nicht vollständig):

1. Der Entwickler testet seine Änderungen, bevor es ins VCS geht, und findet einen Fehler - in dem Fall behebt er diesen natürlich, dokumentiert wird da nix (höchstens in Form von Code -> Unit-Test). Tritt beim Integrationstest (CI-Server) ein Fehler aufgrund einer eingecheckten Änderung auf, bekommt der Entwickler eine Mail. Es ist dann sein Job, sich darum zu kümmern. Dokumentiert wird das meist via VCS.

2. Ein anderer Entwickler findet einen Fehler: hier kommt es darauf an, wie schwerwiegend die Sche ist. Ist es trivial, wird das gefixt. Dokumentiert wird via VCS. Ist es nicht ganz so einfach, wird der andere informiert, der hat sich dann darum zu kümmern. Findet man eine größere Sache, geht der Spaß zusätzlich in den Bugtracker.

3. Bevor eine Änderung freigegeben wird, wird sie bei uns in der Regel von einer unabhängigen Person manuell getestet. Das ist ein klassischer Black-Box-Test. Der Tester hat relativ wenig (keine) Ahnung von Programmierung und spielt als Anwender verschiedene Szenarien durch. Findet der was, wird das in der Regel per Mail kommuniziert. Entwickler schaut sich das an, und hat wieder die Möglichkeiten von oben: VCS und Bugtracker.

4. Meldet der Kunde einen Fehler: Bugtracker.
 

Neue Themen


Oben