Katalon Studioでテストを自作した

# はじめに

わたしはWebアプリケーションのUIをテストする作業をソフトウェアで自動化する技術に関心があります。2018年1月以来わたしは [Katalon Studio](https://www.katalon.com/) というソフトウェアに注目しています。以前[「Katalon Studioとはどんなソフトウエアか」](https://qiita.com/kazurayam/items/aece5d314f84893a0a14#_reference-ddacffec3e84567a0caa)で概要を紹介しました。そして前回はRecord機能を使ってコードを自動生成しました。

今回は前回自動生成したKatalon Studioプロジェクトを手直しします。小規模だが自動化テストとよべる内容を備えていてエラー無しに動くKatalon Studioプロジェクトに仕立てます。

# 今回すること

前回[「Katalon StudioでRecordしてみた」](https://qiita.com/kazurayam/items/433876c0b3bc7f33f019)においてテスト一式をRecord機能を使って自動生成しました。ここで生成されたコードを調べてみるとオブジェクトの名前が不適当だったり、HTML内の特定の要素を特定するSelectorとしてのXPath式が冗長だったり。改善すべき箇所がたくさんあるのがわかります。そこで前回自動生成したコードをリファクタリングすることから始めます。外から見た動作仕様を変更せずにテスト・コードを書きかえます。オブジェクトの名前を分かりやすいものに変更し、Selectorを最適化していきます。

リファクタリングが済んだら次に verification すなわち「検証」の動作を導入します。Webページ間の遷移がちゃんとできているか、ページに表示された文字データが正しいものかどうかをチェックして、もしもダメだったらエラーを報告することをKatalon Studioにやらせます。

# 前提条件

- macOS High Siera 10.16, 
- Katalon Studio 5.4.1がインストール済みであること。まだならば[「Katalon Studioをインストールした」](https://qiita.com/kazurayam/items/135cb30233d11c2f4840)を参考に。

# サンプル in GitHub

この記事が説明するKatalon Projectのファイル一式をGitHubにアップしました。

-  https://github.com/kazurayam/CURA-Test-Project

このレポジトリのmasterブランチをローカルにcloneするにはこうします。

```
$ cd ~
$ mkdir katalon-workspace
$ cd katalon-workspace
$ git clone https://github.com/kazurayam/CURA-Test-Project.git
```

このレポジトリにはmasterプランチだけでなく、途中経過を保存したブランチがいくつかあります。

| ブランチ名 | 内容 |
|:--------:|:-------------|
| step0    | Recordで自動生成したばかり。リファクタリングする前。verification無し。Runすれば成功する  |
| step1    | Object Repositoryにページ毎サブフォルダ4つを追加し、Test Object群を配置し直した。Test Objectの名前はもとのまま |
| step2    | Test Objectの名前を見直した |
| step3    | Test Objectのselectorを見直した |
| step4    | 不要なTest Objectを削除した |
| step5    | ページ遷移のチェックを実装した |
| step6    | データのチェックを実装した |
| step7    | わざとverifyEqualがFAILするようにした、LogViewerの表示を確認するため |
| master   | 最終形 |

リモートのstep0ブランチをローカルに取り出すには下記の操作をします。

```
$ git checkout -b step0 origin/step0 
```


# 用語の定義

| 用語 | 定義 |
|:------|:----------|
|AUT|Application Under Testの略。テスト・コードが対象としているWebアプリケーション|
|Test Object| Object Repositoryのなかに作られたモノを集合的に Test Objectと呼ぶ。Test ObjectはTest CaseがアクセスしたいHTML要素がページの中のどこにあるかを示すSelector式のコンテナである。 ![スクリーンショット 2018-05-05 16.25.42.png](https://qiita-image-store.s3.amazonaws.com/0/52995/600745ef-7435-0dad-a1cc-4a06d04d1ea2.png) |
|Test Case |テストの処理手順を具体的に記述したGroovyスクリプトである。 ![スクリーンショット 2018-05-05 16.30.01.png](https://qiita-image-store.s3.amazonaws.com/0/52995/1e091727-2c42-8157-19b8-b01317240f95.png)
|

# 準備

[「Katalon StudioでRecordして見た」](https://qiita.com/kazurayam/items/433876c0b3bc7f33f019)を参考に あなたのPC上に `CURA Test Project` を作ってください。ないしは https://github.com/kazurayam/CURA-Test-Project をローカルにcloneしてブランチstep0をcheckoutしてください。

# Object Repositoryをリファクタリングする

Record機能が生成したCURA Test Projectのコードを調べてみるとイマイチなところがたくさんあります。リファクタリングしてスッキリさせましょう。

### Test ObjectをWebページ毎に仕分けしよう
Webサイト CURA Healthcare Service は次の４つのURLから構成されていました。

- http://demoaut.katalon.com/ ホーム・ページ
- http://demoaut.katalon.com/profile.php#login ログイン・ページ
- http://demoaut.katalon.com/#appointment 受診予約の入力ページ
- http://demoaut.katalon.com/appointment.php#summary 受診予約の確認ページ

一方でRecord機能がObject Repositoryの中にどんなTest Objectを生成したかというと、 `Page_CURA Healthcare Service` というフォルダをひとつ生成して、その中に20個弱のTest Objectを出力しました。下記のスクリーンショットのとおり。

![スクリーンショット 2018-05-04 6.42.04.png](https://qiita-image-store.s3.amazonaws.com/0/52995/89455327-1a7f-060a-8cc5-ae125deebb36.png)

AUTが4つのページで構成されているのだから、それと１対１に対応するようにObject Repositoryの下にページ毎に4つのフォルダを設けてTest Objectを再配置しましょう。そのほうが分かりやすいから。

| ページ | フォルダ名 |
|:--|:--|:--|
| ホーム・ページ | Page_CuraHomepage |
| ログイン・ページ | Page_Login |
| 受診予約の入力ページ | Page_CuraAppointment |
| 受診予約の確認ページ | Page_AppointmentConfirmation |

Object Repositoryをマウスで右クリックすると操作メニューが展開します。`New > Folder` と選択してフォルダを追加しましょう。
![スクリーンショット 2018-05-04 7.07.01.png](https://qiita-image-store.s3.amazonaws.com/0/52995/bb8c92f9-138c-6f9d-6b8c-8e16b8a00b54.png)

こうなりました。

![スクリーンショット 2018-05-04 8.43.14.png](https://qiita-image-store.s3.amazonaws.com/0/52995/1b1bfce8-cf8f-be44-3504-cc8581abe10d.png)

#### Test Objectをどのフォルダに移すべきか?を考える

たとえば `Page_CURA Healthcare Service/input_password` というTest Objectをダブルクリックすれば画面右ペインに属性が表示されます。

![スクリーンショット 2018-05-04 9.54.51.clipped.png](https://qiita-image-store.s3.amazonaws.com/0/52995/f143a5d9-7b33-4985-feab-f05ac9d442b4.png)

Object Propertiesの内容を見ればこのTest Objectに対応するHTML要素が `<input id="txt-username" name="username">` であるとわかります。この`<input>`タグがAUTのどのページにあったっけ？と考えます。Firefoxブラウザで http://devaut.katalon.com/ を開き PF12 キーを押して開発者ツールを起動してページのHTMLコードを調べましょう。 ... ログイン・ページのなかに`<input id="txt-username"`がありました。
![スクリーンショット 2018-05-04 10.23.47.png](https://qiita-image-store.s3.amazonaws.com/0/52995/368feaef-6cb0-843b-d379-c3ce6fb1d440.png)

だからTest Object `Page_CURA Healthcare Service/input_password` は `Page_Login/input_password` へ移動するのが適切だと判断できます。

こんなふうにしてTest Objectひとつひとつの氏素性を調べどのサブフォルダに移動すべきかを判断します。Test Objectをぜんぶ調べ終わった時、あなたはきっとRecord機能が自動生成したテスト・コードの全体を把握できているでしょう。

#### ドラッグ&ドロップでTest Objectを移動する

ページ毎のフォルダにRecord機能が自動生成したTest Objectたちを移動しましょう。ドラッグ＆ドロップできます。例えば `Page_CURA Healthcare Service/input_password` を `Page_Login/input_password` へ移動しましょう。

Test Objectをドラッグ＆ドロップするとKatalon StudioがTest Case `Basic` のコードを自動的に修正します。例えばこれ:

```
WebUI.setText(findTestObject('Page_CURA Healthcare Service/input_password'), 'ThisIsNotAPassword')

```

がこんなふうに

```
WebUI.setText(findTestObject('Page_Login/input_password'), 'ThisIsNotAPassword')

```
自動的に修正されます。eclipseのJavaエディタでリファクタリング機能のrename classしたような感じです。

`Page_CURA Healthcare Service`サブフォルダの中にあった２０個弱のTest Objectをぜんぶページ別のサブフォルダへ移しましょう。空になった`Page_CURA Healthcare Service`サブフォルダは不要ですから削除しましょう。下記スクリーンショットのようになりました。

![スクリーンショット 2018-05-04 10.59.07.png](https://qiita-image-store.s3.amazonaws.com/0/52995/4b1e3637-1045-9f97-bc7a-8a8d7b7e1be0.png)

#### Test CaseをRunする

Test Objectを移動しました。それに伴ってTest Caseも自動的に変更されました。ここでTest Caseを実行してまともに動くかどうかを確かめましょう。Test Caseを実行する操作は[こちら](https://qiita.com/kazurayam/items/433876c0b3bc7f33f019#replay%E3%81%AE%E6%93%8D%E4%BD%9C%E6%89%8B%E9%A0%86)を参照のこと。

#### step1

以上でTest Object群を4つのWebページに対応する形に整理することができました。

この段階をGitHub上のCURA-Testing-Projectのstep1ブランチとして保存しました。step1ブランチをローカルに取り出すには下記の操作をします。

```
$ cd ~/katalon-workspace/CURA-Test-Project
$ git checkout -b step1 origin/step1 
```


### Test Objectの名前を改善しよう

Rename機能が自動生成したTest Objectの名前を見直しましょう。`a_Make Appointment`や`input_password`という名前は適切です。そのままで良いでしょう。しかし `p_30052018` とか `p_Yes` とかいう名前はどうもいただけません。なんじゃこりゃ？と思ってしまう。

![スクリーンショット 2018-05-04 11.24.39.png](https://qiita-image-store.s3.amazonaws.com/0/52995/e09c2910-def4-3d70-5ac8-4b48975d6d3e.png)


なぜこんな名前になったのか？Test Object `p_30052018` に対応するHTML要素はこれでした。

```
        <p id="visit_date">30/05/2018</p>

```

"30/05/2018"という内容を持つpタグでした。スラッシュ文字(/)はOSのファイルパスの区切りとして特殊な意味を持つ文字なのでオブジェクトの名前の一部として使うのは避けたほうがいい。だからRecord機能は `p_30052018` という名前を作りだしたのでしょう。しかし `<p id="visit_date"` というふうにID属性があるのだからそれを根拠とする名前の方が適切です。つまり `p_30052018` よりも `p_visit_date` が好ましい。

Test Objectの名前を変更することができます。たとえRecord機能が決めた名前でも変更してかまいません。 `p_30052018` をマウスで右クリックしてメニューを開きRenameしましょう。

![スクリーンショット 2018-05-04 13.07.24.clipped.png](https://qiita-image-store.s3.amazonaws.com/0/52995/4f09c0e4-8633-df25-9090-8f8463f4f825.png)

こんなふうにしてTest Objectの名前をひとつひとつ見直していきます。HTML要素がid属性を持っているならそれをTest Objectの名前の一部として転用するのが得策でしょう。

Test Objectの名前をぜんぶ見直した結果こんなふうになりました。
![スクリーンショット 2018-05-04 13.11.14.clipped.png](https://qiita-image-store.s3.amazonaws.com/0/52995/a5bc1bbb-e8bc-ac0a-6a1e-0b48fccabff3.png)

#### step2 

この段階をGitHub上のCURA-Testing-Projectのstep2ブランチとして保存しました。step2ブランチをローカルに取り出すには下記の操作をします。

```
$ cd ~/katalon-workspace/CURA-Test-Project
$ git checkout -b step2 origin/step2 
```

### Test ObjectのSelectorを改善しよう

Test Object `Page_CuraHomepage/a_Make Appointment` のSelectorがこうなっていました。

```
//a[@id = 'btn-make-appointment' and @href = './profile.php#login' and (text() = 'Make Appointment' or . = 'Make Appointment')]
``` 

![スクリーンショット 2018-05-04 13.23.30.png](https://qiita-image-store.s3.amazonaws.com/0/52995/6c98a34a-538c-be2f-646c-f4c6f12b842c.png)

このSelectorはダメだ。冗長すぎる。シンプルにしましょう。

1. `and @href = './profile.php#login'`の部分は無いほうが良い。これがあると将来Webアプリの設計が変更されてログイン・ページのURLが `./login.php` に変わった場合にこのテストも一緒に修正しなければならない。もし修正し忘れるとテストが失敗するだろう。
2. `//a[@id = 'btn-make-appointment' and (text() = 'Make Appointment' or . = 'Make Appointment')]`のようにid属性による選択と内容文字列による選択の二つをAND条件で結合する必要はない。どちらか片方あれば十分だ。
 
こう考えれば次の２つのうちいづれかを選択することになるでしょう。

1. `//a[@id = 'btn-make-appointment']`
2. `//a[text() = 'Make Appointment' or . = 'Make Appointment']`

AUTの仕様によりid属性の値が固定であって頼りにできるならば#1が良いでしょう。ところがWebアプリケーションの種類によっては（たとえば[Angular](https://angular.io/)とか）id属性の値が可変な場合があります。可変なidはTest ObjectのSelectorの根拠として使いづらい。id属性が可変な場合にはむしろ#2のようにHTML要素の内容文字列をSelectorの根拠とする方が具合がいい。

AUTがどう設計されているかを考慮に入れながら適切にSelectorを修正していきます。

ここでは#2を選択することにします。つまりSelectorを `//a[text() = 'Make Appointment' or . = 'Make Appointment']` に変更したい。そのためには Test Object `Page_CuraHomepage/a_Make Appointment` の設定を変更します。下記のスクリーンショットを参照。 **Detect object by?** のチェックボックスをon/offしてtagとtextを根拠として選択します。チェックボックスのon/offを更新する都度selector式が更新されるのが分かります。

![スクリーンショット 2018-05-04 14.00.16.png](https://qiita-image-store.s3.amazonaws.com/0/52995/f793a79b-4c15-a16d-c145-6775bc4fbb56.png)

#### step3

同様のやり方でぜんぶのTest ObjectのSelectorをシンプルなものに変更しました。この段階をGitHub上のCURA-Testing-Projectのstep３ブランチとして保存しました。step3ブランチをローカルに取り出すには下記の操作をします。

```
$ cd ~/katalon-workspace/CURA-Test-Project
$ git checkout -b step3 origin/step3 
```

### 不要なTest Objectを削除しよう

`td_30`という名前のTest ObjectがRecord機能によって自動されていました。

![スクリーンショット 2018-05-04 14.56.30.png](https://qiita-image-store.s3.amazonaws.com/0/52995/bbe831bb-1d25-0716-b31d-763cae9e1ad8.png)

わたしが予約ページで受診日を入力しようとtextフィールドにマウスをのせたら、JavaScriptが動いてDate Chooserの小窓の中から日付を選べと促してきた。そこでわたしは30日をクリックしました。その操作がrecordされた結果として `td_30` が生成されたのでした。

![スクリーンショット 2018-05-04 15.02.43.clipped.png](https://qiita-image-store.s3.amazonaws.com/0/52995/b3220e5b-4732-6d2a-996e-577f05d339e7.png)

じつはTest Object `td_30` をTest Case `Basic` は利用しません。日付を `input_visit_date` に文字を直接設定してしまいます。こんなふうに:

```
WebUI.setText(findTestObject('Page_CuraAppointment/input_visit_date'), '30/05/2018')
```

だからRecord機能によって生成された Test Object `td_30` は不要です。削除してしまいましょう。

あなたが自分のPCでKatalon StudioのRecordを実行した時にWebブラウザのウインドウ内部をクリックすることでしょう。何の気なしに何回もクリックしてしまう。するとそのクリック１回につきRecord機能がTest Objectをひとつ自動生成するでしょう。結果的に、あとで振り返ってみると何のためにこれが生成されたのかよくわからないTest Objectがたくさんできている、ということがありえます。あなたがクリックしたからです。理由はそれだけ。Test Objectの氏素性を見極めて不要と判断できたら、削除してしまいましょう。

#### step4

この段階をGitHub上のCURA-Testing-Projectのstep4ブランチとして保存しました。step4ブランチをローカルに取り出すには下記の操作をします。

```
$ cd ~/katalon-workspace/CURA-Test-Project
$ git checkout -b step4 origin/step4
```
 
以上でリファクタリングが完了しました。

# 検証を実装する

CURA-Testing-Projectのstep4ブランチのコードには検証のためのコードがひとつもありません。あなたがブラウザで http://demoaut.katalon.com/ を開いてマウスとキーボードで操作したのをリプレイできるが、それだけです。これでは 自動化されたテスト（automated test）とはいえません。そこで次に検証のためのコードを作りましょう。

## ページの遷移を検証しよう

http://demoaut.katalon.com/ のサイトは下記の図のように4つのページで構成されていてボタンをクリックすることによりページからページへ遷移します。

![page transition.png](https://qiita-image-store.s3.amazonaws.com/0/52995/ab229616-a641-648c-355a-607242129400.png)

この図には５本の矢印があります。矢印はページ間の遷移を表しています。ボタンのクリックによってねらいどおりのページに遷移できたかどうかを確かめたい。どうやって確かめるか？

**遷移先のページの中に存在しているはずのHTML要素がいま現在表示中のページの中にあるかどうかをTest Caseが調べればいい。** それによってページ遷移が成功したかどうかを判断することができます。

各ページを特徴付けるHTML要素を特定します。たとえばホーム・ページには ![MakeAppointment.png](https://qiita-image-store.s3.amazonaws.com/0/52995/f6de845f-4638-f24f-6267-979e743f06a2.png)ボタンがある。そこでTest Caseがホーム・ページを開いたあとでいま現在表示されているページの中に `Make Appointment`ボタンが存在するかどうかをチェックできればいい。いま表示されているページのなかに `Make Appointment`ボタンが存在しているかどうかをチェックするには [verifyElementPresent](https://docs.katalon.com/display/KD/%5BWebUI%5D+Verify+Element+Present)キーワードを使えばよい。

そこでTest Case `Basic`を下記のように記述しました。

```
WebUI.openBrowser('')

WebUI.navigateToUrl('http://demoaut.katalon.com/')

// Make Appointmentボタンがあるか?
WebUI.verifyElementPresent(findTestObject('Page_CuraHomepage/a_Make Appointment'),
    10, FailureHandling.STOP_ON_FAILURE)
```

このコードは次のことをしています。

1. ブラウザを立ち上げる
2. ブラウザで http://demoaut.katalon.com/ を開く
3. ページのなかに `Make Appointment`ボタンがあるかどうか調べる。ページが表示されるのに若干時間がかかるのを考慮して最大10秒間待つ。もしも `Make Appointment`ボタンが見つからなければログにFAILEDと出力したうえで処理を中断する。FAILED発生後の動きとして[FailureHandling.STOP_ON_FAILURE](https://docs.katalon.com/display/KD/Failure+handling)を指定している。

同じ方法を上図の5つの矢印すべてに適用することができます。

#### step５ 

この段階をGitHub上のCURA-Testing-Projectのstep5ブランチとして保存しました。step5ブランチをローカルに取り出すには下記の操作をします。

```
$ cd ~/katalon-workspace/CURA-Test-Project
$ git checkout -b step5 origin/step5 
```

## 表示されたデータを検証しよう

確認画面に受信予約の内容が表示されます。

![スクリーンショット 2018-05-05 15.33.14.clipped.png](https://qiita-image-store.s3.amazonaws.com/0/52995/fd40905c-9bad-b819-b26f-af613a53ce21.png)

ここに表示されたデータが妥当であるかどうか？それを検証するコードを書きましょう。

どういう条件が満足されればデータが妥当だと判断するのか、その仕様を決める必要があります。ここでは下記の通りとします。

| Test Object名 | データの検証条件 |
|:---------------|:----------------|
| p_facility | 次の３通りの文字列いづれかと一致すること<br/>`Tokyo CURA Healthcare Center` <br/> `Hongkong CURA Healthcare Center` <br/> `Seoul CURA Healthcare Center` |
| p_hospital_readmission | `Yes` と `No` のいづれかと一致すること|
| p_program | `Medicare` と `Medicaid` と `None` のいづれかと一致すること |
| p_visit_date | dd/MM/yyyyの形式の日付であること。今日よりも未来の日付であること。日曜日でないこと。|
| p_comment | 未入力でもOK。もし入力があるなら400文字以下であること。 |

### 許される値と一致するかどうかのチェック --- 正規表現を使う

ページのなかのpタグの内容文字列として表示されているテキストを取り出すには[getText](https://docs.katalon.com/display/KD/%5BWebUI%5D+Get+Text)キーワードを使います。そしてテキストを正規表現と照合してマッチするかどうかを判定するのに[verifyMatch](https://docs.katalon.com/display/KD/%5BCommon%5D+Verify+Match)キーワードを使うことができます。

例えば p_facility つまり施設の名前として表示されているテキストが妥当かどうかの検証を下記のようなGroovyコードで記述することができます。

```
def facility = WebUI.getText(findTestObject('Page_AppointmentConfirmation/p_facility'))
WebUI.verifyMatch(facility,
	'^(Tokyo|Hongkong|Seoul) CURA Healthcare Center$', true)
```

正規表現を使ったデータの妥当性チェックは多くの場面で応用が効きます。p_hospital_readmissionとp_programについても正規表現によるチェックが適用できます。

### 日付の詳細なチェック --- Groovyコードで補強する

p_visit_dateつまり受診する予定の日付に関して「dd/MM/yyyyの形式の日付であること、今日よりも未来の日付であること、日曜日でないこと」というチェックを行いたいのですが、このチェックを実現するキーワードがKatalon Studioにあらかじめ組み込まれてはいません。しかし対処する方法があります。

Katalon StudioのTest Caseつまりテスト手順を具体的に記述したモノは実はGroovyスクリプトです。Groovy言語の文法にしたがって正しく書けばTest Caseのなかでなんでも記述できます。 **java.time.LocaleDateTime** などの[Java8の日付時刻API](https://qiita.com/liguofeng29/items/c643c6f81afc62aac77d)をTest Caseのなかで使って日付データに関する詳細なチェックを記述することができます。

こんなコードです。

```
def visitDateStr2 = WebUI.getText(findTestObject('Page_AppointmentConfirmation/p_visit_date'))
WebUI.verifyMatch(visitDateStr2,
	'[0-9]{2}/[0-9]{2}/[0-9]{4}',
	true, FailureHandling.CONTINUE_ON_FAILURE)

import java.time.temporal.TemporalAccessor
TemporalAccessor parsed = 
    DateTimeFormatter.ofPattern('dd/MM/uuuu').parse(visitDateStr2)
import java.time.LocalDate
LocalDateTime visitDate2 = LocalDate.from(parsed).atStartOfDay()
// 今日よりも未来の日付であること
boolean isAfterNow = visitDate2.isAfter(LocalDateTime.now())
WebUI.verifyEqual(isAfterNow, true,
                  FailureHandling.CONTINUE_ON_FAILURE)

// 日曜日ではないこと
def dayOfWeek = DateTimeFormatter.ofPattern('E').withLocale(Locale.US).format(parsed)
WebUI.verifyNotEqual(dayOfWeek, 'Sun')
```

コメント欄（p_comment）にかんするチェック「未入力でもOK。もし入力があるなら400文字以下であること」もGroovyスクリプトで下記のように記述することができます。

```
def comment = WebUI.getText(findTestObject('Page_AppointmentConfirmation/p_comment'))
if (comment != null) {
	WebUI.verifyLessThan(comment.length(), 400)
}
```

### step6

この段階をGitHub上のCURA-Testing-Projectのstep6ブランチとして保存しました。step6ブランチをローカルに取り出すには下記の操作をします。

```
$ cd ~/katalon-workspace/CURA-Test-Project
$ git checkout -b step6 origin/step6 
```

# LogViewerをチェックして検証の失敗に気づく

[WebUI.verifyMatch()](https://docs.katalon.com/display/KD/%5BWebUI%5D+Verify+Match)] とか [WebUI.verifyElementPresent()](https://docs.katalon.com/display/KD/%5BWebUI%5D+Verify+Element+Present) などのKatalon Studio組み込みのキーワードを使って検証を実行した時に失敗したら（FAILED）どうなるか？ Katalon Studioの画面上のどこに失敗が表示されるのでしょうか？

Test Case `Basic` を実行した時、Katalon Studioの画面の右下にログが表示されます。こんなふうに：
![スクリーンショット 2018-05-12 11.21.20.png](https://qiita-image-store.s3.amazonaws.com/0/52995/239bd385-d832-a926-a284-17ba908e13f9.png)

もしも FAILED があれば赤いバツ印が表示されます。こんなふうに：
![スクリーンショット 2018-05-12 11.38.36.png](https://qiita-image-store.s3.amazonaws.com/0/52995/d2c1e351-ec6d-cf32-e7fd-ab9693690724.png)

FAILEDを見つけたら即刻対処しましょう。

### step7

FAILEDの表示を見たかったのでわざとverifyが失敗するようにTest Case `Basic`を１行書きかえました。

```
// 日曜日ではないこと
def dayOfWeek = DateTimeFormatter.ofPattern('E').withLocale(Locale.US).format(parsed)
//WebUI.verifyNotEqual(dayOfWeek, 'Sun')      //本当はこっち
WebUI.verifyEqual(dayOfWeek, 'Sun')           //わざと失敗させてみた
```

この段階をGitHub上のCURA-Testing-Projectのstep6ブランチとして保存しました。step6ブランチをローカルに取り出すには下記の操作をします。

```
$ cd ~/katalon-workspace/CURA-Test-Project
$ git checkout -b step7 origin/step7 
```

# 結び

今回は、ページ間遷移がちゃんとできているかどうか、ページに表示されたデータが妥当かどうかのチェックを行う自動化テストをKatalon Studioで自作しました。

[次回](https://qiita.com/kazurayam/items/29282b749def80a806de)はKatalon Studioが実現している下記のfeaturesを紹介するつもりです。

- Test Caseのモジュール化
- GlobalVariable
- Execution Profile --- ひとつのProjectで複数環境をテストする
- Test Suite
- Report