Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

ISTQB - Foundation Level > 3. Statische Prüftechniken und der Testprozess > Flashcards

3. Statische Prüftechniken und der Testprozess Flashcards

1
Q

Statische Tests

A

Anders als das dynamische Testen, welches die Ausführung der Software voraussetzt, beruhen statische Prüftechniken auf der „manuellen“ Überprüfung (Reviews) oder automatisierten Analysen (statische
Analyse) des Codes oder anderer Projektdokumentation,ohne den Programmcode auszuführen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Reviews

A

Ein Review kann komplett als manuelle Aktivität durchgeführt, aber ebenso durch Werkzeuge unterstützt werden.

Die wichtigste manuelle Tätigkeit ist die Prüfung und Kommentierung des Arbeitsergebnisses.

Jedes Arbeitsergebnis der Softwareentwicklung kann einem Review unterzogen werden, einschließlich Anforderungsspezifikationen, Designspezifikationen, Quellcode, Testkonzepte, Testspezifikationen,
Testfälle, Testskripte, Anwenderhandbücher oder Web-Seiten.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Reviews, statische Analyse und dynamische Tests

A

Reviews, statische Analyse und dynamischer Test haben das gleiche Ziel, nämlich Fehlerzustände zu identifizieren.

Sie ergänzen sich: Die verschiedenen Methoden können verschiedene Arten von Fehlern wirksam und effizient aufdecken.

Verglichen mit dem dynamischen Test finden statische Prüftechniken eher Ursachen der Fehlerwirkungen (Fehlerzustände) als Fehlerwirkungen selbst.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Vorteile von Reviews

A

Vorteile von Reviews sind:

  1. frühe Aufdeckung und Korrektur von Fehlerzuständen
  2. Verbesserung der Softwareentwicklungsproduktivität
  3. reduzierte Entwicklungsdauer
  4. reduzierte Testkosten und -dauer
  5. Reduzierung der Kosten während der Lebensdauer
  6. weniger Fehlerzustände und
  7. verbesserte Kommunikation.

Reviews können beispielsweise Auslassungen in Anforderungen aufdecken (z.B. fehlende Funktionen), die durch einen dynamischen Test vermutlich nicht gefunden würden.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Typische Fehlerzustände

die durch Reviews aufgedeckt werden

A

Zu den typische Fehlerzuständen, die effektiver und effizienter durch Reviews als durch dynamische Tests zu finden sind, gehören:

  1. Abweichungen von Standards
  2. Fehlerzustände in Anforderungen
  3. Fehlerzustände im Design
  4. unzureichende Wartbarkeit und
  5. fehlerhafte Schnittstellenspezifikationen.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Mögliche Ziele eines Reviews

A
  • Finden von Fehlerzuständen
  • Erwerben von Verständnis
  • Ausbildung von Testern und neuen Teammitgliedern oder
  • einer Diskussion und Entscheidungsfindung im Konsens.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Aktivitäten eines formalen Reviews

A
  1. Planen
  2. Kickk-off
  3. Individuelle Vorbereitung
  4. Prüfen/Bewerten/Festhalten der Ergebnisse (Reviewsitzung)
  5. Überarbeitung
  6. Nachbearbeitung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Aktivitäten eines formalen Reviews

Planen

A
  • Festlegen von Review-/Prüfkriterien
  • Auswahl der beteiligten Personen
  • Besetzen der Rollen
  • Festlegen der Eingangs- und Endekriterien bei mehr formalen Reviewarten (z.B. Inspektion)
  • Auswahl der zu prüfenden Dokumententeile
  • Prüfen der Eingangskriterien (bei formaleren Reviewarten)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Aktivitäten eines formalen Reviews

Kick-off

A
  • Verteilen der Dokumente
  • Erläutern der Ziele, des Prozesses und der Dokumente den Teilnehmern gegenüber
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Aktivitäten eines formalen Reviews

Individuelle Vorbereitung

A
  • Vorbereiten der Reviewsitzung durch Prüfung des/der Dokuments/e
  • Notieren von potenziellen Fehlerzuständen, Fragen und Kommentaren
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Aktivitäten eines formalen Reviews

  • *Prüfen/Bewerten/Festhalten der Ergebnisse**
  • *(Reviewsitzung)**
A
  • Diskussion oder Protokollierung, mit dokumentierten Ergebnissen oder Protokollen (bei formaleren Reviewarten)
  • Festhalten von Fehlerzuständen, Empfehlungen zum Umgang mit ihnen oder Entscheidungen über die Fehlerzustände
  • Prüfen/Bewerten und Protokollieren von Problemen während eines physischen Treffens oder Nachverfolgen von elektronischer Gruppenkommunikation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Aktivitäten eines formalen Reviews

Überarbeiten

A
  • Beheben der gefundenen Fehlerzustände typischerweise durch den Autor
  • Protokollieren des aktualisierten Fehlerstatus (in formalen Reviews)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Aktivitäten eines formalen Reviews

Nachbereiten

