Testen von Softwaresystemen - Exam

Aufgabe 1)

Context:Die Definition und die Ziele des Softwaretestens bilden die Grundlage für das Testen von Softwaresystemen. Dabei steht der systematische Prozess zur Evaluierung der Qualität und Funktionsweise der Software im Vordergrund. Zu den Hauptzielen gehören das Erkennen von Fehlern und Mängeln, das Sicherstellen der Erfüllung der Anforderungen, die Verbesserung der Softwarequalität, die Vermeidung von Risiken sowie die Validierung und Verifikation der Software.

• Erkennen von Fehlern und Mängeln
• Sicherstellen der Erfüllung der Anforderungen
• Verbesserung der Softwarequalität
• Vermeidung von Risiken
• Validierung und Verifikation

a)

Aufgabe 1:Beschreibe den Unterschied zwischen Validierung und Verifikation im Kontext des Softwaretestens und gib ein konkretes Beispiel für jede dieser Aktivitäten.

Lösung:

Aufgabe 1:Beschreibe den Unterschied zwischen Validierung und Verifikation im Kontext des Softwaretestens und gib ein konkretes Beispiel für jede dieser Aktivitäten.Unterschied zwischen Validierung und Verifikation:

• Validierung: Validierung ist der Prozess, bei dem überprüft wird, ob ein Softwaresystem die tatsächlichen Anforderungen und Erwartungen der Endbenutzer erfüllt. Es geht darum zu prüfen, ob die richtige Software gebaut wurde, die für den beabsichtigten Zweck geeignet ist. Validierung wird typischerweise während und zum Ende des Softwareentwicklungsprozesses durchgeführt, häufig durch Aktivitäten wie Benutzertests, Beta-Tests und Pilotprojekte.
• Verifikation: Verifikation ist der Prozess, bei dem überprüft wird, ob das Softwaresystem korrekt gemäß den spezifizierten Anforderungen und technischen Designs implementiert wurde. Es geht darum zu prüfen, ob die Software richtig gebaut wurde, also ob sie den festgelegten Spezifikationen entspricht. Verifikation erfolgt durch Inspektionen, Durchsichten, Walkthroughs und Testmethoden wie Unit-Tests, Integrationstests und Systemtests.

• Beispiel für Validierung: Ein Unternehmen entwickelt eine neue mobile App für Online-Banking. Nach der Implementierung lädt es eine Gruppe von realen Nutzern ein, die App im Rahmen eines Beta-Tests zu verwenden. Durch das Sammeln von Feedback und Beobachten, wie Nutzer mit der App interagieren, stellt das Unternehmen fest, ob die App die Bedürfnisse und Erwartungen der Benutzer erfüllt und benutzerfreundlich ist.
• Beispiel für Verifikation: Bei der Entwicklung einer neuen Software für die Buchhaltung werden während der Implementierungsphase Unit-Tests durchgeführt, um zu überprüfen, ob jede Funktion und jedes Modul der Software gemäß den Spezifikationen richtig funktioniert. Zum Beispiel wird ein Testskript erstellt, um sicherzustellen, dass die Funktion zur Berechnung der Mehrwertsteuer den korrekten Betrag für verschiedene Eingabewerte liefert.

b)

Aufgabe 2:Angenommen, Du leitest das Testteam eines Projekts zur Entwicklung einer neuen Banking-App. Eine der Hauptfunktionen ist die Durchführung sicherer Online-Transaktionen. Skizziere einen Testplan, der die folgenden Ziele adressiert:

• Erkennen von Fehlern und Mängeln in der Transaktionsverarbeitung
• Sicherstellen, dass die Sicherheitsanforderungen erfüllt werden
• Vermeidung von Risiken im Zusammenhang mit Datensicherheit

Lösung:

Aufgabe 2:Angenommen, Du leitest das Testteam eines Projekts zur Entwicklung einer neuen Banking-App. Eine der Hauptfunktionen ist die Durchführung sicherer Online-Transaktionen. Skizziere einen Testplan, der die folgenden Ziele adressiert:

• Erkennen von Fehlern und Mängeln in der Transaktionsverarbeitung
• Sicherstellen, dass die Sicherheitsanforderungen erfüllt werden
• Vermeidung von Risiken im Zusammenhang mit Datensicherheit

