ISTQB-4.0-Kapitel3-Statischer Test

Lernkarten erstellt aus Power-Point (GTB) - Basiswisssen Softwaretest - abgeglichen mit Lehrplan

Lernkarten erstellt aus Power-Point (GTB) - Basiswisssen Softwaretest - abgeglichen mit Lehrplan


S. B.
Diese Lernkarten bieten eine umfassende Übersicht über statische Tests im Bereich der Informatik, speziell für die Berufslehre. Sie konzentrieren sich auf verschiedene Arten von Reviews, deren Ziele, Prozesse und die Rollen der Beteiligten, wie den Reviewleiter, Gutachter und Autor. Die Karteikarten behandeln auch die Analyse von Arbeitsergebnissen, die Identifikation von Fehlerzuständen und die Bedeutung von Feedback für Stakeholder. Ideal für angehende IT-Profis, die sich auf Prüfungen vorbereiten oder ihr Verständnis von Testverfahren vertiefen möchten.
Cartes-fiches
47
Utilisateurs
5
Langue
Allemand
Catégorie
Informatique
Niveau
Apprentissage
Créé / Mis à jour
02.11.2025 / 23.12.2025

Cartes-fiches

Im Gegensatz zum dynamischen test muss beim statischen Test ...

die zu testende Software nicht ausgeführt werden.

Was sind die Testziele des statischen Tests?

  • Verbesserung der Qualität

  • Finden von Anomalien bzw. Fehlerzuständen 

  • -Bewertung von Merkmalen wie Lesbarkeit, Vollständigkeit, Korrektheit, Testbarkeit und Konsistenz

Werden statische Tests seher zur Verifizierung oder zur VAlidierung eingesetzt?

Statische Tests können sowohl zur Verifizierung, als auch zur VAlidierung eingesetzt werden.

Was ist Example-Mapping?

Tester, Fachbereichsvertreter (Product Owner, Businessanalysten etc.) und Entwickler arbeiten beim Example-Mapping, beim gemeinsamen Schreiben von User-Storys und bei der Verfeinerung (Refinement) des Backlogs zusammen, um sicherzustellen, dass die User-Storys und die zugehörigen Arbeitsergebnisse definierten Kriterien entsprechen, z. B. der Definition-of-Ready.

Wo können Reviewverfahren angewendet werden?

Reviewverfahren können angewendet werden, um sicherzustellen, dass die User-Storys vollständig und verständlich sind und testbare Akzeptanzkriterien enthalten. Indem sie die richtigen Fragen stellen, können Tester die vorgeschlagenen User-Storys analysieren, hinterfragen und verbessern.

Die statische Analyse kann Probleme vor dem dynamischen Testen aufdecken. Warum ist die statische Analyse oft mit weniger Aufwand als das dynamische Testen verbunden?

Es sind keine Testfälle erforderlich und in der Regel können Werkzeuge verwendet werden.

In welchen Frameworks wird die statische Analyse häufig verwendet?

In CI-Frameworks (Continuous Integration)

Wozu dient die statische Analyse?

Die statische Analyse dient:

  • hauptsächlich zur Erkennung spezifischer Fehlerzustände im Code
  • Bewertung der Wartbarkeit und Sicherheit
  • zur Prüfung der Rechtschreibung und der Lesbarkeit

Welche Arbeitsergebnisse können durch statische Tests untersucht werden?

Fast jedes Arbeitsergebnis kann mit statischen Tests untersucht werden. Beispiele hierfür sind:

  • Spezifikation der Anforderungen
  • Quellcode
  • Testkonzepte
  • Testfälle
  • Produkt-Backlog-Einträge
  • Test-Chartas
  • Projektdokumentation
  • Verträge
  • Modelle

Welche Arbeitsergebnisse können dürch Reviews untersucht werden?

Jedes Arbeitsergebnis, das gelesen und verstanden werden kann, kann Gegenstand eines Reviews sein.

