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
-
- 1 / 47
-
Flashcards
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
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.
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