【UiPath】テストケース入門（1）_自動テストを始めよう！

## 1. はじめに


UiPath Studioで自動テスト(テストケース)ができるようになりましたが、まとまっている記事が無かったのでまとめました。

![Animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/668b9478-12f3-ce24-4a9d-1d6f64150f1e.gif)

全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風にまとめると

- ロボットの動作の正しさを保証するため
- レビューの工数を下げるため
- リファクタリングをしやすくするため
- ロボットの品質を高めるため
- テストそのものの工数を削減するため
- バグを潰すため
- 仕様書の代わりになるため

https://zenn.dev/tis1116/articles/bef862a5754187

となります。

### 2.2. 何をどうテストするのか考える

UiPathではテストケースという機能を使って自動テストをしていきますが、
何をどうやってテストするかは、かなり考えどころです。

#### 2.2.1. テストパターン

テストの分類は流派がありますが、今回は以下の考え方で進めます。
ただし、本記事では異常系も**想定した対処ができれば結果は成功**というように作ります。

- 正常系テスト
    - 想定通りで期待通りの動きができるか確認するテスト
- 異常系テスト
    - だいたい想定はしているけど期待はしていない時に対処できるか確認するテスト(準正常系とも呼ぶ)
    - 想定も期待もしていない時に対処できるか確認するテスト

|   | 想定 | 期待 |
|:-:|:-:|:-:|
| 正常系 | ○  | ○ |
| 異常系(準正常系)  | ○ | ×  |
| 異常系  | ×  | ×  |

[「正常系テスト」と「異常系テスト」と「準正常系テスト」の違い](https://wa3.i-3-i.info/diff610test.html)

#### 2.2.2. どこまでカバーするのか

**考えられるすべてのパターンを網羅する必要はありません。**
また、すべてのアクティビティを通ること(カバレッジ100%)を目指す必要もありません。

ケースバイケースですが**すべてのワークフローに対してテストを作りこむ必要もありません。**

**テストケースを作り込めばそれだけ開発・維持工数がかかるのも事実です。**
なので最初に取り組むのは**クリティカルな部分**や**頻繁な改修**が予想される部分のみで良いでしょう。

その辺りはそれぞれの開発状況によると思います。

**正常系を1つ、異常系を1つ**作っておけばとりあえず安心できます。

#### 2.2.3. どうテストするのか

単純な値の受け渡しをしているワークフローであればわかりやすいです。
出力引数の値と比較すれば良いだけなので。

しかし、RPAによくあるファイルの操作は結構比較が難しいので、読み込んで判断させるのか、存在チェックのみにするのかなどはそれぞれ考える必要があります。

ブラウザの操作も同様。

この辺は模索中です。

## 3. ロボットの準備

ここからは、手順に沿って自動テストを作成して実行できるまでを解説します。
まずはテストをするロボットについて解説します。

### 3.1. 対象のロボット

今回は実用性皆無のロボット **「数字を3倍にして返してくれる君」**
でテストケースを作成してみましょう。

特徴は以下のとおり

- 入力引数に設定された数字を3倍にして出力します
- 計算部分は別のワークフローとして呼び出します

#### 3.1.1. 概要

```mermaid
graph TD;
    Start("開始")-->
    Node1["開始ログ"]-->
    Node2["数字を変数に設定する"]-->
    Node3["変数Numに入力引数in_Numを代入"]-->
    Node4["変数Num1=Num+Num"]-->
    Node5["変数Num2=Num1+Num"]-->
    Node6["出力引数out_3TimesNumに変数Num2を代入"]-->
    Node7["結果の数字を出力"]-->
    End("終了")

    subgraph "3倍掛け算.xaml"
        Node3
        Node4
        Node5
        Node6
    end
```

### 3.2. 各シーケンス

UiPathで実際に作成するとこんな感じです。
UiPath Studioで作成しておいてください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/82167be4-c543-64cd-09a9-25ac3c25f4a5.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/b860e079-c8ab-7532-3f9f-d8fd20e416a9.png)

:::note alert
### 3.3. このロボットの問題点

単純に`出力引数=入力引数×3`をすれば良いのに足し算を2回して変数を増やしています。
今はあえてこうしています。