• Functional Testing: Führe Tests durch, um sicherzustellen, dass alle Transaktionsprozesse (wie Überweisungen, Zahlungen und Saldenabfragen) korrekt funktionieren. Dies umfasst Testfälle für verschiedene Transaktionsszenarien wie erfolgreiche Transaktionen, fehlgeschlagene Transaktionen (z.B. bei unzureichendem Kontostand) und Transaktionen mit ungültigen Daten.
• Boundary Value Analysis: Teste die Transaktionsprozesse an den Grenzwerten (z.B. maximale und minimale Transaktionsbeträge), um sicherzustellen, dass das System auch an den Randwerten korrekt funktioniert.
• Performance Testing: Führe Belastungstests (Load Testing) und Stresstests (Stress Testing) durch, um zu überprüfen, ob das System Transaktionen auch unter hoher Last und extremen Bedingungen korrekt und effizient verarbeitet.

• Security Testing: Überprüfe die Einhaltung der Sicherheitsanforderungen durch Tests wie Penetrationstests (Penetration Testing) und Schwachstellenscans (Vulnerability Scanning), um potenzielle Sicherheitslücken in der Transaktionsverarbeitung zu identifizieren und zu beheben.
• Access Control Testing: Teste die Zugriffskontrollen (z.B. Benutzerrollen und Berechtigungen) um sicherzustellen, dass nur autorisierte Benutzer Transaktionen durchführen oder darauf zugreifen können.
• Encryption Testing: Stelle sicher, dass alle sensiblen Daten während der Transaktionsverarbeitung (z.B. Zahlungsinformationen, Kontodaten) verschlüsselt werden. Teste die Implementierung der Verschlüsselungsmethoden (z.B. TLS/SSL) und überprüfe, ob die Daten sowohl bei der Übertragung als auch im Ruhezustand sicher sind.

• Data Privacy Testing: Überprüfe, ob die Anwendung die Datenschutzrichtlinien und -anforderungen einhält, insbesondere hinsichtlich der Verarbeitung, Speicherung und Übertragung von personenbezogenen Daten der Nutzer.
• Backup and Recovery Testing: Teste die Backup- und Wiederherstellungsmechanismen (Recovery Testing), um sicherzustellen, dass alle Transaktionsdaten im Falle eines Systemausfalls oder Datenverlusts zuverlässig wiederhergestellt werden können.
• Audit Logging and Monitoring: Implementiere und teste Audit- und Protokollierungsmechanismen (Logging), um sicherzustellen, dass alle Transaktionen und sicherheitsrelevanten Ereignisse ordnungsgemäß protokolliert und überwacht werden. Dies hilft bei der Erkennung und Analyse von Sicherheitsvorfällen.

• Peer Reviews und Code Inspections: Führe regelmäßige Überprüfungen und Inspektionen des Codes durch, um potenzielle Fehler und Schwachstellen frühzeitig zu erkennen.
• Automatisierte Tests: Verwende automatisierte Testwerkzeuge (z.B. Selenium, JUnit), um wiederholbare Testfälle und Regressionstests effizient durchzuführen und sicherzustellen, dass neue Änderungen keine bestehenden Funktionen beeinträchtigen.
• End-to-End Testing: Führe End-to-End-Tests durch, um sicherzustellen, dass die gesamte Transaktionsverarbeitung von einem Ende zum anderen korrekt und sicher funktioniert.

Aufgabe 2)

In einem mittelgroßen Softwareentwicklungsprojekt arbeitest Du an einem neuen Webanwendungssystem. Dein Team hat vier Arten von Tests spezifiziert: Unit-Tests, Integrationstests, Systemtests und Abnahmetests.

Die Module der Anwendung umfassen Authentifizierung, Benutzerprofile, Artikelverwaltung und Zahlungssysteme. Diese Module interagieren miteinander, um eine voll funktionsfähige Plattform bereitzustellen.

Du sollst sicherstellen, dass jede Art von Test für das System korrekt implementiert und durchgeführt wird.

a)

(a) Erstelle ein detailliertes Testkonzept für das Modul 'Zahlungssysteme', das alle vier Arten von Tests (Unit-Tests, Integrationstests, Systemtests und Abnahmetests) umfasst. Beschreibe für jede Testart spezifische Testszenarien und erkläre, warum diese Tests notwendig sind.

Lösung:

Testkonzept für das Modul 'Zahlungssysteme'

