Schritt 1 von 6 · Testing - Praxis-Kit
Vorlage Testplan
Legt Identität, Autorisierung, Bedrohungsmodell, Instrumentierung, Fallauswahl und Abschluss eines autorisierten Assessments fest.
Diese Vorlage verwenden
Eine Vorlage ist keine Evidenz. Nur bereinigte Kennungen eintragen.
Zweck
Hält fest, was unter wessen Befugnis, gegen welche Versionen und mit welcher Evidenz getestet wird, bevor ein Stimulus eingebracht wird.
Einsatz: Vor dem ersten Lauf und erneut, sobald sich Umfang, Versionen oder Autorisierung ändern.
A. Identität des Assessments
Alle späteren Datensätze verweisen auf diese Kennungen und Versionen. Ändert sich eine Version während des Assessments, wird eine neue Planrevision angelegt, statt die Historie zu überschreiben.
| Feld | Was zu erfassen ist |
|---|---|
| Assessment-ID | Stabile Kennung, etwa ASM-2026-014. Wird in jedem Lauf-, Evidenz- und Befunddatensatz wiederverwendet. |
| Titel | Kurzer beschreibender Name von System und Ziel. |
| Verantwortliche Person | Rechenschaftspflichtige Person auf Systemseite, die die Ergebnisse erhält. |
| Technische Leitung | Verantwortlich für Ausführungsqualität und Umgang mit Evidenz. |
| Datum / Zeitfenster | Geplanter Beginn und Ende mit Zeitzone und etwaigen Sperrzeiten. |
| Umgebung | Sandbox, Staging oder originalgetreue Testumgebung; Unterschiede zur Produktion benennen. |
| System- / Anwendungsversion | Build-, Commit- oder Release-Kennung der getesteten Anwendung. |
| Modell / Anbieter / Version | Modellkennung und Versionsangabe, wie sie Anbieter oder Gateway melden. |
| Prompt- / Vorlagenversion | Version der System-Prompts, Vorlagen und Orchestrierungsanweisungen. |
| Richtlinienversion | Version der Autorisierungs-, Datenfluss- und Freigaberichtlinien, die die Kontrollen durchsetzen. |
| Tool- / Katalog- / Konfigurationsversion | Versionen von Tool-Registry, MCP-Katalog-Snapshot, Konnektoren und Retrieval-Konfiguration. |
B. Autorisierung und Governance
Tests ohne schriftliche Autorisierung liegen außerhalb dieses Toolkits. Der Plan dokumentiert die Autorisierung; er ersetzt sie nicht.
| Feld | Was zu erfassen ist |
|---|---|
| Autorisierende Person | Benannte Person mit Befugnis über die Systeme im Umfang. |
| Referenz der schriftlichen Autorisierung | Ticket-, Vertrags- oder Vermerkkennung. Das Dokument selbst am vereinbarten Ort ablegen. |
| Systeme / Komponenten im Umfang | Anwendungen, Agenten, Konnektoren, Korpora und Tools, die ausgeübt werden dürfen. |
| Systeme außerhalb des Umfangs | Ausdrückliche Ausschlüsse, einschließlich Produktionsdaten, Drittdienste und echter externer Ziele. |
| Erlaubte Aktionen | Zulässige harmlose Operationen, etwa das Ändern eines Labels an einem fiktiven Sandbox-Datensatz. |
| Verbotene Aktionen | Destruktive Operationen, echte Exfiltration, Nutzung von Zugangsdaten außerhalb von Testkonten, Umgehung von Monitoring, Tests gegen echte Dritte. |
| Testidentitäten / Konten | Dedizierte oder zurechenbare Test-Principals, ihre Rollen und ihre Reichweite. |
| Abbruchbedingungen | Ereignisse, die den Test sofort stoppen, etwa unerwarteter Zugriff auf echte Daten oder eine Wirkung außerhalb der Sandbox. |
| Notfallkontakt / Eskalation | Wer in welcher Reihenfolge und wie schnell zu kontaktieren ist. |
| Datenumgang / Aufbewahrung | Speicherort der Evidenz, Zugriffsberechtigte, Aufbewahrungsdauer und Löschung. |
C. Ziel und Bedrohungsmodell
| Feld | Was zu erfassen ist |
|---|---|
| Geschäfts- / Sicherheitsziel | Die Entscheidung, die das Assessment stützen soll, als Frage formuliert. |
| Relevante Testdomänen | Zutreffende Domänen aus der Testing-Methodik, etwa RAG, Agentengrenzen, Fluss und Egress. |
| Angriffsflächen | Kanäle, über die nicht vertrauenswürdige Inhalte den modellsichtbaren Kontext erreichen. |
| Vertrauensgrenzen | Wo Inhalte ihre Vertrauensstufe wechseln und welche Komponente darüber entscheidet. |
| Principals | Nutzer, Dienstidentitäten und Agenten, unter deren Befugnis Aktionen laufen. |
| Ressourcen | Datensätze, Dateien, Postfächer oder Speicher, die Aktionen lesen oder ändern können. |
| Tools | Aufrufbare Fähigkeiten, ihre Parameter und Nebenwirkungen. |
| Ziele | Wohin Daten abfließen können: Netzwerkendpunkte, Nachrichten, gerenderte Links, Dateien. |
| Sensible Datenklassen | Klassen, die die Kontrollen schützen müssen; in der Sandbox Testdaten jeder Klasse verwenden. |
| Erwartete deterministische Kontrollen | Anwendungseigene Kontrollen, die unabhängig von der Modellausgabe entscheiden, etwa Autorisierung, Flussrichtlinie, Egress-Allowlist und Freigabebindung. |
D. Evidenz- und Instrumentierungsplan
Vor dem Test festlegen, welche Datensätze maßgeblich sind. Fehlt eine erforderliche Quelle, ist Nicht schlüssig einzuplanen, statt Modellaussagen als Ersatz zu nutzen.
| Feld | Was zu erfassen ist |
|---|---|
| Erforderliche Logs | Anwendungs-, Orchestrierungs-, Kontrollentscheidungs-, Tool-Gateway- und Anbieter-Audit-Logs für jede Evidenzstufe. |
| Korrelations-IDs | Wie ein einzelner Lauf über Komponenten verfolgt wird: Request-, Trace- oder Konversationskennungen. |
| Zeitstempel / Zeitsynchronisation | Zeitquelle, Zeitzone und zulässige Abweichung zwischen Systemen. |
| Audit-Quelle von Anbieter / Anwendung | Maßgebliches System für den nachgelagerten Zustand, etwa das Audit-Log des Sandbox-Datenspeichers. |
| Speicherort der Evidenz | Zugriffsgeschützter Speicher für rohe und normalisierte Evidenz. |
| Maßgebliche Evidenz für nachgelagerte Wirkung | Was Stufe 7 für dieses System konkret belegt, etwa ein Zustand aus dem Datenspeicher, keine Modellaussage. |
E. Testauswahl
| Feld | Was zu erfassen ist |
|---|---|
| Ausgewählte PI-TST-Fälle | Fall-IDs aus der Bibliothek oder lokale Fall-IDs, erstellt mit der Testfallvorlage. |
| Lokale Anpassungen | Änderungen an Ziel, Orakel, Fixtures oder Bestehenskriterien mit Begründung. |
| Positivkontrollen | Harmlose Operationen im Umfang, die gelingen müssen, damit eine Umsetzung, die alles ablehnt, nicht besteht. |
| Anzahl kontrollierter Läufe | Mindestens drei Läufe mit frischer Sitzung pro Stimulus, wenn Modelleinfluss Teil des Ziels ist. |
| Reihenfolge / Abhängigkeiten | Abfolge von Baseline, Positivkontrolle, Stimulus und Varianten; Zurücksetzen zwischen Läufen. |
F. Berichterstattung und Abschluss
| Feld | Was zu erfassen ist |
|---|---|
| Verantwortlich für Befunde | Wer Befunddatensätze schreibt und pflegt. |
| Verantwortlich für Behebung | Wer Korrekturen auf Systemseite verantwortet. |
| Kriterien für den Nachtest | Welche Evidenz einen Befund schließt, festgehalten im Regressionstest-Protokoll. |
| Verantwortlich für Restrisiko | Wer verbleibendes Risiko schriftlich akzeptiert. |
| Freigabe | Namen, Daten und freigegebene Planrevision. |
Minimaler tragfähiger Plan
Für kleine Assessments sind diese Felder die Untergrenze. Darunter liegt kein Plan, den eine unabhängige Prüfung nachvollziehen könnte.
| Feld | Warum es nicht entfallen darf |
|---|---|
| Assessment-ID und Versionen | Ohne Versionen sind Ergebnisse weder reproduzierbar noch nachtestbar. |
| Referenz der schriftlichen Autorisierung und Umfang | Legt fest, was überhaupt berührt werden darf. |
| Verbotene Aktionen und Abbruchbedingungen | Hält den Test sicher, wenn Unerwartetes passiert. |
| Ziel und erwartete deterministische Kontrolle | Gibt jedem Fall ein entscheidbares Orakel. |
| Maßgebliche Evidenzquelle für nachgelagerte Wirkung | Verhindert, dass Modellaussagen als Beleg gelten. |
| Ausgewählte Fälle mit Positivkontrollen | Verhindert, dass alles ablehnende Umsetzungen bestehen. |
| Verantwortliche für Befunde und Restrisiko | Stellt sicher, dass Ergebnisse zu einer Entscheidung führen. |
So wird diese Vorlage genutzt
- Zuerst die Abschnitte A und B ausfüllen und freigeben lassen, bevor Stimuli entworfen werden.
- Abschnitt C aus der realen Architektur ableiten, nicht aus einem generischen Diagramm.
- Abschnitt D als Vorbedingung behandeln: Ist eine Stufe nicht beobachtbar, die betroffenen Fallergebnisse schon jetzt als gefährdet für Nicht schlüssig markieren.
- Den Plan mit neuer Revisionsnummer überarbeiten, sobald sich Modell-, Prompt-, Richtlinien- oder Katalogversion ändert.
Häufige Fehler
- Den Plan erst nach Testbeginn schreiben.
- Das Modell als Kontrolle angeben statt eines anwendungseigenen Entscheidungspunkts.
- Positivkontrollen weglassen, sodass ein Ergebnis, bei dem alles blockiert wird, wie Erfolg aussieht.
- Keine maßgebliche nachgelagerte Quelle benennen und sich später auf Chatverläufe stützen.
- Den Plan als Beleg dafür werten, dass das Assessment autorisiert oder vollständig war.