c2b_default

Softwarequalitätssicherung

Lernkarteikarten zur Vorlesung "Softwarequalitätssicherung" an der TU Ilmenau (SS 2013)

Lernkarteikarten zur Vorlesung "Softwarequalitätssicherung" an der TU Ilmenau (SS 2013)

100
0.0 (0)
Robin Douglas
Robin Douglas

Kartei Details

Karten 100
Sprache Deutsch
Kategorie Informatik
Stufe Universität
Erstellt / Aktualisiert 23.09.2013 / 13.03.2020
Weblink
https://card2brain.ch/box/softwarequalitaetssicherung
Einbinden
<iframe src="https://card2brain.ch/box/softwarequalitaetssicherung/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
Lernen

(Kapitel 6): Welche grundlegenden Testechniken gibt es bei funktionsorientierten Tests?

  1. Äquivalenzklassen
    => für alle Prüfebenen, Ergänzung durch Grenzwertanalyse
  2. Ursache-Wirkungsgraph
    => Erfassung von logischen Abhängigkeiten in einem Booleaschen Graph (Basis für Entscheidungstabellen)
  3. Zustandsbasierter Test
    => Test reaktiver, zustandsabhängiger Systeme
  4. Anforderungs- und Anwendungsfallbasierter Test
    => für System- und Abnahmetest

(Kapitel 6): Erläutern Sie kurz das Prinzip von Äquivalenzklassentests!

Ziel des Äquivalenzklassentests ist es, Äquivalenzklassen zu bilden und so eine hohe Fehlerentdeckungsrate mit einer möglichst gerinen Anzahl an Testfällen zu erreichen. Die Äquivalenzklassen sind bezüglich ihrer Ein- und Ausgabedaten ähnliche Klassen bzw. Objekte, bei denen erwartet wird, dass sie sich gleichartig verhalten. Bei diesem Verfahren werden die gesamten Eingabe- und Ausgabedaten eines Programms in Gruppen von Äquivalenzklassen unterteilt, so dass man annehmen kann, dass mit jedem beliebigen Objekt der jeweiligen Klasse die gleichen Fehler wie mit jedem anderem Objekt der Klasse auftreten. Die Bildung von Testfällen zu Äquivalenzklassen erfolgt wie folgt:

  1. Analyse und Spezifikation der Eingabe- und Ausgabedaten sowie den Bedingungen gem. Spezifikation
  2. Bildung der Äquivalenzklassen durch Klassifizierung der Wertebereiche für Eingabe- und Ausgabedaten
  3. Bestimmung der Testfälle durch Werteauswahl für jede Äquivalenzklasse

Es werden zwei Arten von Äquivalenzklassen unterschieden:

  1. Gültige Äquivalenzklassen
    => Werte liegen im spezifizierten Eingabe- Ausgabebereich
  2. Ungültige Äquivalenzklassen
    => Werte liegen außerhalb des Spezifikationsbereichs

(Kapitel 6): Was ist die Grenzwertanalyse? Wie werden entsprechende Testfälle ausgewählt? Unter welchen Voraussetzungen ist dieses Verfahren sinnvoll?

Die Grenzwertanalyse basiert auf der Tatsache, dass Fehler häufig an Grenzen von Wertebereichen auftreten.

Regel zur Testfallauswahl:

  • als Testeingaben werden gewählt
    • die Grenzwerte einer Äquivalenzklasse (oben und unten)
    • jeweils die benachbarten Werte jedes Grenzwertes

=> Grenzwertanalyse ist nur für sortierte Wertemengen sinnvoll

(Kapitel 6): Beschreibe das grobe Vorgehen des Ursache-Wirkungsgraphen!

Das Ziel beim Ursache-Wirkungsgraph besteht darin, systematisch logische Beziehungen zwischen Äquivalenzklassen durch Testfälle zu erfassen.

Prinzip:

  • Die Programmspezifikation wird in einen Graph umgesetzt, der die logischen Verknüpfung von Ursachen (Eingabeäquivalenzklassen) und Wirkungen (Ausgabeäquivalenzklassen) abbildet
  • Der Graph kann in eine Entscheidungstabelle transformiert werden