Um sicherzustellen, dass das Modul 'Zahlungssysteme' ordnungsgemäß funktioniert, werden vier Arten von Tests durchgeführt: Unit-Tests, Integrationstests, Systemtests und Abnahmetests. Jedes dieser Testszenarien hat einen bestimmten Zweck und ist entscheidend, um die Qualität und Zuverlässigkeit des Moduls zu gewährleisten.

• Unit-Tests:

  Unit-Tests konzentrieren sich darauf, einzelne Funktionen und Methoden innerhalb des Zahlungssystems isoliert zu testen. Diese Tests gewährleisten, dass jede Komponente unabhängig korrekt funktioniert.

  • Szenario 1: Testen der Funktion, die Zahlungen verarbeitet. Sicherstellen, dass die Funktion den richtigen Betrag abzieht und die Transaktion als erfolgreich markiert.
  • Szenario 2: Validierung der Eingabedaten. Verifizierung, dass ungültige Kartennummern und abgelaufene Kreditkarten korrekt zurückgewiesen werden.
  • Szenario 3: Testen der Fehlerbehandlungsroutinen, um sicherzustellen, dass Ausnahmen wie Netzwerkfehler ordnungsgemäß behandelt werden.
• Integrationstests:

  Integrationstests prüfen die Zusammenarbeit von verschiedenen Modulen und Komponenten des Zahlungssystems miteinander.

  • Szenario 1: Testen der Integration zwischen dem Authentifizierungsmodul und dem Zahlungssystem, um sicherzustellen, dass nur authentifizierte Benutzer Zahlungen vornehmen können.
  • Szenario 2: Überprüfung der Kommunikation zwischen der Zahlungsabwicklung und dem Benutzerprofilmodul, um sicherzustellen, dass Zahlungsinformationen korrekt im Benutzerprofil gespeichert werden.
• Systemtests:

  Systemtests evaluieren das gesamte Zahlungssystem als eine komplette Einheit, einschließlich der Schnittstellen zu anderen Systemen und Modulen.

  • Szenario 1: Durchführung einer End-to-End-Testtransaktion, um sicherzustellen, dass eine gesamte Zahlung vom Anfang bis zum Ende korrekt abgewickelt wird.
  • Szenario 2: Testen der Systemperformance bei mehreren gleichzeitigen Zahlungen, um die Belastbarkeit und Leistungsfähigkeit des Zahlungssystems zu prüfen.
  • Szenario 3: Sicherstellen, dass die Sicherheitsmechanismen zur Betrugserkennung und -verhinderung wirksam funktionieren.
• Abnahmetests:

  Abnahmetests werden durchgeführt, um sicherzustellen, dass das Zahlungssystem den Anforderungen und Spezifikationen des Kunden entspricht.

  • Szenario 1: Verifizierung der korrekten Implementierung der vom Kunden vorgegebenen Zahlungsfunktionen und -anforderungen.
  • Szenario 2: Durchführung von Usability-Tests, um sicherzustellen, dass Benutzer nahtlos und ohne Komplikationen Zahlungen durchführen können.
  • Szenario 3: Durchführung von Szenarien, die durch den Kunden spezifiziert werden, um deren Zufriedenheit und Vertrauen in das System zu gewährleisten.

Jeder dieser Tests ist notwendig, um sicherzustellen, dass das Zahlungssystem fehlerfrei, sicher und benutzerfreundlich ist. Ein gut strukturiertes Testkonzept hilft bei der Früherkennung und Behebung von Fehlern, bevor sie zu größeren Problemen führen.

b)

(b) Angenommen, bei den Integrationstests für die Module 'Benutzerprofile' und 'Artikelverwaltung' tritt ein Fehler auf, bei dem die Profile der Benutzer nicht korrekt geladen werden, wenn ein Artikel erstellt wird. Beschreibe einen möglichen Debugging-Prozess von der Fehleraufnahme bis zur Fehlerbehebung. Nutze dazu geeignete Methoden und Werkzeuge aus dem Bereich des Softwaretestens und beschreibe die notwendigen Schritte, wie Unit-Tests, Logging und Fehlerprotokollierung, bis zur erfolgreichen Integration

Lösung:

Möglicher Debugging-Prozess für den Fehler bei den Integrationstests der Module 'Benutzerprofile' und 'Artikelverwaltung'

