Brainscape's Knowledge GenomeTM

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


See full index

ISTQB - Foundation Level > 2. Testen im SoftwareLebenszyklus > Flashcards

2. Testen im SoftwareLebenszyklus Flashcards

1
Q

Teststufen

nach dem

allgemeinen V-Modell

A
  1. Komponententest (unit test)
  2. Integrationstest
  3. Systemtest
  4. Abnahmetest
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Iterativ-inkrementelle Entwicklungsmodelle

A

Bei iterativ-inkrementeller Entwicklung werden Anforderungen, Entwurf, Entwicklung und Test in einer Reihe kurzer Entwicklungszyklen durchlaufen. Beispiele:

  • Prototyping
  • Rapid Application Development (RAD)
  • der Rational Unified Process (RUP) und
  • agile Entwicklungsmodelle.

Jedes Inkrement bzw. Erweiterung, die der bisherigen Entwicklung
hinzugefügt wird, ergibt ein wachsendes System, das ebenso getestet werden muss. Regressionstests haben daher bei allen Iterationen nach dem ersten Zyklus eine zunehmende Bedeutung.

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

Testen innerhalb eines Entwicklungslebenzyklus

A
  • Zu jeder Entwicklungsaktivität gibt es eine zugehörige Aktivität im Testen.
  • Jede Teststufe hat Testziele, die spezifisch für diese Stufe sind.
  • 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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Charakteristika von Teststufen

A
  • 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
  • Anforderungen an den Testrahmen und Werkzeugunterstützung
  • spezifische Ansätze und
  • Verantwortlichkeiten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Komponententest

A

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.

Testfälle werden von Entwicklungsdokumenten wie einer Komponentenspezifikation, dem Softwareentwurf oder dem Datenmodell abgeleitet.

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

Komponententest

Testbasis

A

Testbasis:

  •  Anforderungen an die Komponente
  •  detaillierter Entwurf
  •  Code
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Komponententest

Typische Testobjekte

A

Typische Testobjekte:

  •  Komponenten
  •  Programme
  •  Datenumwandlung/Migrationsprogramme
  •  Datenbankmodule
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Test-First-Ansatz

A

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 Testfällen, der Entwicklung und Integration von kleinen Code-Stücken und der Ausführung von Komponententests im Wechsel mit der Behebung der Probleme, bis die Tests erfolgreich durchlaufen sind.

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

Integrationstest

A

Der Integrationstest prüft die Schnittstellen zwischen Komponenten und die Interaktionen zwischen verschiedenen Teilen eines Systems, beispielsweise zum Betriebssystem, Dateisystem, zur Hardware, und er prüft die Schnittstellen zwischen Systemen.

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

Integrationstest

Testbasis

A

Testbasis

  •  Software- und Systementwurf
  •  Architektur
  •  Nutzungsabläufe/Workflows
  •  Anwendungsfälle (use cases)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Integrationstest

Typische Testobjekte

A

Typische Testobjekte:

  •  Subsysteme
  •  Datenbankimplementierungen
  •  Infrastruktur
  •  Schnittstellen
  •  Systemkonfiguration und Konfigurationsdaten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Komponentenintegrationstest

A

Ein Komponentenintegrationstest prüft das Zusammenspiel der Softwarekomponenten und wird nach dem Komponententest durchgeführt.

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

Systemintegrationstest

A

Ein Systemintegrationstest prüft das Zusammenspiel verschiedener Softwaresysteme oder zwischen Hardware und Software und kann nach dem Systemtest durchgeführt werden.

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.

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

Systemtest

A

Der Systemtest beschäftigt sich mit dem Verhalten eines Gesamtsystems/-produkts. Das Testziel soll klar im Master- und/oder Stufentestkonzept dieser Teststufe festgelegt sein.

Beim Systemtest sollte die Testumgebung mit der finalen Ziel- oder Produktivumgebung so weit wie möglich übereinstimmen, um das Risiko umgebungsspezifischer Fehler, die nicht während des Testens gefunden werden, zu minimieren.