A
  •  Prüfen, ob Fehlerzustände zugewiesen wurden
  •  Sammeln von Metriken
  •  Prüfen von Endekriterien (bei formaleren Reviewarten)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Formale Reviews

Rollen und Verantwortlichkeiten

A

Bei einem typischen formalen Review findet man folgende Rollen:

  1. Manager
  2. Moderator
  3. Autor
  4. Gutachter
  5. Protokollant
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Formale Reviews - Rollen

Manager

A

Die Person, die

  • über die Durchführung von Reviews entscheidet,
  • Zeit im Projektplan zur Verfügung stellt und
  • überprüft, ob die Reviewziele erfüllt sind.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Formale Reviews - Rollen

Moderator

A

Die Person, die

  • das Review eines Dokuments bzw. von einigen zusammengehörenden Dokumenten leitet, einschließlich der Reviewplanung, der Leitung der Sitzung und der Nachbereitung nach der Sitzung.
  • Falls nötig, kann der Moderator zwischen den verschiedenen Standpunkten vermitteln.
  • Er ist häufig die Person, von der der Erfolg des Reviews abhängt.
17
Q

Formale Reviews - Rollen

Autor

A

Der Verfasser oder die Person, die für das/die zu prüfende/n Dokument/e hauptverantwortlich ist.

18
Q

Formale Reviews - Rollen

Gutachter

A
  • Personen mit einem spezifischen technischen oder fachlichen Hintergrund (auch Prüfer oder Inspektoren genannt), die nach der nötigen Vorbereitung im Prüfobjekt Befunde identifizieren und beschreiben (z.B. Fehlerzustände).
  • Gutachter sollten so gewählt werden, dass verschiedene Sichten und Rollen im Reviewprozess vertreten sind.
  • Sie sollten an allen Reviewsitzungen teilnehmen können.
19
Q

Formale Reviews - Rollen

Protokollant

A
  • Die Person, die alle Ergebnisse, Probleme und offenen Punkte dokumentiert, die im Verlauf der Sitzung identifiziert werden.
20
Q

Reviews und Checklisten

A

Softwareprodukte oder darauf bezogene Arbeitsergebnisse aus verschiedenen Perspektiven zu betrachten und Checklisten zu nutzen, kann Reviews wirksamer und effizienter machen.

So kann eine Checkliste helfen, bisher unentdeckte Probleme aufzudecken, wenn sie typische Anforderungsprobleme enthält und unterschiedliche Perspektiven einnimmt, beispielsweise vom Benutzer, Wartungspersonal,
Tester oder Operator.

21
Q

Reviewarten

A
  1. Informelles Review
  2. Walkthrough
  3. Technisches Review
  4. Inspektion
22
Q

Informelles Review

A
  • kein formaler Prozess
  • kann in Form des Programmierens in Paaren (pair programming) durchgeführt werden oder ein technischer Experte unterzieht Entwurf und Quellcode einem Review
  • Ergebnisse können dokumentiert werden
  • Nutzen variiert abhängig von den Gutachtern
  • Hauptzweck: Günstiger Weg eine Verbesserung zu erreichen
23
Q

Walkthrough

A
  • Sitzung geleitet durch den Autor
  • kann in Form von Szenarien, Probeläufen oder im Kreis gleichgestellter Mitarbeiter (Peer Review) stattfinden
  • Open-End-Sitzungen
    • wahlweise der Sitzung vorausgehende Vorbereitung der Gutachter
    • wahlweise Vorbereitung eines Reviewberichts, der eine Liste der Befunde enthält
  • wahlweise Protokollant (der aber nicht der Autor ist)
  • kann in der Praxis von informell bis sehr formal variieren
  • Hauptzweck:
    • Lernen
    • Verständnis erzielen
    • Fehlerzustände finden
24
Q

Technisches Review

A
  • dokumentierter und definierter Fehlerfindungsprozess, der gleichgestellte Mitarbeiter und technische Experten sowie optional Personen aus dem Management einschließt
  • kann als Peer Review ohne Teilnahme des Managements ausgeführt werden
  • idealerweise durch einen geschulten Moderator geleitet (nicht der Autor)
  • Vorbereitung vor der Sitzung durch Gutachter
  • wahlweise Nutzung von Checklisten
  • Vorbereitung eines Reviewberichts, der folgende Punkte enthält:
    • die Liste der Befunde,
    • eine Gesamtbewertung, inwieweit das Softwareprodukt die Anforderungen erfüllt, und
    • Empfehlungen in Bezug auf die Befunde, wo angebracht
  • kann in der Praxis von informell bis sehr formal variieren
  • Hauptzweck:
    • Diskussion
    • Entscheidungen treffen
    • Alternativen bewerten
    • Fehlerzustände finden,
    • technische Probleme lösen und
    • prüfen, ob Übereinstimmung mit Spezifikationen, Plänen, Bestimmungen und Standards existiert
25
Q

Inspektion

