Androidアプリの実機試験を行う際に気をつけている事に関するメモです。
試験端末の選び方を示した「試験端末の選び方編」と、実際のテスト方法に関する「実機試験編」に分けて記述します。
この記事は「実機試験編」となります。
基本的な考え方
単体試験はすでにした、あるいはテストコード書いているということを前提に、実機でしかできない点を中心に触っていきます。
ここではソフトウェア工学などの小難しい理論ではなく、もっと取り組みやすいテスト方法について述べていきます。
わりとモンキーテストに近い部分がありますが、これは開発者が普段やらない操作をして思わぬ不具合を見つけるのが目的です。
テスト方法について
ネットワーク関連の試験
ネットワークに接続するアプリの場合、ネットワーク状況が良くない場合(通信エラー等)の状況を考えて試験します。
開発時に通信エラーの場合にエラーダイアログを表示する、キャッシュを利用するなどのエラー処理のポリシーを開発時に決めておくと、テストの際に確認する項目がはっきりしやすくなります。
会社や家の中で開発していると快適なwifiだったりするのでわりと気が付きにくいのですが、外で使う場合は回線が混んでて通信速度が遅かったり、地下で電波が入らないケースもあり、そういった場合にアプリが思わぬ不具合を起こす場合があります。
また、ネットワークがつながらない時に何も表示されない、先に進まない、延々と待たされるというのはユーザーにとって不親切だと思います。
お手軽ですがよくやるのが、機内モードにしてアプリを動作した場合に適切な処理がなされているかというテストです。
しかし、実際はこれだけでは不十分で、timeoutも考慮に入れた試験をします。
例えば、サーバーからの応答がなくてタイムアウトとなった場合(connect timeout)、サーバーに接続できたけれども負荷が高いなどでレスポンスが帰ってこない場合にタイムアウトになった場合(read timeout)などです。
具体的にはread timeoutの時はサーバーにsleepを入れたり、間にプロキシ的なものを介してコントロールします。
iPhoneのデベロッパーメニュ－はよくできていて、OSレベルで通信速度を遅くできるのですが、Androidにはそういう機能はないんでしょうかね。
違和感ありますが、Androidから通信速度を遅くしたiPhoneにテザリングして接続すると割と楽です。。
ボタン連打
onClickイベントが設定されたボタンを何度も連打した時に通信が何度も走らないとか、フラグが変わって整合性が取れなくなってしまわないかなどを確認します。
バックキーの処理
各画面でバックキーを押した場合の動作を確認します。
だいたい画面が１つ戻ったり、ダイアログが閉じたりなどするはずですが、それぞれについて期待した動きとなっていることを確認します。
iOSにはバックキーという概念がないのですが、Androidにはあるので、両方のプラットホームで開発する場合もバックキーに関する動作を決めておく必要があると思います。
アクティビティを保持しない
Androidの開発者オプションの「アクティビティを保持しない」オプションを利用することで、メモリが逼迫してアクティビティが破棄された場合の動作を確認できます。
アクティビティにstaticな変数を書いてほかのアクティビティから参照するような怪しいコードは、アクティビティの破棄や再生成を考慮していないので、おかしくなります。
また、onSavedInstanceが予想通り機能しているかのチェックにも利用ができます。
バックグラウンドプロセスの上限と合わせて調査に使います。
画面を電源ボタンでON/OFFしまくる
少し過激かもしれませんが、アプリ起動中に電源ボタンをひたすらON/OFFして動作を確認します。
イベント処理が適切で無い時や、onResumeで重たい処理を行っていると思わぬ不具合が起きる時があります。
エミュレータやroot化した端末で/data/data/[パッケージ名]/以下を覗く
Androidの開発者であれば /data/data/[パッケージ名]/ を覗いてみましょう。
一部メーカーの機種では
adb shell
で接続した後に
run-as [パッケージ名]
でデバッグ中のアプリに限り、Emulatorやroot端末でなくともファイルを見ることもできます。
adb shellで入っても使えるコマンドは限られているので、adb pullでファイルを引っこ抜いてくるか、catコマンドでファイルの中身を参照します。
確認するチェックポイントとしては、SharedPreferencesのパーミッションです。
デフォルトはMODE_PRIVATEという自分のアプリからしか読み込めないのですが、MODE_WORLD_READABLEなどにしていると他のアプリから読み取れてしまいます。
また、実際のファイルをcatコマンドなどで開くことによって、不要なキーや設定値が保存されていないか、見られたり書き換えられてこまるような値は保存されていないかを確認します。
SQLiteファイルも同様にadb pullでファイルを持ってきて、SQLiteコマンドで参照するか、エミュレータならsqlite3コマンドで表示可能、改変可能ですが、実機テストのチェック項目というテーマからズレてきたので、方法についてはここでは割愛します。