Fähigkeiten zum Testen verteilter Systeme

Zwei Fähigkeiten für KI-Coding-Agenten, die anspruchsgesteuerte Tests für verteilte und zustandsbehaftete Systeme entwerfen und ausführen. Zusammen erzeugen sie einen strukturierten Markdown-Testplan und einen Befundbericht mit 10-Zustands- Urteilen und einer expliziten Zuordnung der Schuld zu SUT / Harness / Checker / Umgebung. Ein Prüfer liest die beiden Artefakte und entscheidet, ob ausgeliefert wird; nichts anderes muss erneut ausgeführt werden.

Funktioniert mit Claude Code, Codex, Copilot CLI, Cursor, Gemini oder jedem Agenten, der Markdown liest und Shell ausführt. Die Fähigkeiten sind einfache SKILL.md-Dateien. Der Agent führt sie aus; der Plan und der Befund- bericht sind die Ausgabe.

Eine Fähigkeit entwirft den Plan. Die andere führt ihn aus. Ein Plan beginnt mit den Ansprüchen des Produkts, generiert Hypothesen, die an diese Ansprüche gebunden sind, und schreibt Szenarien, die nach dem Anspruch benannt sind, den jedes zu widerlegen versucht. Für konsistenzkritische Szenarien bindet jedes Szenario außerdem ein abstraktes Modell (register | queue | log | lock | lease | ledger | …) an ein Operation-History-Schema, einen benannten Checker und einen Nemesis mit beobachtbarer Landing-Evidenz. Der Plan endet mit einem Argument für die Angemessenheit der Abdeckung und einer konservativen Konfidenzaussage.

Warum

Der Standardansatz zum Testen verteilter und zustandsbehafteter Systeme — ein paar Integrationstests schreiben und es dabei belassen — findet nur einen kleinen Bruchteil der Fehler, die diese Systeme in der Produktion tatsächlich zum Scheitern bringen: partielle Netzwerkpartitionen, nicht-deterministische Nebenläufigkeit, Crash-Recovery, Upgrade/Rollback, Idempotenz unter Replay, zeitkritische Reihenfolge.

Diese Fähigkeiten erzwingen einen meinungsstarken Workflow, der aus dem hart erarbeiteten Wissen des Fachgebiets schöpft:

• Anspruchsgesteuert, nicht testgesteuert. Beginne mit dem, was das Produkt verspricht. Jedes Szenario widerlegt einen Anspruch unter einem Fehler. Ein Test, der nach seinem Anspruch benannt ist, ist schwerer abzuschwächen als einer, der nach seinem Setup benannt ist.
• Angemessenheit der Abdeckung ist ein Lieferergebnis. Der Plan endet mit einem Argument, dass die gewählten Szenarien ausreichen, um auszuliefern, plus einer ehrlichen Liste dessen, was unverifiziert bleibt.
• Nutze die eigene Toolbox der SUT. Die Ausführungsfähigkeit entdeckt vorhandene Tests, Runbooks und Fault-Injection-Gerüste, bevor etwas Neues erfunden wird.
• Modell + Historie + Checker, nicht nur Chaos. Für Sicherheits-, Dauerhaftigkeits-, Idempotenz-, Isolations-, Reihenfolge- oder Mitgliedschafts- Ansprüche deklariert jedes Szenario ein abstraktes Modell, ein Operation-History-Schema, einen benannten Checker (Linearizability, Serializability, Session-Consistency, No-Lost-Ack, Exactly-Once, …) und wie es mit mehrdeutigen Ergebnissen umgeht (Timeouts, unbekannte Commits, Wiederholungen). Chaos plus ein Modell und ein Checker, nicht Chaos allein.
• Keine stillen Bestehensmeldungen. Jedes PASS zitiert Oracle-Ausführungsevidenz und das Signal, das beweist, dass der Fehler tatsächlich ausgelöst wurde. Urteile kommen aus einem 10-Zustands-Set, sodass „das Chaos-Skript lief sauber durch" nicht als „der Anspruch hat den Fehler überlebt" gelesen werden kann. Jedes FAIL trägt ein SUT / Harness / Checker / Umgebungs-Schuld-Tag, damit Reproduzierer die richtige Warteschlange erreichen.

