IT -Teststrategien, -umsetzung, -technologien

IT -Teststrategien, -umsetzung, -technologien

Posts 1-4 of 4
  • Dr. Stephan Weißleder
    Dr. Stephan Weißleder
    The company name is only visible to registered members.
    Softwaretests solo?
    Hallo,

    zum Testaufbau gehören ja nicht nur die Testziele, sondern auch die Grundlagen und Spezifikationen, auf deren Basis oder gegen die getestet werden kann, sowie die Techniken, die die Testrealisierung und -ausführung unterstützen.

    Ich selbst beschäftige mich mit der automatischen Erstellung von Softwaretests auf der Basis von UML-Modellen.
    Mich interessiert einerseits, inwieweit Testen in welchem Umfang in der Praxis angekommen ist:
    - schreiben die Tester die Tests nach Gutdünken?
    - schreiben die Tester die Tests nach in/semi-formalen Dokumenten?
    - kommen auch formale Dokumente zum Einsatz (z.B. Szenarien in einer formalen Sprache (Petrinetze, ASM, ...))?
    - werden Tests auch schon automatisch generiert (wenn ja: auf welcher Basis?)?

    Andererseits interessiert mich, ob Testen "solo" eingesetzt wird oder von weiteren Techniken begleitet wird / werden kann.
    Spätestens bei der automatischen Generierung müssen weitere Techniken zum Einsatz kommen, die die Wahl der Testfälle und die Wahl der Eingabedaten übernehmen oder schlicht ein Testendekriterium definieren. Solche Techniken finden sich z.B. im Bereich der statischen Analyse. Es gibt zahlreiche theoretische Arbeiten (teilweise auch mit SW-Realisierung), die sich mit der Verbindung der dynamischen und statischen Analyse (Kontrollflussanalyse, Datenflussanalyse, ...) beschäftigen, um z.B. dem Problem der Zustandsexplosion zu begegnen. Dabei kann man zusätzlich noch unterscheiden, auf welchem Teilgebiet man sich gerade bewegt: evolutionäres Testen, Regressionstests, modellbasierte Tests, ...

    Welche konkreten Verwendungen oder Projekte sind Ihnen bekannt, bei denen dieser gekoppelte Einsatz verschiedener Techniken zum tragen kam? Welchen Effekt hatte diese Kopplung? Und sind Ihnen weitere Möglichkeiten bekannt, Softwaretests durch zusätzliche Techniken zu ergänzen / verbessern?
    This post was modified on 23 Mar 2007 at 05:03 pm.
    • 23 Mar 2007, 4:56 pm
  • Martin Böhm
    Martin Böhm
    The company name is only visible to registered members.
    Re: Softwaretests solo?
    Hallo Herr Weißleder,

    das sind ja sehr viele Fragen auf einmal.
    Um es vorweg zu sagen, es gibt kein Softwareentwicklungsprojekt in dem nicht
    getestet wird, denn Tests gehören obligatorisch dazu - ohne Test keine Abnahme!
    Allerdings sind die Testarten von Projekt zu Projekt sehr unterschiedlich und
    abhängig von den Qualitäts- und Softwareanforderungen. Während das eine
    Projekt hohe Performanceanforderungen stellt, mag ein anderes eher mit hohen
    Usability-Anforderungen konfrontiert sein.

    Aus diesen Anforderungen ergeben sich kurz gesagt Testkonzepte, die dann in
    die entsprechenden Testspezifikationen münden, in Szenario 1 könnten dies
    sehr umfangreiche und ausgeklügelte Performancetests, in Szenario 2 könnten
    dies umfangreiche Tests mit Probanden unter der Regie von Psychologen und
    Softwareergonomen sein.

    Wenn Sie mit UML-Modellen arbeiten, kennen sie ja die einfachen Use-Cases.
    Aus diesen lassen sich bereits grobe Abnahmetests entwickeln. Das ist auch
    eine der Möglichkeiten, wie die Tester ihre Testfälle entwickeln, um Ihre
    1. Frage aufzugreifen. In der Regel nutzen die Tester jedoch alle Ihnen zur
    Verfügung stehenden Dokumente, um ihre Tests grob zu entwickeln. Im Anfangs-
    stadium sind das manchmal sogar Lasten- und Pflichtenhefte, denn meist sind
    die Softwarespezifikationen und -beschreibungen selbst noch in der Entwick-
    lung oder unvollständig.

    Nach Gutdünken wird hier nicht entwickelt, denn der Testfokus ist meist durch
    die Softwareanforderungen schon gut abgesteckt. Wesentlich schwieriger ist
    es für die Tester die entsprechenden Tests dafür zu entwickeln. Nicht zu
    unterschätzen ist dabei die notwendige fachliche Expertise, die die Tester
    mitbringen müssen, insbesondere dann, wenn fachliche und technische Eigen-
    schaften der Software getestet werden müssen, z. B. hat nicht jeder Tester
    Kenntnisse im Bankenwesen bzw. im Umgang mit XML-Parsern.

    Aber das sind ja bei weitem nicht alle Testmöglichkeiten. Für die Beschreibung
    und Spezifikation von Lasttests kommen die Ausgangsdaten der Tester meist aus
    den Lastverhaltensanforderungen des Pflichtenheftes.

    Zu Ihrer 2. Frage könnte man verkürzt sagen, dass die Testfallbeschrei-
    bungen mit zunehmender Projektgröße und Testumfang formaler gestaltet
    sind. Während für grobe Testkonzepte häufig Word die beste Wahl ist, um
    die Tests prosaisch zu notieren, muss es für den genau spezifizierten
    und mit Testdaten zu verknüpfenden Testfall häufig ein spezielles
    Werkzeug sein. Notwendig ist das vorallem aus folgenden Gründen:
    - die Test müssen immer wieder nachvollziehbar und u. U. wiederholbar
    sein, dazu müssen die Ausgangsbedingungen, Testaktionen und Ergebnisse
    nachvollziehbar sein.
    - je formaler die Spezifikation umso einfacher lassen sich Auswertungen
    über alle Testfälle erstellen, z. B. über die Testabdeckung bestimmter
    Use-Cases und natürlich auch Auswertungen über den Testfortschritt.

    Zu Ihrer 3. Frage: Natürlich kommen auch die von Ihnen angesprochenen
    Dokumente und Beschreibungssprachen zum Einsatz. Jenachdem, wie es das
    Testkonzept eben vorsieht sind für die unterschiedlichen Testszenarien
    unterschiedliche Testhilfsmittel sinnvoll; angefangen bei einfachen
    Testchecklisten mit entsprechenden Testkonstellationen bis hin zu
    Zustandsgraphen, die für die Prüfung und Kontrolle von Zustands-
    änderungen hinzugezogen werden.

    Zu Ihrer 4. Frage: Mit der Generierung von Tests selbst habe ich zwar
    selbst noch nicht zu tun gehabt, weiß aber, dass man beispielsweise
    aus den Constraints bestimmter OO-Modelle Testfälle insoweit generieren
    kann, dass man aus den ermittelten Grenzwerten entsprechende Testdaten
    generiert.

    Zu ihrer letzten Frage: Im allgemeinen werden Testtechniken selten
    isoliert eingesetzt, denn die zu testenden Anforderungen einer
    Software, mag sie auch noch so simpel sein, lassen sich selten mit
    nur einer Testtechnik prüfen. LSP- und Funktionstests gelten als
    state-of-the-art, genauso wie logische Prüfungen von Code, die von
    den meisten Softwareentwicklungswerkzeugen mitgebracht werden.

    Aber nicht nur das, auch entwicklungsbegleitend wird immerwieder
    geprüft; Code- und Architekturreviews, Call-Analysen, Tracking und
    Logging etc. pp.

    Man könnte hier noch unzählige weitere in der Praxis geführte Techniken
    aufführen. Aber wie ich bereits andeutete ist dieses Feld einfach un-
    erschöpflich. Die eher bedeutendere Frage im QS-Umfeld beschäftigt
    sich eher damit, genau jene Testtechniken herauszufinden, die im
    betreffenden Projekt den größten Nutzen bei geringem Aufwand erzielen.

    Viele Grüße,
    Ihr Martin Böhm
    • 27 Mar 2007, 9:39 pm
  • Dr. Stephan Weißleder
    Dr. Stephan Weißleder
    The company name is only visible to registered members.
    Re^2: Softwaretests solo?
    Sehr geehrter Herr Böhm,

    vielen Dank für Ihre Antwort. Ich hätte meine einleitenden Fragen vielleicht etwas kürzer halten und meinen Fokus auf mein eigentliches Ziel setzen sollen: die konkrete Kombination von Testtechniken mit anderen eher statisch orientierten Methoden, die auch schon automatisiert ausführbar sind.

    Methoden wie das Slicing (dynamisch, statisch, forward, backward, conditioned, ...), statische Analyse, Model Checking ergeben hier einige Möglichkeiten für die Kombination.
    So bietet gerade das Conditioned Slicing Möglichkeiten, die Domänengrenzen von Tests zu überprüfen. Die statische Analyse hilft, den Testfokus einzugrenzen und Model Checking erlaubt es, Eigenschaften auf einem formalen Modell des Systems zu überprüfen, aus deren Verletzung automatisch Testfälle erzeugt werden können.

    Arbeiten von Ammann, Black, Gargantini, Heitmeyer, Khor, Grogono, Bogza, Artho, Biere, Wegener, Mueller, Ghirvu, Hierons, Harman, Chang, Pargas, etc. liefern für eine solche Verknüpfung verschiedener Technologien eine breitgefächerte theoretische Grundlage, die teilweise sogar schon in tools umgesetzt wurde.

    Meine eigentliche Frage in dem Sinne ist also inwiefern die Verknüpfung solcher Methoden schon in der Praxis angekommen ist.

    Mit freundlichen Grüßen,
    Stephan Weißleder
    • 15 Apr 2007, 3:15 pm
  • Martin Böhm
    Martin Böhm
    The company name is only visible to registered members.
    Re^3: Softwaretests solo?
    Hallo Herr Weißleder,

    bisher habe ich mich mit den von Ihnen genannten Methoden noch
    nicht eingehend in der Praxis beschäftigt. Ich denke, dass
    gerade die statische Analyse weniger im Bereich des Testens
    eine Rolle spielt sondern vielmehr bei der logischen Prüfung
    und Optimierung von Code, quasi zur Verbesserung der Code-
    quality. Tools zur Erstellung von Code-Metriken gibt es ja einige.
    Insofern würde mich einmal interessieren, welche Tools es in
    Richtung der statischen Analyse außerhalb der Ermittlung von
    Code-Metriken noch gibt und wie diese genau arbeiten.
    Können sie mir einige Tools mit deren Anwendungsfokus
    nennen?

    Dass sich die Möglichkeiten der statischen Analyse bisher
    noch nicht so im Bereich der automatischen Erstellung von
    Testfällen durchsetzen konnten, könnte meiner Ansicht nach
    wohl daher rühren, dass die Testfälle eher von technischen
    Laien erstellt und durchgeführt werden, die Technizität
    und Logik des Codes allerdings hauptsächlich von
    Programmierern und Mathematikern beherrscht wird. Ich
    denke, dass diese Diskrepanz ein Grund für den wenig ver-
    breiteten Einsatz sein könnte, u. A. vielleicht auch,
    weil gerade aktuelle Entwicklungsumgebungen bereits aus-
    reichend gute Codeoptimierungsmöglichkeiten anbieten und
    andererseits, es für viele Anwendungsfälle ausreichend
    ist, die Testfälle aus den Use Cases abzuleiten.

    Mit freundlichen Grüßen
    Martin Böhm
    • 30 Apr 2007, 10:55 pm