Testen spezieller Systeme
In dieser Lerneinheit konzentrierst du dich auf professionelle Teststrategien für Web-Anwendungen und -Services. Du lernst verschiedene Testarten wie funktionale Tests kennen und erfährst, wie du diese in der Praxis systematisch planst und durchführst. Das Wissen ermöglicht dir, Web-Anwendungen zuverlässig auf Qualität und Funktionalität zu prüfen.
Einführung
Eine Banking-App muss auf 50 verschiedenen Smartphone-Modellen funktionieren. Ein vernetzter Herzschrittmacher darf keine Millisekunde zu spät reagieren. Und ein KI-System zur Kreditprüfung muss nicht nur korrekt, sondern auch fair entscheiden.
Jedes dieser Systeme stellt völlig unterschiedliche Anforderungen an das Testen. Standard-Testmethoden reichen hier nicht aus.
Während du bei einer Desktop-Anwendung vielleicht nur eine Umgebung testen musst, erfordert eine Mobile App Tests auf dutzenden Geräten. Ein Embedded System hat Echtzeitanforderungen, die bei Web-Apps keine Rolle spielen. Und KI-Systeme verhalten sich nicht deterministisch, sie liefern bei gleicher Eingabe nicht immer die gleiche Ausgabe.
In dieser Lerneinheit lernst du, wie du Teststrategien an die besonderen Anforderungen verschiedener Systemtypen anpasst: Web-Anwendungen, Mobile Apps, Embedded Systems, IoT-Geräte und KI-Systeme.
Lernziele
Nach dieser Lerneinheit kannst du:
- Teststrategien für Web-Anwendungen beschreiben und REST API-Tests mit Tools wie Postman durchführen
- Die Besonderheiten des Mobile Testings erklären und die Unterschiede zwischen iOS- und Android-Testing benennen
- Echtzeitanforderungen und Ressourcenbeschränkungen bei Embedded Systems und IoT-Geräten beim Testen berücksichtigen
- Die Herausforderungen beim Testen von KI/ML-Systemen verstehen und geeignete Teststrategien auswählen
- Performance- und Lasttests planen und geeignete Werkzeuge wie JMeter einsetzen
Überleitung
Von der Banking-App über den Herzschrittmacher bis zum KI-System: Jedes System hat seine eigenen Tücken beim Testen.
Wir beginnen mit Web-Anwendungen, dem häufigsten Einsatzgebiet für viele Entwickler. Hier lernst du die grundlegenden Testarten und Tools kennen, bevor wir uns spezielleren Systemen widmen.
Web-Anwendungen testen: Besondere Herausforderungen
Web-Anwendungen stellen besondere Anforderungen an das Testing. Während die Grundlagen funktionaler und nicht-funktionaler Tests aus Lerneinheit 2 weiterhin gelten, kommen hier spezifische Aspekte hinzu:
Was Web-Testing besonders macht:
| Herausforderung | Konsequenz für Tests |
|---|---|
| Verschiedene Browser | Cross-Browser-Testing nötig |
| Unterschiedliche Geräte | Responsive-Tests erforderlich |
| Client-Server-Trennung | API-Tests zusätzlich zu UI-Tests |
| Netzwerklatenz | Performance unter realen Bedingungen |
Diese Herausforderungen erfordern eine mehrschichtige Teststrategie, die UI-, API- und Performance-Tests kombiniert.
REST-API-Testing: Die Schnittstelle prüfen
Moderne Web-Anwendungen kommunizieren über REST-APIs. Diese Schnittstellen lassen sich unabhängig von der Benutzeroberfläche testen.
Typischer API-Test:
GET /api/users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer token123Erwartete Antwort:
{
"id": 123,
"name": "Max Mustermann",
"email": "max@example.com"
}API-Tests prüfen: Statuscodes (200, 404, 500), Response-Format (JSON-Struktur), Datenvalidierung und Fehlerbehandlung.
SOAP-Webservices: Das ältere Geschwister
SOAP (Simple Object Access Protocol) ist der ältere, formellere Bruder von REST. Während REST flexibel und leichtgewichtig ist, bietet SOAP strikte Verträge und eingebaute Sicherheit.
SOAP vs. REST im Vergleich:
| Aspekt | SOAP | REST |
|---|---|---|
| Format | Nur XML | JSON, XML, etc. |
| Vertrag | WSDL (strikt) | OpenAPI (optional) |
| Sicherheit | WS-Security | HTTPS + OAuth |
| Einsatz | Banken, Enterprise | Web-Apps, Mobile |
Wann SOAP? Bei hohen Sicherheitsanforderungen und wenn formale Verträge zwischen Systemen nötig sind.
Werkzeuge für Web-Testing
Für verschiedene Testarten gibt es spezialisierte Tools:
UI-Tests (Automatisierung)
- Selenium WebDriver: Browser-Automatisierung für alle gängigen Browser
- Cypress: Modernes E2E-Testing mit Live-Reload
- Playwright: Cross-Browser-Testing von Microsoft
API-Tests
- Postman: GUI für API-Entwicklung und -Tests
- REST-assured: Java-Bibliothek für API-Tests
- curl: Kommandozeilen-Tool für schnelle Tests
Sicherheitstests
- OWASP ZAP: Automatisierte Security-Scans
- Burp Suite: Proxy für manuelle Sicherheitsprüfung
Selenium WebDriver in der Praxis
Ein einfacher UI-Test mit Selenium prüft, ob ein Login funktioniert:
from selenium import webdriver
from selenium.webdriver.common.by import By
driver = webdriver.Chrome()
driver.get("https://example.com/login")
# Formular ausfüllen
driver.find_element(By.ID, "username").send_keys("testuser")
driver.find_element(By.ID, "password").send_keys("secret123")
driver.find_element(By.ID, "login-btn").click()
# Prüfen ob Login erfolgreich
assert "Dashboard" in driver.title
driver.quit()Was passiert hier? Der Test öffnet einen Browser, füllt das Login-Formular aus, klickt den Button und prüft, ob die Dashboard-Seite erscheint.
Mobile Apps testen: Eine fragmentierte Welt
Das Problem: Allein Android läuft auf tausenden verschiedenen Geräten mit unterschiedlichen Bildschirmgrößen, Prozessoren und Android-Versionen. iOS ist homogener, aber auch hier gibt es signifikante Unterschiede.
Die Fragmentierungs-Herausforderung:
| Plattform | Gerätevielfalt | OS-Versionen | Bildschirmgrößen |
|---|---|---|---|
| Android | ~24.000 Modelle | 5-6 aktive | 3.5” bis 10”+ |
| iOS | ~30 Modelle | 2-3 aktive | 4.7” bis 12.9” |
Konsequenz: Kein Team kann auf allen Geräten testen. Priorisierung nach Marktanteil und Zielgruppe ist essentiell.
Mobile-spezifische Testszenarien
Mobile Apps müssen unter Bedingungen funktionieren, die bei Desktop-Anwendungen keine Rolle spielen:
Kritische Testszenarien:
- Netzwerkwechsel: WLAN zu Mobilfunk und zurück
- Verbindungsabbrüche: Tunnel, Aufzug, schlechter Empfang
- Unterbrechungen: Anrufe, Benachrichtigungen, andere Apps
- Ressourcenknappheit: Wenig Speicher, schwacher Akku
- Offline-Modus: Funktioniert die App auch ohne Internet?
Best Practice: Diese Szenarien automatisiert testen ist schwierig. Hier hilft exploratives Testen durch erfahrene Tester, die reale Nutzungssituationen simulieren.
Mobile Testing Tools und Device Farms
Da kein Team hunderte Geräte vorhalten kann, gibt es Cloud-basierte Device Farms:
Test-Infrastruktur:
| Lösung | Typ | Einsatz |
|---|---|---|
| Appium | Open Source | Cross-Platform Automation |
| AWS Device Farm | Cloud | Echte Geräte in der Cloud |
| Firebase Test Lab | Cloud | Android + iOS mit Robo-Tests |
| BrowserStack | Cloud | Browser + Mobile Devices |
| Emulatoren | Lokal | Schnelle Entwickler-Tests |
Wichtig: Emulatoren sind schnell, aber ersetzen keine echten Geräte. Bestimmte Bugs treten nur auf realer Hardware auf (GPS, Kamera, Sensoren).
Embedded Systems und IoT: Testen an der Hardware-Grenze
Eingebettete Systeme sind Computer, die in Geräten versteckt sind: Herzschrittmacher, Autos, Waschmaschinen, Industrieroboter. Hier gelten andere Regeln als bei Web-Apps.
Was Embedded Testing besonders macht:
| Aspekt | Standard-Software | Embedded Systems |
|---|---|---|
| Fehlertoleranz | Neustart möglich | Oft fatal |
| Zugriff | Immer verfügbar | Begrenzt/keiner |
| Ressourcen | Reichlich | Stark limitiert |
| Echtzeit | Selten kritisch | Oft harte Deadlines |
| Lebensdauer | Monate | Jahre bis Jahrzehnte |
Hardware-in-the-Loop (HIL) Testing
Wenn Software direkt mit Hardware interagiert, brauchen wir spezielle Testumgebungen. Hardware-in-the-Loop (HIL) simuliert die reale Umgebung:
HIL-Prinzip:
- Echte Software läuft auf echtem Steuergerät
- Simulierte Sensoren liefern Testdaten
- Simulierte Aktoren empfangen Steuerbefehle
- Testrechner überwacht und protokolliert alles
Beispiel Motorsteuerung: Das echte Steuergerät bekommt simulierte Sensordaten (Drehzahl, Temperatur). Seine Reaktion (Einspritzung, Zündung) wird gemessen und geprüft.
HIL-Tests ermöglichen es, gefährliche oder teure Szenarien sicher zu testen, ohne echte Hardware zu beschädigen.
IoT-Sicherheit: Die unterschätzte Gefahr
Vernetzte Geräte sind attraktive Angriffsziele. Ein unsicheres IoT-Gerät kann das Einfallstor ins Heimnetzwerk sein.
Kritische Sicherheitstests für IoT:
- Kommunikation verschlüsselt? HTTPS/TLS mandatory
- Firmware-Updates signiert? Verhindert Manipulation
- Standard-Passwörter? Müssen geändert werden können
- Datenminimierung? Nur notwendige Daten sammeln
- Lokale Speicherung sicher? Verschlüsselung sensibler Daten
Berüchtigtes Beispiel: Das Mirai-Botnetz nutzte IoT-Geräte mit Standard-Passwörtern, um massive DDoS-Angriffe durchzuführen. Millionen Kameras und Router wurden zu Angriffswerkzeugen.
Embedded Debugging: JTAG und Echtzeit-Tracing
JTAG (Joint Test Action Group) ist die Standardschnittstelle für Embedded-Debugging. Sie erlaubt direkten Zugriff auf den Prozessor:
Was JTAG ermöglicht:
- Breakpoints setzen: Code anhalten und Zustand inspizieren
- Memory lesen/schreiben: RAM und Register direkt manipulieren
- Flash programmieren: Firmware auf Gerät laden
- Boundary Scan: Hardware-Fehler auf Platine finden
Echtzeit-Tracing geht noch weiter: Es zeichnet jeden Befehl auf, ohne den Code zu unterbrechen. Essentiell für zeitkritische Systeme, wo ein Breakpoint das Verhalten verfälschen würde.
KI und Machine Learning: Testen des Unvorhersehbaren
Klassisches Testen vergleicht Ist mit Soll. Bei KI-Systemen gibt es oft kein eindeutiges “Soll”, denn das System soll ja gerade Muster erkennen, die Menschen nicht explizit programmiert haben.
Die fundamentale Herausforderung:
| Klassisch | KI/ML |
|---|---|
| Deterministisch | Probabilistisch |
| Richtig/Falsch klar | Genauigkeit in Prozent |
| Fehler reproduzierbar | Verhalten variiert |
| Logik nachvollziehbar | ”Black Box” möglich |
Beispiel: Ein Bilderkennungs-Modell klassifiziert ein Bild mit 87% Konfidenz als “Katze”. Ist das richtig oder falsch? Die Antwort hängt vom Anwendungsfall ab.
ML-Metriken verstehen: Mehr als nur Genauigkeit
Accuracy (Genauigkeit) allein reicht nicht. Ein Spam-Filter mit 99% Accuracy klingt gut, aber was, wenn er alle E-Mails als “kein Spam” klassifiziert und nur 1% der E-Mails tatsächlich Spam sind?
Die wichtigsten ML-Metriken:
| Metrik | Bedeutung | Wann wichtig? |
|---|---|---|
| Precision | Wie viele positive Vorhersagen waren korrekt? | Wenn False Positives teuer sind |
| Recall | Wie viele echte Positive wurden gefunden? | Wenn False Negatives teuer sind |
| F1-Score | Harmonisches Mittel aus Precision und Recall | Balancierte Bewertung |
| AUC-ROC | Trennschärfe über alle Schwellenwerte | Klassifikationsqualität allgemein |
Bias-Testing: Fairness von KI prüfen
KI-Systeme lernen aus Daten. Sind die Trainingsdaten verzerrt, ist es das Modell auch. Das kann zu diskriminierenden Entscheidungen führen.
Typische Bias-Quellen:
- Historische Daten: Spiegeln vergangene Ungleichheiten wider
- Sampling Bias: Unterrepräsentation bestimmter Gruppen
- Label Bias: Voreingenommene menschliche Annotationen
- Feature Bias: Proxy-Variablen für geschützte Attribute
Praxisbeispiel: Ein Bewerbungs-Screening trainiert auf historischen Einstellungsdaten bevorzugt Kandidaten mit “männlichen” Lebensläufen, weil früher mehr Männer eingestellt wurden.
Test-Ansatz: Modell-Vorhersagen nach demografischen Gruppen aufschlüsseln und auf signifikante Unterschiede prüfen.
Bias-Testing ist nicht optional, sondern eine ethische und oft auch rechtliche Anforderung für KI-Systeme.
Model Drift: Wenn KI veraltet
ML-Modelle werden auf historischen Daten trainiert. Ändert sich die Welt, passen die gelernten Muster nicht mehr.
Arten von Drift:
| Drift-Typ | Beschreibung | Beispiel |
|---|---|---|
| Data Drift | Input-Verteilung ändert sich | Neue Kundengruppe |
| Concept Drift | Beziehung Input-Output ändert sich | Neues Kaufverhalten nach Krise |
| Label Drift | Definition der Zielgröße ändert sich | Neue Spam-Kategorien |
Monitoring ist Pflicht: Produktive ML-Systeme brauchen kontinuierliches Monitoring der Vorhersagequalität. Fällt die Performance unter einen Schwellenwert, muss neu trainiert werden.
Performance- und Lasttests: Grenzen ausloten
Was passiert, wenn 10.000 Nutzer gleichzeitig auf “Kaufen” klicken? Performance-Tests beantworten diese Frage, bevor es im Produktivbetrieb knallt.
Die verschiedenen Testarten:
| Test-Typ | Ziel | Fragestellung |
|---|---|---|
| Load Test | Normale Last simulieren | Wie verhält sich das System bei erwarteter Nutzung? |
| Stress Test | System überlasten | Wo ist der Bruchpunkt? |
| Spike Test | Plötzliche Lastspitzen | Wie reagiert das System auf Traffic-Bursts? |
| Soak Test | Langzeit unter Last | Gibt es Memory Leaks oder andere Degradation? |
Die Wahl des richtigen Testtyps hängt davon ab, welche Frage du beantworten willst.
Performance-Test-Tools: JMeter und Alternativen
Apache JMeter ist das Standardwerkzeug für Lasttests. Es simuliert viele gleichzeitige Nutzer und misst Antwortzeiten.
Tool-Übersicht:
| Tool | Stärke | Einsatzgebiet |
|---|---|---|
| JMeter | Vielseitig, Open Source | HTTP, JDBC, FTP, etc. |
| Gatling | Scala-basiert, CI-Integration | Entwicklerfreundlich |
| k6 | JavaScript, modern | Cloud-native Tests |
| Locust | Python, verteilt | Skalierbare Tests |
Wichtige Metriken: Response Time (Durchschnitt, 95. Perzentil), Throughput (Requests/Sekunde), Error Rate, Concurrent Users.
Die Auswahl des Tools hängt von deinem Tech-Stack und der gewünschten CI/CD-Integration ab.
Performance-Tests richtig planen
Ein Lasttest ohne Vorbereitung ist nutzlos. Diese Fragen müssen vorher geklärt sein:
Planungs-Checkliste:
- Ziele definieren: Welche Antwortzeiten sind akzeptabel? (z.B. 95% unter 200ms)
- Lastprofil erstellen: Wie viele User, welche Aktionen, zu welchen Zeiten?
- Testumgebung: Produktionsnah? Isoliert? Mit echten Daten?
- Monitoring einrichten: CPU, Memory, DB-Queries, Network I/O
- Baseline messen: Wie ist die aktuelle Performance?
Häufiger Fehler: Lasttests nur vor Release durchführen. Besser: Performance-Tests in die CI/CD-Pipeline integrieren und bei jedem Commit prüfen.
Zusammenfassung und Ausblick
Zusammenfassung
Web- und API-Testing
In dieser Lerneinheit hast du gelernt, wie sich das Testen spezieller Systeme von klassischem Software-Testing unterscheidet.
- Web-Anwendungen erfordern eine mehrschichtige Teststrategie: UI-Tests mit Selenium oder Cypress prüfen die Benutzeroberfläche, während API-Tests mit Postman die Schnittstellen validieren. Cross-Browser-Testing stellt sicher, dass die Anwendung in Chrome, Firefox und Safari gleich funktioniert.
- REST-APIs werden auf Statuscodes, Response-Format und Fehlerbehandlung geprüft. SOAP-Webservices bieten strikte Verträge über WSDL.
Mobile, Embedded und IoT
- Mobile Apps kämpfen mit Gerätefragmentierung: Android läuft auf tausenden Modellen, iOS auf etwa 30. Device Farms wie AWS Device Farm oder Firebase Test Lab ermöglichen Tests auf echten Geräten in der Cloud.
- Embedded Systems haben Echtzeitanforderungen und begrenzte Ressourcen. HIL-Testing (Hardware-in-the-Loop) simuliert Sensoren und Aktoren, um gefährliche Szenarien sicher zu testen.
- IoT-Geräte sind Sicherheitsrisiken: Das Mirai-Botnetz nutzte Geräte mit Standard-Passwörtern für DDoS-Angriffe.
KI/ML und Performance
- KI-Systeme verhalten sich probabilistisch, nicht deterministisch. Accuracy allein reicht nicht. Precision, Recall und F1-Score geben ein vollständigeres Bild. Bias-Testing prüft auf Fairness, Model Drift erfordert kontinuierliches Monitoring.
- Performance-Tests unterscheiden Load-, Stress-, Spike- und Soak-Tests. JMeter ist der Open-Source-Standard, k6 und Gatling sind moderne Alternativen.
Ausblick
In der nächsten Lerneinheit “Testmanagement und -prozesse” lernst du, wie du all diese Testarten in einen strukturierten Prozess einbettest. Du erfährst, wie Testplanung, Defect-Management und Reporting zusammenspielen und wie du Tests in CI/CD-Pipelines integrierst.