6. Systematisches Testen von Software

1. Durchführung ist unabhängig der Teststufe zu jedem Test

1. Unterschiedlich, je nach Komplexität

1. Bestimmung Qualitätsziele bzw. der zu erreichende Qualitätsgrad

   Beschreibung, welche Systemfunktionen und Systemeigenschaften getestet werden

2. grobe Beschreibungen der Testfälle oder des Testgegenstandes, ohne dabei auf Details zum Ablauf oder zu den Testdaten einzugehen.

Systemtests

—> Komplexe Testmgebung, da Test in prduktnaher Umgebung

1. Testfälle erstellt, beschrieben, später ausgeführt

2. Detaillierte Beschreibung:

   • Zweck des Testfalls;

   • Testgegenstände;

   • Zustand des Systems vor und nach Testausführung;

   • Art und Struktur der Testdaten;

   • benötige Hard- und Softwareumgebung;

   • benötigtes Personal sowie

   • Abhängigkeiten zu anderen Testfällen.

1. Verbunden mit Testfallspezifikation

2. Testdatensätze, die zur Durchführung der spezifizierten Testfälle benötigt werden

3. Abhängig von Spezifikation und Teststufe

   —> Je höher die Stufe, desto komplexer

4. Quellen

   • Architekturbeschreibung

   • Spezifikation

   • Programmcode

   • Produktionsdaten

   • Testdatenbestand (Erweiterbar, Wiederverwendbarkeit)

1. Ausführung der Testfälle unter Verwendung der Testdaten und Protokollierung der Ergebnisse

2. Auswertung anhand Prtokoll, ob Qualitätsgrad mithilfe von Ticketsystemen/ Bugtracker

   —> identifizierte Fehler in Mängelliste festgehalten

3. 
   

   	manuell	automatisch
   Ausfürhung	Mensch	Tools
   Kosten	Personal, Zeit	Lizenz
   Anwendung	explorative tests, Usability-Test	alle Teststufen

4. Systeme zur Unterstützung der Dokumentation, Bewertung und Behebung von Softwarefehlern.

1. Testergebnisse auswerten und Qualität bewerten

2. Grundlage für Entscheidung, ob Qualität erreicht

   (Z.B. Auslieferung, Quality Gate passieren oder nacharbeiten)

1. Zerlegung des Systems in logische Bestandteile

2. Separate Implementierung jeder Komponente

   —> Integration in System nach Fertigstellung

3. Prüfung auf Einhaltung Qualität während oder nach Integration

1. Isolierte Prüfen von einzelnen SW-Bestandteilen

1. Prüfung einzelner Funktionen technischer Klassen und Komponenten auf richtige Ausführung

2. Vor Zusammenführung mit bereits bestehenden Programmcode

3. möglichst große Testabdeckung der Anweisungen und Kontrollstrukturen im erstellten Programm­code

4. White-Box-Tests,

   Anweisungen, Bedingungen oder Pfade

5. Eigenschaten

   • Reproduzierbarkeit

     durch Verwendung fest def. Tesdaten

   • Unabhängigkeit

     keine Reihenfolge, jeder Test eigene Vorsorge für benötigte Vorbedingungen

   • Regressionsfähigkeit

     = Durchführung bereits bestandener Tests nach Änderung im Programmcode zum Ende einer Iteration

1. Vorgehensweise zur Erstellung von Unit-Tests, bei der die Testfälle bereits vor dem zu testenden Programmcode implementiert werden.

2. hohe Qualität und eine hohe Abdeckung des erstellten Programmcodes

3. „Testfall erstellen“ und „Programmcode erzeugen“ genau in der umgekehrten Reihenfolge

1. mindestens zwei Softwarekomponenten fertiggestellt

2. ob die Komponenten so zusammenarbeiten, wie es in der Spezifikation beschrieben wurde

3. usammenspiel der Komponenten über deren technische Schnittstellen (Funktionen, Daten)

4. Bottom-up, Top-down und By-Value vorgestellt.

   —> Unterschied in der Reihenfolge der Integration und Test von Komponenten