(Kapitel 6): Was ist zustandsbasiertes Testen? Welche Testziele sind hierbei zu beachten? Wann ist dieses Verfahren geeignet?

  • Der zustandsbasierte Test gehört zum funktionsorientierten Testen, da die Beschreibung mit einem Zustandsgraph eine funktionale Spezifikation darstellt
  • Die bisherigen Testtechniken berücksichtigen nicht das Verhalten gedächtnisbehafteter Software (Verhalten hängt von der Ausführungshistorie ab)

Anwendungsbereich:

  • jede Software, die durch einen Zustandsautomaten beschrieben werden kann
  • geeignet für
    • Modultest
    • Use Case Test

Testziele:

  1. Alle Zustände einmalig abdecken
    => erfasst nicht alle Zustandsübergänge
  2. Alle Zustandsübergänge einmal durchlaufen
    => subsumiert alle Zustände
  3. Ereignisse test
    => sinnvoll wenn, Zustandsübergänge durch mehrere Ereignisse stattfinden können

 

(Kapitel 6): Was ist das Ziel des anfoderungsbasierten Testens?

Beim anforderungsbasierten Test wird getestet, ob alle spezifizierten Funktionen vorhanden und ausführbar sind, d.h. es wird jede Funktion durch einen Testfall erreicht. Die Testfälle sind auf das Normalverhalten des Testobjekts ausgerichtet.

=> Kein Test unerwarteter Eingaben!

(Kapitel 6): Was ist das Ziel des anwendungsfallbasierten Testens?

Beim anwendungsfallorientierten Test wird getestet, ob alle Use Cases implementiert sind (System- und Abnahmetest). Da das Zusammenwirken unterschiedlicher Komponenten betrachtet wird, können auch Fehler entdeckt werden, die beim Integrationstest entgangen sind.

(Kapitel 7): Was ist ein strukturorientierter Test? Wie werden die Testfälle gebildet?

Der strukturorientierte Test ist eine Ergänzung zum funktionsorientierten Test mit dem Ziel der Abdeckung des Kontrollflusses in einem Programm. Die Testfälle werden folglich aus dem Kontrollfluss des Programms abgeleitet.

  • Modultest
    • Testfallableitung zur Anweisungs-, Zweig- bzw. Pfadüberdeckung
    • Testfallableitung nach Datenflusskritierien
  • Integrationstest
    • Testfallableitung aus der Aufrufhierarchie

(Kapitel 7): Benennen Sie Ansatz, Testziele sowie die Vor- und Nachteile für den Anweisungs- , Zweig- und Pfadüberdeckungstest!

1. Anweisungstest:

  • Testziel:
    • mindestens einmal alle Anweisungen ausführen, d.h. Abdeckung aller Knoten im Graph
    • C = Anzahl der ausgeführten Anweisungen / Anzahl der Anweisungen
  • Vorteile:
    • findet toten, d.h. nicht erreichbaren Code
  • Nachteile:
    • übersieht Fehler in Bedingungen (schwacher Test)

2. Zweigüberdeckungstest:

  • Testziel:
    • Ausführung, d.h. Abdeckung aller Zweige im Graph
    • C = (Anzahl ausgeführter Zweige / Anzahl Zweige) = 100 %
  • Vorteile:
    • erkennt besonders oft durchlaufende Zweige, die ggf. optimiert werden
  • Nachteile:
    • komplexe Beindungen sind nicht ausreichend getestet

3. Pfadüberdeckungstest:

  • Testziel:
    • mindestens einmal alle Pfade in einem Graphen durchlaufen
    • C = (Anzahl durchlaufener Pfade / Anzahl der Pfade) = 100 %
  • Vorteile:
    • höchste Fehlerfindungsrate
  • Nachteile:
    • hoher Aufwand => hohe Überdeckung nicht erreichbar

 

(Kapitel 7): Was ist der boundary-interior Test? Welcher Grundansatz wird hier verfolgt?

Beim Boundary-Interior Test werden Grenzen und Innenleben von Schleifen untersucht. Man geht dabei davon aus, dass die meisten Fehler bereits nach wenigen Interationen entdeckt werden, d.h. es wird nach einem Testkritierium mit vertretbarem Aufwand gesucht. Hierzu werden drei Äquivalenzklassen gebildet:

  1. Test führt zu keiner Schleifenausführung
    => nur bei abweisenden Schleifen
  2. Test führt genau zu einer Schleifenausführung
    => boundary test
  3. Test führt mindestens zu zwei Schleifenausführungen
    => interior test (k=2 Pfaddurchläufe)

