Systematische Testcase-Entwicklung

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • 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 ?

  • 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:
    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.

  • 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 seleniumhq.org/ (Meine Empfehlung) oder 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

  • "Hafner" schrieb:

    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.