ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1794
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 11/84
1.8.2011
© International Software Testing Qualifications Board
1.1 Warum sind Softwaretests notwendig? (K2)
20 Minuten
Begriffe
Fehler, Fehlerwirkung, Fehlerzustand/ Defekt, Fehlhandlung, Qualität, Risiko
1.1.1 Softwaresystemzusammenhang (K1)
Softwaresysteme sind aus dem täglichen Leben nicht wegzudenken, angefangen von Business-
Software (z.B. Bankanwendungen) bis hin zu Gebrauchsgegenständen (z.B. Autos). Die meisten
Endanwender haben bereits schlechte Erfahrungen mit Softwaresystemen gemacht, die nicht so funk-
tioniert haben wie erwartet. Software, die nicht korrekt funktioniert, kann zu vielerlei Problemen führen,
wie Geld-, Zeit- oder Imageverlust oder sogar zu Personenschäden, wie Verletzungen oder Tod.
1.1.2 Ursachen von Softwarefehlern (K2)
Ein Mensch kann eine Fehlhandlung begehen, die einen Fehlerzustand im Programmcode oder in
einem Dokument verursacht. Wenn der fehlerhafte Code ausgeführt wird, wird das System möglicher-
weise nicht das tun, was es tun sollte (oder etwas tun, was es nicht tun sollte) und dabei eine Fehler-
wirkung hervorrufen. Fehler in Software, Systemen oder Dokumenten können, müssen aber nicht zu
einer Fehlerwirkung führen.
Fehlerzustände treten auf, weil Menschen Fehlhandlungen begehen, z.B. unter Zeitdruck, bei komple-
xem Code, durch Komplexität der Infrastruktur, bei sich ändernden Technologien, und/oder vielen
Systemwechselbeziehungen.
Fehlerwirkungen können aber auch durch Umgebungsbedingungen hervorgerufen werden. Zum Bei-
spiel können Strahlung, elektromagnetische Felder oder Schmutz Fehlerzustände in der Firmware
verursachen; ebenso kann die Ausführung der Software durch das Ändern von Hardwarezuständen
beeinflusst werden.
1.1.3 Die Rolle des Testens bei Entwicklung, Wartung und Betrieb von Software (K2)
Intensives Testen von Systemen und Dokumentation kann helfen das Risiko zu reduzieren, dass
Probleme im operativen Betrieb auftreten. Weiterhin kann es dazu beitragen, die Qualität des Soft-
waresystems zu erhöhen, indem Fehlerzustände vor der betrieblichen Freigabe gefunden und beho-
ben werden.
Softwaretesten kann auch notwendig sein, um vertragliche oder gesetzliche Vorgaben oder spezielle
Industrienormen zu erfüllen.
1.1.4 Testen und Qualität (K2)
Testen ermöglicht es, die Qualität von Software zu messen. Qualität wird hier ausgedrückt durch die
Anzahl gefundener Fehlerzustände. Das gilt sowohl für funktionale als auch für nicht-funktionale An-
forderungen und Qualitätsmerkmale (z.B. Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und
Übertragbarkeit); für weitere Informationen zum Thema nicht-funktionales Testen siehe Kapitel 2; für
weitere Information über Softwarequalitätsmerkmale siehe die Norm ‘Software engineering – Product
quality’ (ISO 9126-1, 2001).
Wenn wenige oder keine Fehlerzustände gefunden werden, kann Testen Vertrauen in die Qualität
eines Systems schaffen. Ein angemessen spezifizierter Test, der keine Fehler zeigt, reduziert das
allgemeine Risikoniveau in einem System. Falls Testen Fehlerzustände findet und diese Fehlerzu-
stände behoben werden, steigt die Qualität des Softwaresystems.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 12/84
1.8.2011
© International Software Testing Qualifications Board
Aus den Fehlern vorangegangener Projekte sollte gelernt werden. Wenn man die Fehlerursachen
verstanden hat, die beim Test in anderen Projekten gefunden wurden, kann man Entwicklungsprozes-
se zielgerichtet verbessern. Das wiederum beugt dem erneuten Auftreten der Fehlerzustände vor und
sollte als Konsequenz die Qualität zukünftiger Systeme verbessern. Das ist ein Aspekt der Qualitätssi-
cherung.
Testen sollte als eine Qualitätssicherungsmaßnahme in den Entwicklungsprozess integriert sein (ne-
ben beispielsweise Entwicklungsstandards, Schulung und Fehlerursachenanalyse).
1.1.5 Wie viel Testaufwand ist notwendig? (K2)
Um zu entscheiden, wie viel Testen notwendig ist, sollte das Risikoniveau berücksichtigt werden. Das
schließt sowohl technische, Betriebssicherheits- und wirtschaftliche Risiken, als auch Projektrandbe-
dingungen, wie Zeit und Budget ein. (Risiko wird im Kapitel 5 weiter diskutiert.)
Testen sollte den Beteiligten genügend Informationen liefern, um fundierte Entscheidungen über die
Freigabe der getesteten Software oder des Systems treffen zu können. Die Freigabe kann die Über-
gabe des Systems an den nächsten Entwicklungsschritt bedeuten oder die Übergabe des Systems an
die Kunden.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 13/84
1.8.2011
© International Software Testing Qualifications Board
1.2 Was ist Softwaretesten? (K2)
30 Minuten
Begriffe
Anforderung, Debugging, Review, Testen, Testfall, Testziel
Hintergrund
Verbreitet ist die Auffassung, dass Testen nur aus dem Ausführen von Tests, d.h. dem Ausführen der
Software, besteht. Dabei handelt es sich jedoch nur um einen Teilbereich des Testens.
Weitere Testaktivitäten sind vor und nach der Testdurchführung angesiedelt. Dazu gehören: Planung
und Steuerung der Tests, Auswahl der Testbedingungen, Testfallspezifikation, Ausführung der Test-
fälle, Überprüfung der Ergebnisse, Auswertung der Ausgangskriterien, Berichten über den Testpro-
zess und das zu testende System sowie nach Abschluss einer Testphase Abschlussarbeiten zu Ende
zu bringen. Zum Testen zählt ebenfalls das Prüfen von Dokumenten (Quellcode inbegriffen) und die
Durchführung von statischen Analysen.
Sowohl das dynamische Testen als auch das statische Testen können als Mittel zur Erreichung ähnli-
cher Zielsetzungen eingesetzt werden. Dabei werden Informationen zur Verbesserung des zu testen-
den Systems, des Entwicklungs- und des Testprozesses geliefert.
Testen kann die folgenden Ziele haben:
•
Aufdecken von Fehlerzuständen
•
Erzeugen von Vertrauen bezüglich des Qualitätsniveaus des Systems
•
Liefern von Informationen zur Entscheidungsfindung
•
Vorbeugen von Fehlerzuständen
Ein konsequenter Prozess und ein Beginn der Tätigkeiten zur Erstellung von Tests schon früh im Le-
benszyklus (das Prüfen der Testbasis durch den Testentwurf) kann Fehler im Programmcode verhin-
dern. Reviews von Dokumenten (z.B. Anforderungsspezifikation) sowie Identifizierung und Lösung
von Problemen kann ebenfalls Fehler im Programmcode verhindern.
Aus den verschiedenen Zielsetzungen beim Testen ergeben sich verschiedene Gesichtspunkte. Zum
Beispiel könnte bei herstellerinternen Tests im Testentwurf (z.B. Komponententest, Integrationstest
oder Systemtest) das Hauptziel sein, so viele Fehlerwirkungen wie möglich zu verursachen, so dass
Fehlerzustände in der Software identifiziert und behoben werden können. Demgegenüber könnte im
Abnahmetest das Hauptziel sein, zu bestätigen, dass das System wie erwartet funktioniert, um Ver-
trauen zu schaffen, dass es den Anforderungen entspricht. In manchen Fällen könnte das Hauptziel
des Testens sein, die Softwarequalität zu bewerten (ohne die Absicht Fehlerzustände zu beheben),
um die Beteiligten über das Risiko einer Systemfreigabe zu einem bestimmten Zeitpunkt zu informie-
ren. Wartungstests enthalten oft Tests, die sicherstellen sollen, dass durch die Änderung der Software
keine neuen Fehler eingebaut wurden. Beim Betriebstest (orientiert an Nutzungsprofilen) kann das
Hauptziel sein, ein System hinsichtlich Ausprägungen wie Zuverlässigkeit oder Verfügbarkeit zu be-
werten.
Debugging und Testen sind verschiedene Dinge. Dynamische Tests können Fehlerwirkungen zeigen,
die durch Fehlerzustände verursacht werden. Debugging ist eine Entwicklungsaktivität, die die Ursa-
che einer Fehlerwirkung identifiziert, analysiert und entfernt. Anschließende Fehlernachtests durch
einen Tester stellen sicher, dass die Lösung wirklich die Fehlerwirkung behoben hat. Die Verantwor-
tung für Testen liegt üblicherweise beim Tester, die für Debugging beim Entwickler.
Der Testprozess und seine Aktivitäten werden in Abschnitt 1.4 näher behandelt.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 14/84
1.8.2011
© International Software Testing Qualifications Board
1.3 Die sieben Grundsätze des Softwaretestens
(K2)
35 Minuten
Begriffe
erschöpfender Test
Grundsätze
In den letzten 40 Jahren haben sich folgende Grundsätze des Testens herauskristallisiert, die als ge-
nerelle Leitlinien beim Testen angesehen werden.
Grundsatz 1: Testen zeigt die Anwesenheit von Fehlerzuständen
Mit Testen wird das Vorhandensein von Fehlerzuständen nachgewiesen.
Mit Testen lässt sich nicht beweisen, dass keine Fehlerzustände im Testobjekt vorhanden sind. Aus-
reichendes Testen verringert die Wahrscheinlichkeit, dass noch unentdeckte Fehlerzustände im Test-
objekt vorhanden sind. Selbst wenn keine Fehlerzustände im Test aufgezeigt wurden, ist das kein
Nachweis für Fehlerfreiheit.
Grundsatz 2: Vollständiges Testen ist nicht möglich
Ein vollständiger Test, bei dem alle möglichen Eingabewerte und deren Kombinationen unter Berück-
sichtigung aller unterschiedlichen Vorbedingungen ausgeführt werden, ist nicht durchführbar, mit Aus-
nahme von sehr trivialen Testobjekten. Tests sind immer nur Stichproben, und der Testaufwand ist
entsprechend Risiko und Priorität festzulegen.
Grundsatz 3: Mit dem Testen frühzeitig beginnen
Um Fehlerzustände frühzeitig zu finden, sollen Testaktivitäten im System- oder Softwarelebenszyklus
so früh wie möglich beginnen und definierte Ziele verfolgen.
Grundsatz 4: Häufung von Fehlern
Der Testaufwand soll sich proportional zu der erwarteten und später beobachteten Fehlerdichte auf
die Module fokussieren. Ein kleiner Teil der Module enthält gewöhnlich die meisten Fehlerzustände,
die während der Testphase entdeckt werden oder ist für die meisten Fehlerwirkungen im Betrieb ver-
antwortlich.
Grundsatz 5: Wiederholungen haben keine Wirksamkeit
Wiederholungen der immer gleichen Testfälle führen nicht zu neuen Erkenntnissen. Damit die Effekti-
vität der Tests nicht abnimmt, sind die Testfälle regelmäßig zu prüfen und neue oder modifizierte Test-
fälle zu erstellen. Bisher nicht geprüfte Teile der Software oder unberücksichtigte Konstellationen bei
der Eingabe werden dann ausgeführt und somit mögliche weitere Fehlerzustände nachgewiesen.
Grundsatz 6: Testen ist abhängig vom Umfeld
Je nach Einsatzgebiet und Umfeld des zu prüfenden Systems ist das Testen anzupassen. Sicher-
heitskritische Systeme werden beispielsweise anders getestet als E-Commerce-Systeme.
Grundsatz 7: Trugschluss: „Keine Fehler“ bedeutet ein brauchbares System
Fehlerzustände zu finden und zu beseitigen, hilft nicht, wenn das gebaute System nicht nutzbar ist
und nicht den Vorstellungen und Erwartungen der Nutzer entspricht.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 15/84
1.8.2011
© International Software Testing Qualifications Board
1.4 Fundamentaler Testprozess (K1)
35 Minuten
Begriffe
Abweichung, Ausgangskriterien, Fehlernachtest, Mastertestkonzept, Regressionstest, Testablauf,
Testabschlussbericht, Testbasis, Testbedingung, Testdaten, Testdurchführung, Testkonzept, Testmit-
tel, Testprotokoll, Testrichtlinie, Testsuite, Testüberdeckung
Hintergrund
Die Testdurchführung ist der sichtbarste Teil des Testens. Um effektiv und effizient zu sein, müssen
Testkonzepte darüber hinaus aber Zeit vorsehen, um die Tests zu planen, Testfälle zu spezifizieren
und die Testdurchführung vorzubereiten, sowie die Testergebnisse zu bewerten.
Der fundamentale Testprozess besteht aus den folgenden Hauptaktivitäten:
•
Testplanung und Steuerung
•
Testanalyse und Testentwurf
•
Testrealisierung und Testdurchführung
•
Bewertung von Ausgangskriterien und Bericht
•
Abschluss der Testaktivitäten
Auch wenn sie hier logisch sequentiell aufgelistet sind, können all diese Testprozessaktivitäten in der
Praxis zeitlich überlappend oder parallel stattfinden. Gewöhnlich ist es nötig, Ausprägungen und Rei-
henfolge dieser Hauptaktivitäten jeweils dem zu testenden System oder dem Projekt anzupassen.
1.4.1 Testplanung und Steuerung (K1)
Zur Testplanung gehören folgende Aktivitäten: die Definition der Testziele und die Festlegung der
Testaktivitäten, die notwendig sind, um Aufgabenumfang und Testziele erreichen zu können.
Teststeuerung ist die fortlaufende Aktivität, den aktuellen Testfortschritt gegen den Plan einschließlich
eventueller Abweichungen vom Plan zu überprüfen und den Status aufzuzeigen, sowie ggf. das Einlei-
ten von Korrekturmaßnahmen. Um Tests steuern zu können, ist es notwendig, projektbegleitend ge-
eignete Fortschrittsdaten zu ermitteln. Die Testplanung muss Feedback aus solchen Überwachungs-
und Steuerungsaktivitäten berücksichtigen und die Pläne entsprechend fortschreiben.
Aufgaben der Testplanung und –steuerung werden im Kapitel 5 des Lehrplans im Detail behandelt.
1.4.2 Testanalyse und Testentwurf (K1)
Testanalyse und -entwurf ist die Aktivität, in der die allgemeinen Testziele zu konkreten Testbedin-
gungen und Testfällen verfeinert werden.
Dies umfasst die folgenden Hauptaufgaben:
•
Review der Testbasis (z.B. Anforderungen, Software Integrity Level
1
(Risikoausmaß), Risiko-
analysebericht, Architektur, Design, Schnittstellenspezifikation)
•
Bewertung der Testbarkeit von Testbasis und Testobjekten
•
Identifizierung und Priorisierung der Testbedingungen auf Grundlage der Testobjektanalyse,
der Spezifikation, des Verhaltens und der Struktur der Software
•
Entwurf (Design) und Priorisierung von abstrakten Testfällen
•
Identifizierung benötigter Testdaten, um Definition von Testbedingungen und Testfällen zu un-
terstützen
1
Der Erfüllungsgrad einer Menge vom Stakeholder ausgewählter Software- und/oder Software-basierter Merkmale (z.B.
Softwarekomplexität, Risikoeinstufung, Sicherheitsstufe (Zugriffsschutz) und funktionalen Sicherheit, gewünschte Perfor-
manz, Zuverlässigkeit, oder Kosten), die definiert wurden, um die Bedeutung der Software für den Stakeholder zum Aus-
druck zu bringen.