3

私の現在のプロジェクトには、各チェックイン後に開始される 5 つの個別の自動ビルドが あり
ます

DB): ~80 分
Web サイト 2 UI1 (Selenium、UI から DB まで): ~90 分
Web サイト 2 UI2 (Selenium、UI から DB まで): ~100 分

Maven2、JUnit、および Selenium を使用しています。

統合テスト時間を大幅に短縮すると思われる 1 つの戦略は、できるだけ多くの統合テストを単体テストに移動し、単純に統合プロジェクトを使用して DB への永続性をテストすることです。

大規模なプロジェクトのビルド時間を短縮するのに役立った戦略は何ですか。

4

8 に答える 8

2

ビルド ランタイムはほぼ同じですが、セレンでは少し少ないかもしれません (ランタイムは 3x50 分程度で、firefox、つまり、opera での同じサイト テストと言えます)。私たちの解決策は、より多くの CPU を投入することでした。合計 7 つのデュアルコア ノードのクラスター化された竹の環境があります。

web-container/selenium テストとは別のボックスで selenium-rc とブラウザーを実行すると、selenium ランタイムが大幅に改善されることがわかりました。

于 2009-02-10T21:28:20.460 に答える
1

GNU makeを使用してすべてを自動化しています。プロジェクトにもよりますが、2分から30分程度かかります。

于 2009-02-10T21:30:31.563 に答える
0

チームシステム: 全部で 1 時間以内

于 2009-02-10T21:29:15.967 に答える
0

あなたのプロジェクトはいくつかのサブプロジェクトで構成されていると思います。そうでない場合は、そうなるようにコード ベースをリファクタリングすることをお勧めします。このようにして、アプリケーション全体の特定の部分のみをビルドし、個々の部分をテストしてから、作業中のサブプロジェクトのバグを解決したときに統合テストを実行することを選択できます。

于 2009-02-10T21:30:26.633 に答える
0

Hudson を使用して、少数の Windows サービス、Web サービス、および実行可能ファイルを含む大規模な C# ソリューションを構築します。MSTest.exe による約 800 程度のテストで、ビルドごとに約 12 ~ 15 分かかります。MSTest は遅いため、テストが大きな部分を占めます。

時間を短縮するために、セットアップとティアダウンに時間がかかるように見えるため、MSTest を実行するために生成されるアセンブリの数を制限しようとしました。

編集: 私たちのビルドは、Web サービス、Windows サービス、実行可能ファイル、およびデータベースのデプロイを含む証明書環境にもデプロイされます。範囲のアイデアを提供するだけです

于 2009-02-10T21:32:59.733 に答える
0

自動ビルドはすべて Team City で行われます。

私たちが取り組んでいる最も自動化されたプロジェクトは、事実上コンパイラです。私たちのテスト スイートは、チェックインごとに実行される、コンパイルおよび実行される約 20000 のテスト クエリで構成されています。以前はこれに 1 時間近くかかっていましたが、(毎回チェックアウトするのではなく) ビルド マシンの RAM ドライブに完全なテスト スイートを保持することで、これを数分に短縮できます。

毎晩、これらと同じテストを実行する 2 番目のビルドがトリガーされますが、コード カバレッジ レポートを生成する NCover の下で実行されている間、4 つの異なるプロファイルの下で実行されます。このシナリオには数時間かかるため、ナイトリー ビルドとして実行されます。すべてが正常に機能していることを確認するために、他の内部レポートも同時に作成されます。

テスト スイート自体の更新は個別にトリガーされ、次の実行に備えて RAM ドライブにチェックアウトされます。それ以外の場合は、テストのチェックアウトにビルド時間のほとんどが費やされていました。テスト スイートの一部は、リモートの CVS リポジトリから取得され、ビルド時間に数分追加された更新を照会することさえできません。したがって、これは「更新テスト」ビルドでも行われます。この疎結合により、このプロジェクトのビルドを 1 台のマシンに制限する必要がありましたが、フィードバックは非常に迅速であるため、これは大きな問題ではありません。

コードベースの高いカバレッジを維持しながら、「通常の」テスト ビルドをできるだけ高速に維持することが非常に役立つことが証明されています。遅いテスト (1 秒以上) はナイトリー ビルドにプルされています。私たちのケースでは、テストを RAM ドライブに保持することは本当に役に立ちましたが、私たちのシナリオはかなり専門的です。データベースをモックすることが最も近いと思います。私のアドバイスは、「分厚い」または遅いテストを削除して、1 つのビルドを「無駄のない」状態に保つことです。他のビルドは別のマシンで実行することも、高速ビルドからの応答を迅速に保つために夜間に実行することもできます。

概観すると、(別のプロジェクトの) 最も長い自動ビルドは 1 日以上かかることがありますが、ありがたいことに、定期的に実行する必要があるビルドではありません。

于 2009-02-10T22:36:03.730 に答える
0

Erlang Common Test - 単体テストではなく、主にシステム テストに焦点を当てています。

于 2009-02-10T21:48:04.000 に答える