Die CLI muss nicht an Ihrer Firewall enden.
Abgeschottete Unternehmensnetzwerke bedeuteten bisher, dass cloud-verbundene CLI-Tools von innen schlicht nicht funktionierten. Die TestSprite-CLI lässt sich so konfigurieren, dass sie ihren Traffic über einen HTTP/HTTPS-Proxy des Unternehmens leitet — und läuft damit hinter Ihrer Firewall genauso wie überall sonst.
Teil derselben CLI, die Sie bereits nutzen
Einmal konfiguriert, überall einsatzbereit
Richten Sie den Proxy zusammen mit dem Rest Ihrer CLI-Konfiguration ein, und jeder Befehl — Testgenerierung, Wiederholungsläufe, Artefakt-Abrufe — läuft automatisch darüber.
Keine besonderen Netzwerkausnahmen
Die CLI erreicht die Cloud-Sandbox von TestSprite über denselben Unternehmens-Proxy, den Ihre übrigen Entwickler-Tools bereits nutzen — es gibt also nichts Neues, das ein Netzwerk- oder Security-Team freigeben müsste.
Funktioniert in CI, nicht nur auf Ihrem Laptop
Das Setup kann nicht-interaktiv mit testsprite setup --from-env --yes --agent <name> ausgeführt werden, sodass die Proxy-Konfiguration sauber in CI-Pipelines übernommen wird, die unter derselben Netzwerkrichtlinie laufen.
Zugangsdaten bleiben getrennt verwaltet
Proxy-Konfiguration und gespeicherte Projekt-Zugangsdaten über project credential sind unabhängig voneinander — ein Netzwerkwechsel bedeutet also nicht, API-Keys erneut eingeben zu müssen.
$ testsprite doctor Checking CLI environment... Node.js version — OK Network connectivity — OK (via corporate proxy) TESTSPRITE_API_KEY — found $ testsprite setup --from-env --yes --agent claude Reading TESTSPRITE_API_KEY from environment... Corporate proxy detected — routing CLI traffic through it Setup complete.
Lassen Sie nicht die Netzwerkrichtlinie entscheiden, was Sie automatisieren können
Entwickler in Unternehmen mit abgeschotteten Netzwerkrichtlinien können cloud-verbundene CLI-Tools oft gar nicht nutzen — jede ausgehende Anfrage wird blockiert, bevor sie das Gebäude verlässt. Proxy-Unterstützung bedeutet, dass die TestSprite-CLI innerhalb dieser Richtlinie funktioniert, statt eine Ausnahme davon zu verlangen.
Entwickelt für Teams hinter einer Unternehmens-Firewall
Funktioniert mit Standard-Unternehmens-Proxys
Wird über den eigenen Setup-Ablauf der CLI konfiguriert, sodass die IT keinen direkten Internetzugang speziell für TestSprite öffnen muss.
Fügt sich in bestehende CI-Pipelines ein
Das nicht-interaktive Setup mit testsprite setup --from-env --yes --agent <name> übernimmt die Proxy-Konfiguration in GitHub Actions, GitLab CI oder jeden anderen Runner unter derselben Richtlinie.
Kein separates Enterprise-Build
Die Proxy-Unterstützung steckt in derselben CLI, die Sie bereits mit npm install -g @testsprite/testsprite-cli installiert haben — nichts Zusätzliches anzufragen oder zu lizenzieren.
Ergänzt die Zugangsdatenverwaltung
Nutzen Sie project credential, um gespeicherte Zugangsdaten pro Projekt zu verwalten — unabhängig davon, wie die CLI die Cloud-Sandbox von TestSprite erreicht.
Weltweit von Unternehmen geschätzt
"TestSprite bietet eine umfangreiche Testfallgenerierung, eine klare Struktur und leicht lesbaren Code. Es unterstützt auch einfaches Online-Debugging mit der Möglichkeit, schnell durch die Generierung neuer Testfälle zu erweitern."
"Die Automatisierung von TestSprite hilft uns, Tonnen manueller Arbeit zu reduzieren. Die Entwickler können Fehler im Entwicklungsprozess leichter und früher erkennen und beheben."
FAQ
Funktioniert die TestSprite-CLI hinter einem Unternehmens-HTTP/HTTPS-Proxy?
Ja — die Proxy-Unterstützung wurde mit CLI-Release v0.3.0 eingeführt. Die CLI lässt sich so konfigurieren, dass sie ihren Traffic über einen Unternehmens-Proxy leitet, statt die Cloud-Sandbox von TestSprite direkt zu erreichen.
Warum ist das relevant, wenn ich nicht in einem abgeschotteten Netzwerk arbeite?
Für Sie ändert sich nichts — die Proxy-Konfiguration ist optional. Sie ist relevant für Entwickler in Unternehmen, in denen jeglicher ausgehende Traffic erst durch einen freigegebenen Proxy laufen muss, bevor er überhaupt das Internet erreicht.
Verändert die Proxy-Unterstützung, wie Tests tatsächlich ausgeführt werden?
Nein. Frontend-Tests laufen weiterhin über einen Browser gegen eine Live-URL, und Backend-Tests laufen weiterhin gegen eine Basis-URL, beide ausgeführt in der Cloud-Sandbox von TestSprite mit Auto-Heal für brüchige Selektoren. Der Proxy ändert nur, wie die CLI diese Sandbox erreicht.
Wie richte ich die CLI in einem solchen Netzwerk ein?
Genauso wie überall sonst — interaktiv mit testsprite setup, oder nicht-interaktiv mit testsprite setup --from-env --yes --agent <name>, das Ihren API-Key aus der Umgebungsvariable TESTSPRITE_API_KEY liest.
Wirkt sich das darauf aus, wie meine Projekt-Zugangsdaten gespeichert werden?
Nein — Proxy-Konfiguration und Zugangsdatenspeicherung über project credential werden getrennt behandelt, sodass die Art, wie die CLI das Netzwerk erreicht, nichts daran ändert, wie sie die Zugangsdaten Ihres Projekts verwaltet.
Ihre Netzwerkrichtlinie sollte Ihre Testautomatisierung nicht blockieren.
Installieren Sie die CLI, richten Sie sie auf Ihren Unternehmens-Proxy aus und führen Sie dieselbe Testautomatisierung aus, auf die sich Ihr Team schon jetzt verlässt — ohne die Security-Abteilung um eine Ausnahme zu bitten.