アクセシビリティツリーのないアプリのための WinAppDriver の代替

WinAppDriver の代替ツールとは、Windows アプリケーションをそのインターフェイスを通じて操作するあらゆるツールのことです: そのほとんどはアプリケーションのアクセシビリティツリーを読み、各要素を見た目で見つけるものはわずかですが、ツリーのないアプリケーションに必要なのはそちらです。

テストツールにアプリが見えないとき

Inspect をアプリケーションの「保存」ボタンに向けると、表示されるのは空のペイン 1 個だけです。ロケーターは何も見つけられず、WinAppDriver のテストは失敗し、WinAppDriver の代替探しが始まります。

このガイドでは、Windows デスクトップのテスト自動化がどう動いているか、どのアプリケーションが見えないのか、そしてそうした Windows デスクトップアプリケーションをそれでもテストする方法を説明します: 人がするように、すべての要素を見た目で見つける方法です。

Windows デスクトップのテスト自動化はどう動いているのか?

各アプリケーションは、自分のインターフェイスをツリーとして Windows に伝えます。ウィンドウはペインを持ち、ペインはボタン、フィールド、リストを持ち、それぞれに名前、種類、画面上の位置があります。Microsoft Active Accessibility (MSAA) は、古いプログラムに同じことをする、より古い技術です。

テストツールはそのツリーを読み、AutomationId、名前、ツリーをたどる XPath といったロケーターで要素を見つけ、クリックしたり、入力したり、値を読み取ったりします。

ツリーが完全なら、これはうまく働きます。Microsoft は標準の Win32、Windows Forms (WinForms)、WPF の全コントロールの説明を提供しているので、それらは自然にツリーに現れます。カスタムコントロールは違います: その説明は開発者が書かなければならず、それがなければ、Microsoft のドキュメントによると、そのコントロールは UI Automation からほぼ不透明で、位置程度しか報告できません。

WinAppDriver もその代替ツールも同じツリーを読む

Microsoft の Windows Application Driver である WinAppDriver は、UWP、Windows Forms、WPF、従来の Win32 アプリに Selenium のような自動化をもたらしました。GitHub での最後の安定版リリースはバージョン 1.2.1 で 2020 年 11 月のもので、その後 2021 年 7 月に 1.3 のリリース候補版が出ています。その上に作られた Appium Windows ドライバーは現在非推奨とされ、そのドキュメントは Appium WinCore ドライバーを公式の後継として挙げています。

よく挙がる代替ツールは、それぞれ違う道を通って同じツリーにたどり着きます:

WinUI 3 アプリ向けの Microsoft の最新のガイダンスである、AI エージェント向けの winapp ui コマンドでさえ、実行中のアクセシビリティツリーを読み、すべての対話的なコントロールに AutomationId を設定するよう開発者に求めています。

Web テストツールの比較は、比較調査をご覧ください。

Android アプリも出荷しているチーム向けには、Windows デスクトップアプリと Android アプリのための Appium の代替ツールが、両方を対象にできる 7 個のツールを比較しています。

WinAppDriver の代替ツールの比較

同じツールを並べて比較します: アクセシビリティツリーを読むか、要素の画像にフォールバックできるか、テストを書く言語、ライセンス、そしてまだ保守されているかです。どの行も 2026 年 11 月 6 日にプロジェクトまたはベンダー自身のページで確認したもので、最後の列のリンクからそのページに移動できます。

各ツールの強みと限界

アクセシビリティツリーを持たない Windows アプリとは?

これらのどれかに Inspect を向けると、フォームがあるはずの場所に空のペインが 1 個あるだけ、ということがよくあります。これがレガシーアプリケーションのテストの日常であり、多くの最新アプリでも同じです。

ツリーはあっても、アプリケーションに手を加えられないこともあります: 他社のプログラム、監査のために固定されたビルド、AutomationId を追加してくれないチーム。そうなると、テスト用ビルド、アプリ内のエージェント、コードの変更を必要とするツールはどれも手が届きません。

Electron アプリは特別なケースです: そのページは Chromium と同じように自分自身を Windows に伝えますが、ネイティブのダイアログ、メニュー、トレイアイコン、通知はそのページの外にあり、それを扱うのがElectron アプリのエンドツーエンドテストです。

自分のアプリを 2 分で確認する方法

1. 1

   検査ツールを開く

   Microsoft の検査ツールである Accessibility Insights for Windows をインストールするか、Windows SDK の Inspect を使います。

2. 2

   テストに必要な要素の上にマウスを置く

   それぞれが名前、種類、AutomationId とともに表示されるはずです。

3. 3

   表示されたものを読む

   ウィンドウ全体がペイン 1 個だったり、要素に名前がなかったりするなら、ツリーベースのツールはそれらを確実には見つけられません。

画像ベースのテスト: 画面にあるものをテストする

SikuliX はその古典的なオープンソースの例です: 各要素の画像をキャプチャし、各ステップをスクリプト 1 行として書きます。商用ツールはこれを代替手段として用意しています。たとえば TestComplete のドキュメントによると、画像ベースのテストを記録できるのは Android アプリだけです: デスクトップアプリでは、画像をキャプチャし、テストコマンドを手作業で追加します。

素朴に作ると、見た目によるテストにはよく知られた弱点があります。それぞれに答えがあります:

ツリーを必要としない WinAppDriver の代替

GUI Test Studio は Windows 向けのエンドツーエンドの GUI テストスイートで、画面に見えるどんなアプリケーションでも、コードなしでテストします。ツリーか画面かのどちらかを選ぶことはしません。

GUI Test Studio が要素を見つける仕組みでは、2 通りの方法がどう連携するかを説明しています。ここでは、ツリーのないアプリにとってそれが何を意味するかを、順を追って見ていきます。