(Zusatzinformationen vom Foliensatz:

  • Spezifikationen, z. B. Fachanforderungen, technische Anforderungen und IT-Sicherheitsanforderungen, Abnahmekriterien
  • Produkt-Backlog-Elemente wie Epics, User Storys und Definition-of-Ready sowie Definition-of-Done, Test-Chartas
  • Architektur und Entwurfsspezifikationen, Benutzeranleitungen, Handbücher
  • Verträge, Projektpläne, Zeitpläne und Budgetpläne
  • Testkonzepte, Testspezifikationen, Testskripte, Testberichte )

Was ist die Voraussetzung für die statische Analyse?

Für die statische Analyse benötigen Arbeitsergebnisse jedoch eine Struktur, anhand derer sie überprüft werden können, Beispiele sind:

  • Programmquellcode

  • Modelle, wie Aktivitätsdiagramme oder Zustandsdiagramme

  • Text mit einer formalen Syntax (Webseiten, Konfigurationsscripte)

Welche Arbeitsergebnisse eignen sich nicht für statische Tests?

Nicht statisch testbar sind solche Arbeitsergebnisse, die

  • für den Menschen schwer zu interpretieren sind
  • die nicht mit Hilfe von Werkzeugen analysiert werden können oder dürfen, z. B.:
    • ausführbarer Code von Drittanbietern, welcher aus rechtlichen Gründen nicht untersucht werden darf
    • Ausführbarer Code, der aufgrund von Obfuskation („Unkenntlichkeitmachung“)  nicht ohne größeren Aufwand wieder in eine analysierbare Struktur gebracht werden kann
    • Dynamisch generierter Code (zur Laufzeit generiert oder modifiziert wie bei einigen Skriptsprachen oder durch bestimmte Frameworks) kann nicht vollständig statisch analysiert werden, da sein endgültiger Zustand oder seine Ausführung vom Kontext zur Laufzeit abhängt

Der statische Test kann Fehlerzustände in den frühesten Phasen des SDLC aufdecken. Welchen Grundsaz des testens erfüllt er damit?

Den Grundsatz des frühen Testens.

Nennen Sie Fehlerzustände, die nicht durch dynamische aber durch statische Tests erkannt werden können.

  • nicht erreichbarer Code
  • nicht wie gewünscht implementierte Entwurfsmuster
  • Fehlerzustände in nicht ausführbaren Arbeitsergebnissen

Eine Vielzahl von Stakeholdern sollte in statische Tests miteinbezogen werden. Nennen Sie Argumente die die dies begründen.

Statische Tests

  • können die Qualität von Arbeitsergebnissen bewerten und Vertrauen in sie aufzubauen
  • stellen durch die Überprüfung der dokumentierten Anforderungen durch die Stakeholder auch sicher, dass diese ihre tatsächlichen Bedürfnisse beschreiben
  • schaffen ein gemeinsames Verständnis zwischen den beteiligten Stakeholdern
  • verbessern auch die Kommunikation zwischen den beteiligten Stakeholdern

Die Durchführung von Reviews verursacht Kosten, trotzdem sind die Gesamtkosten eines Projekts mit Reviews wesentlich geringer. Was ist diue Ursache?

Das liegt daran, dass weniger Zeit und Aufwand für die Behebung von Fehlerzuständen im späteren Verlauf des Projekts aufgewendet werden müssen.

Bestimmte Fehlerzustände im Code können durch statische Analyse effizienter aufgedeckt werden als durch dynamische Tests, Was bedeutet dies für den ENtwicklungsaufwand?

iI der Regel führt das Vorgehen zu weniger Fehler im Code, als auch zu einem geringeren Gesamtentwicklungsaufwand.

Statischer Test und dynamischer Test ergänzen sich gegenseitig. Sie haben ähnliche Ziele, wie z. B. die Unterstützung bei der Erkennung von Fehlerzuständen in Arbeitsergebnissen aber es gibt auch einige Unterschiede. Nennen Sie vier Vorteile statischer Tests.