:::

## 4. 自動テストを始めるまでの手順解説

自動テストの対象を`3倍掛け算.xaml`にして説明していきます。

### 4.1. フォルダ構成

最終的なフォルダ構成としては図の通りになります。
一応Dドライブ直下にロボット管理フォルダを置いていますが、任意の場所で構いません。

```mermaid
graph LR;

    subgraph "ロボット管理フォルダ"
        subgraph "プロジェクトフォルダ"
            Node3["Main.xaml"]
            Node4["3倍掛け算.xaml"]
            
            subgraph "Testsフォルダ"
                Node7["テスト_3倍掛け算.xaml"]
            end          
        end
        
        subgraph "テストデータフォルダ"
            subgraph "テスト_3倍掛け算フォルダ"
                Node9["テスト_3倍掛け算.xlsx"]
      
            end
        end
    end

```

### 4.2. テストケース用フォルダの作成

UiPath Studioでプロジェクトを開いておいてください。

プロジェクトパネルで右クリック→追加→フォルダー
プロジェクト内に`Tests`フォルダを作成してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/afdc9ff4-65ae-4b6e-8ec1-e0b908a6216d.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/606eb8c3-ae9e-0256-672f-893bdedc4d4d.png)


### 4.3. テストケースの作成

プロジェクトパネルから`3倍掛け算.xaml`を右クリックして`テスト ケースを作成`を選択してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/68587c15-ae2d-70ad-c2ef-16f5cb11750a.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/89a8286e-2ed6-3dea-8ae9-fd77f968c92b.png)


#### 4.3.1. 名前

`テスト_`を先頭に付けて`テスト_3倍掛け算`としてください。

#### 4.3.2. 場所

先程作った`Tests`フォルダを指定してください。

#### 4.3.3. 作成元

`ビヘイビア駆動開発(BDD)テストケース`を指定してください。

[ビヘイビア駆動開発とは](https://zenn.dev/miya_tech/articles/707757332608ec)

#### 4.3.4. 実行テンプレート

`実行テンプレートなし`を指定してください。

#### 4.3.5. テストデータ

`テスト データ`は`なし`のままでOKです。

### 4.4. テストケース確認

画像のようにワークフローが`When`シーケンスの中にあるテストケースが作成されればOKです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/83fcf6c0-0708-1237-c598-a920c4745bbf.png)



### 4.5. テストデータ用のフォルダを作成する

テストデータを管理するフォルダを作成します。
今回はxamlが入っている`PJ`フォルダが入っている`ロボット管理`フォルダ内に作成しましょう。
=Studioのプロジェクト管理外

`テストデータ`フォルダを作成します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/2db83f26-44e5-7426-617d-ce40df829929.png)


### 4.6. テストケースと同じ名前のフォルダを作成する。

`テストデータ`フォルダ内に作成したテストケースと同じ名前のフォルダ`テスト_3倍掛け算`を作成します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/f0e23c92-dc1d-8d21-43a6-a8b78eded96a.png)



### 4.7. テストパターンを考える

今回は単純な掛け算ですので数字をいくつか入力引数に設定して、結果が計算通りならOKというテストができそうです。


### 4.8. テストデータを作成する

テストパターンを考えたらテストデータを作成しましょう。テストデータを作っている内に新しくパターンを思いつくこともあると思います。

#### 4.8.1. テストデータExcelファイル作成

今回はExcelファイル `テスト_3倍掛け算.xlsx`を`テスト_3倍掛け算`フォルダの中に作成します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/e81811af-0458-159b-e931-9c4d1acf64a7.png)

#### 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`が一致すればテスト成功になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/5fbd4fff-8609-b7b8-c89d-40d83eb455da.png)


:::note
jsonでも作成できます。慣れている場合はそちらでもOK。
今回のようなシンプルな場合、jsonファイルであればプロジェクト内で管理した方が良いかもしれません

次回解説以降の複雑なパターンを見越して、プロジェクト外でテストデータを作成しています。
:::




### 4.9. テストデータを読み込む
Excelファイルを保存して閉じてください。
Studioに戻り、テストデータをインポートしましょう。

