QTPとSelenium-比較
.netテクノロジを使用して作成されたアプリケーション/製品があります。この製品には、Web API（アプリケーションサーバー上のSOAP）を使用してDBに接続するGUIがあります。テストの大部分はDB内の値に対して実行されますが、その他はユーザビリティ、パフォーマンスなどに分類される可能性があります。したがって、実行されるテストの60〜70％は、DB内の値が正しく表示されているかどうかを確認するためのものです。 GUIで、他の人はGUIが要件仕様で希望どおりに機能しているかどうかをテストします。
テストのもう1つの側面は、DBとGUIの両方を使用してバックエンドアプリケーションサーバーインターフェイスをテストすることです。これにより、App ServerがGUIに不正な値を送信しているのか、それとも不正な値を持つDBなのかを判断できます。
製品のUIは、追加のドロップダウンメニュー項目とこれらのメニュー項目の追加ページの形で新しい機能を追加することを除いて、あまり変わりません。
上記を考慮すると、どのフレームワークがより適切でしょうか？ QTPまたはSeleniumまたはその他の商用/オープンソースツール？
（コストは大きな問題ではなく、ブラウザーの互換性やOSも問題ではありません。システムはWindows Serverにインストールされ、DBは互換性があります。）
Java + dbバックエンドと通信するフレックスUIを備えたアプリをテストするためにSeleniumを中心に構築された受け入れテスト「フレームワーク」があります。
スクリプトをJavaで記述し、junitを使用してテストを実行できるため、Seleniumを既存のテストおよび継続的インテグレーションインフラストラクチャに簡単に統合できます。これらのテストも開発者によって作成および保守されます。各テストの前に、dbunitを使用してデータベースをセットアップします。
しかし、私たちのテスト部門はQTPを採用することにしました。彼らは私たちのインフラストラクチャがSeleniumを中心に構築されていることを示しましたが、理解するのは難しいと感じました。私は彼らがテストを書きそしてそれらを維持するために専任の専任の人を持っていることを知っています。
私はあなたの正確な状況を知らないので、私はあなたに以下を考慮することを提案することができるだけです：
- 誰がテストを作成して維持していますか？
- スイートはより大きなインフラストラクチャの一部になる予定ですか？
セレンは次の場合に最適です...
- テストの作成と保守を担当する開発者がいます
- より大きなインフラストラクチャの一部としてこれらのテストを行う必要があります
- ブラウザの外で多くのテストを行う必要はないと確信しています
- windows以外の他のブラウザや他のプラットフォームをテストしたいと思うかもしれません
- あなたは何か無料のものが欲しい
QTPは次の場合に適しています...
- テストを作成および保守するコードに精通した人が少なくなります（ただし、Selenium IDEは非コーダーにとって習得が難しいかどうかはわかりません）
- ブラウザの外部で重要なテストが必要な場合
この 記事 もあなたを助けるかもしれません。
私がどちらを好むかは明らかだと思いますが、状況に最も適したものを決定する必要があります。
あなたの最良の選択は、GUIおよび非GUIテスト用のHPの新しいソリューションになると思います。新しいソリューションは、QTPとServiceTestの2つの製品との新しい統合です。
- QTPは、組織がGUIレイヤーでアプリケーションを自動化するのに役立つ拡張機能を備えた既知のGUI自動化ソリューションです。
- ServiceTestは、Webサービスやその他の非GUIインターフェイスを自動化できるまったく新しいソリューションです。
これら2つの統合により、ユーザーは、クロスレイヤーアプリケーションと異なるアプリケーション間の統合テストを自動化するための1つのソリューションを利用できます。
詳細については、HPサイトをご覧ください。
プログラミングライブラリ（Javaなど）の膨大な配列（しゃれは意図されていません）にアクセスできるので、私の投票はSelenium-RCを使用することです。しかし、最初のポスターのように、これには追加の学習と保守の曲線が必要です。しかし、一度セットアップすると、アプリケーションはあなたの想像力（そしてプログラミングの腕前:)）によってのみ拘束されます。 Selenium-RC（Java）を使用したDB統合は簡単でした。また、サーバーの応答の測定にSeleniumを幅広く使用することができました。 QTPにも同じことをするハックがあると確信していますが、HPのサポートがあれば、最近のように、あなたの賭けはオープンソースコミュニティ（およびstackoverflow :)）にあるはずです...
.Netあなたが言う？
VS2010を使用している場合、コード化されたUIは非常に優れています。長年のQTPユーザー（もちろん、より技術的な側面）として、コード化されたUIは夢でした。その存在の初期段階でさえ、非常に強力で、緊密に統合されています。 Visual Studioエコシステムを使用できる場合は、強くお勧めします。あなたはについて読むことができます ここ
私の経験がより制限されているもう1つのツールですが、良いことを聞いたことがあります（ specflow ）。これは、コード化されたUIとうまく連携して、適切な方法でテストを作成および整理できます。
とにかくあなたに考える何かを与えるかもしれません！
これについての私の見解-
セレンは次の場合に最適です...
- QualityCenterにスクリプトを配置する必要がない場合。一方、継続的インテグレーションははるかに簡単です。
- Seleniumは、チェックポイントなどの機能が少ない低レベルのツールです。大したことではありませんが、スクリプトの開発と保守にも時間がかかります。 Selenium 3が登場し、新しいSeleniumがリリースされるたびに、APIが変更されるため、古いスクリプトに別れを告げる準備をしてください（異なるバージョンのSeleniumを備えた別々のマシンを除く）。
- Seleniumは無料のツールですが、機能がまだ開発されていないという理由だけで、特定のプラットフォームまたはブラウザーで特定のアクションを実行できない場合があります。
- いいえ、開発者は通常、Selenium、特にWeb層（ブラウザーの自動化）に精通していません。 Javaの知識は、htmldomを完全に理解しているわけではありません。JUnitと混同しないでください。JUnitは時々使用します。
- 大規模なSeleniumプロジェクトは、Eclipseの他のプロジェクトと同じように見えます。この場合、特にQCの場合、QTPの方がはるかに優れています。
- Javaはデータ構造に最適であり、VBScriptとは異なり、完全なOO言語です。
QTPは...の場合に適しています。
- QCとの統合が必要です。 Continiuos統合の直接的なサポートはありません。
- 大規模なインフラストラクチャプロジェクトは、QTPを使用するとよりクリーンに見えます。 QTPには、設計によってコードから分離されたWeb層の説明があります（スクリプトで使用されている要素のhtml属性を含むGUIファイル）。すべてのライブラリファイルはQCに保存され、テストデータはExcelファイルに保存されます（ベストプラクティスによる）。
- VBScriptはWindowsに最適です。QTPAPIとともに、WinAPIへの非常に強力なアクセスとHTMLDOMへの直接アクセスを取得します。
- QTPは5年前から古いコードをサポートしており、カスタマーサポートもあります。
- 市場投入までの時間はSeleniumよりも短くなります。 xpathまたはテキストでリンクをクリックする必要がある場合は、フォーラムを検索する必要はありません...クリックするだけです。また、チェックポイントやその他の形で追加機能
さまざまなブラウザに対して自動化テストスクリプトの開発を開始する前に、よく考えてください。 GUIの欠陥に関しては、自動化は不十分です。そして、ほとんどすべてのブラウザ固有の欠陥は、スタイリング、レイアウト（GUI）です。機能上の欠陥の値が正しく表示されない、またはコントロールが機能しない場合は、1つのプラットフォームで識別できる機能上の欠陥です。