Statische Tests

  • können leichter Fehlerzustände aufdecken, die auf selten ausgeführten Pfaden durch den Code liegen oder schwer durch dynamische Tests zu erreichen sind
  • können auch auf nicht ausführbare Arbeitsergebnisse angewandt werden, z.B. informelle Texte, Modelle
  • messen Qualitätsmerkmale ohne Ausführung des Codes (z. B. Wartbarkeit), während dynamische Tests Qualitätsmerkmalen während der Ausführung des Codes messen (z. B. Performanz)
  • finden Fehlerzustände direkt, während beim dynamische Test Fehlerwirkungen auftreten, anhand derer die zugehörigen Fehlerzustände dann ermittelt werden müssen

Können alle Fehler durch einen statischen Test gefunden werden?

Sowohl statischer Test als auch dynamischer Test (mit Analyse der Fehlerwirkungen) können zur Entdeckung von Fehlerzuständen führen, allerdings gibt es einige Fehlerzustände, die nur durch statischen oder dynamischen Test gefunden werden können.

Nennen Sie die sieben typische Fehlerzustände, die durch statische Tests leichter und/oder kostengünstiger zu finden sind.

  • Fehlerzustände in Anforderungen, z. B. Inkonsistenzen, Mehrdeutigkeiten, Widersprüche, Auslassungen, Ungenauigkeiten, Duplikationen
  • Fehlerzustände im Entwurf, z. B. ineffiziente Datenbankstrukturen, schlechte Modularität
  • Bestimmte Arten von Fehlerzuständen im Code, z. B. Variablen mit undefinierten Werten, nicht deklarierte Variablen, unerreichbarer oder duplizierter Code, übermäßige Komplexität des Codes
  • Abweichungen von Standards, z. B. mangelnde Einhaltung von Namenskonventionen in Programmierstandards
  • Falsche Spezifikation von Schnittstellen, z. B. nicht übereinstimmende Anzahl, Art oder Reihenfolge von Parametern
  • Spezifische Arten von Schwachstellen in der Sicherheit, z. B. Pufferüberläufe
  • Lücken oder Ungenauigkeiten in der Überdeckung der Testbasis, z. B. fehlende Tests für ein Akzeptanzkriterium

Was ermöglicht frühzeitiges und häufiges Feedback?

•Frühzeitiges und häufiges Feedback ermöglicht die frühzeitige Kommunikation von potenziellen Qualitätsproblemen.

Welche Folgen kann ein mangelnder EInbezug der Stakeholder während des SDLC zur Folge haben?

  • Das zu entwickelnde Produkt entspricht  möglicherweise nicht den ursprünglichen oder aktuellen Vorstellungen der Stakeholder
  • Dies kann dies zu kostspieligen Nacharbeiten, verpassten Terminen, Schuldzuweisungen und sogar zu einem kompletten Scheitern des Projekts führen

Welche Folgen kann ein häufiges Feedback der Stakeholder während des SDLC haben?

Häufiges Feedback der Stakeholder während des SDLC kann Missverständnissen über Anforderungen vorbeugen und sicherstellen, dass Änderungen an den Anforderungen verstanden und früher umgesetzt werden

  • Entwicklungsteam kann besser zu verstehen, was es für wen entwickelt
  • Ermöglicht Konzentration auf solche Features, die für die Stakeholder den größten Nutzen bringen und den positivsten Einfluss auf die identifizierten Risiken haben

Warum sollte der  Reviewprozess mehrfach durchgeführt werden?

Viele Arbeitsergebnisse sind zu umfangreich, als dass sie in einem einzigen Review behandelt werden könnten.

Welche Norm definiert einen generischen Reviewprozess?

ISO/IEC 20246:2017 Software and Systems Engineering - Work Product Reviews

Wie lauten die 5 Aktivitäten beim Reviewprozess?

Was wird in der Review-Planung festgelegt.

In der Planungsphase wird der Umfang des Reviews festgelegt, der den Zweck, das zu überprüfende Arbeitsergebnis, die zu bewertenden Qualitätsmerkmale, die zu berücksichtigenden Bereiche, die Endekriterien, unterstützende Informationen wie Normen, den Aufwand und den Zeitrahmen für das Review umfasst.

