TABOK粗読による自動化の座学 - カテゴリー4「テスト自動化フレームワーク」(2)

　機能テストの自動化、レベル2のお話です。

www.kzsuzuki.com

　レベル1を読んで、「いやそんなはずないだろ」って思いますよね。

www.kzsuzuki.com

「テキストボックスに”25”を入れてクリック・・・」「テキストボックスに”35”を入れてクリック・・・」という碇シンジのようなスクリプトを1つずつ書くなんて、信じがたい非効率。何とかせねば。

　レベル2のキーワードは「データ駆動(data driven)」と、「機能分解(Functional Decomposition)」です。

4.2.3.1　データ駆動

　上の例では、「25」と「35」以外はすべて、同じ動きになります。だとしたら、パラメターとして外出し（parametarize）したくなるのが人情ってもんでしょう。
　スクリプト自体は1本に共通化して、その中で差異のある値の部分をパラメターとして、外部ファイルに一覧化しておく。スクリプトは、この外部ファイルを読んで、各値を検証する。これだけでも無駄が省かれます。

　絵で描くとこんなイメージですかね。

　白いハコは画面です。その右の点線で囲んでいるハコが、1つのスクリプト。スクリプト1と2は、操作と画面遷移が同じなので、ほとんどの部分が重複しており、冗長です。違うのは「年齢」の入力値だけ。
　スクリプト3では、黄色の、「値だけ違う部分」の値を<age>というパラメターにしています。その具体的な値は、外出ししておく。

データ駆動の長所

　何と言っても使い回しが聞くこと。同じスクリプトで、パラメターとして他の値を試したければ、外部ファイルに1行追加すればすみます。
　もうひとつは、レベル1で作ったスクリプトをちょこっといじれば、レベル2スクリプトに進化させられることです。必要な部分だけ外出しすればよいのですから。

データ駆動の短所

　パラメター外出しで共通化できるのは、スクリプト1と2のように、操作の流れ自体が同じで値だけが違うというケース。流れが違えば、スクリプトはやっぱり別になり、冗長な部分は残ります。
　もう1つの欠点は、やっぱり読むのが難しいということ。どっかでエラーになったら、スクリプトの解読を始める必要があります。

4.2.3.2　機能分解

　下の絵を見てください。スクリプト3で「年齢」に入れる値を外出しすることで、同じシナリオであれば1つのスクリプトで複数の値をチェックすることができるようになりました。
　一方スクリプト4。こちらは、確認画面から一度戻り、値を入力しなおしてもう一度確認に進むシナリオです。スクリプト4でも「年齢」に入れる値を外出ししてはいますが、スクリプト3とは別のものになってしまいます。スクリプト3と一本化することはできません。

　ですがよく見ると、途中の操作の流れはほとんど同じです。ならば、スクリプト3をバラバラに分割することで、使い回すことを考える。

　「分解したスクリプト」を見ると、初めの方はそのままスクリプト4に使えるし、「年齢」に入力して「登録」ボタンを押すスクリプトは、2回使い回せばいい。スクリプト4の緑色の部品「戻る」ボタンを押下」はないので、新しく作ることになります。

　TABOKでは、このように作られたスクリプト部品を、いくつかのタイプに分けています。それぞれの部品がもつ動作の細かさは、フレームワーク次第のようです。

• クラスレベル機能: 「テキストボックスに値を入力する」といった動作を受け持つ。
• ユーティリティ機能: 「アプリケーションへのログイン」のように、テストにおいて共通的に必要になる動作を受け持つ。
• ナビゲーション機能: テストのシナリオの中でよく出てくる画面遷移を受け持つ。
  ・・

機能分解の長所

　冗長性を大幅に減らすことができる点。また、部品を作っていくので、アプリケーションの実装が終わる前から着手できる点が、長所です。

機能分解の短所

　部品ができてしまえば、それをガッチャンコして新しいシナリオを作るのは、そう難しくない。一方、最初の部品作り、そしてそに先立つ部品設計と標準化、ドキュメンテーションに、スキルとコストと時間を要するのが難点です。部品は使いまわされるので、汎用的に使えるよう、厳格なルール決めが必要になってくるということですね。

　・・・あれ？レベル3に辿りつかない・・・。