Was du bekommst

End-to-End erzeugen die beiden Fähigkeiten:

docs/testing-plans/<slug>.md        ← plan with §0–§9 (see below)
test-sessions/<slug>/<UTC>/
  ├── session-log.md                 ← timeline + toolbox + env probe
  ├── logs/                          ← per-scenario stdout/stderr
  ├── metrics/                       ← metric snapshots
  ├── artifacts/                     ← ephemeral harnesses, dumps
  └── findings/
      ├── <scenario>.md              ← per-scenario verdict (written as run proceeds)
      └── report.md                  ← summary + adequacy + confidence delta

Die Planstruktur (ein Reviewer kann dies lesen und entscheiden, ob ausgeliefert werden soll, ohne die Tests erneut auszuführen):

0. Architectural summary       — system as it actually exists
1. Scope
1b. Claims under test          — the spine
1c. Missing claims discovered  — docs ↔ code drift
2. SUT model
3. Existing test inventory     — what's already covered
4. Failure-mode hypotheses     — tied to claim IDs
5. Coverage matrix             — claim × hypothesis
6. Technique selection         — from the catalog
6b. Environment requirements
7. Scenarios                   — each named after the claim, with
                                  Target test file + Skeleton
   7.M Model / history /       — mandatory when the scenario falsifies
       checker discipline        a claim in {safety, durability,
                                  idempotency, isolation, ordering,
                                  membership}: model under test,
                                  operation-history schema, named
                                  checker, nemesis + landing evidence,
                                  ambiguous-outcome handling, reduction
                                  plan (SUT/harness/checker/env blame)
7b. Coverage adequacy argument — why these tests are enough
7c. Residual uncertainty       — what stays unverified, and why ok
7d. Confidence statement       — the reviewer's verdict
8. What this plan does NOT cover
9. Open questions / followups

Beispiel §7.M-Block (Auszug aus einem Plan)

### Scenario S3: linearizable_append_under_partition
- Falsifies if it FAILs: C1 (every acknowledged append is durable
  and linearisable), C5 (leader election completes within 5s)
- Workload: 8 clients, 70% append / 30% read, 5min, key-skew zipf
- Faults: asymmetric partition isolating current leader at T+60s
  for 30s
- Oracle: linearizability via Porcupine over per-key histories

§7.M (model / history / checker discipline)
- Model under test:    log
- Operation history:   default 11-field schema (op id, process id,
                       invoke/complete ts, op type, key, input,
                       output, error, timeout marker, node seen,
                       fault epoch). Recorded in-process + server-
                       side audit.
- Checker:             linearizability (Porcupine) per-key, then
                       no-lost-ack against final state
- Nemesis + landing:   asymmetric-partition (iptables drop one
                       direction). Landing evidence = iptables drop
                       counter goes 0 → 14,712 over the 30s window
                       AND raft log emits "leader-lost; starting
                       election" within 2s of injection.
- Ambiguous outcomes:  timeouts → timeout_marker=true, complete_ts
                       =null, treated as could-have-succeeded;
                       retries are separate ops sharing input
- Reduction plan:      if FAIL, bisect fault window + fix seed, then
                       classify SUT / harness / checker / environment
                       per references/test-case-reduction.md

Beispielzeile im Findings-Bericht

ID	Urteil	Nemesis-Landing-Nachweis	Reduktionsklasse
S3	PASS-hardening	iptables ctr 0→14.712; Raft-Neuwahl bei T+1,8s	n/a
S4	FAIL-reproducible	Partition gelandet; Elle: G2-Item-Anomalie bei Schlüssel K17	SUT
S7	INCONCLUSIVE-fault-not-proven	iptables-Regel installiert, aber Zähler blieb 0 — falsche Chain	Harness
S9	PARTIAL-model	Landing ok; Checker deckte pro Schlüssel ab, nicht schlüsselübergreifend	n/a