Zum Inhalt springen

Statisches Software-Testverfahren

aus Wikipedia, der freien Enzyklopädie

Statische Software-Testverfahren (kurz: statische Tests) gehören zu den analysierenden Verfahren beim Softwaretest und unterteilen sich in

  • Strukturierte Gruppenprüfung (englisch {{#invoke:Vorlage:lang|flat}})
  • Statische Code-Analyse bzw. kurz statische Analyse

Statische Software-Testverfahren zeichnen sich dadurch aus, dass die Software bei diesen Tests nicht ausgeführt wird ({{#invoke:Vorlage:lang|flat}}), im Gegensatz zu dynamischen Software-Testverfahren ({{#invoke:Vorlage:lang|flat}}).

Software Reviews

{{#if: Review (Softwaretest)|{{#ifexist:Review (Softwaretest)|

|{{#if: |{{#ifexist:{{{2}}}|

→ Haupt{{#if:|seite|artikel}}: [[{{{2}}}{{#if: ||{{{titel2}}}}}]]{{#if: |{{#ifexist:{{{3}}}| und [[{{{3}}}{{#if: ||{{{titel3}}}}}]]|}}|}}

|{{#if: |{{#ifexist:{{{3}}}|

→ Haupt{{#if:|seite|artikel}}: [[{{{3}}}{{#if: ||{{{titel3}}}}}]]

|}}|}}|}}|}}|}}|Einbindungsfehler: Die Vorlage Hauptartikel benötigt immer mindestens ein Argument.}}

Bei Reviews nutzt man die menschlichen Denk- und Analysefähigkeiten, um durch Lesen und Nachvollziehen das Testobjekt zu prüfen. Die Norm IEEE 1028 ({{#invoke:Vorlage:lang|flat}}<ref name="IEEE2008" />) beschreibt fünf Reviewarten:

  • Management-Review
  • Technisches Review
  • Walkthrough
  • Inspection
  • Audit

Diese Reviewarten können prinzipiell auf alle Arbeitsergebnisse im Softwareentwicklungsprozess (z. B. Anforderungsspezifikationen, Designspezifikationen, Quelltext, Testspezifikationen, Softwaredokumentation) angewendet werden und bieten damit die Möglichkeit, bereits sehr früh in der Softwareentwicklungsphase qualitätssichernde Maßnahmen durchzuführen. Teilnehmer eines solchen Reviews sind mindestens der Autor des Programms, ein Gutachter, ein Protokollant und ein Moderator. Häufig kommt eine standardisierte Checkliste zum Einsatz. Mit Hilfe eines vollständigen Reviews werden 60–90 % der Fehler gefunden. Der Walkthrough ist eine Variante mit weniger formalistischem Aufwand und weniger Teilnehmern.

Beispielhafte Checkliste

  1. Funktionsumfang / Spezifikation / Entwurf / Dokumentation
    Ist die Funktion entsprechend der Spezifikation umgesetzt worden?
    Ist die Dokumentation des Programms vorhanden und vollständig
    Enthält das Programm nicht gewünschten / spezifizierten Code?
    ...
  2. Programmierung allgemein
    Gibt es mehrfach vorhandenen Code (z. B. durch mehrfaches Kopieren)
    ...
  3. Initialisierung und Deklaration
  4. Methodenaufruf
  5. Felder
  6. ...

Statische Analyse

{{#if: Statische Code-Analyse|{{#ifexist:Statische Code-Analyse|

|{{#if: |{{#ifexist:{{{2}}}|

→ Haupt{{#if:|seite|artikel}}: [[{{{2}}}{{#if: ||{{{titel2}}}}}]]{{#if: |{{#ifexist:{{{3}}}| und [[{{{3}}}{{#if: ||{{{titel3}}}}}]]|}}|}}

|{{#if: |{{#ifexist:{{{3}}}|

→ Haupt{{#if:|seite|artikel}}: [[{{{3}}}{{#if: ||{{{titel3}}}}}]]

|}}|}}|}}|}}|}}|Einbindungsfehler: Die Vorlage Hauptartikel benötigt immer mindestens ein Argument.}}

Die statische Analyse hat das Ziel, Fehler im Programmcode oder in formal beschriebenen Softwaremodellen zu finden. Die statische Analyse wird mit entsprechender Werkzeugunterstützung durchgeführt. Einsatzgebiete von statischen Analysewerkzeugen sind die Überprüfung gegen Programmierrichtlinien, Datenflussanalyse, Kontrollflussanalyse und Erstellung von Metriken (z. B. Lines of Code (LOC), Zyklomatische Komplexität).

Einzelnachweise

<references>

 <ref name="IEEE2008">{{#invoke:Vorlage:Literatur|f}}</ref>

</references>

Literatur

  • {{#invoke:Vorlage:Literatur|f}}
  • {{#invoke:Vorlage:Literatur|f}}
  • {{#invoke:Vorlage:Literatur|f}}

Weblinks