1. はじめに
UiPath Studioで自動テスト(テストケース)ができるようになりましたが、まとまっている記事が無かったのでまとめました。
全5回の予定でUiPathのテストについて解説していきます。
1.1. この記事でできること
- UiPathでのテストの必要性が理解できる
- UiPath Studioで単体テストが実行できるようになる
1.2. この記事の対象者
- UiPath StudioでのRPA開発者
- UiPath開発チーム運営者
1.3. 動作環境
- Windows11
- UiPath Studio 2024.2.1
- Windows
- VB.NET
- UiPath.Testing.Activities 23.10.1
1.4. RPA開発環境
- 開発を特定のフォルダやサーバー内で実施している
- 特定のフォルダやサーバーにアクセスできる開発機でテストを実行したい
今回はOrchestratorでのテスト実行は対象にしていません。
2. 自動テストとは
2.1. 自動テストの必要性
自動テスト≒テストコードとします。
その必要性はリンク先が分かりやすく解説してくれています。
短くRPA風にまとめると
- ロボットの動作の正しさを保証するため
- レビューの工数を下げるため
- リファクタリングをしやすくするため
- ロボットの品質を高めるため
- テストそのものの工数を削減するため
- バグを潰すため
- 仕様書の代わりになるため
となります。
2.2. 何をどうテストするのか考える
UiPathではテストケースという機能を使って自動テストをしていきますが、
何をどうやってテストするかは、かなり考えどころです。
2.2.1. テストパターン
テストの分類は流派がありますが、今回は以下の考え方で進めます。
ただし、本記事では異常系も想定した対処ができれば結果は成功というように作ります。
- 正常系テスト
- 想定通りで期待通りの動きができるか確認するテスト
- 異常系テスト
- だいたい想定はしているけど期待はしていない時に対処できるか確認するテスト(準正常系とも呼ぶ)
- 想定も期待もしていない時に対処できるか確認するテスト
| 想定 | 期待 | |
|---|---|---|
| 正常系 | ○ | ○ |
| 異常系(準正常系) | ○ | × |
| 異常系 | × | × |
「正常系テスト」と「異常系テスト」と「準正常系テスト」の違い
2.2.2. どこまでカバーするのか
考えられるすべてのパターンを網羅する必要はありません。
また、すべてのアクティビティを通ること(カバレッジ100%)を目指す必要もありません。
ケースバイケースですがすべてのワークフローに対してテストを作りこむ必要もありません。
テストケースを作り込めばそれだけ開発・維持工数がかかるのも事実です。
なので最初に取り組むのはクリティカルな部分や頻繁な改修が予想される部分のみで良いでしょう。
その辺りはそれぞれの開発状況によると思います。
正常系を1つ、異常系を1つ作っておけばとりあえず安心できます。
2.2.3. どうテストするのか
単純な値の受け渡しをしているワークフローであればわかりやすいです。
出力引数の値と比較すれば良いだけなので。
しかし、RPAによくあるファイルの操作は結構比較が難しいので、読み込んで判断させるのか、存在チェックのみにするのかなどはそれぞれ考える必要があります。
ブラウザの操作も同様。
この辺は模索中です。
3. ロボットの準備
ここからは、手順に沿って自動テストを作成して実行できるまでを解説します。
まずはテストをするロボットについて解説します。
3.1. 対象のロボット
今回は実用性皆無のロボット 「数字を3倍にして返してくれる君」
でテストケースを作成してみましょう。
特徴は以下のとおり
- 入力引数に設定された数字を3倍にして出力します
- 計算部分は別のワークフローとして呼び出します
3.1.1. 概要
3.2. 各シーケンス
UiPathで実際に作成するとこんな感じです。
UiPath Studioで作成しておいてください。
4. 自動テストを始めるまでの手順解説
自動テストの対象を3倍掛け算.xamlにして説明していきます。
4.1. フォルダ構成
最終的なフォルダ構成としては図の通りになります。
一応Dドライブ直下にロボット管理フォルダを置いていますが、任意の場所で構いません。
4.2. テストケース用フォルダの作成
UiPath Studioでプロジェクトを開いておいてください。
プロジェクトパネルで右クリック→追加→フォルダー
プロジェクト内にTestsフォルダを作成してください。
4.3. テストケースの作成
プロジェクトパネルから3倍掛け算.xamlを右クリックしてテスト ケースを作成を選択してください。
4.3.1. 名前
テスト_を先頭に付けてテスト_3倍掛け算としてください。
4.3.2. 場所
先程作ったTestsフォルダを指定してください。
4.3.3. 作成元
ビヘイビア駆動開発(BDD)テストケースを指定してください。
4.3.4. 実行テンプレート
実行テンプレートなしを指定してください。
4.3.5. テストデータ
テスト データはなしのままでOKです。
4.4. テストケース確認
画像のようにワークフローがWhenシーケンスの中にあるテストケースが作成されればOKです。
4.5. テストデータ用のフォルダを作成する
テストデータを管理するフォルダを作成します。
今回はxamlが入っているPJフォルダが入っているロボット管理フォルダ内に作成しましょう。
=Studioのプロジェクト管理外
テストデータフォルダを作成します。
4.6. テストケースと同じ名前のフォルダを作成する。
テストデータフォルダ内に作成したテストケースと同じ名前のフォルダテスト_3倍掛け算を作成します。
4.7. テストパターンを考える
今回は単純な掛け算ですので数字をいくつか入力引数に設定して、結果が計算通りならOKというテストができそうです。
4.8. テストデータを作成する
テストパターンを考えたらテストデータを作成しましょう。テストデータを作っている内に新しくパターンを思いつくこともあると思います。
4.8.1. テストデータExcelファイル作成
今回はExcelファイル テスト_3倍掛け算.xlsxをテスト_3倍掛け算フォルダの中に作成します。
4.8.2. テストデータ列用意
Excelファイルの中身はA1セルから次のようにしてください。
- TestID：何個目のテストパターンかを記載しましょう
- TestDescription：正常系か異常系を記載して、テストの説明を書きましょう
- TestInput列：テスト対象のワークフローに渡される入力引数です
- ExpectedResult列：期待する結果の内容です
4.8.3. テストデータ用意
今回の例では
3倍掛け算.xamlの入力引数は3倍される数字、出力引数は3倍された数字なので、テストデータは以下のようになります。
| TestID | TestDescription | TestInput_in_Num | ExpectedResult_out_3TimesNum |
|---|---|---|---|
| 1 | 正常系 | 3 | 9 |
| 2 | 正常系 | 4 | 12 |
| 3 | 正常系:大きな数字 | 10000 | 30000 |
-
3を渡すと9が返ってくるか -
4を渡すと12が返ってくるか -
10000を渡すと30000が返ってくるか
をこれでテストできます。
テスト実行の結果、出力引数out_3TimesNumとExpectedResult_out_3TimesNumが一致すればテスト成功になります。
jsonでも作成できます。慣れている場合はそちらでもOK。
今回のようなシンプルな場合、jsonファイルであればプロジェクト内で管理した方が良いかもしれません
次回解説以降の複雑なパターンを見越して、プロジェクト外でテストデータを作成しています。
4.9. テストデータを読み込む
Excelファイルを保存して閉じてください。
Studioに戻り、テストデータをインポートしましょう。
プロジェクトパネルでテスト_3倍掛け算.xamlを右クリック→テスト データを追加を選択。
ソースをファイルにして、テストデータに先程作成したExcelファイルのパスを選択します。
自動でExcelファイルが読み込まれます。
インポートをクリックしてください。
_(アンダーバー)がなくなっているように見えますが読み込んだ後は復活します。
仕様かバグかは不明
テストデータ追加後はプロジェクトに保存されます。
テスト_3倍掛け算.xlsxとは関係が無くなるので注意してください。
テストケースの引数パネルに読み込んだテストデータの1つ目のデータが表示されています
今のところ、Excelファイルから読み込んだ引数はすべてString型になるようです。
JSONファイルではStringとint64になりました。
テストエクスプローラーに各テストパターンが表示されました。
これでテストデータの準備完了です。
4.10. テストケースの作りこみ
Given、When、Thenとあるので順番に説明します。
4.10.1. Given
Givenではテスト対象のワークフローの前処理を行います。
今回はログを出力するだけですが、次回解説以降の「Excelファイルを読み込む」などがある場合はここで処理をします。
ファイル操作をする場合はここでテスト用のファイルを生成したりコピーします。
4.10.1.1. 開始ログ
テストのログを追うために開始ログを用意します。
"テストID："+TestID+" "+TestDescription +" 開始"
情報量を増やすためにTestInput_in_Numなど出力しても良いです。
4.10.2. When
テスト対象になるワークフローがあらかじめ入っています。
基本的にはアクティビティはいじらなくて良いです。
ワークフローの動作によってはトライキャッチで囲んだりします。
4.10.2.1. 変数作成
出力引数を受け取るInt32型の変数CalcNumを作成しましょう。スコープは全体にしておきます。
4.10.2.2. 引数設定
引数をインポートを選択してください。
3倍掛け算の入力引数in_NumにTestInput_in_Numを渡します。
そのままだと文字列型でエラーになるので数値に変換します。
Int32.Parse(TestInput_in_Num)
出力引数も設定します。
CalcNumを設定してください。
4.10.3. Then
Thenではワークフローを実行した結果を検証します。
また、操作したファイルを消すなどテスト後の後始末をします。
テストは複数回、何も気にせず実行するため、テスト前後で状況が変わらないようにする必要があります。
今回はファイルを操作していないので検証のみ配置します。
4.10.3.1. 検証
検証用のアクティビティがいくつかありますが、今回は式を演算子で検証を使用します。
アクティビティパネルから、式を演算子で検証をThenの中に配置します。
-
最初の式： 検証される結果
CalcNum -
演算子：
Equality -
2番目の式： 想定される結果
Int32.Parse(ExpectedResult_out_3TimesNum)
にします。
これで検証する結果が想定と等しければTrueとなり、そのテストパターンは成功となります。
4.11. テストケース完成
これで準備完了です。
5. テスト実行
テストエクスプローラーからテストケースを右クリックしてデバッグ実行してみましょう。(実行でもOK)
それぞれ順番に実行され、検証が成功すれば緑のチェックが入ります。
6. 何が嬉しいのか
デバッグ実行で毎回、変数を変えれば良いのでは？と思いますが、開発後半やリリース後の改修になってくると威力を発揮します。それを体験してみましょう。
6.1. ワークフローを改修してみる
3倍掛け算.xamlの中身が足し算の連続で汚いのですっきりさせます(リファクタリング)。
6.1.1. 改修前
掛け算のない世界でした。
シーケンスが緑になっているのはテストが実行されたためです。
6.1.2. 改修後
アクティビティ1つで済ませました
6.1.3. 再テスト
テストケースはそのままなので再度実行すると…
OK！
大丈夫そうです。
6.2. つまり
何らかの改修をしたとしても
テストが通ったので大丈夫！！
と胸を張って再度パブリッシュできます。
また、変更したワークフローが全体の後半であれば毎回最初からデバッグをして見守るのも非効率的です。
パターンを増やすのも簡単ですし、実行前後で他に影響を及ぼさないように作れば何度でも試すことができます。
もしもここで赤＝失敗になった場合、改修後に機能が悪化しているので修正が必要です。
7. 異常系の追加と対応
ちなみに、Int32の限界値は2,147,483,647です。これを超えるとエラーで止まります。
テストパターンに正常系だと思って1,000,000,000を追加してみました。
テストデータの更新でExcelにパターンを追加して更新します。
オーバーフローしてしまいました。
この時の対応として、エラーが発生してもいいようにテストケースとワークフローを改修します。
対策はいくつか考えられますが、今回は単純にオーバーフローエラーが発生したらログを出しましょう。
7.1. テストデータの更新
オーバーフローになるとCalc_Numは0のままなのでテストデータも0に変更します。
TestDescriptionも異常系に変更しましょう。
今回はInt32のオーバーフローという原因がつかめているので巨大な数字をもっと
具体的に計算結果がInt32の最大値を超える場合などにしても良いです。
テストパターンの説明が具体的だと後々の改修の時にラクになります。
7.2. テストケースの改修
- トライキャッチでワークフローを囲みます
-
exeptionをOverflowExeption - ログ
7.3. 再度テストを実行
再度テストします。今度はデバッグではなく実行します。
テストケースを変更しているのですべてのパターンテストを実行しましょう。
テストが通りました！
これをもとに実際のmain.xamlにも同じように対応を追加しましょう。
仕様かどうかはわかりませんがデバッグでは検証が成功してもエラーが途中で発生していれば失敗扱いになるようです。
実際は型をLongに変更するなど対応すればよいです。
8. 参考資料
9. まとめ
テストケース作ろう！
テストケースの基礎について理解いただけましたか？
実際、テストケースとテストデータの作成には工数がかかり、ワークフローと同時に保守が必要です。
ですが、複雑なパターンを網羅していなくても正常系のテスト1つあるかないかでその後の開発と保守の安心感が段違いです。
次回からはRPAでありがちなExcelが絡んだ場合のテストについて触れていきます。