0

私は現在、クライアントの Web サイトからデータを解析している環境にいます。テストを使用して、クライアントがサイトを変更したときに、いつ情報を受信できなくなったかを確認したいと考えています.

私の最初のアプローチは、テストがクライアントのサイトにヒットし、データが見つかったことをアサートする純粋な統合テストを行うことでした。しかし、途中で500回のテストが行​​われると、テストの実行が耐えられなくなり、場合によってはタイムアウトが発生し始めました. そのため、提供されているコア保護を失わずにできる限り多くのテストをクリアし、350 程度まで減らしました。すべてのテストを破るためだけにテストを追加することを恐れています。また、変更を加えると、5 分以上実行していないことに気付きます (サイトとの通信速度に基づいているため、一部のクライアントはそれより長くなります)。これは完全な失敗だと思います。

私はこれについて多くのことを考え、オフィスで尋ねてきました。次の試みとして、クライアントのページをプルダウンし、プロジェクトに埋め込まれたこれらのリソースに対してテストを作成することを考えています。これにより、テスト範囲が広がり、孤立したテストに戻ることができます。ただし、変更を行ったときに通知を受け、ページを再度プルダウンしてテストする必要があります。クライアントがこれに固執するとは思わない。

失敗したテスト (クライアント サイトをヒット) と同じ機能を果たすが、以前よりもはるかに少ない数で機能する一連の「ランダムな」統合テストを使用して、これを補強するよう提案されました。私はランダムなテストのアイデアが本当に好きではありません。同じコードで赤信号が発生したり、緑信号が発生したりする可能性があります。しかし、これまでのところ、クライアントのサイトが変更され、コードがデータを見つけられなくなったことを認識できるようにするための最良のアイデアのように思えます。

このような環境をテストしていることに気付いた人はいますか? テスト コミュニティからの提案はありますか?

4

4 に答える 4

0

テストを分割して、おそらく独立して実行できる個別のアセンブリに分割することを検討する必要があります。私は通常、単体テストアセンブリと、実行速度の遅い統合テストアセンブリを持っています。

私の単体テストのアセンブリは非常に高速で（コードはモックを使用して分離してテストされるため）、開発中に非常に頻繁に実行されます。統合テストは遅く、機能を終了したとき/チェックインしたとき、または何かを壊すことについて気分が悪い場合にのみ実行します。

たぶん、あなたは似たようなことをするか、アイデアをさらに進めて、3つのテストスイートを持ち、3つ目はさらに遅いクライアントUIポーリングテストを含むことができます。

継続的インテグレーションサーバー/プロセスがない場合は、セットアップを検討する必要があります。これにより、ソフトウェアが継続的に構築され、テストが実行されます。これは、チェックインを監視してバックグラウンドで動作し、何かが失敗した場合に通知を送信するように設定できます。これが適切に配置されていれば、クライアントUIポーリングテストを自分で実行する必要がないため、テストにかかる時間は気になりません。

于 2012-04-13T14:12:48.513 に答える
0

確実にテストを分割します - 単体テストを統合テストから分離します。

Martyn が言ったように、継続的インテグレーション システムを導入します。私は Teamcity を使用しています。Teamcity は優れていて使いやすく、最初の 20 ビルドまでは無料です。サーバーを自由に使用できない場合は、自分のマシンで問題なく実行できます - http://www.jetbrains.com /チームシティ/

チェックインごとに 1 つのビルドを実行するように設定し、そのビルドで単体テストを実行するか、必要に応じて高速実行テストを実行します。

2 番目のビルドを毎晩深夜 (またはその他の都合の良い時間) に実行するように設定し、これに実行時間の長いクライアント呼び出し統合テストを含めます。これが整っていれば、テストにどれだけ時間がかかるかは問題ではなく、クライアントがあなたのものを壊した場合、朝一番に大きな危険信号が表示されます. 問題があると思われる場合は、必要に応じてこれらを手動で実行することもできます。

于 2012-04-14T00:21:35.817 に答える
0

大規模なテストに耐えられなくなったと言うときは、このテスト スイートを手動で実行していることを示唆しています。あなたはする必要はありません。スイートを完了するのにかかる速度に関係なく、バックグラウンドで常に実行されている必要があります。その後、最初からやり直します (関連するコストがある場合は、おそらく遅延の後で)。何か問題が発生した場合にのみ、アラートを受け取る必要があります。

数が増えるにつれてテストが遅くなる原因がテストにある場合は、それを見つけて修正してください。テストは互いに独立している必要があるため、単純に複数のテストを実行しても、個々のテストがタイムアウトすることはありません。

于 2012-04-13T13:58:22.397 に答える
0

不確実性を扱うコードの部分を可能な限り分離することをお勧めします。この部分は、他のすべてのコードで使用されるサービスとして機能する API である必要があります。このようにして、ほとんどのコードを変更から保護します。

コードの安定した部分は単体テストする必要があります。その部分がクライアントのサイトへの接続から独立しているため、テストはより速く実行され、テストの信頼性も向上します。

クライアントの Web サイトの変更に対処しなければならない部分を減らすことができます。この方法では、問題を解決することはできませんが、少なくとも問題を最小限に抑え、コードの 1 つのモジュールだけに集中させることができます。

データを Web サービスとして公開することをクライアントに提案するのが最善です。しかし、それはあなた次第ではないと思います:P.

于 2012-04-13T14:01:27.597 に答える