Power Automate Desktopで実用的なテスト実施RPAを作るコツ

PowerAutomate Desktopで 実用的なテスト実施RPAを 作るコツ 2023/8/29 須藤（suusanex）

自己紹介  ID：suusanex（ connpass・Twitter・GitHub共通）  名前：須藤圭太  サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属  4年ほど受託開発で、上流から下流まで全部を回す  ここ10年ほどは、自社製品開発も担当  Windowsアプリ開発のネタが多い  勉強会もやってます。  https://sciencepark.connpass.com

• https://sciencepark.connpass.com/

概要  MS製のRPAツール、PowerAutomate Desktopを使う話  いまさらRPA？  見た目は便利そうだが、現実的には使い物にならないよなあ  何かが変わるとすぐ動かなくなるし、保守されずにゴミになるだけだよなあ  そう言わずに聞いて下さい、ちゃんと使えば特定の用途では便利です  今回は「GUI操作が必要なテスト項目を実施させる」という用途で  実用的に使えるものにするためのコツを紹介します

話の流れ  最低限の使い方の紹介  その使い方の限界（問題点）  改善のためのコツの紹介

まずは最低限の使い方 （知らない人向け）  実際の操作をレコーディングするだけ  選択する要素などが視覚的に分かりやすく、使いやすいUI

出来上がったフロー  見た目にも理解できる感じ  フローを作成した環境で、同じ操作を 何度もやらせるだけなら、これで十分

その使い方の限界（問題点）  「GUI操作が必要なテスト項目を実施させる」という実用に使うと  次々と問題が起きる  OSのバージョンが変わったら動かなくなった  スペックが異なる別のPCで動かしたら動かなくなった  だいたい60%くらいの確率で正常に動く・・・  何が悪いのか  レコーディングは、変化する条件としない条件の判断ができない  例えば：プロセス名explorer.exeは変化しないが、タイトルバー「クイックアクセ ス」の表記は変わる

実用的に使えるものにするには？  レコーディングは叩き台と思え  この後はプログラマのお仕事  次のポイントを解説していきます  ウインドウ・コントロールのセレクタ  フローの呼び出し  条件が揃うのを待つ処理

ポイント1：ウインドウ・コントロール のセレクタ  レコーディングは、対象を見つけるための「セレクタ」を作成している  セレクタの完全一致条件は減らせる（条件を減らす・部分一致にするなど）  セレクタはOR定義できる  これらを生かして、環境による違いを吸収する

セレクタとは  フローごとに保存されていて、右の「UI要素」タブから一覧できる  まずウインドウのセレクタがあり、その子コントロールのセレクタがある

セレクタとは  開くと、対象を選択する具体的なステップが書かれている  Windowsアプリのウインドウの知識が無いとかなり辛い  Spy++でウインドウのクラス名などを見た、といった経験がある人には、ピン と来やすいかも

汎用的なものに直す  対象を特定するための条件は、少ないほど良い  そこまでの操作の流れが前提なので、誤認可能性は少ない  一番ありがち：ウインドウのタイトルバーのNameが完全一致条件  開いているファイル名などで変わるので、部分一致に   Wordなら、「タイトル – Microsoft Word」なので「Word」の部分一致など  正規表現も使える ClassやIdなどの、言語に依存しない要素で指定できそうならば、より良い

選択できるかどうか、テスト  変更してみたら、実際のウインドウを表示した状態で、選択できるか試す  「テスト」ボタンで試せる

セレクタが大きく違う場合  OSなどの条件で明らかにセレクタ自体が違う場合は、セレクタを増やす。  「新規」を押して、実際にその要素を選択すると、レコーディングされてセレ クタが増える  複数セレクタを定義すると「OR」 扱いになるので、どれか1個一致すれば動く

ウインドウ自体が異なる場合  親ウインドウの条件がまったく違う場合、手軽にORにできない  良い方法模索中、情報あったら教えてください！  例えばエクスプローラの新規作成は、OSバージョンによってボタンだったりウ インドウだったりする  フローのステップ自体を複数にして、ステップのエラー条件を、失敗しても次 に進むように設定する→擬似的にORを実現  全てが失敗しても次に進んでしまうが、たいていのフローは次のステップで失 敗するので問題ないはず

ポイント2：フローの呼び出し  セレクタは、フローごとに保存されている  つまり、セレクタの変更が発生すると、全フローの変更が必要  関数化と同じ考え方で、同じ役割のものは1フローにまとめるべき  関数呼び出しと同様に、引数を指定したフローの呼び出しが可能

フローの呼び出し  引数を指定して別フローを呼び出せる。関数呼び出しそのまんま

名前付けとコメントが大事  フローの中を見ても意図は分からないので、意図の分かる名前とコメントを付 けよう  名前付けが大事で、さらにコメントが大事なのは、コーディングと同じ

ポイント3：条件が揃うのを待つ処理  よくある処理「ファイルを開いたら、入力可能になるまで待つ」  「やってみたら3秒で開いたから、5秒のウエイトを入れよう」  これはアンチパターン  「60%くらいの確率で正常動作する」とかになりがち  条件が揃うのを待つ処理が多々あるので、それを使おう

待ち処理いろいろ  プロセス起動待ち、ウインドウ起動待ち、特定のWebブラウザの処理待ちなど、 色々ある  下記は、Excelを起動して何らかのウインドウが入力可能になるまで待つ処理

ちょっと参考  ここでウインドウ待機に使っている「Window Any Excel」とは  ウインドウの選択条件からプロセス名以外の全てを取り除いたもの

まとめ  ポイントをまとめなおすと  ウインドウとコントロールの選択条件が環境に依存しやすいので、そこをORにして 工夫する  共通化（関数化）して、1の変更を容易にする。変化する部分は引数にする  名前付けやコメントを工夫して、役割を読み取りやすくする  経過時間で待たない。イベントを待つ。  つまり・・・  1つ目はともかく、他はどれもプログラミングの基本  GUI操作ができる人なら使えるツールだ、と考えると問題を起こす  WindowsのGUIを操作可能なプログラミング言語だと思って使えば、問題を起 こしづらい