Wenn bei den Integrationstests ein Fehler auftritt, bei dem die Benutzerprofile nicht korrekt geladen werden, wenn ein Artikel erstellt wird, sollte der Debugging-Prozess systematisch und methodisch durchgeführt werden. Hier ist ein detaillierter Prozess, um den Fehler von der Aufnahme bis zur Behebung zu verfolgen:

1. Fehleraufnahme und -analyse:
   • Sammle alle relevanten Informationen über den Fehler. Dazu gehören Fehlernachrichten, Fehlermeldungen oder ungewöhnliche Verhaltensweisen, die während der Integrationstests beobachtet wurden.
   • Stelle sicher, dass der Fehler reproduzierbar ist. Führe den Integrationstest mehrmals durch, um die genauen Bedingungen und Schritte zu identifizieren, die den Fehler auslösen.
2. Logging und Fehlerprotokollierung:
   • Analysiere die vorhandenen Log-Dateien, um Hinweise auf den Fehler zu finden. Suche nach Fehlermeldungen oder verdächtigen Einträgen in den Log-Dateien des 'Benutzerprofile'- und 'Artikelverwaltung'-Moduls.
   • Wenn das Logging nicht ausreichend ist, erweitere die Logging-Funktionalität, um detailliertere Informationen zu sammeln. Stelle sicher, dass ausreichend Log-Einträge vorhanden sind, um den Fehlerprozess nachzuverfolgen.
3. Unit-Tests:
   • Stelle sicher, dass alle relevanten Unit-Tests für die betroffenen Funktionen und Methoden vorhanden und ausführlich sind. Füge bei Bedarf zusätzliche Unit-Tests hinzu, um mögliche Fehlstellen zu überprüfen.
   • Führe die Unit-Tests durch, um sicherzustellen, dass die grundlegenden Funktionalitäten korrekt arbeiten. Suche nach möglichen Fehlern in den einzelnen Komponenten.
4. Integrationstests:
   • Isoliere den Fehlerfall, indem Du die betroffenen Integrationstests eingehender analysierst. Führe gezielte Tests durch, um den Fehler auf bestimmte Interaktionen zwischen den Modulen einzugrenzen.
   • Untersuche die Schnittstellen zwischen den Modulen 'Benutzerprofile' und 'Artikelverwaltung'. Überprüfe, ob Daten korrekt übermittelt und empfangen werden.
5. Funktionsanalyse und Debugging:
   • Verwende Debugging-Tools, um den Ablauf der betroffenen Funktionen Schritt für Schritt zu verfolgen. Dies kann mit einem Debugger wie GDB, Visual Studio Debugger oder einem anderen geeigneten Werkzeug geschehen.
   • Setze Haltepunkte an relevanten Stellen im Code, insbesondere dort, wo Daten zwischen den Modulen ausgetauscht werden.
6. Fehlerlokalisierung und -behebung:
   • Sobald der genaue Ort und die Ursache des Fehlers identifiziert sind, bearbeite den Code, um den Fehler zu beheben. Dies kann das Korrigieren von fehlerhaften Methodenaufrufen, das Bereinigen von Datenstrukturen oder die Anpassung von Schnittstellen umfassen.
   • Füge gegebenenfalls zusätzliche Testfälle hinzu, um die Korrektur zu verifizieren und sicherzustellen, dass der Fehler nicht erneut auftritt.
7. Erneute Durchführung der Tests:
   • Führe die korrigierten Unit-Tests, Integrationstests und Systemtests erneut durch, um sicherzustellen, dass der Fehler behoben ist und keine neuen Probleme eingeführt wurden.
   • Überprüfe, ob die Benutzerprofile nun korrekt geladen werden, wenn ein Artikel erstellt wird. Sichere die fehlerfreie Integration.
8. Dokumentation:
   • Dokumentiere den gesamten Debugging-Prozess, einschließlich der Fehlerbeschreibung, der durchgeführten Schritte, der verwendeten Tools und der vorgenommenen Änderungen.
   • Teile die Dokumentation mit Deinem Team, um Wissen über den Fehler und dessen Behebung zu verbreiten und zukünftige Probleme ähnlicher Art zu vermeiden.

Dieser systematische Debugging-Prozess stellt sicher, dass der Fehler effizient und effektiv behoben wird, wodurch die korrekte Funktionalität des 'Benutzerprofile'- und 'Artikelverwaltung'-Moduls gewährleistet wird.

