Experten-System-Prompt für Senior-API-Tests

# API-Tester – Testplan & Aufgabenliste ## Kontext - **API-Endpunkte**: Nicht spezifiziert – Annahme: REST-API mit CRUD-Endpunkten, Authentifizierung, Webhooks und Datei-Upload. - **Architektur**: Nicht spezifiziert – Annahme: Microservices hinter Load Balancer, mit Datenbank, Cache und Message Queue. - **Testziele**: Produktionsreife validieren – Performance, Last, Verträge, Resilienz, Sicherheit, Observability. - **Aktuelle Baselines**: Nicht verfügbar – müssen durch Baseline-Tests etabliert werden. - **Ziel-SLAs**: p95 Latenz < 500ms für Leseoperationen, Fehlerquote < 0,1% (5xx), Durchsatz > 1000 RPS pro Instanz (leseintensiv). - **Testumgebung**: Staging-Umgebung mit Produktionstopologie (LB, DB, Cache). Begrenzte Ressourcen – Tests müssen priorisiert werden. --- ## API-Testplan ### 1. Performance-Profiling - [ ] **APIT-PLAN-1.1 [Baseline-Performance-Profil]**: - **Typ**: Performance - **Ziel**: Alle kritischen Endpunkte (GET, POST, PUT, DELETE) - **Erfolgskriterium**: p50/p95/p99 Latenz erfasst; CPU/Memory-Basiswerte dokumentiert - **Tools**: k6, APM (z.B. New Relic), `top`/`htop` - [ ] **APIT-PLAN-1.2 [N+1-Query-Analyse]**: - **Typ**: Performance - **Ziel**: Datenbankabfragen aller Endpunkte - **Erfolgskriterium**: Keine N+1-Queries identifiziert; ineffiziente Abfragen dokumentiert - **Tools**: APM Query Analyzer, PostgreSQL `EXPLAIN ANALYZE` - [ ] **APIT-PLAN-1.3 [Cache-Effektivitätstest]**: - **Typ**: Performance - **Ziel**: Cache-fähige Endpunkte (GET) - **Erfolgskriterium**: Cache-Hit-Rate > 80%; Latenzverbesserung quantifiziert - **Tools**: k6, Cache-Statistiken (Redis `INFO`) ### 2. Last- und Stresstests - [ ] **APIT-PLAN-2.1 [Ramp-Up-Test]**: - **Typ**: Last - **Ziel**: Gesamte API - **Erfolgskriterium**: Bruchpunkt identifiziert (Fehlerrate > 1%); Ressourcenengpässe dokumentiert - **Tools**: k6 mit Staging-Profil - [ ] **APIT-PLAN-2.2 [Spike-Test]**: - **Typ**: Last - **Ziel**: Gesamte API - **Erfolgskriterium**: 10x Lastanstieg überlebt; Erholungszeit < 5 Minuten - **Tools**: k6 mit Spike-Profil - [ ] **APIT-PLAN-2.3 [Soak-Test]**: - **Typ**: Last - **Ziel**: Gesamte API - **Erfolgskriterium**: 4 Stunden Dauerlast ohne Speicherleck oder Leistungsabfall - **Tools**: k6 mit Soak-Profil, Memory-Monitoring ### 3. Vertrags- und Integrationstests - [ ] **APIT-PLAN-3.1 [OpenAPI-Schema-Validierung]**: - **Typ**: Vertrag - **Ziel**: Alle Endpunkte - **Erfolgskriterium**: 100% Schema-Konformität; 0 Verstöße - **Tools**: Pact, Schemathesis - [ ] **APIT-PLAN-3.2 [Rückwärtskompatibilitätstest]**: - **Typ**: Vertrag - **Ziel**: API-Versionen v1, v2 - **Erfolgskriterium**: Bestehende Consumer funktionieren ohne Änderungen - **Tools**: Pact Broker, Consumer-Driven Contracts - [ ] **APIT-PLAN-3.3 [Webhook-Zustellungstest]**: - **Typ**: Integration - **Ziel**: Webhook-Endpunkt - **Erfolgskriterium**: Zustellung < 1s; Retry-Logik funktioniert; Idempotenz gewährleistet - **Tools**: Postman/Newman, Webhook-Testdienst ### 4. Chaos- und Resilienztests - [ ] **APIT-PLAN-4.1 [Netzwerkfehler-Simulation]**: - **Typ**: Chaos - **Ziel**: Service-zu-Service-Kommunikation - **Erfolgskriterium**: Graceful Degradation; keine 500er-Fehlerlawine - **Tools**: Toxiproxy, Chaos Monkey - [ ] **APIT-PLAN-4.2 [Datenbankausfall-Test]**: - **Typ**: Chaos - **Ziel**: Datenbankverbindung - **Erfolgskriterium**: Connection-Pool-Erschöpfung vermieden; Fehlermeldungen aussagekräftig - **Tools**: Manuelles Stoppen des DB-Dienstes, k6 - [ ] **APIT-PLAN-4.3 [Circuit-Breaker-Test]**: - **Typ**: Chaos - **Ziel**: Downstream-Service - **Erfolgskriterium**: Zustandsübergänge (offen/halb-offen/geschlossen) korrekt; Erholung automatisch - **Tools**: Chaos Monkey, manuelle Fehlerinjektion ### 5. Sicherheitstests - [ ] **APIT-PLAN-5.1 [Injection-Test]**: - **Typ**: Sicherheit - **Ziel**: Alle Eingabe-Endpunkte - **Erfolgskriterium**: Keine SQL/NoSQL-Injection möglich; Eingaben validiert - **Tools**: OWASP ZAP, manuelle Payloads - [ ] **APIT-PLAN-5.2 [Authentifizierungs- und Autorisierungstest]**: - **Typ**: Sicherheit - **Ziel**: Alle geschützten Endpunkte - **Erfolgskriterium**: Token-Ablauf, fehlende Berechtigungen korrekt behandelt; keine Informationslecks - **Tools**: Postman, JWT-Testwerkzeuge - [ ] **APIT-PLAN-5.3 [Rate-Limiting-Bypass-Test]**: - **Typ**: Sicherheit - **Ziel**: Rate-Limiting-Mechanismus - **Erfolgskriterium**: Kein Bypass durch Header-Manipulation oder IP-Spoofing - **Tools**: k6, manuelle Header-Tests ### 6. Monitoring und Observability - [ ] **APIT-PLAN-6.1 [Metrik-Setup]**: - **Typ**: Observability - **Ziel**: Gesamte API - **Erfolgskriterium**: Metriken für Request-Rate, Fehlerrate, Latenz-Perzentile, Sättigung vorhanden - **Tools**: Prometheus, Grafana - [ ] **APIT-PLAN-6.2 [Alerting-Konfiguration]**: - **Typ**: Observability - **Ziel**: Kritische Schwellenwerte - **Erfolgskriterium**: Alerts für p95 > 500ms, Fehlerrate > 0,1%, CPU > 70% konfiguriert - **Tools**: Alertmanager, Grafana Alerting - [ ] **APIT-PLAN-6.3 [Synthetisches Monitoring]**: - **Typ**: Observability - **Ziel**: Produktionsendpunkte - **Erfolgskriterium**: Kontinuierliche Validierung alle 5 Minuten; Benachrichtigung bei Ausfall - **Tools**: Synthetisches Monitoring Tool (z.B. Pingdom, Datadog) --- ## API-Testaufgaben ### Performance-Profiling - [ ] **APIT-ITEM-1.1 [Latenz-Baseline für GET /api/v1/users]**: - **Beschreibung**: Misst p50/p95/p99 Latenz unter normaler Last - **Eingabe**: 1000 Anfragen, 50 VUs, 1 Minute - **Erwartete Ausgabe**: p95 < 100ms; Latenzverteilung dokumentiert - **Priorität**: Kritisch - [ ] **APIT-ITEM-1.2 [N+1-Query-Erkennung für GET /api/v1/orders]**: - **Beschreibung**: Analysiert DB-Abfragen auf N+1-Muster - **Eingabe**: APM-Trace für 100 Anfragen - **Erwartete Ausgabe**: Keine N+1-Queries; ineffiziente Abfragen identifiziert - **Priorität**: Hoch - [ ] **APIT-ITEM-1.3 [Cache-Test für GET /api/v1/products]**: - **Beschreibung**: Misst Cache-Hit-Rate und Latenzverbesserung - **Eingabe**: 5000 Anfragen, 100 VUs, 5 Minuten - **Erwartete Ausgabe**: Cache-Hit-Rate > 80%; Latenzverbesserung > 50% - **Priorität**: Hoch ### Last- und Stresstests - [ ] **APIT-ITEM-2.1 [Ramp-Up-Test bis 500 VUs]**: - **Beschreibung**: Erhöht Last schrittweise, um Bruchpunkt zu finden - **Eingabe**: 0 bis 500 VUs, 10 Minuten Ramp-Up - **Erwartete Ausgabe**: Bruchpunkt bei spezifischer VU-Zahl; Fehlerrate dokumentiert - **Priorität**: Kritisch - [ ] **APIT-ITEM-2.2 [Spike-Test mit 10x Last]**: - **Beschreibung**: Simuliert plötzlichen 10x Traffic-Anstieg - **Eingabe**: 50 VUs auf 500 VUs in 10 Sekunden - **Erwartete Ausgabe**: System erholt sich < 5 Minuten; keine dauerhaften Fehler - **Priorität**: Kritisch - [ ] **APIT-ITEM-2.3 [Soak-Test über 4 Stunden]**: - **Beschreibung**: Dauerlast zur Erkennung von Speicherlecks - **Eingabe**: 200 VUs, 4 Stunden - **Erwartete Ausgabe**: Kein Speicheranstieg > 10%; Latenz stabil - **Priorität**: Hoch ### Vertrags- und Integrationstests - [ ] **APIT-ITEM-3.1 [Schema-Validierung für alle GET-Endpunkte]**: - **Beschreibung**: Prüft Antworten gegen OpenAPI-Spezifikation - **Eingabe**: Automatisierte Tests gegen alle GET-Endpunkte - **Erwartete Ausgabe**: 0 Schema-Verstöße; Datentypen korrekt - **Priorität**: Kritisch - [ ] **APIT-ITEM-3.2 [Rückwärtskompatibilität für API v1]**: - **Beschreibung**: Stellt sicher, dass v1-Consumer mit v2-Backend funktionieren - **Eingabe**: Pact-Verträge von v1-Consumern - **Erwartete Ausgabe**: Alle Verträge erfüllt; keine Breaking Changes - **Priorität**: Hoch - [ ] **APIT-ITEM-3.3 [Webhook-Zustellung und Retry]**: - **Beschreibung**: Testet Webhook-Zustellung, Retry-Logik und Idempotenz - **Eingabe**: Simulierte Webhook-Ereignisse mit absichtlichen Fehlern - **Erwartete Ausgabe**: Zustellung < 1s; Retry mit Backoff; keine Duplikate - **Priorität**: Hoch ### Chaos- und Resilienztests - [ ] **APIT-ITEM-4.1 [Netzwerklatenz-Injektion]**: - **Beschreibung**: Fügt 500ms Latenz zwischen Services ein - **Eingabe**: Toxiproxy-Konfiguration für 5 Minuten - **Erwartete Ausgabe**: Timeouts korrekt behandelt; keine 500er-Fehlerlawine - **Priorität**: Hoch - [ ] **APIT-ITEM-4.2 [Datenbank-Verbindungsabbruch]**: - **Beschreibung**: Stoppt DB-Dienst für 2 Minuten - **Eingabe**: Manuelles Stoppen des DB-Containers - **Erwartete Ausgabe**: Aussagekräftige Fehlermeldungen; Connection-Pool-Erschöpfung vermieden - **Priorität**: Kritisch - [ ] **APIT-ITEM-4.3 [Circuit-Breaker-Übergang]**: - **Beschreibung**: Testet offen/halb-offen/geschlossen Zustände - **Eingabe**: Fehlerinjektion bei Downstream-Service - **Erwartete Ausgabe**: Circuit öffnet nach Schwellenwert; halb-offen nach Timeout; schließt nach Erfolg - **Priorität**: Hoch ### Sicherheitstests - [ ] **APIT-ITEM-5.1 [SQL-Injection-Versuch]**: - **Beschreibung**: Sendet bösartige SQL-Payloads an Such-Endpunkte - **Eingabe**: `' OR 1=1 --`, `'; DROP TABLE users; --` - **Erwartete Ausgabe**: Eingaben validiert; keine SQL-Fehler; keine Datenlecks - **Priorität**: Kritisch - [ ] **APIT-ITEM-5.2 [Token-Ablauf und -Validierung]**: - **Beschreibung**: Testet abgelaufene und manipulierte JWT-Tokens - **Eingabe**: Abgelaufenes Token, Token mit falscher Signatur - **Erwartete Ausgabe**: 401-Fehler; keine Daten preisgegeben - **Priorität**: Kritisch - [ ] **APIT-ITEM-5.3 [Rate-Limiting-Bypass-Versuch]**: - **Beschreibung**: Versucht Rate-Limit durch Header-Manipulation zu umgehen - **Eingabe**: `X-Forwarded-For`-Header mit wechselnden IPs - **Erwartete Ausgabe**: Rate-Limit greift weiterhin; kein Bypass möglich - **Priorität**: Hoch ### Monitoring und Observability - [ ] **APIT-ITEM-6.1 [Metrik-Export validieren]**: - **Beschreibung**: Prüft, ob alle Metriken in Prometheus ankommen - **Eingabe**: API-Anfragen generieren; Prometheus abfragen - **Erwartete Ausgabe**: Metriken für Request-Rate, Fehlerrate, Latenz vorhanden - **Priorität**: Hoch - [ ] **APIT-ITEM-6.2 [Alert-Regeln testen]**: - **Beschreibung**: Löst Alerts durch künstliche Last aus - **Eingabe**: Lastgenerierung bis p95 > 500ms - **Erwartete Ausgabe**: Alert wird ausgelöst; Benachrichtigung erfolgt - **Priorität**: Hoch - [ ] **APIT-ITEM-6.3 [Synthetisches Monitoring einrichten]**: - **Beschreibung**: Konfiguriert kontinuierliche Endpunkt-Validierung - **Eingabe**: Pingdom/Datadog-Konfiguration für kritische Endpunkte - **Erwartete Ausgabe**: Checks alle 5 Minuten; Benachrichtigung bei Ausfall - **Priorität**: Mittel --- ## Vorgeschlagene Code-Änderungen ### k6-Lasttest-Skript (`load-test.js`) ```javascript import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '2m', target: 100 }, // Ramp-Up { duration: '5m', target: 100 }, // Stabil { duration: '2m', target: 500 }, // Spike { duration: '5m', target: 500 }, // Stress { duration: '2m', target: 0 }, // Ramp-Down ], thresholds: { http_req_duration: ['p(95)<500'], http_req_failed: ['rate<0.01'], }, }; export default function () { const res = http.get('https://api.example.com/api/v1/users'); check(res, { 'Status ist 200': (r) => r.status === 200, 'Antwortzeit < 500ms': (r) => r.timings.duration < 500, }); sleep(1); } ``` ### Pact-Contract-Test (`provider-test.js`) ```javascript const { Verifier } = require('@pact-foundation/pact'); describe('API-Provider-Verifizierung', () => { it('erfüllt alle Consumer-Verträge', async () => { const verifier = new Verifier({ providerBaseUrl: 'https://api.example.com', pactBrokerUrl: 'https://pact-broker.example.com', provider: 'api-service', publishVerificationResult: true, }); await verifier.verifyProvider(); }); }); ``` ### Chaos-Test-Skript (`chaos-test.sh`) ```bash #!/bin/bash # Netzwerklatenz injizieren echo "Füge 500ms Latenz hinzu..." docker run --rm -it toxiproxy-cli create -l localhost:6666 -u localhost:6379 docker run --rm -it toxiproxy-cli toxic add -t latency -a latency=500 # 2 Minuten warten sleep 120 # Latenz entfernen docker run --rm -it toxiproxy-cli toxic remove -t latency echo "Latenz entfernt." ``` --- ## Befehle ### Lokal ```bash # k6-Lasttest ausführen k6 run load-test.js # Pact-Provider-Verifizierung npm run test:pact # Chaos-Test starten ./chaos-test.sh # Sicherheitstest mit OWASP ZAP zap-baseline.py -t https://api.example.com -r zap_report.html ``` ### CI/CD (GitHub Actions) ```yaml name: API-Tests on: [push, pull_request] jobs: load-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: k6-Lasttest run: k6 run load-test.js - name: Pact-Verifizierung run: npm run test:pact - name: Sicherheitstest run: zap-baseline.py -t https://api.example.com -r zap_report.html ``` --- ## Qualitätssicherungs-Checkliste - [ ] Alle kritischen Endpunkte haben Performance-, Vertrags- und Sicherheitstestabdeckung - [ ] Lasttestszenarien decken Baseline, Peak, Spike und Soak ab - [ ] Vertragstests validieren gegen die aktuelle API-Spezifikation - [ ] Resilienztests decken Service-Ausfälle, Netzwerkprobleme und Ressourcenerschöpfung ab - [ ] Testergebnisse enthalten quantifizierte Metriken mit Vergleich zu Ziel-SLAs - [ ] Monitoring- und Alerting-Empfehlungen sind an spezifische SLI/SLO-Schwellenwerte gebunden - [ ] Alle Testskripte sind reproduzierbar und für CI/CD-Integration geeignet