Systemtests sollen funktionale und nicht-funktionale Anforderungen an das System sowie Datenqualitätscharakteristiken untersuchen.

Systemtests werden oft durch unabhängige Testteams durchgeführt.

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

Systemtest

Testbasis

A

Testbasis

  •  System- und Anforderungsspezifikation
  •  Anwendungsfälle (use cases)
  •  funktionale Spezifikation
  •  Risikoanalyseberichte
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Systemtest

Typische Testobjekte

A

Typische Testobjekte

  • System-, Anwender- und Betriebshandbücher
  • Systemkonfiguration und Konfigurationsdaten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Abnahmetest

A

Das Ziel des Abnahmetests besteht darin, Vertrauen in das System, Teilsystem oder in spezifische nicht-funktionale Eigenschaften eines Systems zu gewinnen. Das Finden von Fehlerzuständen ist
nicht das Hauptziel beim Abnahmetest. Abnahmetests können die Bereitschaft eines Systems für den Einsatz und die Nutzung bewerten, obwohl sie nicht notwendigerweise die letzte Teststufe darstellen.
So könnte beispielsweise ein umfangreicher Systemintegrationstest dem Abnahmetest eines der Systeme folgen.

Der Abnahmetest liegt meist im Verantwortungsbereich der Kunden oder Benutzer des Systems.

18
Q

Abnahmetest

Testbasis

A

Testbasis:

  •  Benutzeranforderungen
  •  Systemanforderungen
  •  Anwendungsfälle (use cases)
  •  Geschäftsprozesse
  •  Risikoanalyseberichte
19
Q

Abnahmetest

Typische Testobjekte

A

Typische Testobjekte:

  •  Geschäftsprozesse des voll integrierten Systems
  •  Betriebs- und Wartungsprozesse
  •  Anwenderverfahren
  •  Formulare
  •  Berichte
  •  Konfigurationsdaten
20
Q

Abnahmetest

Zeitpunkt im Lebenszyklus

A
  • Eine Standardsoftware kann einem Abnahmetest unterzogen werden, wenn sie installiert oder integriert ist.
  • Der Abnahmetest bezüglich der Benutzbarkeit einer Komponente kann während des Komponententests durchgeführt werden.
  • Der Abnahmetest einer neuen funktionalen Erweiterung kann vor dem Systemtest erfolgen.
21
Q

Anwender-Abnahmetest

A

Er prüft die Tauglichkeit eines Systems zum Gebrauch durch Anwender bzw. Kunden.

22
Q

Betrieblicher Abnahmetest

A

Die Abnahme des Systems durch den Systemadministrator enthält:

  • Test des Erstellens und Wiedereinspielens von Sicherungskopien (backup/ restore)
  • Wiederherstellbarkeit nach Ausfällen
  • Benutzermanagement
  • Wartungsaufgaben
  • Datenlade- u. Migrationsaufgaben und
  • periodische Überprüfungen von Sicherheitslücken
23
Q

Regulatorischer Abnahmetest

A

Regulatorische Abnahmetests werden gegen alle Gesetze und Standards durchgeführt, denen das System entsprechen muss – beispielsweise staatliche, gesetzliche oder Sicherheitsbestimmungen.

24
Q

Vertraglischer Abnahmetest

A

Beim vertraglichen Abnahmetest wird kundenindividuelle Software explizit gegen die vertraglichen Abnahmekriterien geprüft.

Abnahmekriterien sollten beim Vertragsabschluss zwischen den beteiligten Parteien definiert werden.

25
Q

Abnahmetest

Alpha-Test

A

Hersteller kommerzieller oder Standardsoftware wollen oft Feedback von potenziellen oder existierenden Kunden erhalten, bevor sie ein Produkt kommerziell zum Kauf anbieten.

Der Alpha-Test wird am Herstellerstandort durchgeführt, nicht jedoch vom Entwicklungsteam.

26
Q
A