Aufgabe 3)

Kontext: In einem Softwareprojekt verwendet ihr Team sowohl Black-Box-Testing als auch White-Box-Testing, um die Qualität des Systems zu überprüfen. Sie möchten sicherstellen, dass alle funktionalen und nicht-funktionalen Anforderungen erfüllt werden und dass der Code vollständig getestet wird.

a)

Erkläre den Hauptunterschied zwischen Black-Box-Testing und White-Box-Testing in Bezug auf ihre Testansätze und Ziele. Gehe dabei auf zwei spezifische Techniken ein, die für jede Testmethode charakteristisch sind.

Lösung:

Black-Box-Testing:

• Testansatz: Beim Black-Box-Testing konzentriert sich der Tester auf die Spezifikationen und Anforderungen der Software, ohne den inneren Code oder die Implementierungsdetails zu kennen. Der Fokus liegt darauf, Eingaben in das System zu geben und die Ausgaben zu überprüfen.
• Ziele: Das Hauptziel des Black-Box-Testings ist es, sicherzustellen, dass alle funktionalen und nicht-funktionalen Anforderungen erfüllt werden und dass das System korrekt auf verschiedene Eingaben reagiert.
• Techniken:
  • Äquivalenzklassenbildung: Diese Technik unterteilt die Eingabedaten in verschiedene Klassen, sodass eine Klasse alle möglichen Werte repräsentiert. Beispielsweise könnte man alle gültigen Eingabewerte für ein Textfeld als eine Klasse betrachten und alle ungültigen Eingabewerte als eine andere Klasse.
  • Grenzwertanalyse: Diese Technik konzentriert sich auf die Randwerte der Äquivalenzklassen. Bei einem Textfeld, das eine Eingabe zwischen 1 und 100 akzeptiert, würden die Grenzwerte 1 und 100 sowie die unmittelbaren Nachbarn, z.B. 0 und 101, getestet.

White-Box-Testing:

• Testansatz: Beim White-Box-Testing kennt der Tester den inneren Code und die Struktur der Software. Der Schwerpunkt liegt auf der Überprüfung der internen Logik, der Pfade und der Kontrollstrukturen des Codes.
• Ziele: Das Hauptziel des White-Box-Testings ist es, alle möglichen Ausführungspfade im Code zu überprüfen, um sicherzustellen, dass keine logischen Fehler oder ungetesteten Pfade vorhanden sind.
• Techniken:
  • Kontrollflussanalyse: Diese Technik analysiert den Kontrollfluss des Programms, indem sie sicherstellt, dass alle möglichen Ausführungspfade getestet werden. Dies umfasst die Überprüfung von Schleifen, Verzweigungen und bedingten Anweisungen.
  • Codeüberdeckungsanalyse: Diese Technik verwendet verschiedene Metriken wie Anweisungsüberdeckung, Zweigüberdeckung und Pfadüberdeckung, um sicherzustellen, dass jede Codezeile und jede logische Bedingung mindestens einmal getestet wird.

b)

Stelle Dir vor, das System, das Du testen sollst, hat die folgende Anforderung: 'Der Benutzer muss sich erfolgreich einloggen können, wenn er einen gültigen Benutzernamen und ein richtiges Passwort eingibt.' Beschreibe, wie Du diese Anforderung sowohl mit Black-Box-Testing als auch mit White-Box-Testing überprüfen würdest. Welche Testfälle würdest Du erstellen?

Lösung:

Überprüfung der Anforderung mittels Black-Box-Testing:

• Testansatz: Beim Black-Box-Testing werde ich die Funktion des Anmeldeprozesses anhand der Spezifikationen und Anforderungen überprüfen, ohne den zugrunde liegenden Code zu kennen.
• Testfälle:
  • Gültige Eingabe: Den Benutzernamen „validUser” und das richtige Passwort „validPass” eingeben und erwarten, dass die Anmeldung erfolgreich ist.
  • Ungültiger Benutzername: Einen ungültigen Benutzernamen „invalidUser” und ein beliebiges Passwort eingeben und erwarten, dass die Anmeldung fehlschlägt.
  • Ungültiges Passwort: Einen gültigen Benutzernamen „validUser” und ein falsches Passwort „invalidPass” eingeben und erwarten, dass die Anmeldung fehlschlägt.
  • Leeres Passwort: Einen gültigen Benutzernamen „validUser” und ein leeres Passwort eingeben und erwarten, dass die Anmeldung fehlschlägt.
  • SQL Injection: Versuchen, eine SQL Injection wie „' OR '1'='1” im Feld für den Benutzernamen oder das Passwort einzugeben, um sicherzustellen, dass das System gegen solche Angriffe geschützt ist.

