Postman Variable im Postman Runner nicht persistent: Ursache und Lösung

TL;DR

Variablen, die bei der manuellen Ausführung von Anfragen gesetzt werden, verschwinden oft, wenn Sie dieselbe Sammlung im Postman Collection Runner ausführen. Die Grundursache ist eine Diskrepanz im Variablenbereich: pm.environment.set verhält sich im Runner anders als im manuellen Modus, und Sammlungs-Variablen funktionieren anders als Umgebungs-Variablen. Dieser Leitfaden erklärt genau, warum dies geschieht und wie man es beheben kann, und zeigt dann, wie Apidog den Variablenbereich auf eine Weise handhabt, die weniger anfällig für versehentliche Fehlkonfigurationen ist.

Einleitung

Sie haben eine API manuell in Postman getestet. Sie führen eine Anmeldeanfrage aus, das Pre-Request-Skript setzt ein Authentifizierungs-Token, und nachfolgende Anfragen übernehmen es problemlos. Alles funktioniert.

Dann klicken Sie auf „Sammlung ausführen“. Der Runner startet, die Anmeldeanfrage ist erfolgreich, aber die nächste Anfrage schlägt mit einem 401-Fehler fehl. Das Token ist nicht vorhanden.

Dieses Szenario taucht immer wieder auf Stack Overflow und in den Postman-Community-Foren auf. Die Antworten verweisen gewöhnlich auf den Variablenbereich, erklären aber selten das vollständige Bild, warum sich das Verhalten zwischen manuellem Testen und dem Runner unterscheidet.

Um dies zu verstehen, muss man die Hierarchie des Variablenbereichs von Postman kennen. Sobald man sie klar sieht, ist die Lösung unkompliziert.

Die Variablenbereichshierarchie von Postman

Postman verfügt über fünf Variablenbereiche, aufgelistet nach höchster bis niedrigster Priorität:

1. Lokale Variablen – nur innerhalb der aktuellen Skriptausführung verfügbar, nicht über Anfragen hinweg zugänglich
2. Datenvariablen – werden aus einer CSV- oder JSON-Datei für datengesteuerte Ausführungen geladen
3. Sammlungsvariablen – auf die Sammlung bezogen, bleiben über Anfragen in dieser Sammlung erhalten
4. Umgebungsvariablen – auf die ausgewählte Umgebung bezogen, bleiben über Sammlungen hinweg erhalten
5. Globale Variablen – in jeder Sammlung in jeder Umgebung verfügbar

Wenn Postman einen Variablenverweis wie {{token}} auflöst, durchläuft es diese Liste und verwendet die erste Übereinstimmung, die es findet.

Das Problem ist, dass „beibehalten“ je nachdem, wie Sie die Sammlung ausführen, unterschiedliche Bedeutungen hat.

Warum Variablen im Collection Runner verschwinden

Der Unterschied zwischen aktuellem Wert und Initialwert

Jede Postman-Variable hat zwei Felder: „Initialwert“ und „Aktueller Wert“.

• Initialwert wird mit der Postman-Cloud synchronisiert und mit Teamkollegen geteilt.
• Aktueller Wert ist lokal auf Ihrem Rechner und wird nie synchronisiert.

Wenn Sie eine Variable programmatisch in einem Skript mit pm.environment.set('token', value) setzen, aktualisiert Postman den aktuellen Wert in Ihrer aktiven Umgebung.

Im manuellen Testmodus funktioniert dies wie erwartet, da Ihre lokalen aktuellen Werte über einzelne Anfragausführungen innerhalb derselben Sitzung hinweg bestehen bleiben.

Im Collection Runner ändert sich das Verhalten. Der Runner startet jede Ausführung vom aktuellen Zustand der Umgebung zu Beginn der Ausführung. Skripte, die Variablen während der Ausführung aktualisieren, funktionieren innerhalb dieser Ausführung korrekt. Wenn der Runner jedoch so konfiguriert ist, dass er Variablen zwischen den Ausführungen löscht, oder wenn der Initialwert leer ist und der Runner eine neue Umgebungs-Momentaufnahme verwendet, können Sie in einem Zustand enden, in dem Ihr Skript ausgeführt wird, die Variable aber nicht zu bestehen scheint.

Das Problem mit Umgebungs- vs. Sammlungsvariablen

Hier ist die häufigere Falle. Sie setzen eine Variable in einem Post-Response-Skript:

pm.environment.set('token', pm.response.json().access_token);

Dies setzt eine Variable in der aktiven Umgebung. Aber der Collection Runner hat eine Option namens „Variablenwerte beibehalten“. Wenn dieses Kontrollkästchen nicht aktiviert ist (standardmäßig ist es deaktiviert), setzt der Runner die Umgebungsvariablen nach der Ausführung auf ihre Initialwerte zurück. Jeder während der Ausführung gesetzte Wert wird verworfen.