1. Das sind Softwarefragmente, die das Aufrufen anderer Komponenten simulieren.

2. Das sind Softwarefragmente, die das Aufrufen anderer Komponenten simulieren.

3. Wenn nicht alle Komponente für einen SW-Test fertig sind

4.

1. Integration beginnt mit den untersten, fundamentalen Modulen und arbeitet sich nach oben vor.

2. Fehler in den grundlegenden Funktionen werden früh erkannt und behoben.

3. Eine stabile, gut getestete Basis wird früh geschaffen

4. Frühe Sichtbarkeit des Gesamtsystems ist nicht gegeben.

5. Projekte, bei denen die untersten Ebenen (z. B. Datenbanken) kritisch sind und zuerst stabil sein müssen.

1. Integration beginnt mit den obersten, steuernden Modulen und arbeitet sich nach unten vor.

2. Schnittstellenfehler zwischen den Hauptkomponenten werden früh entdeckt.

3. Frühzeitig existiert ein lauffähiger Prototyp, der Feedback zur Benutzeroberfläche ermöglicht.

4. Kritische, tiefergelegte Module werden erst spät getestet.

5. Projekte, bei denen die Benutzeroberfläche und die allgemeine Struktur früh validiert werden müssen.

1. Integration basiert auf der Übergabe von Daten an Funktionen, die mit einer Kopie des Werts arbeiten.

2. Fokus liegt nicht auf der Integration von Modulen, sondern auf der korrekten Datenübergabe, um unerwünschte Nebeneffekte zu vermeiden.

3. Sicherheit, da eine Funktion den ursprünglichen Wert einer Variable nicht verändern kann.

4. Keine direkte Strategie zur Integration von Systemen. Die Überprüfung auf korrekte Datenübergabe muss gewährleistet sein.

5. Programmierung auf Modulebene, um die Datenintegrität zu gewährleisten.

Bottom-up & Top-down:

• Oft nur Idealmuster, in der Praxis selten in Reinform anwendbar.

• Zu starr, da Komponenten oft nicht wie geplant fertig werden.

• Bieten keine flexible Reaktion auf Projektrisiken

By-value

• Bietet mehr Flexibilität.

• Ermöglicht es dem Team, auf geänderte Situationen zu reagieren.

• Treiber und Dummies können bei Bedarf zum Testen erstellt werden.

• Passt sich dem tatsächlichen Projektverlauf an.

1. Zweck:

   Ermöglicht anderen Entwicklungsteams, ihre eigenen Komponenten zu testen, bevor die echte Komponente fertig ist.

2. Vorteile:

   • Frühe Tests: Tests können jederzeit durchgeführt werden, ohne auf die Fertigstellung der Original-Komponente warten zu müssen.

   • Aktualität: Das verantwortliche Entwicklungsteam pflegt den Dummy, sodass er immer dem aktuellen Entwicklungsstand und den Schnittstellen-Änderungen entspricht.

   • Flexibilität: Dummies können sowohl als Treiber (um andere Komponenten zu testen) als auch als Dummies (als Ersatz für noch nicht fertige Komponenten) eingesetzt werden.

1. System als Ganzes testen

2. Überprüfung, ob das System als Ganzes die spezifizierten Anforderungen erfüllt

3. Funktionstests, Performancetests und Lasttests

4. originalgetreue Nachbildung der Produktivumgebung des Kunden. Dazu zählen neben der …

   • … Hardware und Softwareumgebung, in der das System betrieben wird, die

   • Softwaresysteme, zu denen das zu testende System technische Schnittstellen hat, eine

   • realistische Auslastung und realistisches Nutzerverhalten ebenso wie

   • möglichst echte Datensätze.

   • originalgetreuen Datensätzen, die gleichzeitig den Vorschriften des Datenschutzes entsprechen

1. Ziel: Überprüfung, ob das Gesamtsystem die funktionalen Anforderungen aus Sicht des Anwenders erfüllt.