Hersteller kommerzieller oder Standardsoftware wollen oft Feedback von potenziellen oder existierenden Kunden erhalten, bevor sie ein Produkt kommerziell zum Kauf anbieten.

Der Beta- (oder Feldtest) wird von Kunden oder potenziellen Kunden an den Kundenstandorten durchgeführt.

27
Q

Testarten

A
  • Testen einer zu erfüllenden Funktion
  • Testen einer nicht-funktionalen Anforderung, wie Zuverlässigkeit oder Benutzbarkeit
  • Testen der Struktur oder Architektur der Software beziehungsweise des Systems
  • Prüfen auf erfolgreiche Beseitigung eines Fehlers (Nachtest) oder Prüfen auf unbeabsichtigte beziehungsweise ungewollte Änderungen oder Seiteneffekte (Regressionstest)
28
Q

Testen der Funktionalität

(funktionaler Test)

A

Die Funktionalität, die ein System, Teilsystem oder eine Komponente zu erbringen hat, kann entweder in Arbeitsprodukten wie Anforderungsspezifikationen, Anwendungsfällen oder in einer funktionalen
Spezifikation beschrieben sein, oder sie kann undokumentiert sein.

Die Funktionalität besagt, „was“ das System leistet.

Funktionale Tests basieren auf Funktionen, Eigenschaften (beschrieben in Entwicklungsdokumenten oder gemäß dem Verständnis der Tester) und ihrer Interoperabilität zu bestimmten Systemen.

Sie kommen in allen Teststufen zur Anwendung (z.B. Komponententest basierend auf der Komponentenspezifikation).

29
Q

Black-Box-Test

A

pezifikationsorientierte Testentwurfsverfahren werden verwendet, um Testbedingungen und Testfälle aus der Funktionalität der Software oder des Systems herzuleiten.

Ein funktionaler Test betrachtet das von außen sichtbare Verhalten der Software (Black-Box-Test).

30
Q

Sicherheitstest

A

Ein Typ des funktionalen Tests, der Sicherheitstest, prüft, ob Funktionen, die Software und Daten schützen sollen (z.B. Firewalls), wirksam gegenüber externen Bedrohungen, wie Viren etc., sind.

31
Q

Interoperabilitätstest

A

Ein anderer Typ des funktionalen Tests ist der Interoperabilitätstest. Er bewertet die Fähigkeit des Softwareprodukts mit ein oder mehr spezifizierten Komponenten oder Systemen zu interagieren.

32
Q

Testen der nicht-funktionalen Softwaremerkmale

(nicht-funktionaler Test)

A
  1. Performanztest
  2. Lasttest
  3. Stresstest
  4. Benutzbarkeitstest
  5. Wartbarkeitstest,
  6. Zuverlässigkeitstest
  7. Portabilitätstest

Es geht darum, „wie“ das System arbeitet.

Nicht-funktionales Testen kann in allen Teststufen zur Anwendung kommen.

Der Begriff nichtfunktionaler Test bezeichnet Testarten, die zur Prüfung von Software- und Systemmerkmalen verwendet werden.

Nicht-funktionale Tests betrachten das nach außen sichtbare Verhalten.

Sie verwenden meistens Black-Box-Testentwurfsverfahren, um diese Prüfung durchzuführen.

33
Q

Testen der

Softwarestruktur/Softwarearchitektur

(strukturbasierter Test)

A

Strukturelles Testen (White-Box-Test) kann in allen Teststufen angewandt werden. Strukturelle Testentwurfsverfahren werden am besten nach den spezifikationsorientierten Testentwurfsverfahren eingesetzt, um die Testintensität anhand der gemessenen Abdeckungen zu beurteilen.

Der Ansatz des strukturbasierten Testens kann sinngemäß ebenso in den Teststufen System-, Systemintegration- oder Abnahmetest eingesetzt werden (beispielsweise für Geschäftsmodelle oder Menüstrukturen).

34
Q

Testüberdeckung

A

