Werkzeuge & Abläufe · Testpaket & Fehlerfälle
Eine Anfrage. Eine Aufgabe. Auch bei Dubletten im Stapel.
Prüfen Sie nicht nur, ob eine gute Anfrage funktioniert. Prüfen Sie auch, ob eine schlechte sichtbar bleibt und eine wiederholte Kennung im selben Stapel erkannt wird. Ein erneuter Workflow-Lauf verarbeitet den ganzen Stapel erneut.
Anfrage zu Aufgabe · Version 1
Ein Fall, zwei Workflow-Dateien.
Mit synthetischen Eingaben, Soll-Ergebnissen, genauer Anleitung und dokumentierten Grenzen. Ohne Registrierung.
Gesamtes Testpaket (ZIP) ↓Die Dateien einzeln öffnen
- n8n-Workflow ↓ Importdatei
- Make-Blueprint ↓ Handverfasst; Cloudimport und Ausführung offen
- Synthetische Eingaben ↓ Keine echten Anfragen
- Erwartete Ergebnisse ↓ Sollwerte, keine Messung
- Einrichtungsanleitung ↓ Versionen und Voraussetzungen
- Cloud-Prüfprozedur ↓ Schrittfolge und Protokoll
- Tatsächlicher Testbericht ↓ Ausführung und Nachweisgrenzen
- Dateimanifest ↓ SHA-256 für Integrität
Vier Fragen an jeden Ablauf
01 · Vollständig und neu
Erzeugt eine gültige neue Anfrage genau einen Aufgabenvorschlag? Stimmen Kennung und übernommene Angaben?
Fehlsignal: Der Lauf ist erfolgreich, aber die Aufgabe fehlt oder hat andere Daten.
02 · Pflichtfeld fehlt
Bleibt die unvollständige Anfrage sichtbar, mit einem verständlichen Grund und ohne erfundene Ergänzung?
Fehlsignal: Die Eingabe verschwindet zwischen Filter und Ausgang.
03 · Dieselbe Anfrage erneut
Wird die Wiederholung innerhalb desselben Stapels erkannt, ohne eine zweite Aufgabe anzulegen? Auch ein geänderter Text mit derselben gültigen Kennung wird als Dublette behandelt. Die Quelldatei bleibt zur Prüfung erhalten.
Fehlsignal: Ein zufällig neu erzeugter Schlüssel lässt jede Wiederholung wie eine neue Anfrage aussehen.
04 · Unerwarteter Fehler
Was passiert außerhalb der vereinbarten Textfelder? n8n stoppt bei falscher Struktur ausdrücklich. Make besitzt diese zusätzlichen Eingangsguards noch nicht; eine leere Liste kann ohne Ausgabe enden. Das ist eine benannte Lücke vor einem echten Anschluss, kein bestandener gemeinsamer Test.
Fehlsignal: „Erfolgreich“ zählt nur die guten Ausgänge und verschweigt den Rest.
Erwartet ist nicht beobachtet
expected-results.json ist das Prüforakel. test-report.json beschreibt tatsächliche Ausführung. Ein unverändert passendes Schema kann keinen Make-Cloudlauf ersetzen. Lesen Sie im Bericht deshalb immer die Art des Nachweises, nicht nur einen Status.
Die Demo verarbeitet eine begrenzte Testmenge. Für echten Betrieb kommen weitere Fälle dazu: gleichzeitige Anfragen, Abbruch nach dem Anlegen der Aufgabe, fehlende Berechtigung, nicht erreichbares Ziel und erneuter Versuch. Erst deren Prüfung rechtfertigt Aussagen über den angeschlossenen Betrieb.
So prüfen Sie denselben Fall ohne Automatisierung
- Übertragen Sie die gültige Anfrage in eine Aufgabenliste mit eindeutiger Vorgangskennung.
- Suchen Sie vor einer zweiten Anlage nach dieser Kennung.
- Legen Sie unvollständige Anfragen in eine eigene Prüfliste und notieren Sie das fehlende Feld.
- Zählen Sie Eingänge und alle Ausgänge. Kein Eingang darf still verschwinden.
Bei wenigen Vorgängen kann diese Routine ausreichen. Sie liefert außerdem einen verständlichen Vergleich für den automatisierten Ablauf.
Wenn ein Download nicht öffnet
Speichern Sie die Datei über den Downloadlink. JSON-Dateien sind Textdateien; ein Browser darf sie auch anzeigen. Der Dateiname und die Endung müssen erhalten bleiben. Eine HTML-Fehlerseite mit .json-Namen ist kein Workflow. Im ZIP finden Sie denselben Stand mit Manifest. Nutzen Sie bei Abweichungen die Kontaktseite und nennen Sie Dateiname, Version und Fehlertext, ohne Zugangsdaten oder Kundendaten zu senden.
