0

チェックイン後にコードをコンパイルし、コンパイルが失敗した場合に通知を受け、テストを実行し、テスト結果を通知され、アプリケーションを公開する (Web サイトを公開するか、デスクトップ アプリ用の msi ファイルを作成する) 必要があります。

私たちはSVNを使用しており、msunitテストを持つ.netプロジェクトの継続的統合サーバーにTeamCityまたはCruiseControl.NETを使用することを検討していました.

私のプロジェクト マネージャーは、HP Quality Center と Quick Test Professional (既に購入済み) を思いつき、問題の追跡 (現在は Jira を使用しています) と継続的統合に使用することを提案しました。

それは理にかなっていますか？

4

4 に答える 4

3

いいえ。私は今クライアントで使用していますが、それは嫌いです。MS 以外のブラウザー (ActiveX など) をサポートしていないため、OS X では VM などで立ち往生しています。さらに、インターフェイスは非常に扱いにくく、低速です。それは古く、恐ろしい、レガシー技術です。はるかに優れたオプションがあります。

于 2011-10-27T20:41:02.413 に答える
2

QC欠陥とテスト追跡をパイプライン化された継続的インテグレーションに統合する多くのお客様がいます。しかし、QCはプロセスを推進しているのではなく、CIおよびCIDプロセスに統合されています。

于 2009-03-26T16:39:44.987 に答える
0

QC を使用して、テスト セットと呼ばれるものを実行します。私たちはこの方法で非常に成功しています。QC を使用して、失敗した実行について通知することができます。これはもちろん、QTP 側で何かがコンパイルされなかった場合に通知します。また、スクリプトが失敗した場合に実行する他の QTP および LoadRunner スクリプトもセットアップします。

于 2009-04-29T18:03:48.153 に答える
0

良い考えではありません。私は QC と Borland ツール (HP 用) の POC を行いました。可能ではありますが、同期を完全に行わなければならない領域が多すぎて、ネットワークなどのために QC の応答時間が遅いことがあります。適切なファイルをトリガーし、コンパイルの結果を取得して公開するには、少し不安定です。ここでも技術的には API を介して完全に実行可能です。

于 2010-11-29T23:55:01.923 に答える