CLIは、あなたのファイアウォールの前で立ち止まる必要はありません。
かつて、ロックダウンされた企業ネットワークでは、クラウド接続型のCLIツールはそもそも動きませんでした。TestSprite CLIは企業のHTTP/HTTPSプロキシ経由でトラフィックをルーティングするように設定できるので、ファイアウォールの内側でも他の場所と同じように動作します。
すでに使っている同じCLIに組み込み済み
一度設定すれば、どこでも動く
他のCLI設定と一緒にプロキシを設定すれば、テスト生成、再実行、アーティファクトの取得など、すべてのコマンドが自動的にそこを経由するようになります。
特別なネットワーク例外は不要
CLIは、他の開発者ツールがすでに使っているのと同じ企業プロキシを経由してTestSpriteのクラウドサンドボックスに到達します。ネットワークチームやセキュリティチームが新たに承認すべきことは何もありません。
ノートPCだけでなくCIでも動く
testsprite setup --from-env --yes --agent <name>を使えばセットアップを非対話的に実行できるので、プロキシ設定は同じネットワークポリシー下で動くCIパイプラインにもそのまま引き継がれます。
認証情報は別管理のまま
プロキシ設定と、project credentialで保存されるプロジェクトの認証情報は独立しています。ネットワークを切り替えてもAPIキーを入力し直す必要はありません。
$ 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.
ネットワークポリシーに、自動化できることを決めさせない
ロックダウンされたネットワークポリシーを持つ企業の開発者は、クラウド接続型のCLIツールをまったく使えないことがよくあります — すべての発信リクエストが建物を出る前にブロックされてしまうからです。プロキシ対応があれば、TestSprite CLIはそのポリシーに例外を求めるのではなく、ポリシーの内側で動作します。
企業のファイアウォールの内側で働くチームのために
標準的な企業プロキシに対応
CLI自体のセットアップフローの中で設定されるので、IT部門がTestSpriteのためだけにインターネットへの直接経路を開放する必要はありません。
既存のCIパイプラインにそのまま収まる
testsprite setup --from-env --yes --agent <name>による非対話セットアップは、GitHub Actions、GitLab CI、あるいは同じポリシー下にあるどんなランナーにもプロキシ設定を引き継ぎます。
別途エンタープライズ版は不要
プロキシ対応は、すでにnpm install -g @testsprite/testsprite-cliでインストールした同じCLIの中にあります — 追加で申請したりライセンスを取得したりする必要はありません。
認証情報の管理と組み合わせる
project credentialを使えば、CLIがTestSpriteのクラウドサンドボックスにどうやって到達するかとは無関係に、プロジェクトごとの保存済み認証情報を管理できます。
世界中の企業から信頼されています
"TestSpriteは豊富なテストケース生成、明確な構造、読みやすいコードを提供します。また、新しいテストケースを生成して迅速に拡張できるシンプルなオンラインデバッグもサポートしています。"
"TestSpriteの自動化により、膨大な手作業を削減できています。開発者は開発プロセスの早い段階でバグを簡単に発見し、解決することができます。"
よくある質問
TestSprite CLIは企業のHTTP/HTTPSプロキシの内側でも動きますか？
動きます — プロキシ対応はCLIリリースv0.3.0で追加されました。CLIは、TestSpriteのクラウドサンドボックスに直接到達する代わりに、企業プロキシ経由でトラフィックをルーティングするように設定できます。
ロックダウンされたネットワークにいない場合、これは関係ありますか？
あなたにとっては何も変わりません — プロキシ設定はオプションです。関係があるのは、すべての発信トラフィックがインターネットに到達する前に承認済みプロキシを通過しなければならない企業の開発者たちです。
プロキシ対応によって、実際のテストの実行方法は変わりますか？
変わりません。フロントエンドテストは引き続きブラウザ経由で本番URLに対して実行され、バックエンドテストは引き続きベースURLに対して実行されます。どちらもTestSpriteのクラウドサンドボックスで、脆弱なセレクタに対するAuto-Healとともに実行されます。プロキシが変えるのは、CLIがそのサンドボックスにどうやって到達するかだけです。
このようなネットワークでCLIをどうセットアップすればいいですか？
他の場所と同じ方法です — 対話的にtestsprite setupを使うか、非対話的にtestsprite setup --from-env --yes --agent <name>を使います。後者はTESTSPRITE_API_KEY環境変数からAPIキーを読み取ります。
これはプロジェクトの認証情報の保存方法に影響しますか？
影響しません — プロキシ設定と、project credentialによる認証情報の保存は別々に扱われます。CLIがネットワークにどうやって到達するかは、プロジェクトの認証情報の管理方法を変えません。
ネットワークポリシーが、テスト自動化を止める理由にはならない。
CLIをインストールし、企業のプロキシを指定するだけで、チームがすでに頼っているのと同じテスト自動化を実行できます — セキュリティチームに例外を求めることなく。