Executing Distributed System Tests

Führt einen entworfenen Testplan für verteilte Systeme aus und bewertet jeden Lauf nach einer 10-stufigen Urteilstaxonomie

von shenli · shenli/distributed-system-testing

Funktioniert mit Setup ★ 8.0/10

Executing Distributed System Tests — Führt einen entworfenen Testplan für verteilte Systeme aus und bewertet jeden Lauf nach einer 10-stufigen Urteilstaxonomie

Was es kann

Führt einen zuvor entworfenen Testplan für verteilte Systeme gegen einen realen oder simulierten Cluster aus: entdeckt die vorhandene Test-Toolbox des SUT, steuert Workload und Fehlerinjektion, erfasst pro-Szenario Nemesis-Landing-Beweise und weist einen von zehn Urteilszuständen mit Green-but-broken- und Weak-Oracle-Audits vor jedem PASS zu. Wird ausgelöst bei „execute the plan“, „reproduce a distributed bug“, „run stability/chaos tests“, „validate a release end-to-end“ oder wenn eine Plandatei unter docs/testing-plans/ existiert. Für Grenz- und Fairness-Szenarien bewertet es jeden Oberflächenarm separat und wendet eine Downgrade-Regel an, sodass ein ungetesteter Arm nicht in einen Szenario-Pass einfließen kann.

Testbericht

SKILL.md über die GitHub API abgerufen; Frontmatter parst (name+description), und 3 im Hauptteil referenzierte Dateien gaben HTTP 200 zurück (verdict-taxonomy.md, green-but-broken-red-flags.md, findings-report-template.md). Keine fest codierten Pfade oder Sicherheitslücken; liefert gültige plugin.json/marketplace.json. Der vollständige Ausführungspfad (Steuerung der Fehlerinjektion gegen einen Live-Cluster) benötigt Docker + ein verteiltes SUT + eine entworfene Plandatei, die ich nicht bereitstellen konnte, daher habe ich den charakteristischen Urteils-/Berichtsdisziplin-Slice des Skills gemessen: Angesichts eines Grenzfallszenarios mit 4 Oberflächenarmen, von denen 2 bestanden und 2 nie erreicht wurden, nannte meine Baseline es „PASS (with caveats), nothing blocks shipping“, während die Befolgung der Downgrade-Regel pro Arm des Hauptteils „PARTIAL-surface, NOT a pass, should NOT ship“ plus eine Oberflächenabdeckungstabelle erzwang — genau der gefaltete Oberflächenfehler, den der Skill zu verhindern behauptet (exec_baseline.md vs exec_skill.md).

Getestet am: 2026-07-31 · Claude Code 2.x (agent harness)

Installation

git clone --depth 1 https://github.com/shenli/distributed-system-testing.git /tmp/executing-distributed-system-tests-src
mkdir -p ~/.claude/skills
cp -R /tmp/executing-distributed-system-tests-src/skills/executing-distributed-system-tests ~/.claude/skills/executing-distributed-system-tests
# Plugin-marketplace alternative: /plugin marketplace add shenli/distributed-system-testing  then install the 'distributed-testing-skills' plugin (installs both design + execute skills)
# To ACTUALLY RUN a plan end-to-end you additionally need, none of which the skill bundles:
#   - a plan file produced by the paired 'designing-distributed-system-tests' skill (the skill halts if oracles/budget tiers are missing)
#   - a distributed system-under-test repo to run against
#   - container + fault-injection tooling: docker/podman + compose, iptables/tc/netem, optionally toxiproxy/libfaketime

Befehle & Beispiel-Prompts

/executing-distributed-system-testsFührt einen entworfenen Testplan für verteilte Systeme aus und bewertet jeden Lauf nach einer 10-stufigen Urteilstaxonomie

Skills reagieren auf normale Anfragen — keine Slash-Befehle nötig. Nach der Installation aktivieren Prompts wie diese den Skill (auf Englisch):

Execute the test plan against the staging cluster
Reproduce this distributed bug with chaos testing
Run tenant isolation tests before this release

Vollständiger Testbericht (Englisch) →