1. 1

   アプリを記録する

   GUI Test Runner-Recorder で記録をクリックし、アプリを選びます。開いているアプリの中からプログラムを選ぶか、まだ起動していないものを参照して選びます。テストと一緒に起動して終了時に閉じるチェックボックスをオンにしておくと、どの実行も新しく起動したアプリから始まります。あとは、いつもどおりにアプリを使ってください。

   

   拡大

   アプリを選んでおけば、別のプログラムの通知がテストに入り込まず、それでいて自分のクリックやキー操作はすべて記録されます。テストを記録するをご覧ください。

2. 2

   すべての要素が 2 通りの方法で保持される

   各クリックの直前にビジュアルアサーションが付きます: 要素の画像、つまりビジュアルターゲットです。アプリケーションがその要素を Windows に伝えている場合、テストはその説明も保持します。アプリが空のペイン 1 個で答える場合、保持する価値のあるものはなく、画像だけが要素を見つけます。

   フォームを独自に描き、フォーム自身のウィンドウしか伝えないプログラムもあります。テストはそのウィンドウを保持するので、移動したフォームも今ある場所で再び見つかります。

3. 3

   表示されたものを検証する

   ビジュアルアサーションは、要素が画面上にあり、正しい見た目であることを検証します。テキストアサーションは、要素に何と書かれているかをアプリケーションに尋ね、アプリケーションが答えられないときは画面上の言葉を読み取ります。動的テキストアサーションは、日付や注文番号のように実行のたびに変わる値を、その形式で検証します。

   どの比較も、どんな画面にもある小さな描画の違いは無視しつつ、人が変化と呼ぶ本当のリグレッションはきちんと捕まえます: 間違った色、欠けたアイコン、変わった言葉。ビジュアルアサーションをご覧ください。

4. 4

   ウィンドウがどこに開いても実行する

   テストはクリックやキー操作を実際のマウスとキーボードの入力として再生し、各要素が今ある場所に向けます。アサーションが 1 秒たっても検索範囲内で要素を見つけられないときは画面全体も探すので、ウィンドウが移動してもテストは不合格になりません。その場合、信頼度レポートは要素が検索範囲の外で見つかったことを伝え、GUI Test Studio で検索範囲を広げることを提案します。

   複数のディスプレイを持つコンピューターでは、テストは 1 個のディスプレイかすべてのディスプレイを使い、どちらだったかを記憶します。

   

   拡大

WPF や Windows Forms のアプリについては、コードなしの WPF テスト自動化と WinForms の UI テストが、テストを 1 ステップずつ記録し、アプリがどのコントロールを伝え、どれを隠すかを示します。

ライブラリではなく商用のデスクトップツールから移行するチームは、TestComplete と Ranorex の代替ツール: 購入者のためのチェックリストで、同じ問いへの購入者向けの答えを見つけられます。

Citrix、リモートデスクトップ、仮想マシン

Citrix、リモートデスクトップ (RDP)、VMware Horizon のセッションは、ピクセルだけのウィンドウ 1 個としてコンピューターに届きます。一部のツールは、SmartBear が TestComplete について説明しているように、リモートサーバー自体にインストールされている場合にしかそのコントロールに届きません。GUI Test Studio は、セッションを表示しているコンピューターから、ほかのウィンドウと同じように見た目でテストします。

記録するときにアプリを選んでセッションのウィンドウを指定するか、その中の 1 個のパネルだけなら画面の一部を選びます。仮想マシン内のアプリも同じように動きます: 仮想マシンのウィンドウサイズを固定し、テストを実行するすべてのコンピューターで同じにしてください。テストできるものをご覧ください。

ビルドのたびにデスクトップテストを実行する

コマンドラインランナーの gtr-cli は、「テストを実行」ボタンとまったく同じようにテストを実行します。パイプラインに必要なものを加えます: 終了コード、JUnit ファイル、そして失敗のすべてのエビデンスを 1 個のフォルダーにまとめたものです。

gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifacts

デスクトップテストは実際の画面上で再生されるので、ビルドエージェントにはロックされていない Windows デスクトップセッションが必要です。画面サイズを固定した仮想マシンがテストエージェントとしてよく働きます。CI/CD ガイドでは、その設定を順を追って説明しています。

要点

• 1WinAppDriver は正式には非推奨になっていませんが、もう開発されていません: 最後の安定版リリースは 2020 年 11 月のもので、その上に作られた Appium ドライバーは Appium WinCore を後継として非推奨になっています。
• 2ほぼすべての代替ツールが同じアクセシビリティツリーを読みます: Appium WinCore と NovaWindows、FlaUI、pywinauto、Coded UI はいずれも、アプリケーションが自分の要素を伝えることを必要とします。
• 3多くのアプリケーションは、ほとんど、あるいはまったく何も伝えません: 独自描画のコントロール、Delphi や VB6 のプログラム、Java Swing、ゲーム、キャンバス、Citrix やリモートデスクトップのセッションです。
• 4画像ベースのテストならそれでも届き、うまく行えば、移動したウィンドウに追従し、描画のノイズを無視しながら、本物の変化は確実に捉えます。
• 5GUI Test Studio は両方を行います: まずアプリケーションに尋ね、アプリケーションが何も伝えないときは見た目で要素を見つけ、コードなしで記録からテストを組み立てます。

よくある質問

WinAppDriver、Windows、Visual Studio、Selenium、Appium、FlaUI、pywinauto、TestComplete、Ranorex、SikuliX、Delphi、Java、Citrix、VMware Horizon、Electron は、それぞれの所有者の商標です。