プロジェクトパネルで`テスト_3倍掛け算.xaml`を右クリック→`テスト データを追加`を選択。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/4a349b0d-16cc-0134-eee1-5658b9014c50.png)

ソースを`ファイル`にして、`テストデータ`に先程作成したExcelファイルのパスを選択します。

自動でExcelファイルが読み込まれます。
インポートをクリックしてください。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/c22cab36-c8d0-f70e-3214-2335f394e022.png)


:::note warn
`_`(アンダーバー)がなくなっているように見えますが読み込んだ後は復活します。
仕様かバグかは不明

:::


:::note warn
テストデータ追加後はプロジェクトに保存されます。
`テスト_3倍掛け算.xlsx`とは関係が無くなるので注意してください。
:::

テストケースの引数パネルに読み込んだテストデータの1つ目のデータが表示されています

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/52fa254b-2133-9e81-7559-7322c12aae5f.png)

:::note warn
今のところ、Excelファイルから読み込んだ引数はすべてString型になるようです。
JSONファイルではStringとint64になりました。
:::

テストエクスプローラーに各テストパターンが表示されました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/53eeaefc-0def-ad2f-f43d-1193be5a9281.png)


これでテストデータの準備完了です。

### 4.10. テストケースの作りこみ

Given、When、Thenとあるので順番に説明します。

#### 4.10.1. Given

Givenではテスト対象のワークフローの**前処理**を行います。

今回はログを出力するだけですが、次回解説以降の「Excelファイルを読み込む」などがある場合はここで処理をします。
ファイル操作をする場合はここでテスト用のファイルを生成したりコピーします。

##### 4.10.1.1. 開始ログ
テストのログを追うために開始ログを用意します。

```vb
"テストID："+TestID+" "+TestDescription +" 開始"
```


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/65ca985d-6ecf-8c3c-ef03-df594f5003de.png)

:::note
情報量を増やすために`TestInput_in_Num`など出力しても良いです。
:::

#### 4.10.2. When
テスト対象になるワークフローがあらかじめ入っています。
基本的にはアクティビティはいじらなくて良いです。

ワークフローの動作によってはトライキャッチで囲んだりします。

##### 4.10.2.1. 変数作成
出力引数を受け取る`Int32`型の変数`CalcNum`を作成しましょう。スコープは全体にしておきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/7447b533-355a-4c28-6afa-6ee3087bc215.png)


##### 4.10.2.2. 引数設定

`引数をインポート`を選択してください。
`3倍掛け算`の入力引数`in_Num`に`TestInput_in_Num`を渡します。
そのままだと文字列型でエラーになるので数値に変換します。
```vb
Int32.Parse(TestInput_in_Num)
```
出力引数も設定します。
`CalcNum`を設定してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/60316555-5bbd-f3db-1c59-3310f60889e2.png)

#### 4.10.3. Then

Thenでは**ワークフローを実行した結果を検証**します。
また、操作したファイルを消すなどテスト後の後始末をします。
**テストは複数回、何も気にせず実行するため、テスト前後で状況が変わらないようにする必要があります。**

今回はファイルを操作していないので検証のみ配置します。

##### 4.10.3.1. 検証

検証用のアクティビティがいくつかありますが、今回は`式を演算子で検証`を使用します。

アクティビティパネルから、`式を演算子で検証`を`Then`の中に配置します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/073831a9-b2c3-51c8-e598-2be9c7c7fbf7.png)

- **最初の式：** 検証される結果`CalcNum`
- **演算子：** `Equality`
- **2番目の式：** 想定される結果`Int32.Parse(ExpectedResult_out_3TimesNum)`
にします。
これで検証する結果が想定と等しければ`True`となり、そのテストパターンは成功となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/c866c895-c2c9-cd4e-a8c6-d6c3fbeaf2cf.png)

### 4.11. テストケース完成

これで準備完了です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/b18bd554-7e1b-a4d4-09d7-7e73f7cff368.png)



## 5. テスト実行

テストエクスプローラーからテストケースを右クリックしてデバッグ実行してみましょう。(実行でもOK)

それぞれ順番に実行され、検証が成功すれば緑のチェックが入ります。

![Animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/668b9478-12f3-ce24-4a9d-1d6f64150f1e.gif)

## 6. 何が嬉しいのか

デバッグ実行で毎回、変数を変えれば良いのでは？と思いますが、開発後半やリリース後の改修になってくると威力を発揮します。それを体験してみましょう。


### 6.1. ワークフローを改修してみる

`3倍掛け算.xaml`の中身が足し算の連続で汚いのですっきりさせます(**リファクタリング**)。

#### 6.1.1. 改修前

掛け算のない世界でした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/836f9cc7-eb4a-e327-6b4e-92022e423d8d.png)

:::note
シーケンスが緑になっているのはテストが実行されたためです。
:::

#### 6.1.2. 改修後

アクティビティ1つで済ませました
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/3534646d-5c26-0428-ef20-53c27399d7e7.png)


#### 6.1.3. 再テスト

テストケースはそのままなので再度実行すると…

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/84456d87-85cc-0bb2-8fd8-c821aa18b92e.png)

OK！
大丈夫そうです。

### 6.2. つまり

何らかの改修をしたとしても
**テストが通ったので大丈夫！！**
と胸を張って再度パブリッシュできます。

また、変更したワークフローが全体の後半であれば毎回最初からデバッグをして見守るのも非効率的です。

パターンを増やすのも簡単ですし、実行前後で他に影響を及ぼさないように作れば何度でも試すことができます。

:::note alert
もしもここで赤＝失敗になった場合、改修後に機能が悪化しているので修正が必要です。
:::

## 7. 異常系の追加と対応
ちなみに、Int32の限界値は`2,147,483,647`です。これを超えるとエラーで止まります。

テストパターンに正常系だと思って`1,000,000,000`を追加してみました。
`テストデータの更新`でExcelにパターンを追加して更新します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/c6b78101-0d8a-4963-6f07-5f342937a3a3.png)

![Animation2.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/dba94681-a6b6-f1ff-cb91-008e03620fc8.gif)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/537cd440-968f-c73f-5f2d-157f47ce27db.png)

**オーバーフロー**してしまいました。

この時の対応として、エラーが発生してもいいようにテストケースとワークフローを改修します。

対策はいくつか考えられますが、今回は単純にオーバーフローエラーが発生したらログを出しましょう。

### 7.1. テストデータの更新
オーバーフローになると`Calc_Num`は0のままなのでテストデータも0に変更します。
`TestDescription`も異常系に変更しましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/ac9ae776-b7a3-77ef-3200-819a3dd3547e.png)

:::note
今回はInt32のオーバーフローという原因がつかめているので`巨大な数字`をもっと
具体的に`計算結果がInt32の最大値を超える場合`などにしても良いです。
テストパターンの説明が具体的だと後々の改修の時にラクになります。
:::

### 7.2. テストケースの改修

- トライキャッチでワークフローを囲みます
- `exeption`を`OverflowExeption`
- ログ


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/7228972e-26a7-cb92-634a-8fb9c3abc3c9.png)

### 7.3. 再度テストを実行

再度テストします。今度はデバッグではなく**実行**します。
テストケースを変更しているのですべてのパターンテストを実行しましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755504/c2302414-0c1a-12e7-945d-171b9ed3d364.png)

テストが通りました！
これをもとに実際の`main.xaml`にも同じように対応を追加しましょう。

:::note
仕様かどうかはわかりませんがデバッグでは検証が成功してもエラーが途中で発生していれば失敗扱いになるようです。
:::


:::note warn
実際は型をLongに変更するなど対応すればよいです。
:::





## 8. 参考資料


https://docs.uipath.com/ja/studio/standalone/2024.4/user-guide/application-testing-test-cases

https://rpa.bigtreetc.com/column/test-automated/


## 9. まとめ

**テストケース作ろう！**

テストケースの基礎について理解いただけましたか？

実際、テストケースとテストデータの作成には工数がかかり、**ワークフローと同時に保守が必要**です。

ですが、複雑なパターンを網羅していなくても正常系のテスト1つあるかないかでその後の開発と保守の安心感が段違いです。

次回からはRPAでありがちな**Excelが絡んだ場合**のテストについて触れていきます。