Worum geht es beim Reviewbeginn (Kick-Off)?

Während des Reviewbeginns geht es darum, sicherzustellen, dass jeder Beteiligte und alles, was benötigt wird, vorbereitet ist, um mit dem Review zu
starten. Dazu gehört auch, dass jeder Teilnehmer Zugang zu dem zu prüfenden Arbeitsergebnis hat, seine Rolle und Verantwortlichkeiten versteht und alles erhält, was er für die Durchführung des Reviews benötigt.

Was ist das individuelle Review?

  • Teilnehmer des Reviews bereiten sich individuell auf eine Begutachtiung vor

  • Die Gutachter setzen sich intensiv mit dem zu prüfenden Arbeitsergebnis auseinander, indem sie

    • ein oder mehrere Reviewverfahren anwenden

    • die zur Verfügung gestellten Dokumente als Prüfgrundlage verwenden

    • sich auf bestimmte Aspekte beschränken

  • Notieren die erkannten potenziellen Fehlerzustände, Empfehlungen, Fragen oder sonstigen Kommentare

Was beinhaltet die Kommunikation und Analyse?

  • Alle Anomalien müssen analysiert und diskutiert werden
  • Für jede Anomalie wird:
    • eine Entscheidung über ihren Status
    • ihre Verantwortlichkeit
    • die erforderlichen Maßnahmen

getroffen.

Dies geschieht in der Regel in einer Reviewsitzung, in der die Teilnehmer auch über die Qualität des geprüften Arbeitsergebnisses und über die erforderlichen Folgemaßnahmen entscheiden. Ggf. ist ein Folgereview erforderlich.

Welche Arbeiten umfasst die Behebung und Berichterstattung?

  • Für jeden Fehlerzustand sollte ein Fehlerbericht erstellt werden, damit die Korrekturmaßnahmen nachverfolgt werden können.
  • Wenn die Endekriterien erreicht sind, kann das Arbeitsergebnis abgenommen werden.
  • Über die Ergebnisse des Reviews wird berichtet.

Nennen Sie die sechs wichtigen Rollen und verantwortlichkeiten im Review.

  • Manager
  • Autor
  • Moderator (Facilitator)
  • Protokollant
  • Gutachter
  • Reviewleiter

Welche Aufgabe hat der Manager?

Der Manager entscheidet, was geprüft werden soll, und stellt Ressourcen wie Personal und Zeit für das Review zur Verfügung.

Welche Aufgabe hat der Autor?

Der Autor erstellt und korrigiert das zu prüfende Arbeitsergebnis.

Welche Aufgabe hat der Moderator?

Der Moderator (auch Facilitator genannt)  sorgt für einen effektiven Ablauf der Reviewsitzungen, einschließlich Mediation, Zeitmanagement und einer geschützten Reviewumgebung, in der jeder frei sprechen kann.

Welche Aufgabe hat der Protokollant?

Der Protokollant sammelt Anomalien von Gutachtern und zeichnet Reviewinformationen auf, z. B. Entscheidungen und neue Anomalien, die während der Reviewsitzung gefunden werden.

Welche Aufgabe hat der Gutachter?

Der Gutachter führt Reviews durch. Ein Gutachter (auch Reviewer genannt) kann ein Projektmitarbeiter, ein Fachexperte oder ein anderer Stakeholder sein.

Welche Aufgabe hat der Reviewleiter?

Der Reviewleiter übernimmt die Gesamtverantwortung für das Review, z. B. die Entscheidung, wer daran teilnimmt, und die Organisation, wann und wo das Review stattfindet.

Es gibt viele Arten von Reviews. In Welcher Spanne bewegen sie sich?

Wovon hängt der gewählte Review-Prozess ab?

  • Softwareentwicklungslebenszyklus-Modell
  • Reife des Entwicklungsprozesses
  • Komplexität der zu prüfenden Arbeitsergebnisse
  • rechtlichen oder regulatorischen Anforderungen
  • der Notwendigkeit für einen Prüfnachweis

Étudier