Überprüfung der Anforderung mittels White-Box-Testing:

• Testansatz: Beim White-Box-Testing werde ich den inneren Code des Anmeldeprozesses untersuchen und sicherstellen, dass alle Kontrollstrukturen und Pfade korrekt funktionieren.
• Testfälle:
  • Anweisungsüberdeckung: Sicherstellen, dass jede Codezeile im Anmeldeprozess mindestens einmal ausgeführt wird. Beispiel: Benutzername und Passwort korrekt eingeben und überprüfen, ob der Code alle relevanten Überprüfungen durchführt.
  • Verzweigungsüberdeckung: Sicherstellen, dass jede logische Bedingung mindestens einmal sowohl als wahr als auch als falsch getestet wird. Beispiel: Eine Kombination aus gültigen und ungültigen Benutzernamen und Passwörtern eingeben, um alle Verzweigungen zu überprüfen.
  • Pfadüberdeckung: Sicherstellen, dass alle möglichen Pfade durch den Code mindestens einmal durchlaufen werden. Beispiel: Verschiedene Szenarien wie erfolgreiche Anmeldung, fehlerhafte Anmeldung und Eingabe von speziellen Zeichen prüfen, um alle Pfade zu testen.

c)

Angenommen, Du hast eine Funktion in Deinem Code vorliegen, die wie folgt aussieht:

int calculateSum(int a, int b) {  if (a > 0 && b > 0) { return a + b;  } else { return 0;  }}

Lösung:

Zweigüberdeckung für die Funktion calculateSum(int a, int b):

• Testansatz: Bei der Zweigüberdeckung (Branch Coverage) stellen wir sicher, dass jede mögliche Verzweigung (d.h. wahr oder falsch) der Kontrollstrukturen im Code mindestens einmal getestet wird.
• Anzahl der Testfälle: Um die Zweigüberdeckung zu erreichen, müssen wir beide Verzweigungen (die „if“- und „else“-Pfaden) abdecken. Das bedeutet, dass wir mindestens zwei Testfälle benötigen.
• Testfälle:
  • Testfall 1:
    • Werte: a = 1, b = 1
    • Erwartetes Ergebnis: Die Bedingung a > 0 && b > 0 ist wahr, daher wird a + b zurückgegeben. Das Ergebnis sollte 2 sein.
  • Testfall 2:
    • Werte: a = -1, b = 1
    • Erwartetes Ergebnis: Die Bedingung a > 0 && b > 0 ist falsch, daher wird 0 zurückgegeben. Das Ergebnis sollte 0 sein.
  • Zusätzliche Testfälle:
    • Testfall 3:
      • Werte: a = 1, b = -1
      • Erwartetes Ergebnis: Die Bedingung a > 0 && b > 0 ist falsch, daher wird 0 zurückgegeben. Das Ergebnis sollte 0 sein.
    • Testfall 4:
      • Werte: a = -1, b = -1
      • Erwartetes Ergebnis: Die Bedingung a > 0 && b > 0 ist falsch, daher wird 0 zurückgegeben. Das Ergebnis sollte 0 sein.

d)

Diskutiere, warum es sinnvoll ist, sowohl Black-Box-Testing als auch White-Box-Testing in einem Softwareentwicklungsprojekt zu kombinieren. Erwähne dabei mindestens drei Vorteile, die sich aus dieser Kombination ergeben.

Lösung:

Vorteile der Kombination von Black-Box-Testing und White-Box-Testing in einem Softwareentwicklungsprojekt:

• Umfassende Testabdeckung: Durch die Kombination von Black-Box-Testing und White-Box-Testing kann eine umfassende Testabdeckung erreicht werden. Black-Box-Testing konzentriert sich auf die externen Anforderungen und Benutzerinteraktionen, während White-Box-Testing sicherstellt, dass der interne Code und die Logik korrekt funktionieren. Dies führt zu einer gründlicheren Überprüfung des gesamten Systems.
• Erkennung verschiedener Fehlerarten: Beide Testmethoden decken unterschiedliche Arten von Fehlern auf. Black-Box-Testing kann Probleme in Bezug auf die Benutzeroberfläche, die Systemintegration und die Anforderungen aufdecken, während White-Box-Testing Fehler in der Logik, ungetestete Pfade und Schwachstellen im Code aufspürt. Die Kombination dieser Ansätze erhöht die Wahrscheinlichkeit, verschiedenste Fehler zu entdecken.
• Verbesserte Softwarequalität: Durch den Einsatz beider Testmethoden wird sichergestellt, dass sowohl funktionale als auch nicht-funktionale Anforderungen überprüft werden. Dies führt zu einer höheren Softwarequalität, da sowohl die Benutzererfahrung als auch die Codeimplementierung optimiert werden können. Die Nutzung beider Methoden bietet eine ganzheitliche Sicht auf das System und trägt dazu bei, potenzielle Schwachstellen frühzeitig zu identifizieren und zu beheben.
• Erhöhte Testeffizienz: Durch die Kombination von Black-Box- und White-Box-Testing können Tests effizienter gestaltet werden. Während Black-Box-Tests dazu verwendet werden können, generische Testszenarien abzudecken, erlaubt White-Box-Testing eine gezielte und detaillierte Prüfung von kritischen oder komplexen Codeabschnitten. Dies hilft, Ressourcen besser zu nutzen und den Testprozess zu optimieren.
• Kontinuierliche Verbesserung: Die Kombination der beiden Ansätze fördert eine Kultur der kontinuierlichen Verbesserung. Fehler, die im White-Box-Test gefunden werden, können zu besseren Testfällen im Black-Box-Test führen und umgekehrt. Diese Iterationen verbessern stetig die Teststrategie und die Qualität der Software.

Aufgabe 4)

Gegeben sei eine Softwarekomponente, die zur Berechnung des monatlichen Gehalts eines Mitarbeiters entwickelt wurde. Die Berechnung erfolgt anhand der folgenden Eingabedaten:

• Arbeitsstunden pro Monat (\textit{hours\textunderscore month}): ein Wert zwischen 0 und 160 Stunden
• Stundenlohn (\textit{hourly\textunderscore wage}): ein Wert zwischen 8 und 50 Euro
• Überstunden (\textit{overtime\textunderscore hours}): ein Wert zwischen 0 und 20 Stunden
• Überstundenzuschlag (\textit{overtime\textunderscore rate}): ein Prozentsatz zwischen 0 und 100% des Stundenlohns

Zusätzlich gibt es folgende logische Regel: Wenn die Arbeitsstunden pro Monat 160 Stunden überschreiten, zählen die zusätzlichen Stunden als Überstunden. In diesem Fall sind die Überstunden in die Berechnung einzubeziehen.

a)

Teilaufgabe a: Bilden und definieren Sie die Äquivalenzklassen für die Eingabedaten \textit{hours\textunderscore month}, \textit{hourly\textunderscore wage}, \textit{overtime\textunderscore hours} und \textit{overtime\textunderscore rate}. Achten Sie darauf, sowohl gültige als auch ungültige Äquivalenzklassen zu erstellen.

Lösung:

Teilaufgabe a: Um die Äquivalenzklassen für die Eingabedaten hours_month, hourly_wage, overtime_hours und overtime_rate zu bilden und zu definieren, müssen wir sowohl gültige als auch ungültige Eingabebereiche betrachten. Die Äquivalenzklassen stellen Gruppen von Eingabewerten dar, die das System auf ähnliche Weise behandeln sollte. Hier sind die Äquivalenzklassen für jede Eingabedaten:

• Arbeitsstunden pro Monat (hours_month):
  • Gültig:
    • 0 bis 160 Stunden (inklusive)
    • Über 160 Stunden (Überstunden)
  • Ungültig:
    • Weniger als 0 Stunden
    • Mehr als 200 Stunden (unrealistischer Wert für einen Monat)
• Stundenlohn (hourly_wage):
  • Gültig:
    • 8 bis 50 Euro (inklusive)
  • Ungültig:
    • Weniger als 8 Euro
    • Mehr als 50 Euro
• Überstunden (overtime_hours):
  • Gültig:
    • 0 bis 20 Stunden (inklusive)
  • Ungültig:
    • Weniger als 0 Stunden
    • Mehr als 20 Stunden