A
  • geleitet durch einen geschulten Moderator (nicht der Autor)
  • gewöhnlich durchgeführt als Prüfung durch gleichgestellte Mitarbeiter
  • definierte Rollen
  • schließt das Sammeln von Metriken ein
  • formaler Prozess basierend auf Regeln und Checklisten
  • spezifizierte Eingangs- und Endekriterien für die Abnahme des Softwareprodukts
  • Vorbereitung vor der Sitzung
  • Inspektionsbericht mit Liste der Befunde
  • formaler Prozess für Folgeaktivitäten (optional mit Komponenten zur Prozessverbesserung)
  • wahlweise Vorleser
  • Hauptzweck: Fehlerzustände finden
26
Q

Erfolgsfaktoren für Reviews

A
  • Jedes Review hat klar definierte Ziele.
  • Abhängig von den Reviewzielen werden geeignete Personen ausgewählt.
  • Tester sind geschätzte Gutachter, die einen Beitrag zum Review leisten. Weiterhin lernen sie auch das Produkt kennen, was sie befähigt Tests früher vorzubereiten.
  • Gefundene Fehlerzustände werden positiv aufgenommen und werden objektiv zur Sprache gebracht.
  • Menschliche und psychologische Aspekte werden beachtet, es beispielsweise als eine positive Erfahrung für den Autor zu gestalten.
  • Das Review wird in einer Atmosphäre des Vertrauens durchgeführt, das Ergebnis dient nicht zur Beurteilung der Teilnehmer.
  • Es werden die Reviewtechniken angewendet, die zur Erreichung der Reviewziele, für Art und Stufe von Arbeitsergebnissen der Softwareentwicklung und für die Gutachter geeignet sind.
  • Wenn sie geeignet sind, die Effektivität der Fehleridentifikation zu steigern, werden Checklisten oder Rollen verwendet.
  • Es finden Schulungen in Reviewtechniken statt, besonders für die formaleren Methoden wie Inspektionen.
  • Das Management unterstützt einen guten Reviewprozess, indem es beispielsweise angemessene Zeit für Reviewaktivitäten im Projektplan einräumt.
  • Es liegt eine Betonung auf Lernen und Prozessverbesserung.
27
Q

Statische Analyse

A

Das Ziel der statischen Analyse ist es, Fehlerzustände in Softwarequellcode und in den Softwaremodellen zu finden.

Statische Analyse wird durchgeführt, ohne dass die untersuchte Software tatsächlich durch das Werkzeug ausgeführt wird; dynamischer Test führt Softwarecode aus.

Statische Analyse kann Fehlerzustände lokalisieren, die durch dynamisches Testen schwer zu finden sind.

Ebenso wie Reviews findet die statische Analyse Fehlerzustände eher als Fehlerwirkungen.

Statische Analysewerkzeuge analysieren Programmcode (z.B. Kontrollfluss und Datenfluss), ebenso wie generierte HTML- und XML-Ausgaben.

28
Q

Vorteile der statischen Analyse

A
  • frühes Erkennen von Fehlerzuständen vor der Testdurchführung
  • frühe Warnung vor verdächtigen Aspekten in Code oder Design wie hohes Komplexitätsmaß durch Berechnen von Metriken
  • Identifizieren von Fehlerzuständen, die durch dynamischen Test nicht effektiv und effizient aufzudecken sind
  • Aufdecken von Abhängigkeiten und Inkonsistenzen in Softwaremodellen, beispielsweise tote Links
  • verbesserte Wartbarkeit von Code und Design
  • Vorbeugen von Fehlerzuständen, wenn sich das aus Erfahrung Gelernte in der Entwicklung niederschlägt
29
Q

Statische Analyse

Typische Fehlerzustände

A

Typische Fehlerzustände, die durch eine werkzeuggestützte statische Analyse gefunden werden können:

  1. Referenzierung einer Variablen mit nicht definiertem Wert
  2. inkonsistente Schnittstellen zwischen Modulen und Komponenten
  3. Variablen, die nicht verwendet oder nicht korrekt deklariert werden
  4. unerreichbarer (toter) Code
  5. fehlende oder falsche Logik (mögliche Endlosschleifen)
  6. übermäßig komplizierte Konstrukte
  7. Verletzung von Programmierkonventionen
  8. Sicherheitsschwachstellen
  9. Syntax-Verletzungen von Code und Softwaremodellen
30
Q

Werkzeuge für statische Analysen

A

Werkzeuge für statische Analysen werden typischerweise entwicklungsbegleitend und vor Komponenten- und Integrationstests oder beim Einchecken von Code in Konfigurationsmanagementwerkzeuge
genutzt (Prüfen gegen vordefinierte Regeln oder Programmierstandards), und durch Designer während der Softwaremodellierung.

Werkzeuge für statische Analysen können große Mengen von Warnungen
und Hinweisen erzeugen, die gut verwaltet werden müssen, um eine effektive Nutzung des Werkzeugs zu erlauben.

Compiler können auch eine gute Unterstützung für eine statische Analyse bieten, u.a. durch Berechnen von Metriken.

31
Q
A

ISTQB - Foundation Level (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions