ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1793
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 21/84
1.8.2011
© International Software Testing Qualifications Board
2 Testen im Softwarelebenszyklus (K2)
115 Minuten
Lernziele für den Abschnitt Testen im Softwarelebenszyklus
Die Lernziele legen fest, was Sie nach Beenden des jeweiligen Moduls gelernt haben sollten.
2.1 Softwareentwicklungsmodelle (K2)
LO-2.1.1 Beziehungen zwischen Entwicklungs- und Testaktivitäten und Arbeitsergebnissen im Ent-
wicklungslebenszyklus anhand von Beispielen unter Verwendung von Projekt- und Pro-
dukteigenschaften erklären können (K2)
LO-2.1.2 Die Tatsache erkennen, dass Softwareentwicklungsmodelle an das Projekt und die Pro-
dukteigenschaften angepasst werden müssen (K1)
LO-2.1.3 Eigenschaften „guter” Tests nennen können, die in beliebigen Entwicklungslebenszykle n
anwendbar sind (K1)
2.2 Teststufen (K2)
LO-2.2.1 Verschiedene Teststufen vergleichen können: Hauptziele, typische Testobjekte, typische
Testziele (z.B. funktionale oder strukturelle) und entsprechende Arbeitsergebnisse, Rollen
beim Testen, Arten von zu identifizierenden Fehlerzuständen und –wirkungen (K2)
2.3 Testarten (K2)
LO-2.3.1 Vier Arten des Softwaretestens (funktional, nicht-funktional, strukturell und änderungsbezo-
gen) an Beispielen vergleichen können (K2)
LO-2.3.2 Erkennen, dass funktionale und strukturelle Tests auf jeder Teststufe angewendet werden
können (K1)
LO-2.3.3 Nicht-funktionale Testarten auf Grundlage von nicht-funktionalen Anforderungen identifizie-
ren und beschreiben können (K2)
LO-2.3.4 Testarten basierend auf der Analyse der Struktur oder Architektur des Softwaresystems
identifizieren und beschreiben können (K2)
LO-2.3.5 Zweck eines Fehlernachtests und eines Regressionstests beschreiben können (K2)
2.4 Wartungstests (K2)
LO-2.4.1 Wartungstests (also Testen eines existierenden Systems) vergleichen können mit dem
Testen einer neuen Anwendung bzgl. der Testarten, Auslöser des Testens und des Test-
umfangs (K2)
LO-2.4.2 Indikatoren für Wartungstests (also Modifikation, Migration und Außerbetriebnahme der
Software) erkennen können (K1)
LO-2.4.3 Die Rolle von Regressionstests und Auswirkungsanalyse in der Softwarewartung beschrei-
ben können (K2)
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 22/84
1.8.2011
© International Software Testing Qualifications Board
2.1 Softwareentwicklungsmodelle (K2)
20 Minuten
Begriffe
iterativ-inkrementelles Entwicklungsmodell, kommerzielle Standardsoftware (COTS – Commercial Off
The Shelf), V-Modell (allgemeines), Validierung, Verifizierung
Hintergrund
Testen findet nicht isoliert statt; Testaktivitäten sind immer bezogen auf Softwareentwicklungsaktivitä-
ten. Verschiedene Entwicklungslebenszyklusmodelle erfordern verschiedene Testansätze.
2.1.1 V-Modell (sequentielles Entwicklungsmodell) (K2)
Es existieren Varianten des V-Modells. Das Gängigste, das allgemeine V-Modell, besteht aus fünf
Entwicklungsstufen und vier Teststufen. Die vier Teststufen korrespondieren mit den Entwicklungsstu-
fen.
Die vier in diesem Lehrplan verwendeten Teststufen nach dem allgemeinen V-Modell sind:
•
Komponententest (unit test)
•
Integrationstest
•
Systemtest
•
Abnahmetest
In der Praxis kann ein V-Modell, entsprechend dem Projekt(-vorgehen) oder Produkt, das entwickelt
und getestet werden soll, weniger, mehr oder andere Stufen aufweisen. Beispielsweise kann es Kom-
ponentenintegrationstests nach Komponententests oder Systemintegrationstests nach Systemtests
geben.
Entwicklungsdokumente (wie Geschäftsvorfälle oder Anwendungsfälle, Anforderungsspezifikationen,
Entwurfsdokumente und Code), die während der Entwicklung entstehen, sind oft die Basis für Tests in
einer oder mehreren Stufen.
Referenzen für generische Arbeitspapiere können unter anderem in folgenden Standards gefunden
werden:
•
CMMI-2004 (Capability Maturity Model Integration)
•
IEEE/IEC 12207-2008 (‘Software life cycle processes’)
Verifizierung und Validierung (und früher Testentwurf) können während der Erstellung der Entwick-
lungsdokumente durchgeführt werden.
2.1.2 Iterativ-inkrementelle Entwicklungsmodelle (K2)
Bei iterativ-inkrementeller Entwicklung werden Anforderungen, Entwurf, Entwicklung und Test in einer
Reihe kurzer Entwicklungszyklen durchlaufen. Beispiele hierfür sind Prototyping, Rapid Application
Development (RAD), der Rational Unified Process (RUP) und agile Entwicklungsmodelle. Ein System,
welches unter Nutzung dieser Entwicklungsmodelle erstellt wird, kann in jeder Iteration die verschie-
denen Teststufen durchlaufen. Jedes Inkrement bzw. Erweiterung, die der bisherigen Entwicklung
hinzugefügt wird, ergibt ein wachsendes System, das ebenso getestet werden muss. Regressions-
tests haben daher bei allen Iterationen nach dem ersten Zyklus eine zunehmende Bedeutung. Verifi-
zierung und Validierung können für jede Erweiterung durchgeführt werden.
2.1.3 Testen innerhalb eines Entwicklungslebenszyklus (K2)
In jedem Entwicklungslebenszyklus findet man einige Charakteristika für gutes Testen:
•
Zu jeder Entwicklungsaktivität gibt es eine zugehörige Aktivität im Testen.
•
Jede Teststufe hat Testziele, die spezifisch für diese Stufe sind.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 23/84
1.8.2011
© International Software Testing Qualifications Board
•
Die Analyse und der Entwurf der Tests für eine Teststufe sollten während der zugehörigen
Entwicklungsaktivität beginnen.
•
Die Tester sollten im Reviewprozess der Entwicklungsdokumente (Anforderungen, Analyse
und Design) eingebunden werden, sobald eine Vorabversion eines der Dokumente verfügbar
ist.
Teststufen können in Abhängigkeit des Projekts oder der Systemarchitektur kombiniert oder neu fest-
gelegt (geordnet) werden. Zum Beispiel kann ein Käufer für die Integration kommerzieller Standard-
software den Integrationstest auf Systemebene (z.B. zur Integration in die Infrastruktur und mit ande-
ren Systemen oder zur Nutzung in der Produktivumgebung) und den Abnahmetest (beispielsweise
funktionale und/oder nicht-funktionale Tests und Nutzer- und/oder Betriebstests) durchführen.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 24/84
1.8.2011
© International Software Testing Qualifications Board
2.2 Teststufen (K2)
40 Minuten
Begriffe
Alpha-Test, Benutzer-Abnahmetest, Beta-Test, Feldtest, funktionale Anforderung, Integration, Integra-
tionstest, Komponententest, nicht-funktionale Anforderung, Platzhalter (stubs), Robustheitstest, Sys-
temtest, testgetriebene Entwicklung, Teststufe, Treiber, Testumgebung
Hintergrund
Alle Teststufen können durch die folgenden Aspekte charakterisiert werden: allgemeine Ziele; die
Arbeitsergebnisse, von denen die Testfälle abgeleitet werden (also die Testbasis); das Testobjekt
(also was getestet wird); typische Fehlerwirkungen und –zustände, die gefunden werden sollten; An-
forderungen an den Testrahmen und Werkzeugunterstützung; spezifische Ansätze und Verantwort-
lichkeiten.
Das Testen der Konfigurationsdaten eines Systems soll in der Testplanung berücksichtigt werden.
2.2.1 Komponententest (K2)
Testbasis:
•
Anforderungen an die Komponente
•
detaillierter Entwurf
•
Code
Typische Testobjekte:
•
Komponenten
•
Programme
•
Datenumwandlung/Migrationsprogramme
•
Datenbankmodule
Der Komponententest (auch bekannt als Unit-, Modul- oder Programmtest) hat zum Ziel, Software, die
separat getestet werden kann (z.B. Module, Programme, Objekte, Klassen, etc.), zu prüfen und darin
vorhandene Fehler zu finden. In Abhängigkeit von Lebenszyklus und System kann das durch Isolie-
rung vom Rest des Systems erreicht werden. Dabei werden meist Platzhalter, Treiber und Simulato-
ren eingesetzt.
Der Komponententest kann das Testen funktionaler wie auch nicht-funktionaler Aspekte umfassen, so
etwa das Testen der Ressourcenverwendung (z.B. Suche nach Speicherengpässe), Robustheitstest
oder auch struktureller Test (z.B. Entscheidungsüberdeckung). Testfälle werden von Entwicklungs-
dokumenten wie einer Komponentenspezifikation, dem Softwareentwurf oder dem Datenmodell abge-
leitet.
Meistens stehen den Testern beim Komponententest der Quellcode wie auch Unterstützung aus der
Entwicklungsumgebung zur Verfügung, beispielsweise eine spezielle Komponententestumgebung
(unit test framework) oder Debugging-Werkzeuge. In der Praxis sind oft die für den Code verantwortli-
chen Entwickler an den Komponententests beteiligt. Dabei werden die gefundenen Fehlerzustände
häufig sofort korrigiert und gar nicht erst formell behandelt.
Ein Ansatz beim Komponententest ist es, die Testfälle vor der Implementierung der Funktionalität
vorzubereiten und zu automatisieren. Dies wird Test-First-Ansatz oder testgetriebene Entwicklung
(test-driven) genannt. Dieser Ansatz ist sehr iterativ und basiert auf Zyklen aus Entwicklung von Test-
fällen, der Entwicklung und Integration von kleinen Code-Stücken und der Ausführung von Komponen-
tentests im Wechsel mit der Behebung der Probleme, bis die Tests erfolgreich durchlaufen sind.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 25/84
1.8.2011
© International Software Testing Qualifications Board
2.2.2 Integrationstest (K2)
Testbasis
•
Software- und Systementwurf
•
Architektur
•
Nutzungsabläufe/Workflows
•
Anwendungsfälle (use cases)
Typische Testobjekte
•
Subsysteme
•
Datenbankimplementierungen
•
Infrastruktur
•
Schnittstellen
•
Systemkonfiguration und Konfigurationsdaten
Der Integrationstest prüft die Schnittstellen zwischen Komponenten und die Interaktionen zwischen
verschiedenen Teilen eines Systems, beispielsweise zum Betriebssystem, Dateisystem, zur Hard-
ware, und er prüft die Schnittstellen zwischen Systemen.
Es können mehrere Integrationsstufen zum Einsatz gelangen und diese können Testobjekte unter-
schiedlichster Größe betreffen. Zum Beispiel:
1. Ein Komponentenintegrationstest prüft das Zusammenspiel der Softwarekomponenten und
wird nach dem Komponententest durchgeführt.
2. Ein Systemintegrationstest prüft das Zusammenspiel verschiedener Softwaresysteme oder
zwischen Hardware und Software und kann nach dem Systemtest durchgeführt werden. In
einem solchen Fall hat das Entwicklungsteam oft nur die eine Seite der zu prüfenden Schnitt-
stelle unter seiner Kontrolle. Dies kann als Risiko betrachtet werden. Geschäftsprozesse, die
als Workflows implementiert sind, können eine Reihe von Systemen nutzen. Plattformüber-
greifende Fragestellungen können signifikant sein.
Je größer der Umfang einer Integration ist, desto schwieriger ist die Isolation von Fehlerzuständen in
einer spezifischen Komponente oder einem System, was zur Erhöhung des Risikos und zusätzlichem
Zeitbedarf zur Fehlerbehebung führen kann.
Systematische Integrationsstrategien können auf der Systemarchitektur (z.B. Top-Down und Bottom-
Up), funktionalen Aufgaben, Transaktionsverarbeitungssequenzen oder anderen Aspekten des Sys-
tems oder seiner Komponenten basieren. Um die Fehlerisolation zu erleichtern und Fehlerzustände
früh aufzudecken, sind inkrementelle Integrationsstrategien normalerweise der Big-Bang-Strategie
vorzuziehen.
Das Testen spezieller nicht-funktionaler Eigenschaften (z.B. Performanz) kann im Integrationstest
ebenso enthalten sein, wie funktionale Tests.
Bei jeder Integrationsstufe sollen Tester sich ausschließlich auf die eigentliche Integration konzentrie-
ren. Wenn zum Beispiel das Modul A mit dem Modul B integriert wird, so soll der Fokus auf der Kom-
munikation zwischen den Modulen und nicht etwa auf der Funktionalität der einzelnen Module liegen,
welche Inhalt des Komponententests war. Sowohl funktionale als auch strukturelle Ansätze können
genutzt werden.
Idealerweise sollten Tester die Architektur verstehen und entsprechend auf die Integrationsplanung
Einfluss nehmen. Werden Integrationstests bereits vor der Erstellung der einzelnen Komponenten od-
er Systeme geplant, können diese dann in der für die Integration effizientesten Reihenfolge entwickelt
werden.