6

自動化されたテストは、リアルタイムのプロジェクトの状態を反映するために高速でなければなりません。アイデアは次のとおりです。

  1. リポジトリ自動ビルドへのコミットが実行された後 (可能な限り速く)。
  2. ビルドが成功すると、自動テストが開始されます。高速である必要があります。

これは、あなたの変更が何かを壊すかどうかを知るための私が知っている最良の方法です.

最初はビルドを高速化するのは難しいと思われましたが、100 秒程度に抑えることができました。105(!) プロジェクトのソリューション (MSVS 2008 C#)。

テストはそれほど単純ではないように見えました (NUnit FW を使用しています)。単体テストは大きな問題ではありません。私たちを殺すのは統合テストです。そして、それらが遅いという事実ではなく（それらをより速くする方法に関するアイデアは大歓迎です）、環境をセットアップする必要があるという事実は、はるかに遅い（atm〜1000秒）です！

私たちの統合テストでは、最新の変更を反映するために再デプロイする必要がある web/win サービス (これまでのところ 19 個) を使用しています。これには、サービスの再起動と多くの HDD R/W アクティビティが含まれます。

自動化されたテスト フェーズを短縮するために、環境とワークフローをどのように整理/最適化する必要があるか、どのように最適化できるかについて、誰でも経験を共有できますか。「低レベル」のボトルネックと回避策は何ですか。

PS の書籍や広範な記事は歓迎されますが、実際の作業ソリューションはより高く評価されます。

4

7 に答える 7

5

テストのスループットを向上させるために実行できる最適化戦略は多数ありますが、このテストの目的は何か、なぜ高速である必要があるのか​​を自問する必要があります。

一部のテストには時間がかかります。これは人生の事実です。通常、統合テストには時間がかかり、実行できるように環境をセットアップする必要があります。環境をセットアップする場合は、最終的な本番環境にできるだけ近い環境を用意する必要があります。

次の 2 つの選択肢があります。

  1. テストまたはテストの展開を最適化します。
  2. 頻繁にしないでください。

私の経験では、正しく、バグを見つけ、最終的な実稼働環境を適切に表す統合環境を用意する方がよいでしょう。私は通常、オプション 2 (1) を選択します。

常にすべてをテストすると言いたくなるかもしれませんが、実際には戦略が必要です。

(1) 統合でのみ発見される大量のバグがある場合を除き、その場合は、私が言ったことをすべて忘れてください :-)

于 2008-10-10T06:35:53.470 に答える
3

カテゴリ (テストに使用できる属性) をサポートする .NET と NUnit を使用します。次に、長時間実行するテストを NightlyCategory に配置して、高速に実行したい継続的なビルドではなく、ナイトリー ビルド中にのみ実行されるようにします。

于 2008-10-08T20:20:59.483 に答える
1

いくつかの高レベルのエンドツーエンドテストを実施することをお勧めします。それらのいずれかが失敗した場合は、「高解像度」テストを実行してください。

電話でテクニカルサポートを行うことを考えてください...

あなたのコンピュータは動作しますか？はいの場合、完了。いいえの場合、コンピュータの電源はまったくオンになっていますか？..。

単体テストでは、「コンピューターは機能しますか？」などの高速テストがいくつかあります。それらが合格した場合、私はスイートの残りの部分を実行しません。これらのテストのいずれかが失敗した場合は、関連する一連の低レベルのテストを実行して、その失敗に対するより高い解像度のビューを提供します。

私の見解では、トップレベルのテストの包括的なスイートを実行するのにかかる時間は0.5秒未満です。

このアプローチにより、スピードと詳細の両方が得られます。

于 2008-12-05T15:35:41.050 に答える
1

はるかに遅い環境を設定する必要があるという事実（atm〜1000秒）！

少なくとも、どこに焦点を当てるかはわかっています... その時間がどこに費やされているか知っていますか?

明らかに、解決策はここでの詳細に依存します。

この種の状況で私が使用した 3 つの解決策があります。

  1. より多くのマシンを使用します。おそらく、サービスを 2 台のマシンに分割できますか? セットアップ時間を 1/2 に短縮できますか?

  2. より高速なマシンを使用しますか? 私が知っているチームのある状況では、ハードウェア (複数の CPU、高速 RAID ストレージ、より多くの RAM、動作) をアップグレードすることで、統合テストの実行時間を 18 時間から 1 時間程度に短縮しました。確かに、10,000ドルのオーダーで費用がかかりましたが、それだけの価値がありました.

  3. 統合テストにはメモリ内データベースを使用します。はい、実際のデータベースに対してもテストを行いたいと思われることは承知していますが、最初はメモリ内のバージョンに対してテストを実行して、迅速なフィードバックを得ることができます。

于 2008-12-05T16:32:41.013 に答える
1

この状況に対する最善の解決策は、環境をリセットする前に、環境のゴースト イメージをバックアップし、イメージを復元することです。これは、費やされた時間にとってより意味があります。

于 2012-11-12T10:50:41.950 に答える
1

Turbo-Charged Test Suitesに関するプレゼンテーションをまとめました。後半は Perl 開発者向けですが、前半は役に立つかもしれません。あなたのソフトウェアが適切かどうかを判断するのに十分な知識がありません。

基本的には、テスト スイートでのデータベースの使用を高速化し、単一のプロセスでテストを実行して、ライブラリの絶え間ない再読み込みを回避するための手法を扱います。

于 2008-10-09T11:21:08.247 に答える
0

Buildbot：http ://buildbot.net/trac 継続的インテグレーション（自動テスト）を実行している場合、これを十分に推奨することはできません。クイック構成では、コミットがあるたびにすべての単体テストが実行され、より長い統合テストが1日を通して定期的に実行されます（最後に3回チェックしましたが、これは簡単に変更できます）。

于 2008-10-08T20:24:01.320 に答える