c# - コード化された UI テストでコントロール ID の変更を処理する方法

Question

基本的に私はビジュアル スタジオ CODE UI を使用して Windows ベースのアプリケーションの UI 自動化テストに取り組んでいます。典型的な階層が CODE UI ビルダーによって記録されているスクリーンショットから:-

メイン ウィンドウ -> コントロール Id プロパティを持つウィンドウ -> 実際のコントロール。

では、この階層とコントロール ID に関連する質問はありますか?

1) これらのコントロール ID はどのように生成されますか?

a）GUIのコントロールの深さに応じて、これらのコントロールID番号が生成されるロジックがあることは知っていますが、たとえば画像では、それらがどのように生成されるかについて一貫した方法を見つけることができません2 つのボタンが接続され、ヘルプは同じレベルの GUI にあるように見えますが、それでもそれらのコントロール ID は1 と 5013 と大きく異なります。

b) これらのコントロール ID は、テスト環境で使用されるコード化された UI ビルダーによって生成されますか、または製品開発側に何らかのロジックがあるか、またはそれらが生成されるコード自体がありますか?

2)コントロール IDを持つウィンドウのこの中間層をスキップして、記録と再生を正常に行う方法はありますか?これらのコントロール ID を取り除くため)

3)さらに、ほとんどすべてのコントロールに対して 2 つのレイヤーがあり、論理名またはラベルのみでは機能せず、明示的にコントロール ID が必要な特殊なケースでは 3 つのレイヤーを持つハイブリッド アプローチを使用できますか?

4) 最後になりましたが、このタイプのアクセシブルな実装のどれだけがテスト環境で実行できるかということです。私の知る限り、コントロールのアクセシビリティの大部分は、コード自体にいくつかのプロパティを追加することによって製品開発環境で実行する必要があります。テスト環境で CODE UI などのさまざまなツールを使用してテストするために取得できます。しかし、大規模な製品の場合、開発側に余分な負担がかかり、顧客に提供する必要がある製品に余分な不要なコード (テスト目的でのみ必要) を追加するようなものであるため、これは良いアプローチではないと思います。

私の質問を明確にするために、参考として以下の画像を参照してください。

1 番目の画像は、リモート デスクトップ GUIを示しています

第 2 ショーコンピューター:コード化された UI によって記録されたコントロール プロパティ

3つ目は、コード化された UI によって記録された接続ボタンのプロパティを示しています

4 番目は、コード化された UI によって記録されたヘルプボタンのプロパティを示しています。

Answer 1

今は CodedUI から始めたばかりですが、以前はさまざまな製品を使用し、同じテクノロジ (MSUIA など) を使用して多くの UI オートメーションを行っていました。したがって、これはここにも当てはまります。

各コントロールには、名前やオートメーション ID など、最も重要なものに名前を付けるためのいくつかのプロパティがあります。独自の UI を自動化する (自分でコーディング/ビルドする) 場合は、常に各コントロールに一意のオートメーション ID を与えるようにしてください。これにより、自動化する際の作業がずっと楽になります。プログラムの言語バージョンが異なると頻繁に変更されるため、名前はよくないオプションです。

その場合、ソースがなく、それが報告する値に影響を与えることができないため、与えられたものを操作する必要があります。それでも、CodedUI レコーダーは適切と思われる任意のプロパティを選択しますが、見つかった各要素の UIMap.uitest を変更することで、検索条件を自分で変更できます。

これにはおそらく慣れるまでに時間がかかるでしょう..特に、要素が同様のプロパティを持つより複雑な UI の場合、動的 UI などの場合もそうです。

ちなみに、私が以前に直接使用していた製品はAutomationElementsと連携していました.ここでは、メンテナンスと開始コストが高くても、選択してやりたいことを実行するためのフルパワーがあります. (わかりました。一般的には非常に時間がかかります。VS コード化された UI のような既製のソリューションを使用するよりも常に時間がかかります。)

もう 1 つの簡単な解決策は、(メイン ウィンドウやタブ グループなどの一部の既知のコントロールに関連する) 座標を使用することです。これも 99% の確率で機能し、目標にはるかに早く到達します。

わかりました、具体的な質問に答えます

1）それが私が思うなら、それらは実行時に生成され、実際にはそれらに依存することはありません

2) 下位レベル (AutomationElement など) に移動すると、ツリー全体を検索できます。それでも、それは通常、検索をかなり遅くします-ツリー全体を自分で取得してトラバースする場合よりもそれほど速くはありません

3) 好きなものを混ぜることができます。実際には、ハンドルを AutomationElements から Controls に変換することもできます (少なくともほとんどの標準コントロールでは)。したがって、Win32 SDK などの任意のテクノロジを使用して、ツリーをトラバースできます。実際、すべてのテクノロジのすべての GUI ツリーは類似していますが、同じではありません。そして、コーディングをしている人はほとんどいません..少なくともそれが私の経験です.

4) さまざまなテクノロジー、座標 (実際には、スクリーンショットも使用しました) などを使用すると、ほぼすべてを達成できます。とはいえ、とても時間がかかります。開発中に基本を正しく理解し、UI テスト開発者からのフィードバックを考慮に入れることは、その後のテストのスピードアップに大きく役立ちます。最も単純な例: アプリケーションが画面上に「すべて OK」を描画するかどうか、または「すべて OK」という name プロパティを持つ到達可能なコントロールがあるかどうか - 2 番目の解決策は、自動化担当者にとってはるかに優れています。

また、より複雑な UI については、企業環境にいて、いくらかのお金があり、とにかく UI テストに多くの時間を費やしたい場合は、Ranorex や SilkRunner などの製品をお勧めします。私は数日間 Ranorex Eval を使用しましたが、(ある程度慣れた後) 事前にナビゲートするのが非常に困難な UI をナビゲートすることができました。