問題タブ [qtp]

誰かがこれに対する解決策を提案できれば、非常に感謝しています。

各値がアカウントを表す Web リストを含むページでブラウザーが開かれることを期待している単純な関数があります。アカウントが選択されると、その製品 (存在する場合) が表示されます。

関数の目標は、製品 (最初に見つかったもの) を含むアカウントのインデックスを取得することです。何もない場合は -1 を取得します。

何が原因なのかわからない問題は、関数をデバッグしているときに関数が正しい結果を返すことです。つまり、F10 を使用してコードを段階的に実行すると、間違った結果が返されます。定期的に実行します (F5)。この動作は一貫しており、関数は実行の種類ごとに毎回同じ結果を取得します。つまり、関数がランダムな回答を返すだけのバグではありません。

これは機能です：

Pentium 4、3.2 GHZ、2 GB RAM、Win XP、SP 3、IE 7、QTP 10.0 Build 513 で実行しています。

ありがとう！

標準の Windows アプリで、ボタンとリスト ボックスのような 2 種類のコントロールにアクセスする関数があります。この関数は引数としてコントロール名のみを使用するため、qtp がコントロールのタイプを理解する方法はありません。これを解決するには？ボタン用とリストボックス用の2つの別々の関数を作成しますか?

最初に「WinMenu」などの一部のコントロールで「オブジェクトが表示されない」というエラーが表示され、これらのコントロールに初めてアクセスするには手作業が必要です。その後、正しく実行されます。

開くアプリケーションで2つ以上のプロジェクトを使用しています。たとえば、HT1000とHT1200はアプリケーションによって開かれ、オブジェクトは両方のプロジェクトで同じ（または共通）です。コードは、Excelフレームワークの値を使用して、テストケースを親として実行し、たとえばWindow（ "HT1000"）。Dialog（ "parts"）。Click（ "OK"）の子オブジェクトを識別しますが、 「HT1200」としてExcelフレームワークは、HT1200のオブジェクトにアクセスされていません。

これを解決する方法は？qtpのオブジェクトリポジトリにHT1200プロジェクトとオブジェクトを再度追加する必要がありますか？

QTPに次のようなWebTableがあります。

ここでは、各divRowの値divFirstとdivDataをキャプチャします。理想的には、すべてのdivRowを文字列に格納します。

誰かが私にそれをどのように行うことができるか教えてもらえますか？

どうもありがとう

一部のファイルがロードされているアプリケーションがあり、ファイルのロード中にアプリケーションがしばらく応答を停止します。テストの自動化中に、ファイルの読み込みが自動化されるシナリオがありますが、qtpはアプリケーションが再び応答を開始するまで待機する必要があります。これをコーディングする方法は？「待つ」のような物件はありますか？

私は、約 10,000 個の小さな VBScript プログラム (それぞれ 50 ～ 100 行) のコレクションと、大きなプログラムの小さなコレクションを持っており、手動での文字変換に頼らずにそれらを C# に変換する方法を探しています。プログラムは、HP/Mercury の QuickTest Pro 用に作成された、Web アプリケーション用の自動化されたテスト ケースであり、私はそれらを Selenium 用のテスト ケースに変えようとしています。幸いなことに、テストはビルディング ブロックとイディオム (大規模なプログラム) のライブラリを使用して適切に作成されているように見えるため、テスト ケースは実際には VBScript よりもドメイン固有言語に似ており、QTP 性は良好です。図書館の中に埋もれています。

理想的には、私が探しているのは、DSL っぽいテスト ケースと、より複雑なビルディング ブロック ライブラリの両方について、VBScript から C# への構文変換を実行できるツールです。そうなると、ライブラリを手動でクリーンアップする必要があり、おそらくテスト ケースの作業はほとんどありません。VBScript から VB.NET へのトランスレータを見つけることができれば、VB.NET をコンパイルしてから、.NET Relector などを使用して C# に逆コンパイルできるのではないかと思うので、それも利用します。プラン B は、テスト ケースが非常に直線的なスタイルであるため、独自のトランスレータを作成することですが、ライブラリでは役に立ちません。

何か提案はありますか？私は少なくとも 15 年間コンパイラを書いていません。書き方を忘れたわけではありませんが、楽しみではありません。特に VBScript については!

私の QTP スクリプトは Test Scripts タブにあり、データシートは QC の TestPlan の Attachment タブにあります。これらのデータシートを QTP のデータテーブル (グローバル) にインポートし、QTP スクリプト パラメーター化を使用してアプリケーションでデータを使用し、スクリプトはアプリケーションから自動生成された値でこのグローバル データテーブルを更新します。

ここで、Export / ExportSheet 機能を使用して Global Datatable を QC の添付ファイル タブのテスト データ シートにエクスポートすると、それらが更新されていないことが問題になります。

QTP から Quality Center への Global Datatable のこのエクスポートを実現するにはどうすればよいですか?

DataTable 全体を新しいファイルとして保存するか、既に添付されている DataTable を更新したいと考えています。

「Test Resources」タブに保存しても問題ありません。

実際、どのような方法で Quality Center にアクセスできても、私は満足しています。

QTP 10.0 と QC 10.0 の使用

詳細な例:

Web サイトで商品を購入する顧客に対して計算された税金をチェックするテストがあります。そして、各行の結果を保存したいので
、次のようなデータテーブルがあります

テストを実行すると、QTP がデータ テーブルの空白を埋めます

このデータ テーブルを保存したいのですが、テストが終了するとデータが失われます。だから保存したい。自分のマシンにローカルに保存できることはわかっています。しかし、後で取得できるようにQCに保存したいのです。

アップデート

データ テーブルが実際に保存されていることがわかり、Test Lab を開いてテスト ランを確認すると、データ テーブルを見つけることができます。しかし、データ テーブルをテスト リソースまたは添付ファイルとして保存する方法を知りたいです。

名前の代わりにフィールドのラベルを使用してQCのカスタムユーザーフィールドを更新したい

現時点では、このようにしています

でもこうやってやりたいです

しかし、私はそれを行う方法を見つけることができません。何か案は？

Does anyone have experience building a .NET test execution harness that can execute the logic in existing QuickTest Professional VBScript automation scripts, but without starting an instance of QTP? We are in the process of transitioning to Visual Studio 2010 and the related test management tools, but we can't (justifiably) throw away our existing QTP work.

There are solutions for executing existing QTP automations, but the ones I've seen require launching an actual instance of QTP. A solution for this problem won't require invoking an instance of the QTP application (even in "invisible" mode). Naturally, invoking the libraries included with QTP is permissible, and expected.

For reference, it's the pain of launching QTP (and waiting for various parts of the application to do their thing) that we're trying to avoid. QTP is very untrustworthy to us, and has many bugs, and we want to minimize the QTP surface area with which we interact.

Alternatively, the best solution would involve transforming our existing VBScript automations into .NET automations seamlessly and painlessly, but I'm not holding my breath on that one. :)