８．まとめ

これまでの説明のまとめとして、Seleniumを実用する上で有効な使い方を考察する。

SeleniumはWebアプリケーションのテストを自動化することを目的としているので、テスト品質の向上とテスト工数の軽減に役立つはずであるが、実際にはそれほど多く導入されていないようである。

導入する際の障壁として、主なものとして次の２点が考えられる。

●  SeleniumIDEでFireFoxのテストケースを作成することは容易であることはわかるが、実際は他ブラウザでの動作確認を必要とするのでプログラミングを行う必要がある。しかし、SeleniumコマンドとSeleniumAPIそしてWebDriverの扱い方を習得する時間を取ることができない。

●  全てを自動化できるものとして導入してしまうことによりSeleniumにとって不得手な対応に工数がかかってしまう。

しかし、テストを自動化した場合のメリットを考えるとSeleniumの導入を薦めたいと考える。そこで、導入するメリットとして、Seleniumの長所を挙げてみる。

A)  手入力要素の多いWebアプリケーションでは入力できる文字種と文字数など入力条件を設定できる為、手入力確認によるテスト漏れ・テストの不十分さをカバーする

B)  Webアプリケーションの条件設定によるテストのように複数の要素をマトリックス的に組み合わせたテストケースの作成が容易である

C)  表示内容の確認が容易である

D)  テストの状況、結果とそのスクリーンショットを記録として残すことができる

E)  テスターに依存しない為、何度でも同じテストを同じ条件で行う事ができる

F)  Webアプリケーションの変更による影響の有無を確認できる

G)  ブウラウザ間の差違を発見しやすくなる

これらの項目について詳しく考察してみる。

A)  手作業の入力要素の多いWebアプリケーションでは入力できる文字種と文字数など入力条件を設定できる為、手作業確認によるテスト漏れ・テストの不十分さをカバーする

入力についてはSeleniumIDEで作成できる為、テスト項目を容易に作成しやすい。

●  文字種のテスト

storeコマンドで変数にエラーとなるべき文字列を設定しておき、type ( name=idname, ${string} ) としてテストを行う。変数を利用する事で様々な文字種のテスト項目を作成できる。

typeコマンド後に何らかの操作でエラーメッセージを表示するという仕様であれば、waitForTextコマンドで正常にエラーメッセージを出力するというテスト項目を作成する。

●  入力文字数制限のテスト

storeコマンドを利用して変数にエラーになるべき文字数の文字列を設定し、typeコマンドを行う。

これは手入力によるケアレスミスを防ぐことができる。文字種テストと同様にエラーメッセージを表示するという仕様であれば、waitForTextコマンドで正常にエラーメッセージを出力するというテスト項目を作成する。

このような長所に対して懸念することとしては、対象入力の要素を取得できるかと思われる。

対象要素はSeleniumIDEの右クリックメニューより取得できるが、Webアプリケーション側で右クリックメニューを使用している場合は、Webページのソースコードからcss、xpath等で要素を指定するようになる。

テスト項目として言葉や文章では無く、具体的な内容を作成できること、テスターに依存しないこと、テスト項目が十分であるかを視覚的に確認できること、そしてSleniumIDEで作成できることは、懸念事項を払拭できるメリットであると考える。

B)  Webアプリケーションの条件設定によるテストのように複数の要素をマトリックス的に組み合わせたテストケースの作成が容易である

SeleniumIDEを使用すると、組み合わせ内容と得られるべき結果を視覚的に作成しやすい。

懸念される点はテストケース漏れが考えられるが、A)のメリットと同様にテストケースの内容を視覚的に確認できることを利用して必要なテストケースと照らし合わせが容易であることは、テストケースの漏れを確認する懸念を払拭できるメリットであると考える。

C)  表示内容の確認が容易である

ページに表示されるべき内容の確認が容易である。SeleniumIDEの右クリックメニューの利用あるいは直接、要素を指定することで表示している文字列・画像についてテストケースを作成する。

ここまでのSeleniumの説明の中で要素が取得できない事への対処方法について記述している。ほとんどの場合、要素を取得できるが、深く入り組んだ位置に要素が存在し、かつタグの内容が要素を特定しづらい場合に要素の取得を失敗するように見受けられる。これは一見すると手間のかかることの様に見えるが、一部分のことであるので、Seleniumで表示内容確認のテストケースを作成し、失敗する部分をソース読み込みによる対応にする方法を採用してもSeleniumを使用するメリットがあると考える。

D)  テストの状況、結果とそのスクリーンショットを記録として残すことができる

ここまでの長所の説明にあるように、テストケースのログを出力し、Seleniumコマンドやブラウザ画像読み込みAPIを利用する事で、テストの状況、結果を記録することができるのは、テストの実績を残し、また、Webアプリケーションをバージョンアップ前後のテスト状況を残すことができる。何らかの問題発生した場合、対応の糸口にも役立つ。

ただし、テストの状況を示すメッセージやスクリーンショットを記録するべき位置の指定などはテストケース作成者に依存する。

E)  テスターに依存しない為、何度でも同じテストを同じ条件で行う事ができる

自動化することでテスターによるテストの深さのバラツキや手作業によるケアレスミスを防ぐことが容易である。

Seleniumはパターン化できるテストケースには向いているが、どうしても手作業でなければ確認できないテストケースもある。例えば、Seleniumでは取得できない方法で表示しているメッセージやマウスカーソルの変化などSeleniumの範囲を超えた方法で動作する箇所について手作業で確認することになる。

F)  Webアプリケーションの変更による影響の有無を確認できる

テストを記録として残しておけるので、変更された箇所でエラーになっていることをテストとして利用した確認や正しく変更したことを確認できることは、大きなメリットであると考える。

G)  ブウラウザ間の差違を発見しやすくなる

ブラウザによる差違部分でテストケースがエラーになることを利用してブラウザ間の差違に対処しやすくなる。

結論として、

Seleniumの使い方として、SeleniumIDEでテストケースをほぼ作成し、Javaソースへ変換後、マルチブラウザへの対応を行う。そして、Seleniumの対象範囲は、パターン化できるテストケースに絞ると、Seleniumを有効に実用でき、また、人的負担や工数の軽減につながると考える。

マルチブラウザに対応する際にJavaソースへの変換、そして実用化の為の修正の他、これまでのSeleniumの説明に記述したようにブラウザによって対処しなければならないコードがあるので、テストに負荷がかかってしまうと考えられる。

しかし、Webアプリケーションのテスト要素は多く、またテスト内容も複雑なので、Seleniumを使ったテストケースを作成する工数と、作成後のテストの品質や効率とを比べた場合、やはり、Seleniumを使用したテストを行うことを薦めたいと考える。

上に戻る