このドキュメントは？
テストの自動化のハードルが高い方々に向けて、まず最初の一歩を踏み出しやすくするためのツールを作ろうと日々少しずつ作っていて、最低限の機能は出来たと思うので晒してしまう記事です。
ツールそのものはまだまだ追加したい機能もあるし、リファクタリング全然できてないし、テストコードも書ききれてないし、ツールの説明も足りない状態なのですが
Done is better than perfect.
と、マークザッカーバーグ氏もおっしゃっているので、途中でも公開してしまって進めていこうかな。というテストツールの第一歩の紹介記事です。
ツール自体はGithubで公開していて、使い方などはWikiの方で載せていく予定ですが、「Githubは見れないけどQiitaなら見れる」というような謎環境の方もいるかもしれないので、ある程度はこちらでも記載していこうと考えています。
ツールの紹介
Kubera(仮名) とは
「クベーラ」と読みます。E2Eテストの自動化を簡単に作成、実施できるようにするための自動化サポートツールです。
決められたルールに従って作成されたテストケース(Excelファイルなど)を読み込んで、そのままテストを実行することができます。
画面の操作は、Selenium,Selenide を利用しています。JUnit ベースで実行されるので、CIツールと相性が良いです。
操作対象のオブジェクトを特定するためにある程度のSeleniumでの特定ルール(CSSセレクタなどの知識)が必要となります。
ツールそのものも、テストケースを作成するためのスケルトンもGithubで公開しています。
-
kubera本体
- ソースの中身を見たいときにどうぞ
-
kubera-skeleton
- ツールを利用したい場合は、こちらを使ってください
テストケースはどうやって書くの？
v0.6.0 時点では、下記の３つの書き方が出来ます。
- Javaでコードとして記載する(テスト手順を１手順ずつJSON文字列で渡す)
- テストケースをJSON形式のファイルで作成する
- テストケースをExcel形式のファイルで作成する
1と2の簡単な説明とツールの仕組み
Javaでコードとして記載するパターン
kubera.action("{ \"actionName\": \"gotoURL\", " + "\"actionJson\": { \"url\": \"http://localhost:8080/input\" } }");
kubera.action("{ \"actionName\": \"assertTextbox\", " + "\"actionJson\": { \"locator\": \"id\", \"searchExpression\": \"idInputText\", \"checkValue\": \"\" } }");
kubera.action("{ \"actionName\": \"inputTextbox\", " + "\"actionJson\": { \"locator\": \"id\", \"searchExpression\": \"idInputText\", \"inputString\": \"idを入力\" } }");
一つ一つの操作をJSON文字列で渡すことで画面操作／検証を行うことが出来ますが、製造しやすいわけでも可読性が高いわけでもないので、このパターンを使っていただくことは想定していません。
別途何らかの形式のファイルで作成したテストケースと当テストツールのインターフェースとして内部で利用しています。
JSON形式のファイルとして作成するパターン
機能としては用意していますが、こちらも可読性が高いものでもないので、「テキスト形式で管理したいな」という方はこちらでも。。。
ですが、おススメはしませんので、JSONとしてどういうフォーマットで書くのか。というドキュメントの準備は優先順位低いと思います。すみません。
「必要です！JSONファイルで管理したいです！」という熱いアツいご要望がありましたら優先順位をあげてドキュメント作成しようかと思います。
Excel形式のファイルとして作成するパターン
表形式には表形式のメリットがありまして、並べてみることに価値があるデータの場合には有効だと思います。
テストケースというのはある程度似ているテスト手順で入力値や検証値が異なるというがあったりするので、並べてみることでテストケースの過不足や間違いに気づきやすかったりします。
このツールでは、縦方向にテストの手順、横方向に入力・検証の値を並べてテストケースを管理できます。
↑の画像がテストケース記載のサンプルです。
(この絵のサンプルはA列が空白になるように調整された例です。どの行・列からテストケースを書き始めるかは設定できます。)
簡単に上絵の説明を記載すると
- B-F列：テストの手順です
- B列：ツールが動作するためのキーワードが記載される部分です
- C列：テストの手順を自然言語で記載します。（ツールでは実行時に表示に利用する程度です）
- D列：操作対象を特定するためのロケータを指定します(id, name, css_selectorなど)
- E列：操作対象を特定するための情報を指定します(指定したロケータに従った内容になります)
- F列：操作対象が配列要素の場合、その要素番号を指定します。番号は１から始まる数値です
- G列以降：実際のテストケースを記載していきます。手順に対して入力／検証したい値などを記載します.
１ケース１列で記載します。
テストはB-F列に記載している手順通りに上から順に実行されますが、G列以降に記載したテストケースのセルで未入力のセルは手順そのものがスキップされます。
上絵の例では、G列のテストは下記のように実行されます
- テスト対象のページが開かれる
- 「このプランで予約」というリンクの内、一つ目をクリックする
- 「宿泊予約 | HOTEL PLANISPHERE - テスト自動化練習サイト」というタブを操作対象に切り替える
- id="plan-name"のテキストが「お得な特典付きプラン」であることを検証する
- 以下の手順はセルが空白なので実行されません
使い方は色々と工夫できると思います。
例えば、よくある画面の遷移を定義しておいて、各画面の代表的な操作（ページオブジェクトっぽい使い方でも）を手順として記載しておき、テストケースの方で必要なところだけを埋めれば、一つのシート中に同じ画面遷移パターンのテストケースをまとめることができます。
（細かい処理パターン網羅のようなテストはUTでやれたらやりましょうね）
テスト手順の列を書くのが非エンジニアには難しそう
難しいと思います。。。
が、Webアプリケーションがテストしやすく作ってあったらある程度サポートできるかもしれないツールを同梱しています。
画面操作候補一覧の作成
こちらに使い方が記載されています。
kubera-skeleton をダウンロードしていたら、その中のREADME.mdにも記載がありますので、そちらを参照してください。
ツールを実行するとテスト対象としたいページをブラウザが起動して表示されますので、実際に画面を操作しながら画面操作候補一覧を抽出します。
よく操作するであろうタグなどを中心に操作候補の一覧が作成されます。
下絵は、こちらのページを対象に抽出した例です。
ここで抽出された操作候補を、実際のテストケースの手順部分にコピーして使うことができます。
今後について
まだドキュメント化がおいついていないので、実際に使おうとすると「あれ？どうやってかくんだ？」とか「プロパティ？」「settingsシートってなんだ？」「Wiki見ても準備中ばっかりだぞ？」など説明不足なところが多々あると思います。
徐々に埋めていこうと思いますので、まずはこのツールの存在を知っていただいて、今後を見守っていただければと思います。
こういう機能が欲しいな。というようなものがありましたらこちらのGithubのIssueから投げてもらえると検討するかもしれません！
利用させてもらったサイト
-
テスト自動化の学習用の練習サイト
- ツールのテストケースサンプルでも利用させていただいています。