• Überstundenzuschlag (overtime_rate):
  • Gültig:
    • 0 bis 100% des Stundenlohns (inklusive)
  • Ungültig:
    • Weniger als 0%
    • Mehr als 100%

b)

Teilaufgabe b: Definieren Sie für jede der in Teilaufgabe a identifizierten gültigen Äquivalenzklassen jeweils einen repräsentativen Testfall. Geben Sie dabei die Eingabewerte und das erwartete Ergebnis an.

Lösung:

Teilaufgabe b: Für jede der in Teilaufgabe a identifizierten gültigen Äquivalenzklassen definieren wir nun jeweils einen repräsentativen Testfall mit den entsprechenden Eingabewerten und den erwarteten Ergebnissen:

• Arbeitsstunden pro Monat (hours_month):
  • Testfall 1:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 20 = 3,200 Euro
  • Testfall 2:
    • Eingabewerte:
      • hours_month = 170 (10 Stunden Überstunden)
      • hourly_wage = 15
      • overtime_hours = 10
      • overtime_rate = 50%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 15 + 10 * 15 * 1.5 = 2,400 + 225 = 2,625 Euro
• Stundenlohn (hourly_wage):
  • Testfall 3:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 8
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 8 = 1,280 Euro
  • Testfall 4:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 50
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 50 = 8,000 Euro
• Überstunden (overtime_hours):
  • Testfall 5:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 20 = 3,200 Euro
  • Testfall 6:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 20
      • overtime_rate = 50%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 20 + 20 * 20 * 1.5 = 3,200 + 600 = 3,800 Euro
• Überstundenzuschlag (overtime_rate):
  • Testfall 7:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 10
      • overtime_rate = 0%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 20 + 10 * 20 * 1.0 = 3,200 + 200 = 3,400 Euro
  • Testfall 8:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 10
      • overtime_rate = 100%
    • Erwartetes Ergebnis: Monatliches Gehalt = 160 * 20 + 10 * 20 * 2.0 = 3,200 + 400 = 3,600 Euro

c)

Teilaufgabe c: Definieren Sie für jede der in Teilaufgabe a identifizierten ungültigen Äquivalenzklassen jeweils einen repräsentativen Testfall. Beschreiben Sie die Eingabewerte und das erwartete Verhalten der Softwarekomponente.

Lösung:

Teilaufgabe c: Für jede der in Teilaufgabe a identifizierten ungültigen Äquivalenzklassen definieren wir nun jeweils einen repräsentativen Testfall mit den entsprechenden Eingabewerten und dem erwarteten Verhalten der Softwarekomponente:

• Arbeitsstunden pro Monat (hours_month):
  • Testfall 1:
    • Eingabewerte:
      • hours_month = -5
      • hourly_wage = 20
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass die Arbeitsstunden negativ sind und nicht negativ sein dürfen.
  • Testfall 2:
    • Eingabewerte:
      • hours_month = 220
      • hourly_wage = 20
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass die Arbeitsstunden den zulässigen Bereich von 0 bis 160 überschreiten.
• Stundenlohn (hourly_wage):
  • Testfall 3:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 5
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass der Stundenlohn unter dem zulässigen Minimum von 8 Euro liegt.
  • Testfall 4:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 55
      • overtime_hours = 0
      • overtime_rate = 50%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass der Stundenlohn den zulässigen Bereich von 8 bis 50 Euro überschreitet.
• Überstunden (overtime_hours):
  • Testfall 5:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = -3
      • overtime_rate = 50%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass die Überstunden negativ und somit nicht zulässig sind.
  • Testfall 6:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 25
      • overtime_rate = 50%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass die Überstunden die zulässigen 20 Stunden überschreiten.
• Überstundenzuschlag (overtime_rate):
  • Testfall 7:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 10
      • overtime_rate = -10%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass der Überstundenzuschlag negativ und somit nicht zulässig ist.
  • Testfall 8:
    • Eingabewerte:
      • hours_month = 160
      • hourly_wage = 20
      • overtime_hours = 10
      • overtime_rate = 120%
    • Erwartetes Verhalten: Die Software sollte eine Fehlermeldung anzeigen, dass der Überstundenzuschlag den zulässigen Bereich von 0 bis 100 Prozent überschreitet.