Systematische Testcase-Entwicklung

Intermediate

Monday, December 5th 2011, 10:26pm

Systematische Testcase-Entwicklung

Hi,

ich arbeite jetzt seit ~16 Monaten an einem Projekt, das mittlerweile die Baby- und proof-of-concept Phase deutlich überwachsen hat.
Immer öfter kommt es zu BugFixes die neue/maskierte Fehler zu Tage fördern.
Und immer öfter stelle ich fest, dass ich kaum noch vollständig testen kann. (unerwartete Seiteneffekte)

Die Applikation kann fast vollstandig per Maus, (Multi)Touch, Stift oder Tastatur gesteuert werden um die Akzeptanz zu maximieren.
Zudem hat sie moderat asynchronen Charakter (je nach Zyklus 7 bis 9 Threads exclusive GUI Thread).

Wir entwickeln agil mit Zyklen zwischen 1-2 Wochen.

Zum Glück wurde jetzt ein Versions-freeze angeordnet und das erste Release steht Ende dieses Jahres an. *freu*
Dadurch hab ich jetzt die Zeit anstatt von neuen features unittests zu schreiben.

Was mich interessiert: Habt ihr irgendwelche Erfahrungen/Systematiken, im Nachhinein Unittests hinzuzufügen.
Ich meine womit fängt man am besten an, welche können vorerst vernachlässigt werden.
Also mein erster Ansatz ist jetzt anhand von Assoziationen zu schauen, welche Klassen von den meisten anderen Klassen benutzt wird.
Es ist aber mit nichten so, dass aufgrund dieser Ordnung auch gleich die wichtigsten gefunden werden.

Ich hoffe die Informationen reichen aus - habt ihr da irgendwelche best-practices finden können oder mal einen Weg eingeschlagen, der sich am Ende als falsch herausgestellt hat ?

Hafner

Professional

Posts: 630

Tuesday, December 6th 2011, 12:12am

Hmm,
ich finde den Ansatz mit den Assoziationen nicht so überzeugend. Allerdings komme ich vermutlich aus einem völlig anderen Umfeld der Programmierung.
Normalerweise gibt es ja eine Testphase in denen Anwender deine Software bedienen und Fehler reporten. Mann könnte also annehmen, dass dabei gerade auch die Klassen mit vielen Assoziationen schon gut durchgenommen wurden.

Ich würde zunächst den Focus auf die semantisch wichtigen Sachen legen. Wenn es z.B. eine Software ist, die mit Geld rechnen muss, dann sind disbezügliche Methoden von hoher Wichtigkeit.
Dann sollte man Dinge testen, die durch das einfache durchklicken nur schwer gefunden werden können (z.B. parallele Aufgaben, die im Hintergrund laufen). Wenn du dort ansetzt ergänzt du recht gut den "Durchklick"-Test der Anwender.

Gennerell kann ich dir eine Erfahrung ans Herz legen:
Wenn du einfach nur Tests schreibst, dann ist das zwar schön und gut, aber auf Dauer kümmert sich kein Schwein darum ob sie noch durchlaufen oder nicht. Abhilfe schafft da nur die automatische Ausführing der Unit-Tests.

Für Java gibt es zum Beispiel das Jenkins-Projekt:
http://jenkins-ci.org/
Das ist ein Server, der bei Änderungen im SVN (Git, CVS) automatisch auscheckt, kompiliert, die Unit-Tests ausführt und das Ergebnis per E-Mail an den Nutzer schickt, der eingecheckt hat. Sowas solltest du dir organisieren.

stealth_axg

Intermediate

Posts: 42

Tuesday, December 6th 2011, 11:45am

Je nach Architektur gibt es verschiedene Werkzeuge und Frameworks. Bei uns wird die Datenbank, das Backend und die Oberfläche getrennt betrachtet(jeder hat seine eigenen Tests ), wobei die Oberfläche den umfassenden Ansatz bietet.

Ich würde versuchen den Workflow/Testszenarien auf der Oberfläche mit http://seleniumhq.org/ (Meine Empfehlung) oder http://htmlunit.sourceforge.net/ (Naja) nachzubilden.

Vorteile:
- check der gesamten Anwendung (Oberfläche, Backend, Persistenzschicht)
- Komplexe Testszenarien möglich
- Kann vom Fachbereich durchgeführt werden

Nachteile:
- sehr wartungsintensiv
- nicht regressionstestfähig
- oberflächenabhängig

Latest blogs: Weihnachtsgewinnspiel 2010, Beyond Tellerrand - Mobile 2011

Runnable

Intermediate

Posts: 52

Tuesday, December 6th 2011, 6:15pm

Danke euch, werde darauf eingehen, wenn ich eine Nacht darüber nachgedacht habe.

Gibt es noch weitere Statements ?

Runnable

Intermediate

Posts: 52

Wednesday, December 7th 2011, 8:26pm

Quoted from ""Hafner""

Ich würde zunächst den Focus auf die semantisch wichtigen Sachen legen. Wenn es z.B. eine Software ist, die mit Geld rechnen muss, dann sind disbezügliche Methoden von hoher Wichtigkeit.
Dann sollte man Dinge testen, die durch das einfache durchklicken nur schwer gefunden werden können (z.B. parallele Aufgaben, die im Hintergrund laufen). Wenn du dort ansetzt ergänzt du recht gut den "Durchklick"-Test der Anwender.

Danke für die Inspiriration;
ich denke ich werde mir Thread für Thread einzeln vornehmen und dann danach filtern, was durch das Durchklicken schon abgedeckt ist.
Anschliessend bieten sich wohl alle Zeilen an, die Synchronisationsmechanismen nutzen - das wird vermutlich auch am aufwändigsten.

@stealth_axg: Danke für die Info, mal schauen ob sich ein Tool nützlich macht - bisher ist alles noch rein theoretisch; auf jeden Fall ist es glaube ich nicht schlecht, deinen Beitrag im Hinterkopf zu behalten.