- ＠IT
- アジャイル/DevOps
- Test & Tools
- Webサイトスクレイピングのサンプルで実践するRPAの...
Webサイトスクレイピングのサンプルで実践するRPAのテスト駆動開発：テストドリブン型のRPA開発のススメ（2）
RPAの品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介する連載。今回は、テストドリブン型のRPA開発方法について、具体的なケースを用いて、UiPathを例に実践方法を説明する。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
RPA（Robotic Process Automation）の品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介する本連載「テストドリブン型のRPA開発のススメ」。連載初回となった前回で、テストドリブン型の開発手法とRPAに適用した際のイメージ、そしてRPA開発のベストプラクティスが理解できたと思います。第2回となる今回は、テストドリブン型のRPA開発方法について、具体的なケースを用いて、UiPathを例に実践方法を説明します。他のRPAツールを使う場合でも参考になるかと思います。
RPAでのテストドリブン
実装に入る前に、前回紹介したテストドリブン型のRPA開発の概念を再掲します。
- テスト用ワークフロー開発：ワークフロー開発に着手する前に、開発予定のワークフローをテストするためのテスト用のワークフローを書く。この時点では、ワークフローが存在しないので、このテストは当然エラーとなる
- 自動化ワークフロー開発：テストを成功させるための最低限のワークフロー
- リファクタリング：ワークフローをリファクタリングしてきれいにする
基本的に、IT開発のテストドリブン型開発と同じコンセプトで、実施するものとなります。「assertEqual」は利用できない場合もあるので、「IF（条件）」に置き換えていたりするものですが、基本的にはプログラムのものをワークフローに置き換えているものとなります。
サンプルのシナリオ
ここからは、サンプルの自動化シナリオを使用して、テストドリブン型の開発手法を紹介します。下記は、サンプルの自動化シナリオとそのワークフロー単位での実装イメージです。
テスト用ワークフローの開発
では、テストドリブン型の開発を始めます。
まず、シナリオ図の「1）UiPathのWebサイトよりイベント情報のリストをスクレイピング」に関して取り掛かります。「DownloadEvent」というワークフローとその正常処理をテストする「DownloadEvent_Normal_File_Test」というワークフローを用意します。
「DownloadEvent」のワークフローの引数にはこちらの設定をしておきます。
| 方向 | 引数名 | 型 | 既定値 | 説明 |
|---|---|---|---|---|
| 入力 | in_URL | String | "https://www.uipath.com/ja/news/events" | イベントページのURL |
| 入力 | in_MaximumNumberOfEvents | int32 | 10 | イベント取得の最大件数 |
| 出力 | out_ExtractDataTable | DataTable | - | イベント情報のDataTable |
「DownloadEvent_Normal_File_Test」に関しては、次の通りの構成とします。
- 「DownloadEvent」への入力引数を設定
- 「DownloadEvent」呼び出し
- 出力引数の検証
詳しく見ていきます。「url」には、イベントページをローカルに保存したHTMLを使用します。サーバで動いているページのURLにすると、イベント情報の更新に伴い、テスト実行タイミングで、出力引数の検証も変わってしまうので、ここではわざとローカルに保存したHTMLを使用し、スクレイピング後のデータ検証が正確なものとなるようにします。
なおブラウザへは、絶対パスでURLを渡してあげる必要があり、次のように記載しています。
Path.Combine(Environment.CurrentDirectory, "Test_Data\イベント・セミナー RPAの最新情報 _ UiPath.html")
「maximumNumberOfEvents」には、「10」を設定しておきます。
次に「ワークフロー ファイルを呼び出し」において、「DownloadEvent」を呼び出し、「url」と「maximumNumberOfEvents」を入力引数へ渡します。
その後、検証として、出力引数のeventDataTableのレコード件数が10件であるかどうかを検証します。10件ではないなら、「New BusinessRuleException("eventDataTable Count wasn't 10")」という例外をツール側にスローし、テスト失敗を通知します。
別の検証として、1つ目のレコードの「title」が、「UiPath導入検討者向けハンズオンセミナー」であるかどうかを検証します。異なる場合は、その旨を知らせるための例外をスローし、テスト失敗を通知します。
New BusinessRuleException("Actual: " + eventDataTable.Rows(0).Item("title").ToString + Environment.NewLine + "Expected: " + "UiPath導入検討者向けハンズオンセミナー ")
最後に、1つ目のレコードの「url」が、「"https://www.uipath.com/ja/handson-seminar-20200327"」であるかどうかを検証します。異なる場合は、その旨を知らせるための例外をスローし、テスト失敗を通知します。
New BusinessRuleException("Actual: " + eventDataTable.Rows(0).Item("url").ToString + Environment.NewLine + "Expected: " + "https://www.uipath.com/ja/handson-seminar-20200327")
この時点では「DownloadEvent」の中身がない状態ですが、テスト用のワークフロー「DownloadEvent_Normal_File_Test」を実行します。UiPath Studioで「DownloadEvent_Normal_File_Test」のワークフローを開いて選択した状態で、「ファイルを実行」からこのワークフローを実行します。
実行結果は当然ながら、1つ目の検証でエラーとなります。これでまずテストドリブンの1つ目の「テスト用ワークフロー開発」に関して完了です。
なお、テスト用のワークフローは、テスト項目の単位で複数作成し、テストの網羅性を高めることを推奨します。「DownloadEvent」については、別のテストケースとして、サーバで動いているページのURLからデータを取得し、0件以上のデータが取得できることや異常系について別のテスト用ワークフローを用意し、品質強化を目指します。その他のテスト用ワークフローについては、後ほどの一覧で、簡単に紹介します。
ワークフロー開発
テスト用のワークフローができたので、次のステップである「DownloadEvent」のワークフローの実装に移ります。既に「DownloadEvent」の引数については定義済みです。
| 方向 | 引数名 | 型 | 既定値 | 説明 |
|---|---|---|---|---|
| 入力 | in_URL | String | "https://www.uipath.com/ja/news/events" | イベントページのURL |
| 入力 | in_MaximumNumberOfEvents | int32 | 10 | イベント取得の最大件数 |
テストドリブン型開発では、最初にテスト用のコードを準備しますが、UiPathの場合、引数の「既定値（デフォルト値）」というものが、便利に使用できます。これは、ワークフローにインプットで渡す引数に関して、呼び出し元からの指定がない場合、既定値として使用される値を、そのワークフロー自身に定義できるというものです。
こちらを使用することで、最低限のテストケースとして、「最後までワークフローが稼働するかどうか」を単体テストとして、そのワークフローのみで検証することができます。
「DownloadEvent」のワークフローに関しては、「ブラウザーを開く」と「データスクレイピング」を組み合わせるものとなります。ひとまず、このワークフロー単体で動かし、エラーとならなければ最低限のテストケースは「クリア」となります。
ワークフロー単体が問題なく動くことを確認した上で、早速テスト用のワークフローからのテストも試します。先ほどと同様に、UiPath Studioで「DownloadEvent_Normal_File_Test」のワークフローを開いて選択した状態で、「ファイルを実行」からこのワークフローを実行します。
今回は、どのような結果になるのでしょうか。エラー（例外）が発生しなければ、テストはクリアですが、通常ここで何度もエラーが発生します。そのエラーを修正、再テストを繰り返し、ワークフローを完成させます。テスト用のワークフローが、最後までエラーなしで終了すれば、テストドリブン型開発の2つ目の「自動化ワークフロー開発」は完了です。
リファクタリング
テストドリブン型開発の最後のステップとして、リファクタリングがあります。これは、前段のステップで取りあえず最後まで動くようになったワークフローを、より良いものに改修していく工程です。RPAに関しては、「待ち処理の見直し」「自動化対象システムの要素特定方法の安定性向上」など幾つか、リファクタリングのポイントがあります。
リファクタリングに関しては、テスト用のワークフローのおかげで、ワークフローの修正後にこれを実行するだけでその実装結果の良しあしが簡単に判別できます。リファクタリングが完了すると、テストドリブン型開発の3つ目の「リファクタリング」が完了となり、一連の流れが終了したものとなります。
その他のテストケース、ワークフロー
「DownloadEvent」に関しては、その他のテストケースとして、ファイルではなくURLから正しくスクレイピングが行え、結果がDataTableとして取得できることがあります。エラーのケースとして、URLが不正な場合、イベントページの仕様が変わりスクレイピングが失敗するケースをテスト用のワークフローとして作成します。
「FilterEvent」「SendMail」についても、同様にテストケースを作成し、それに合わせたテスト用ワークフローを作成していきます。
| ワークフロー | テスト用ワークフロー | テスト項目 | テスト用のワークフローの結果（期待値） |
|---|---|---|---|
| DownloadEvent | DownloadEvent_Normal_File_Test.xaml | ローカルのHTMLからスクレイピングが行え、DataTableに変換できること Assert項目 ・スクレイピング後のDataTableのレコード件数が10件であるかどうか ・1つ目のレコードの「title」が、"UiPath導入検討者向けハンズオンセミナー"であるかどうか ・1つ目のレコードの「url」が、"https://www.uipath.com/ja/handson-seminar-20200327"であるかどうか |
Success |
| DownloadEvent_Normal_Web_Test.xaml | URLからスクレイピングが行え、DataTableに変換できること Assert項目 ・スクレイピング後のDataTableのレコード件数が0件ではないこと |
Success | |
| DownloadEvent_Error_Test.xaml | URLに誤りがある場合やイベントページの仕様が変わりスクレイピングが失敗するケース | SystemException | |
| FilterEvent | FilterEvent_Normal_Test.xaml | Assert項目 ・フィルタリング後のDataTableのレコード件数が8件であるどうか |
Success |
| SendMail | SendMail_Normal_Test.xaml | Assert項目 ・下書きフォルダにドラフトメールが生成されているかどうか |
Success |
基本的に正常ケースであれば、「IF(条件)」をAssertとして使用することで期待通りのアウトプットか否かを検証し、正常であればテスト用のワークフローは何事もなく終了します。例外発生においては、Assertでの失敗もしくはその他の問題が考えられます。
一方で、異常ケースの場合、わざとインプットに問題のものを入れ、それが正しく異常として処理されるかどうかを確認したいものです。この場合、テスト用のワークフローの結果が、例外として終了するかどうかで判断するのが一つの手となります。上記テーブルの「テスト用のワークフローの結果（期待値）」は、これを意味します。
なお、異常ケースにおいて厳密に例外の種類も検証する場合、「Try Catch」を用いて、検証します。
次回は、テストの自動化と継続的インテグレーション
今回は、テストドリブン型のRPA開発方法について、具体的なケースを用いて説明しましたが、いかがでしたでしょうか。実践するためのイメージがつかめたかと思います。次回は、今回テストドリブン型の開発で作成したテスト用ワークフロー全てを一括で実行し、結果を確認する方法を紹介し、その自動化したテストが継続的に実行できる環境を作ります。
筆者紹介
井上秀和
データスクレイピング、データマイニング、UIオートメーションをRuby、Python、そしてUiPathで行うことを得意とする。オブジェクト指向を好み、デスクトップOSは、昔Solaris、ちょっと前Ubuntu、最近macOSを愛用。
IT業界で、プログラマー、プロジェクトマネジャー、ビジネスアナリスト、コンサルタントといった役割で、モバイルアプリやWindowsアプリ、Webアプリ、トレーディングシステムの開発、構築、および業務改善に従事。現在は、RPA業界で業務自動化をライフワークとしている。
Copyright © ITmedia, Inc. All Rights Reserved.
Test & Tools 鬯ｯ�ｮ�ｽ�ｫ�ｽ�ｽ�ｽ�ｪ鬮ｯ蛹ｺ�ｻ繧托ｽｽ�ｿ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｺ鬮｣蛹�ｽｽ�ｵ髫ｴ竏ｵ�ｺ�ｷ�ｽ�ｸ�ｽ�ｷ�ｽ�ｽ�ｽ�ｹ髫ｴ雜｣�ｽ�｢�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｳ鬯ｩ蟷｢�ｽ�｢�ｽ�ｽ�ｽ�ｧ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｭ鬯ｩ蟷｢�ｽ�｢髫ｴ雜｣�ｽ�｢�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｳ鬯ｩ蟷｢�ｽ�｢�ｽ�ｽ�ｽ�ｧ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｰ
- 繝�せ繝郁�蜍募喧縺ｫ譛驕ｩ蛹悶＆繧後◆AI繧ｨ繝ｼ繧ｸ繧ｧ繝ｳ繝医ｒUiPath縺梧署萓幃幕蟋九√◎縺ｮ蜉ｹ譫懊���
- Google縲∫┌譁吶が繝ｼ繝励Φ繧ｽ繝ｼ繧ｹ閼�ｼｱ諤ｧ繧ｹ繧ｭ繝｣繝ｳ繝��繝ｫ縲薫SV-Scanner V2.0.0縲榊�髢九繧ｳ繝ｳ繝�リ繧ｹ繧ｭ繝｣繝ｳ縺ｫ蟇ｾ蠢懊√◎縺ｮ莉悶�譁ｰ讖溯�縺ｯ��
- 蠕ｹ蠎墓ｯ碑ｼ�ｼ壹悟�謨｣繝医Ξ繝ｼ繧ｷ繝ｳ繧ｰ縺ｯAPM縺ｮ荳ｻ隕∵ｩ溯�縲阪→縺�≧蜍倬＆縺��縺ｪ縺懃函縺ｾ繧後ｋ��
- 繧｢繧ｸ繝｣繧､繝ｫ髢狗匱縺ｮ蠢�∮驛ｨ縲後せ繧ｯ繝ｩ繝�縺ｮ5螟ｧ繧､繝吶Φ繝医阪ｒ隗｣隱ｬ
- GitHub Copilot縺ｧ蜉ｹ邇�噪縺ｪ繝�ヰ繝�げ繧貞ｮ溽樟縺吶ｋ5縺､縺ｮ遘倡ｭ悶繝舌げ菫ｮ豁｣縺九ｉ繝�せ繝育函謌舌∪縺ｧ繧偵←縺�柑邇�喧縺ｧ縺阪ｋ縺ｮ縺�
- 謾ｹ繧√※蟄ｦ縺ｶDevOps縺ｮ蝓ｺ逶､縲縲靴I縲阪靴T縲阪靴D縲阪�蠖ｹ蜑ｲ縺ｨ縺ｯ
- 窶廨it縺ｮRust蛹問昴′騾ｲ繧�溘豕ｨ逶ｮ縺ｮ縲隈it 2.49縲阪′繝ｪ繝ｪ繝ｼ繧ｹ
- CI/CD繝代う繝励Λ繧､繝ｳ縺ｧ遏･縺｣縺ｦ縺翫￥縺ｹ縺阪�9縺､縺ｮ隕∫ｴ�縲阪荳闊ｬ逧�↑險倅ｺ九�縺翫ｈ縺�5蛟阪�螟ｧ繝懊Μ繝･繝ｼ繝�縺ｧ隗｣隱ｬ
- APM vs. APM縲2縺､縺ｮ驕輔＞繧�5縺､縺ｮ隕ｳ轤ｹ縺ｧ隗｣隱ｬ
- 遉ｾ蜀�た繝輔ヨ繧ｦ繧ｧ繧｢繝�せ繝亥ｮ滓命莨∵･ｭ縺ｮ90��ｻ･荳翫′邨碁ｨ薙≫懷�陬ｽ蛹悶�繧ｸ繝ｬ繝ｳ繝樞昴→縺ｯ縲繧ｪ繝ｼ繝�ぅ繝輔ぃ繧､隱ｿ譟ｻ
- 繝�せ繝郁�蜍募喧縺ｫ譛驕ｩ蛹悶＆繧後◆AI繧ｨ繝ｼ繧ｸ繧ｧ繝ｳ繝医ｒUiPath縺梧署萓幃幕蟋九√◎縺ｮ蜉ｹ譫懊���
- Google縲∫┌譁吶が繝ｼ繝励Φ繧ｽ繝ｼ繧ｹ閼�ｼｱ諤ｧ繧ｹ繧ｭ繝｣繝ｳ繝��繝ｫ縲薫SV-Scanner V2.0.0縲榊�髢九繧ｳ繝ｳ繝�リ繧ｹ繧ｭ繝｣繝ｳ縺ｫ蟇ｾ蠢懊√◎縺ｮ莉悶�譁ｰ讖溯�縺ｯ��
- 蠕ｹ蠎墓ｯ碑ｼ�ｼ壹悟�謨｣繝医Ξ繝ｼ繧ｷ繝ｳ繧ｰ縺ｯAPM縺ｮ荳ｻ隕∵ｩ溯�縲阪→縺�≧蜍倬＆縺��縺ｪ縺懃函縺ｾ繧後ｋ��
- APM vs. APM縲2縺､縺ｮ驕輔＞繧�5縺､縺ｮ隕ｳ轤ｹ縺ｧ隗｣隱ｬ
- 窶廨it縺ｮRust蛹問昴′騾ｲ繧�溘豕ｨ逶ｮ縺ｮ縲隈it 2.49縲阪′繝ｪ繝ｪ繝ｼ繧ｹ
- AI縺ｫ繧医ｋAI縺ｮ菫ｮ豁｣縺ｯ蜿ｯ閭ｽ縺九GitHub Copilot Autofix縺九ｉ隕九∴縺ｦ縺上ｋAI縺ｮ譁ｰ縺溘↑隱ｲ鬘�
- Jenkins縺ｫ莉｣繧上ｋCI/CD繝��繝ｫ縲繝医ャ繝�10
- GitHub Copilot縺ｧ蜉ｹ邇�噪縺ｪ繝�ヰ繝�げ繧貞ｮ溽樟縺吶ｋ5縺､縺ｮ遘倡ｭ悶繝舌げ菫ｮ豁｣縺九ｉ繝�せ繝育函謌舌∪縺ｧ繧偵←縺�柑邇�喧縺ｧ縺阪ｋ縺ｮ縺�
- 謾ｹ繧√※蟄ｦ縺ｶDevOps縺ｮ蝓ｺ逶､縲縲靴I縲阪靴T縲阪靴D縲阪�蠖ｹ蜑ｲ縺ｨ縺ｯ
- 謾ｹ繧√※遒ｺ隱阪＠縺ｦ縺翫″縺溘＞縲後せ繝医�繝ｪ繝ｼ繝昴う繝ｳ繝医阪→縲梧凾髢楢ｦ狗ｩ阪ｂ繧翫阪�驕輔＞
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。