Wenn Sie die Sammlung ohne eine ausgewählte Umgebung ausführen, schlägt pm.environment.set stillschweigend fehl. Es gibt keine Umgebung, in die geschrieben werden kann. Die Variable verschwindet.

Die Bereichsdiskrepanz zwischen manuellem und Runner-Modus

Beim manuellen Testen haben Sie typischerweise eine Umgebung ausgewählt, die über Ihre gesamte Postman-Sitzung hinweg bestehen bleibt. Wenn Sie eine Anfrage ausführen, eine Variable setzen und eine weitere Anfrage ausführen, geschieht all dies im selben persistenten Umgebungskontext.

Der Collection Runner erstellt einen separaten Ausführungskontext. Er lädt den Umgebungszustand zu Beginn, führt alle Anfragen aus und versetzt die Umgebung dann (es sei denn, Sie aktivieren „Variablenwerte beibehalten“) in ihren Zustand vor der Ausführung zurück.

Das bedeutet, dass Variablen, die von einer Anfrage im Runner gesetzt werden, für nachfolgende Anfragen im selben Durchlauf verfügbar sind, aber nicht in Ihrem Umgebungs-Panel bestehen bleiben, nachdem der Durchlauf beendet ist, es sei denn, Sie behalten sie explizit bei.

Lösungen

Lösung 1: „Variablenwerte beibehalten“ im Runner aktivieren

Im Collection Runner, bevor Sie auf Ausführen klicken:

1. Suchen Sie im Konfigurationspanel des Runners nach der Option „Variablenwerte beibehalten“.
2. Aktivieren Sie dieses Kontrollkästchen.

Dies weist den Runner an, alle Variablenänderungen nach Abschluss der Ausführung in Ihre aktive Umgebung zurückzuschreiben. Variablen, die von Skripten während der Ausführung gesetzt wurden, sind in Ihrem Umgebungs-Panel sichtbar, wenn die Ausführung abgeschlossen ist.

Wann zu verwenden: Wenn Sie möchten, dass der Runner den gemeinsamen Zustand aktualisiert, z. B. das Aktualisieren eines Authentifizierungs-Tokens, das andere Tools oder nachfolgende Ausführungen verwenden werden.

Wann nicht zu verwenden: Wenn Sie mehrere Iterationen ausführen und Variablen, die in Iteration 1 gesetzt wurden, Iteration 2 "verschmutzen" würden. In diesem Fall verwenden Sie Datendateien oder setzen Variablen explizit zu Beginn jeder Iteration zurück.

Lösung 2: Sammlungs-Variablen anstelle von Umgebungsvariablen für den Intralauf-Zustand verwenden

Wenn eine Variable nur zwischen Anfragen innerhalb derselben Sammlungs-Ausführung geteilt werden muss, verwenden Sie Sammlungs-Variablen anstelle von Umgebungsvariablen:

// In the post-response script of your login request:
pm.collectionVariables.set('token', pm.response.json().access_token);

// In the pre-request script of subsequent requests:
const token = pm.collectionVariables.get('token');

Sammlungsvariablen sind im Runner immer verfügbar, unabhängig davon, ob eine Umgebung ausgewählt ist. Sie bleiben für die Dauer der Sammlungs-Ausführung erhalten. Sie sind der richtige Bereich für Werte, die innerhalb einer einzigen Sammlung gesetzt und verwendet werden.

Lösung 3: Sicherstellen, dass eine Umgebung vor der Ausführung ausgewählt ist

pm.environment.set schlägt stillschweigend fehl, wenn keine Umgebung aktiv ist. Vor dem Ausführen der Sammlung:

1. Öffnen Sie den Collection Runner.
2. Überprüfen Sie, ob im Dropdown-Menü „Umgebung“ eine Umgebung ausgewählt ist.
3. Wenn Sie keine Umgebungsvariablen benötigen, verwenden Sie stattdessen Sammlungs-Variablen (Lösung 2).

Lösung 4: Initialwerte für Variablen verwenden, die immer existieren sollten

Wenn eine Variable wie baseUrl von der allerersten Anfrage in einem Durchlauf an verfügbar sein muss, setzen Sie sie als Initialwert in Ihrer Umgebung, nicht nur als aktuellen Wert.

Im Umgebungseditor:

• Setzen Sie das Feld „Initialwert“, nicht nur das Feld „Aktueller Wert“.
• Der Initialwert ist das, was der Runner als Startzustand verwendet.

Wenn nur der aktuelle Wert gesetzt ist und der Runner keinen Zugriff auf Ihre lokalen aktuellen Werte hat (z. B. ein Teamkollege, der die Sammlung ausführt, oder ein Newman/Apidog CLI-Lauf), startet die Variable leer.

Lösung 5: Debuggen mit Konsolenprotokollierung

Fügen Sie console.log zu Ihren Pre-Request- und Post-Response-Skripten hinzu, um genau zu sehen, was passiert:

// Pre-request script
console.log('token before request:', pm.collectionVariables.get('token'));
console.log('environment token:', pm.environment.get('token'));