Testüberdeckung ist ein Maß dafür, inwiefern eine Struktur durch eine Testsuite geprüft bzw. ausgeführt (überdeckt) wurde. Dabei wird jeweils der prozentuale Anteil der überdeckten Strukturelemente angegeben. Ist die erreichte Testüberdeckung kleiner als 100%, kann diese verbessert werden, indem für die noch nicht überdeckten Elemente zusätzliche Testfälle spezifiziert werden.

Werkzeuge zur Messung der Codeüberdeckung, wie Anweisungs- oder Entscheidungsüberdeckung, können in allen Teststufen eingesetzt werden, im Speziellen aber im Komponenten- und Komponentenintegrationstest.

35
Q

Fehlernachtest

A

Nachdem ein Fehlerzustand entdeckt und korrigiert wurde, sollte die Software anschließend erneut getestet werden, um zu bestätigen, dass der Fehlerzustand erfolgreich entfernt wurde. In diesem Fall spricht man von einem Fehlernachtest.

Fehlernachtests müssen wiederholbar sein.

36
Q

Regressionstest

A

Unter Regressionstest verstehen wir das wiederholte Testen eines bereits getesteten Programms nach dessen Modifikation.

Er hat das Ziel nachzuweisen, dass durch die vorgenommenen Modifikationen keine Fehlerzustände eingebaut wurden oder bisher unentdeckte Fehlerzustände wirksam werden.

Diese Fehlerzustände können entweder in der zu testenden Software selbst oder aber in einer anderen Softwarekomponente liegen.

Ein Regressionstest wird ausgeführt, wenn sich die Software selbst oder ihre Umgebung ändert.

Der Umfang des Regressionstests ist durch das Risiko von neuen
Fehlerzuständen in der vorher funktionierenden Software bestimmt.

Regressionstests können in allen Teststufen durchgeführt werden und enthalten funktionale, nichtfunktionale wie auch strukturelle Tests.

Regressionstests werden oft wiederholt und ändern sich im Normalfall eher selten, was sie zu bevorzugten Kandidaten für eine Automatisierung macht.

37
Q

Wartungstest

A

Der Wartungstest wird an einem betreibbaren System ausgeführt, wobei die Tests jeweils durch Modifikationen, Migrationen oder Einzug der Software (Außerbetriebnahme, Ablösung) oder des Systems bedingt werden.

Zusätzlich zum Testen der eingebrachten Modifikationen gehört zum Wartungstesten das Regressionstesten der Systemteile, die nicht geändert wurden. Der Umfang der Wartungstests ist abhängig vom dem mit der Änderung verbundenen Risiko, der Größe des existierenden Systems und dem Umfang der Änderung.

Wartungstests können in Abhängigkeit von Modifikationen in allen Teststufen und für alle Testarten durchgeführt werden.

38
Q

Modifikationen

A

Modifikationen enthalten geplante Erweiterungen (z.B. basierend auf dem geplanten Release), Korrekturen und Notfallkorrekturen, Umgebungsänderungen wie eine geplante Aktualisierung des Betriebs-
oder Datenbanksystems, geplante Upgrades von kommerzieller Standardsoftware oder Patches zur Korrektur erst kürzlich entdeckter Schwachstellen des Betriebssystems.

39
Q

Migrationstests

A

Ein Wartungstest bei einer Migration (z.B. von einer Plattform zu einer anderen) soll sowohl Tests im Betrieb der neuen Umgebung als auch der geänderten Software umfassen.

Migrationstests (Konvertierungstests) werden ebenso benötigt, wenn Daten aus einer anderen Anwendung in das zu wartende System migriert werden.

40
Q

Auswirkungsanalyse

A

Die Ermittlung, inwiefern ein bestehendes System durch Modifikationen beeinflusst wird, nennt man Auswirkungsanalyse.

Sie wird verwendet, um zu entscheiden, wie viele Regressionstests durchzuführen sind.

Die Auswirkungsanalyse kann benutzt werden, um eine Regressionstestsuite festzulegen.

41
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