=> Alternative Pfade in Schleifen beachten!

Vorteile:

  • 2 mal höhere Fehlererkennungsrate als bei einer einmaligen Zweigüberdeckung

(Kapitel 7): Erläutern Sie das Ziel des Bedingungs-Überdeckungstests! Vergleichen Sie die die vier Grundarten bezüglich Testkriterium, Vorteile und Nachteile!
 

Bedingungsüberdeckung:

Testziel:

  • logische Struktur komplexer, zusammengesetzter Entscheidungen testen durch
    • minimale, einfache Bedingungsüberdeckung (C2-Test)
    • mehrfache Bedingungsüberdeckung (C3-Test)
  • oder durch abgewandelte Verfahren (starker C2-Test, schacher C3-Test)

1. Kriterium zur mininmalen Beindungsüberdeckung (C2-Test)

=> in einem Programmabschnitt wird jeder Term (atomare Beindung) innerhalb einer komplexen Bedingunsanweisung mindestens einmal gegen wahr und falsch geprüft.

=> relativ geringer Aufwand

=> Zweigüberdeckung ist nicht sicher

2. Kriterium zur mehrfachen Bedingungsabdeckung (C3-Test)

=> alle Kombinationen atomarer Bedingungen werden getestet, d.h. 2^n Testfälle bei n atomaren Bedingungen

=> gesicherte Zweigüberdeckung

=> hoher Aufwand

3. Kriterium für minimalen Mehrfach-Bedingungstest (Schwacher C3-Test)

=> alle atomaren Bedingungen gegen wahr und falsch testen und alle zusammengesetzten Bedingungen gegen wahr und falsch testen

=> Aufwand geringer

=> Operatorfehler können sich aufheben und der Fehler wird nicht erkannt

4. Kriterium für Bedingungs-Entschiedungs-Testabdeckung (Starker C2-Test)

=> alle atomaren Bedingungen gegen wahr und falsch testen und zeigen, dass jede atomare Bedingung in der Lage ist, die Gesamtentscheidung zu beeinflussen

=> Zweigüberdeckung, relativ geringer Aufwand

=> höherer Aufwand, um die richtigen Testfälle zu finden

 

(Kapitel 9): Welche Zielstellung verfolgt das Aufstellen und Nutzen von Metriken in der Softwareentwicklung?

Das Aufstellen und Nutzen von Metriken in der Softwareentwicklung verfolgt im Wesentlichen zwei Ziele:

  1. Objektiver Vergleich von Eigenschaften von Softwareprodukten
  2. Quantitative Bewertung von Entwicklungsprozessen für Software

=> Problem: geeignete Metriken zu finden

(Kapitel 9): Definieren Sie die beiden Begriffe "Maß" und "Metrik"!

Maß: Ein Maß ist ein Messwert, der einem Objekt der realen Welt zugeordnet wird.

Metrik: Eine Metrik ist eine Aussage zum Vergleich von Messwerten bei zwei Objekten aus der realen Welt. Eine Metrik gibt also die Differenz zweier Maße an.

(Kapitel 9): Wozu können Projekt- bzw. Prozessmetriken und Produktmetriken verwendet werden? Geben Sie dazu geeignete Metrikarten an!

Prozess- und Projektmetriken:

  • zur faktenbasierten Entscheidung zur Prozessverbesserung
  • für Prognosen zum Projektverlauf
  • für Aussagen zur Produktivität

=> Produktivitätsmetriken, Kostenmetriken

Produktmetriken:

  • zum Qualitätsnachweis durch erreichte, vorgebene Maße in Projekten
  • zur Vergleichbarkeit mit Konkurrenzprodukten

=> Fehlermetriken

(Kapitel 9): Was sind subjektive bzw. objektive Metriken?

Subjektive Metriken:

  • qualitativ intuitive Statements
  • Interpretation erfolgt erfahrungsbasiert
    • z.B. Maß der Kundenzufriedenheit
    • z.B. Pseudometriken (basieren auf Schätzungen)
    • z.B. Produktivität der Mitarbeiter auf Basis LOC/h

Objektive Metriken:

  • quantitativ, gemessene Maße
  • Interpretationsverfahren können definiert werden
    • z.B. Programmgröße
    • z.B. Ausfallrate

