Suche

» erweiterte Suche » Sitemap

Technische Wissenschaften


» Bild vergrößern
» Blick ins Buch
» weitere Bücher zum Thema


» Buch empfehlen
» Buch bewerten
Produktart: Buch
Verlag: Bachelor + Master Publishing
Erscheinungsdatum: 07.2012
AuflagenNr.: 1
Seiten: 104
Abb.: 34
Sprache: Deutsch
Einband: Paperback

Inhalt

Chipkartensoftware von elektronischen Ausweisdokumenten darf aufgrund der hohen Sicherheitsanforderungen nicht nachträglich veränderbar sein und muss eine höhere Qualität als Computersoftware besitzen, weil Fehler nicht durch das Einspielen von Updates korrigierbar sind, sondern nur durch Rückruf und Austausch behoben werden können. Die hohen Qualitätsziele, die daher an Chipkartensoftware gestellt werden, können nur durch intensive Prüfung abgesichert werden. In der vorliegenden Arbeit wird eine Prüfstrategie entworfen, die besonders auf die spezifischen Eigenschaften der Chipkartensoftware von elektronischen Ausweisdokumenten eingeht, mittels derer sich funktionale Systemtests aus einem Lastenheft (Spezifikation des Auftraggebers) ableiten lassen. Diese Prüfstrategie wird auf die technische Spezifikation des neuen elektronischen Personalausweises angewendet und der resultierende funktionale Systemtest wird mit einem für den elektronischen Personalausweis konzipierten Systemtest verglichen, der erfahrungsbasiert entwickelt wurde.

Leseprobe

Textprobe: Kapitel 3.2.1, Strukturorientierte Prüfmethoden: Die Grundlage des Prüfobjekts für strukturorientierte Tests sind Kontrollflussgraphen. Strukturorientierte Testspezifikationen lassen sich mit den Maßen Anweisungsüberdeckung, Zweigüberdeckung und Pfadüberdeckung (oder auch Bedingungsüberdeckung) bewerten. Hier wird jeweils die Überdeckung im Sinne der Anweisungen, der Verzweigungen und der existierenden möglichen Pfade des Kontrollflussgraphs gemessen. Eine Testspezifikation, deren Zweigüberdeckung vollständig ist, erzielt auch gleichzeitig eine vollständige Anweisungsüberdeckung. Die Pfadüberdeckungmetrik gibt an, wie viele aller möglichen Kombinationen in den Tests abgedeckt sind. Beispiel: Ein Kontrollflussgraph bestehend aus verschachtelten Bedingungen mit Alternative der Tiefe n , besitzt 2n-1 unterschiedliche mögliche Ausführungspfaden. Dieser Testplan ist gleichzeitig minimal für die vollständige Zweig- und Anweisungsüberdeckung. Ein Kontrollflussgraph mit n sequentiellen Bedingungen ohne Alternative hingegen benötigt 1 Test für eine vollständige Anweisungsüberdeckung, 2 Tests für eine vollständige Zweigüberdeckung und 2n Tests für eine vollständige Pfadüberdeckung. Aus dem letzteren Beispiel wird deutlich, dass die Aussagekraft einer Testspezifikation, die eine vollständige Anweisungsüberdeckungsbewertung hat, nur eine begrenzte Aussage über die Abdeckung des Prüfobjekts besitzt. Testspezifikationen mit vollständiger Pfadüberdeckung hingegen erreichen schnell eine unpraktikable Größe, so dass strukturorienierte Testspezifikationen in der Praxis nur in Teilen des Prüfobjekts vollständig im Sinne der Pfadüberdeckung sind. Ein weiterer Nachteil der stukturorientierten Prüfmethode ist, dass ausschließliche Fehlverhalten aufgedeckt wird, das innerhalb der Implementierung auftritt. Fehlerhafte Umsetzungen von Anforderungen werden auf Grund des Prüfobjektbezugs meistens nicht aufgedeckt. Die Klasse der strukturorientierten Testspezifikationen wird in der Literatur auch als White-Box -Tests bezeichnet, da die internen Eigenschaften (in Form von Kontrollflussgraphen) des zu testenden Systems für den Tester bekannt sein müssen. 3.2.2, Funktionsorientierte Prüfmethoden: Die Tests der funktionsorientierten Prüfmethode prüfen, ob die Anforderungen korrekt umgesetzt sind. Der Prüfer betrachtet die Software als Black-Box , von der nur das Verhalten nach außen, nicht aber der innere Zustand des Systems geprüft werden kann. Die Wissensbasis des Prüfers bilden dabei die im Lastenheft definierten Anforderungen der Software. Nach IEEE Std 610.12-1990 ist eine Anforderung wie folgt definiert: 1. Eine Bedingung oder Eigenschaft, die ein System oder eine Person benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen. 2. Eine Bedingung oder Eigenschaft, die ein System oder eine Systemkomponente aufweisen muss, um einen Vertrag zu erfüllen oder einem Standard, einer Spezifikation oder einem anderen formell auferlegten Dokument zu genügen. 3. Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft wie in (1) oder (2) definiert. Aus dieser Definition folgt, dass Anforderungen sowohl informal in natürlicher Sprache als auch formal durch Modelle beschrieben werden können. Für jede Art der Anforderungen haben sich verschiedene Ansätze entwickelt Tests abzuleiten. Der Prozess der Testfallableitung muss in jedem Fall dokumentiert werden, um bei eventuellen Änderungen an den Anforderungen die betroffenen Testfälle zu identifizieren. Außerdem wird durch die Dokumentation die Nachvollziehbarkeit und dadurch Überprüfbarkeit der Abdeckung der Anforderung ermöglicht. Der Grad der Abdeckung einer Anforderung durch Tests ist bei informalen Anforderungen stets subjektiv. Erzeugt der Prüfer nicht für jeden Test eine Dokumentation des Testziels (welcher Aspekt einer Anforderung wird von welchen Tests abgedeckt), so wird die Testspezifikation zusätzlich nicht pflegbar.

weitere Bücher zum Thema

Bewerten und kommentieren

Bitte füllen Sie alle mit * gekennzeichenten Felder aus.


script>