0

開発するとき、私のチームは明らかにdevelopment私たちの環境として使用します。

自動テストを実行するときは、 を使用しますtesting。

また、テスターが機能と最終的な「ライブ」製品をチェックするためにそれぞれ使用するstagingと環境もあります。production

自動化されたテストを実行し、最終的には自動化された展開を支援するために、内部 CI サーバーをセットアップしようとしています。

CI サーバーは実際に自動テストを実行しているため、環境内で実行する必要があると考える人もいtestingます。productionただし、CIサーバーが実際に役立つためには、実際の環境のミラーにできるだけ近いモードで実行する必要があると思いproductionます（明らかに本番DBには触れません）。

CI サーバーを実行する環境として認められているものはありますか? production環境（DBが異なる）が唯一の論理的な答えのようですが、何か不足している可能性があります...

4

1 に答える 1

1

あなたが言ったようにPROD環境でテストを実行する

唯一の論理的な答えのようです

しかし、完全に真実ではありません。テストが実際の環境/アプリケーションに深刻な損傷を与え、回復オプションに直面する可能性があるというリスクがあります。結局のところ、テストの暗い面は、ソフトウェアにマイナーなバグがあるだけでなく、期待どおりに機能していないことを示したり見つけたりすることです。少なくとも、これらの「本番環境をテストしない理由」の考慮事項について考えることができます。

  • 製品が発売されると、顧客はそれに依存します。ソフトウェアが動作していることを期待する () 既にテストされている)。ライブ環境はその役割を果たし、テストをロードしないようにする必要があります。製品が誤動作した (または機能しなかった) 場合は、損傷をカバーし、ギャップを修正して問題なく動作させるために、技術チームを派遣する必要があります。これは製品コストに影響を与えただけでなく、プロジェクトの締め切りを大幅に遅らせました。これは、ベンダーの利益と次のいくつかのプロジェクトに再帰的な効果をもたらします。

  • 生産または開発チームは、最後に製品開発を完了すると、テストのために新しく開発された製品をその環境にロードする前に、テスト チーム用にこのテスト環境を作成する必要があります。

私には、あなたがどんなに

ステージング環境と本番環境もあります

それに応じて Test を使用することが不可欠です。さらに、テスト環境は、本番環境にできるだけ近づけて (構成) する必要があります。また、ある人がテストしようとしている間に、別の人がテストしていたものを壊してしまうこともあります。2 つが分離されていないと、適切なテストを行う方法がありません。

完全な回答として、STAGE環境は会社によって異なる役割を持つことができます. 1 つは、QA とシステム テスト (多くの更新/変更またはアップグレードが本番環境に移行する場合のシステムのテスト) の両方に使用される、本番環境の正確なコピーを持つ QA/STAGE 環境である可能性があることです。

アップデート：

それが私のポイントでもありました。QA 環境は、PRODのミラーである必要があります。ステージング/プロダクションへのファイルのキャッシュ/プリロードに関する問題の解決策として、ステップ前/ステップ後の.bat (仮定しましょう) ファイルを作成することが考えられます。

現在のテスト プロジェクトでは、このアプローチを使用します。前の手順では、テストの実行に必要なファイルをセットアップします (以前の実行からファイルを削除し、最新のコピー/アーティファクトをダウンロードするなど) 。事後手順では、必要なレポート ファイルを設定します。利点は、ファイルが収集され、すべての実行前に同期されることです。

関して

同じ物理ハードウェア上にない

私の場合、専用のリモート テスト サーバーをサポートしています。利点は明らかですが、考慮する必要があるのは、メンテナンス (管理) が必要になることだけです。

于 2014-10-07T05:44:11.973 に答える