2. Abgrenzung: Testet nicht die Verbindung einzelner Komponenten (wie beim Integrationstest), sondern das System als Ganzes.

3. Vorgehensweise: Das System wird als Black Box betrachtet. Man prüft nur, ob die erwartete Ausgabe zur Eingabe passt, ohne die internen Abläufe zu kennen.

4. Durchführung:

   • Eingaben erfolgen über die Benutzeroberfläche oder Systemschnittstellen.

   • Umsysteme (andere Systeme, mit denen das zu testende System verbunden ist) sollen echt sein, keine Dummies.

5. Auswertung: Erfolgt anhand des sichtbaren Systemverhaltens (z. B. UI-Ausgaben, Dokumente, Datenbankänderungen oder Logdateien).

1. Ziel: Prüfen, wie sich ein System unter Belastung verhält und ob es die spezifizierten Leistungseigenschaften erfüllt.

2. Grundgedanke: Reduzierung des Risikos bei der Inbetriebnahme, da das Verhalten des Systems in der späteren Produktivumgebung simuliert wird.

3. Voraussetzungen:

   • Das System muss vollständig integriert und auf der echten Ziel-Hardware installiert sein.

   • Die Hard- und Softwareumgebung muss exakt nachgebildet werden, da schon kleine Änderungen das Ergebnis verfälschen können.

   • Die erforderliche IT-Infrastruktur (Speicher, Rechenzeit etc.) und das nötige Personal müssen verfügbar sein.

4. Service Level Agreements (SLAs): Performancetests dienen auch dazu, zu überprüfen, ob die im Servicevertrag zugesicherten Antwortzeiten oder Verfügbarkeiten eingehalten werden.

• Latenz: Die Zeit von einer Anfrage bis zur Antwort (z.B. Ladezeit nach einem Klick).

• Durchsatz: Die Verarbeitungsgeschwindigkeit von Daten (z.B. Anzahl der bearbeiteten Bestellungen pro Minute).

• Transaktionsrate: Die Verarbeitungsgeschwindigkeit von komplexen Datenänderungen (z.B. Anzahl der Überweisungen pro Minute).

1. Ziel: Systemverhalten unter extrem hoher Belastung und bei begrenzten Ressourcen prüfen.

2. Methoden:

   • Ressourcenentzug: Künstliches Verringern von Arbeits- oder Festplattenspeicher, Netzwerkbandbreite oder Rechenleistung.

   • Lasterzeugung: Simulation von sehr vielen gleichzeitigen Nutzern, großen Datenmengen oder Transaktionen.

3. Zweck:

   • Beobachten, wie das System auf Überlast reagiert.

   • Feststellen, ob es zu Datenverlusten oder Inkonsistenzen kommt.

   • Prüfen, ob sich das System nach dem Hinzufügen von Ressourcen wieder stabilisiert.

4. Wichtige Erkenntnisse:

   • Ergebnisse liefern Indikatoren, die später für das Monitoring im laufenden Betrieb genutzt werden können.

5. Erforderliche Werkzeuge:

   • Lasttests erfordern zwingend den Einsatz spezieller Testwerkzeuge, besonders zur Simulation vieler Nutzer.

   • Die Einrichtung dieser Tools ist oft ein eigenes kleines Projekt.

• Sicherheitstest (Schützt vor Cyberangriffen

• Usability-Test (Benutzerfreundlichkeit)

• Wiederinbetriebnahme (Stellt System nach Ausfall wieder her)

1. Testfälle, die bereits erfolgreich durchgeführt worden sind und nach einer Anpassung des Systems erneut durchgeführt werden

2. evolutionäre SW-Prozess, bei jedem neuen Release

3. Automatisisierung, Dokumentation

1. fertige System beim Auftraggeber installiert und unter den tatsächlichen Betriebsbedingungen getestet

2. System aus Kundensicht die vertraglich vereinbarten Leistungs­merkmale aufweist

3. Durchführung durch eine andere Organisation als die, die das System entwickelt hat

4. Annahme oder Ablehnung