GUIの変更に強い自動化スクリプト(How to write automation script which has tolerance for GUI changing)

自動化はメンテナンス性をよくすることが一番重要である!といつも言っている。そのためにはキーワード駆動型のツールを使うか、キーワード駆動型っぽく関数化するべきだ!といつも言っている。

言ってはいるが、実際に初めて自動化プログラムを組む人のための資料というのはこの世に存在しないことに気づいた。当然IEEE関連のテスト学会でもないし、STARとかでいくつか発表されていた気がするが、あまりに小さいトピックなので広く情報は伝わっていない。ISTQBの自動化シラバスにものっていない。あー、こういう重要なことがちゃんと書き物になっていないことに気づいた(今度書籍を出版するときにこのトピックをいれなきゃと思った)。簡単に言うと、状態遷移と入力と事前条件(必要なら事後条件)の3つをプログラムのアーキテクチャに入れ込むとうまくいく場合あ多い。

 

 

まず上記の図にgui1というUIがあったとしよう。そこでedit1に”Tom”と入れてbutton1を押す、edit2に”36″と入れてbutton2を押す自動化コードを考えてみよう。

TestGui1( )

{
Input.edit1(“Tom”);

Push(button1);

Input.edit2(“36”);

Push(button2);

}

となる。それがGUI変更によって、gui1, gui2に分けられてしまった。TestGui1がTestGui1とTestGui2になる。gui1にbutton3が追加され、gui2に移るようなプログラムになったとしよう。だいたいコピペで以下のようなスクリプトになるはずである。

 

TestGui1( )

{
Input.edit1(“Tom”);

Push(button1);

Input.edit3(“male”);

Push(button3);

}

TestGui2()

{
Input.edit2(“36”);

Push(button2);

}

まあただのつまらない解説なのだが、inputとactionを関数の中にちゃんと事前に定義することが重要だ。抽象レベルの高いコードと、OS依存のコードを明確に分離しなければならない。TestGui1の関数の中にFind.ElementIDなんてGUIの要素を取得するようなコードを入れてはいけない。ここまではキーワード駆動型のスクリプティングの一般的な説明だが、スクリプトを複雑にする要因としては事前条件(このおまじないをしないと、次のGUIにいけないみたいな)がある。事前条件を設定するには往々にしてif文の嵐になる。なので抽象レベルの高い部分はif文を入れてはいけない。

 

さらにすすめると、事前条件を関数化するとさらによい。例えば次のような状態遷移があったとする。gui3のテスト担当者はgui3だけやりたいのだけど、gui3にたどりつくまで様々なおまじないコマンドをいれなければいけない(例えばログインとかパスワードとか)。それをしなくてよいように。

Set.pre-condition-for gui3( );

みたいな関数を作れば、gui3はそこにたどり着くまでのGUIが変更になっても。

TestGui3{

Set.pre-condition-for-gui3( );

Input.edit7(“Tom”);

Push(button7);

}

みたいな関数が書け、gui3のテストのスクリプトを変更する必要がなくなる。愚なのは、gui3までたどり着くためのGUIが変更されるとなにも変更のないGUI3のテストスクリプトの変更することだ。なので、Selenium等々のキーワード駆動のフレームワークがはいってないものは、3つの外部テーブルなり、外部定義ファイルを用意しておくとよう(外部というのはスクリプトの中にぐちゃぐちゃ、そういったものを入れるのを避けるため)。

自動化スクリプトのアーキテクチャー設計と言うと仰々しいが、以下のことを事前に皆で合意してからスクリプトを書くんは悪いアイディアではない。

アクションの定義、アクションと入力の関係(入力値はこのアクションでしか使えない等々)、状態遷移のための関数リスト(上図のtransitin1, transtion2)、GUIに至るためのpre-condition関数リスト(上図のSet.pre-condition-for-gui3)。もちろんここまで読んだ、経験のあるテスト担当者はきっと気づくでしょう。そうですこういうふうに書くことにより、境界値テストと状態遷移テストとディシジョンテーブルテストのテストケースが抽出できたり、俯瞰的に見れたりするのですごーい、テストマネージャとしても楽なのです。