Category Archives: software test

少し前に、雑にモバイルアプリのリリースサイクル毎で行っているテストの流れという記事を書きました。 考え方が少し変わったりしているのですが、そこからE2Eテストという枠を抜き出して、さらにはテスト自動化という文脈で少し話を整理してみようと思います。 ここでは、効率的なコード、失敗時の解析の容易さなどに対する言及は致しません。また、サーバ側に対するテストの話にはちゃんとは触れません。 E2Eテストに含まれる目的 モバイルアプリにおけるE2Eテストという言葉には、恐らく以下の目的(と雑なテストタイプ)が含まれていることが多いと思います。 アプリのGUIから操作した (もしくは表示される要素に対して直接操作した)という文脈を持ったうえでの、 シナリオテスト 想定したStoryやFeatureを含んだシナリオを用意し、そのシナリオを達成できるかを検証したい 機能テスト(システム全体) サーバ側機能を含んだ、モバイルアプリのGUIから操作して意図した通りに機能が単体で振る舞うかを検証したい シナリオとして複数機能をまたがって何かする、という所までは見ない 統合テスト サーバからの応答をえた上で、モバイルアプリのGUI上で描画される要素を検証したい サーバはモック/スタブサーバでも特に限定しない。モバイルアプリ自体を構成する機能を統合させた上で正しく動作するかを見るもの。 GUIテスト 画面の表示、ボタンは位置などのレイアウトに対するGUIのレイアウト崩れ、描画される要素の過不足を検証したい 画面サイズ、解像度、フォントサイズ、アクセシビリティなどを考慮 なお、4に関しては端末のガイドラインに準拠しているかといった内容や、ユーザビリティに対する話は含まれません。 自動化する時に検証する方法 目的4以外のものに関しては、多くはGUIからの操作なので入力に対する出力を得て、その出力に対してアサーションをとることで検証を行うことでしょう。 4のGUIテストに関しては、モバイルアプリの場合は必ずスクリーンショットをとる必要が出てくるでしょう。描画される要素の有無であれば不要ですが、レイアウトが期待通りか、という所まで検証しようとすると、要素が描画された上で確認しなければ正しい/正しくないの判断ができないためです。例えば、画面サイズや解像度の多様性により表示がおかしくなるというのはAndroid/iOSともに多く有ります。 どこまで検証するか GUIから操作するという文脈を持つテストの場合、多くは実行に時間を要します。そのため、どこまで、何を確認するかということで神経を使う必要があります。そこで、アプリをどこまで確認するか、というところで少し雑にまとめてみます。 なお、ここの分け方は検証したいことと、その環境で雑に区分しています。 1. シナリオテスト ユーザが実際に操作する内容をシナリオに落とし込んで、期待されるシナリオを完遂できるか検証する ユーザの操作が変わるパターンはなるべく用意する モック/スタブサーバは利用しない 外部システムとの連携、端末の設定に依存する箇所も含む 2. 機能テスト(システム全体) サーバ側からの応答によりモバイルアプリケーションの振る舞いが変わる場合、それは可能な限り網羅する GUIからすると同じ表示でも、その裏側(サーバからの応答)が異なる場合も含む 機能として仕様に定義した範囲 モック/スタブサーバは利用しない 外部システムとの連携、端末の設定に依存する箇所も含む 3. 統合テスト サーバ側からの応答によりモバイルアプリケーションの振る舞いが変わる場合、それは可能な限り網羅する GUIからすると同じ表示でも、その裏側(サーバからの応答)が異なる場合も含む モック/スタブサーバを用意してでも、サーバからの通信結果をもとに、アプリが期待通り動作することを検証することが目的 端末の設定に依存する箇所を含む 4. GUIテスト レイアウトパターンはなるべく網羅する 同一レイアウトの使い回しに関しては、不要なものは実施しない ツールとテスト モバイルアプリでは、Headless browserのようなGUIの無い高速な確認手段は存在しません。また、espressoや、Debug用にSDKとしてハックしたライブラリを使う以外は、システムが提供するアニメーションなど含めてそれらを許容した上で各種テストを回す必要があります。 そのため、基本的にGUIから操作した上で確認を行う必要があるため実行速度はWebアプリほど速度を出すことが難しいです。一方、espressoなどのように限定した使い方であれば安定して高速に確認する手段もそろってきたので、そこらへんも解消する日が来るかもしれません。 シナリオテストやGUIテストを目的としたE2Eのテストを行う場合、基本的にAppiumのようなGUI越しに操作するツールを使うことになるでしょう。そこでは実行速度と安定性がやはりトレードオフになります。一方で、現在のモバイルアプリを検証するツールとしてはこれ以上の手段は殆どないです。 機能テストや統合テストを目的としたE2Eのテストを行うときの多くもAppiumのようなGUI越しに操作するツールが基本になると思います。ただ、espressoのような高速にView単体を確認できる手段も選択肢としてでてきました。そのため、単なる表示のバリエーションなんかはAppiumのようなもので実施するよりも、遥かに高速に実施できる環境として利用できるようになってきました。 ここで話している文脈における自動化されたテストは、手動テストによる回帰テストを減らすことが目的で使うことが多いと思います。なので、互いに補完関係になるように、プロジェクトとして十分な目的を選んでいきたいですね。…More