前回までは、テストの作業に着目した分類でテスト自動化ツールを解説してきました。今回は視点を変えてテスト対象に着目します。取り上げるのはユーザーが急増しているスマートフォン(以下、スマホ)です。スマホ向けアプリケーション開発での実機を用いたGUIテストの自動化について、現状と問題点を示した後に、問題解決のためのツールを紹介します。
スマホ向けテストの現状と問題点
現在、スマホに代表されるモバイル市場が急速に成長を遂げており、今後もさらなる成長が予測されています。それに伴い、スマホ向けの新規システムの開発や従来システムのスマホ対応への要求が高まっています。
テストという観点で見た場合、スマホ向けアプリケーションが他と大きく異なるのは以下の二つの点です。
- OSアップデートの多さ
- 対応機種の多さ
そのため、アプリケーションはさまざまな環境で動作する必要があり、テストすべき環境のバリエーションも必然的に増えてしまいます。
最終的にはサポートするすべての機種の実機上で動作保証をする必要があるため、100機種ほどの実機に対してテストしなければならないこともあります。これをすべて手動でテストするのが大変なのは想像しただけでもお分かりいただけるかと思います。
特にAndroid端末に関しては、OSを各社独自にカスタマイズしているため機種ごとの差分が多く、それぞれの実機を用いたテストが外せないのが現状です。そのためにアルバイトを雇用して全機種テストを行うなど、開発現場における苦慮がうかがえます。
上記のような背景の下、今後も年間100機種ほどのペースで増え続けると予想されるスマホ向けアプリケーションにおいて、実機上でのテストに対する自動化の要求は高く、現在注目されている分野となっています。
部品の認識方法が異なるスマホ向け自動化ツール
スマホの実機を対象としたテストは主にGUI操作から成るため、以前の記事で紹介したキャプチャーリプレイツールを用いることができます。キャプチャーリプレイツールによりGUI操作を一度記録してしまえば、OSアップデートに伴う回帰テストをいつでも再生することができます。さらに、一つの機種で記録したテストを他の機種のテストに使い回せば、機種の多さにも対応したテストを行うことが可能となります。
表1に、スマホ向けアプリケーションの主なテスト自動化ツールをいくつか紹介します。
ツール名 | 提供元 | 対応アプリケーション | ツール形式 | 認識 方法 |
提供 形態 |
---|---|---|---|---|---|
Silk Mobile | 英Micro Foucus | Web/Native | キャプチャー リプレイツール |
画像 文字 部品*1 |
有償 |
M-eux Test | ベルギーJamo Solutions | 文字 部品*1 |
|||
QC Wing for Android | 日本ノーベル | 画像 | |||
ATESTA-Suite | NTTデータMSE | 座標 | |||
Selenium2 | オープンソース | Web | リプレイツール | 部品 | 無償 |
Robotium | オープンソース | Native |
有償ツールにはキャプチャー機能があるのに対し、無償ツールにはキャプチャー機能はなく、テストコードを書くことでリプレイが可能となります。
また、画面上の部品の認識方法は、座標や画像といった情報から画面へのタッチ入力を模擬するタイプと、IDやXpathといった情報から識別対象を直接指定して命令を出すタイプがあります。それぞれメリット・デメリットがあり、前者はスマホ独特の操作を記録することができますが、作ったスクリプトを他の機種で流用する場合、解像度の問題によりうまく再生できないことがあります。後者は識別対象の部品を直接指定するため、他の機種へのスクリプト流用は容易である一方、スマホ独特の操作(スクロール、フリックなど)を取り入れることが難しくなります。
それぞれのツールの特徴とテストする内容を考慮した上で、適切なテストツールを選定する必要があります。また、実行可能な範囲や制限事項を知るためにも、事前に検証を行った上でツールを利用することを推奨します。