Öffnen Sie die Postman-Konsole (Ansicht > Postman-Konsole anzeigen), bevor Sie die Sammlung ausführen. Die Protokolle zeigen Ihnen genau, aus welchem Bereich jede Variable gelesen wird und welchen Wert sie bei jedem Schritt enthält.

Wie Apidog den Variablenbereich handhabt

Apidog verwendet dieselbe Bereichshierarchie: global, Umgebung, Sammlung und lokal. Der Hauptunterschied liegt in der Benutzeroberfläche.

In Apidogs Variablen-Editor werden Initial- und aktuelle Werte mit expliziten Beschriftungen und Farben angezeigt. Die Oberfläche macht es schwieriger, versehentlich nur den aktuellen Wert zu setzen. Wenn ein Skript eine Variable mit pm.environment.set setzt (was Apidog zur Postman-Kompatibilität unterstützt), aktualisiert sich das Umgebungs-Panel visuell in Echtzeit, sodass Sie die Änderung verfolgen können.

Apidogs Test-Runner setzt Variablenwerte zwischen den Schritten auch nicht zurück, es sei denn, Sie konfigurieren ihn explizit dazu. Das Standardverhalten ist, den Variablenzustand über Anfragen in einem Durchlauf hinweg zu bewahren, was dem entspricht, was die meisten Entwickler vom manuellen Testen erwarten.

Für Teamszenarien bedeutet Apidogs „Local-First“-Modell, dass Umgebungsvariablen auf der Festplatte gespeichert werden. Es gibt keine Cloud-Synchronisierung, die Ihre aktuellen Werte zwischen den Ausführungen überschreibt.

Zusammenfassung häufiger Fehler

Häufig gestellte Fragen (FAQ)

Warum funktioniert pm.environment.set im manuellen Modus, aber nicht im Runner?Im manuellen Modus haben Sie eine persistente Umgebungssitzung. Im Runner wird die Umgebung zu Beginn der Ausführung geladen und standardmäßig am Ende zurückgesetzt. Skripte, die während der Ausführung Variablen setzen, funktionieren immer noch für nachfolgende Anfragen in diesem Durchlauf, aber die Änderungen bleiben nicht in Ihrer Umgebung bestehen, es sei denn, „Variablenwerte beibehalten“ ist aktiviert.

Was ist der Unterschied zwischen pm.environment.set und pm.collectionVariables.set?pm.environment.set schreibt in die aktive Umgebung, die von allen Sammlungen, die diese Umgebung nutzen, geteilt wird. pm.collectionVariables.set schreibt in einen Bereich, der an die spezifische Sammlung gebunden ist. Für Werte, die nur innerhalb eines Sammlungs-Durchlaufs relevant sind, sind Sammlungs-Variablen geeigneter und erfordern keine ausgewählte Umgebung.

Tritt dieses Problem auch in Newman auf?Ja. Newman hat dasselbe Bereichsmodell. Standardmäßig startet Newman jede Ausführung mit den Initialwerten der exportierten Umgebung und behält Änderungen nach der Ausführung nicht bei, es sei denn, Sie verwenden das Flag --export-environment, um den endgültigen Umgebungszustand in eine Datei zu schreiben.

Was ist das Flag --export-environment in Newman?Es weist Newman an, den endgültigen Zustand der Umgebung, einschließlich aller Werte, die von Skripten während der Ausführung gesetzt wurden, nach Abschluss der Ausführung in eine JSON-Datei zu schreiben. Sie können diese Datei dann als Umgebung für die nächste Ausführung übergeben. Dies ist nützlich für Pipelines, bei denen ein Durchlauf Token generiert, die vom nächsten verwendet werden.

Unterstützt Apidog pm.collectionVariables.set?Ja. Apidog unterstützt die vollständige Postman-Skripting-API, einschließlich pm.collectionVariables.set, pm.collectionVariables.get, pm.environment.set und pm.environment.get. Von Postman migrierte Sammlungen verwenden dieselbe Skriptsyntax.

Wie übergebe ich Variablen von einer Sammlung an eine andere in Postman?Verwenden Sie globale Variablen: pm.globals.set('token', value). Globale Variablen bleiben über Sammlungen und Umgebungen hinweg für die Dauer der Postman-Sitzung bestehen. Seien Sie vorsichtig mit diesem Ansatz in Teamumgebungen, da globale Variablen nicht bereichsgebunden sind und Namenskollisionen verursachen können.

Probleme mit dem Variablenbereich in Postman sind eine der zuverlässigsten Quellen für falsch-negative Ergebnisse in API-Testsuiten. Ein Test, der manuell besteht, aber im Runner fehlschlägt, ist kein Test, dem Sie vertrauen können. Das Verständnis des Bereichsmodells, die Verwendung des richtigen Setters für den richtigen Kontext und das Aktivieren von „Variablenwerte beibehalten“ bei Bedarf sind die drei Schritte, die die meisten dieser Probleme lösen.