(Kapitel 9): Wie erfolgt die Auswahl einer Metrik? Welche Gütekriterien für Metriken müssen dabei beachtet werden?

Auswahl einer Metrik:

  1. Was soll gemessen werden?
    • Produkt
    • Prozess
    • Projekt
  2. Wie soll gemessen werden?
    • Verfahren
    • Werkzeuge
    • Ressourcen

=> Aufwand gegen Nutzen abschätzen

Gütekritierien von Metriken:

  1. Objektivität
    => Prüfer kann keinen Einfluss nehmen
  2. Validität (Tauglichkeit)
    => eindeutiger Rückschluss auf die Qualitätseigenschaft
  3. Normierbarkeit
    => es existiert eine Vergleichbarkeitsskala
  4. Wirtschaftlichkeit
    => Messung ist mit relativ niedrigem Aufwand möglich
  5. Nützlichkeit
    => Aussage kann praktisch genutzt werden

(Kapitel 9): Welche Arten von Metriken kennen Sie? Wofür werden Volumenmetriken verwendet? Nennen Sie Beispiele!

  1. Kostenmetriken, Produktivitätsmetriken
    => Aussagen über Kosten, Personal, Entwicklungszeit
  2. Fehler- und Testmetriken
    => Aussagen über gefundene bzw. erwartete Fehler
    => Testüberdeckungsmaße
  3. Volumenmetriken
    => Aussagen zur Größe einer Software
  4. Qualitätsmetriken
    => Aussagen über ein SW-Qualitätsmerkmal

(Kapitel 9): Welche grundlegenden Volumenmetriken kennen Sie? Erläutern Sie die Probleme und die Praxisrelevanz!

Lines of Code (LOC)

  • einfachste Metrik zur Berechnung der Programmkomplexität (Programmgröße)
  • einfaches Aufsummieren der Quellcodezeilen

=> Abschätzung des Aufwands und der Produktivität

Non Comment Source Statements (NCSS)

  • LOC ohne Kommentare
  • Abschätzung des Dokumentationsgrades NCSS/LOC

Probleme:

  • mangelnde Vergleichbarkeit bei Verwendung unterschiedlicher Programmiersprachen
    => Korrektur mit Sprachfaktor SLOC
  • Programmierstil kann hohe Leistung vortäuschen

Praxisbedeutung:

  • Metrik geht in komplexere Metriken ein, z.B. zur Aufwandsschätzung
  • einfach zu ermitteln, daher weit verbreitet

(Kapitel 9): Erläutern Sie die Halstead-Metriken!

These: Programmkomplexität ist abhängig von der Anazahl der Operatoren und Operanden im Programmtext.

Operatoren: alle Schlüsselwörter, vordefinierte Operatoren, Prä-Prozessoranweisungen, etc.

Operanden: Bezeichner für Variablen und Konstanten

Durch Programmtextanalyse werden ermittelt:

  • n1: Anzahl der verschiedenen Operatoren
  • n2: Anzahl der verschienen Operanden
  • N1: Gesamtanzahl der verwendeten Operatoren
  • N2: Gesamtanzahl der verwendeten Operanden

=> n = n1 + n2 (Größe des Vokabulars)
=> N = N1 + N2 (Länge des Programms)

Metrik für Programmvolumen:

V = N log2 n (Anzahl der Bits auf Binärebene)

Metrik für das erwartete Fehleraufkommen:

Im Mittel tritt nach ca. 3000 Elementaroperationen im Gehirn ein Programmierfehler auf

β = V/3000

Metrik für Programmieraufwand, Schwierigkeit:

difficulty = D = (n1*N2)/(2*n2)
=> Maß zur Bewertung von Programmiersprachen

effort = E = D*V
=> Maß zum Aufwand der Programmierung und des Programmverstehens

(Kapitel 9): Welches Qualitätsmerkmal wird mit Komplexitätsmetriken bewertet? Welche Grundidee liegt der Berechnung einer Struktur- bzw. Datenkomplexität zugrunde?

Qualitätsmerkmal: Wartbarkeit

Strukturkomplexität: je mehr Pfade desto schwerer verständlich

Datenkomplexität: je mehr Daten und je größer die Entfernung ihrer Referenzierung desto schwerer verständlich und desto mehr fehleranfällig

Lernen