モバイルアプリケーションでの割り込みテスト
トーマス・ハミルトン
⚡ スマートサマリー
割り込みテストでは、モバイルアプリケーションが通話、アラーム、通知、またはネットワーク切断によって処理が中断されたときにどのように動作するか、また、中断が終了した後にアプリケーションが以前の状態に正確に戻るかどうかを確認します。
割り込みテストとは何ですか?
割り込みテスト これはモバイルアプリケーションテストの一分野であり、アプリケーションが中断にどのように反応し、以前の状態に復帰するかを検証します。中断はアプリケーション外部（オペレーティングシステム、ハードウェア、または別のアプリケーション）から発生し、このテストでは、制御が戻った際にデータ、画面状態、または進行中のトランザクションが失われないことを検証します。
割り込みテストは、Web、モバイル、スタンドアロンなど、あらゆるアプリケーションタイプに適用されます。デバイス、ネットワーク、構成の多様性により、割り込みテストの重要性がさらに高まります。 モバイル 他のものよりも多くのアプリケーション。
なぜ割り込みテストが必要なのでしょうか?
会議中にほぼ必ず起こることといえば何でしょう？そう、話が中断される、ですよね？中断された時、全く動じない人もいれば、少しの間考えがまとまらない人も、完全に思考が途切れてしまう人もいます。簡単に言うと、割り込みテストとは、アプリケーションがどのような挙動を示すかを調べるテストです。
言葉遣いは一旦置いておいて、別の現実的な状況を考えてみましょう。例えば、懐中電灯を持っていて、それを点灯させたとします。電池が切れると、点灯状態が中断されます。電池を交換して点灯状態に戻すと、懐中電灯は通常通り点灯するはずです。これがユースケースです。このような現象が起こるかどうかを検証するテスト手法の一つが、割り込みテストです。
ビジネス上のメリットは明白です。中断は最悪のタイミングで発生します。支払い中、アップロード中、フォーム入力中など、作業中に中断が発生すると、ユーザーは二度とやり直そうとはしません。再開時のクラッシュ、画面の空白、重複したトランザクション、フォーム入力の消失などは、すべて中断によってのみ明らかになる不具合です。そのため、中断が発生しない機能テストでは、これらの不具合は見過ごされてしまうのです。
モバイルアプリケーションの中断の種類
中断は、いくつかのよく知られたグループに分類され、下の図にまとめられています。
私たちは皆、日常的に起こる様々な中断についてよく知っています。以下にそのいくつかをご紹介します。
- 電池残量が少なくなっています
- バッテリー満充電時
- 電話の着信
- 着信SMS
- 別のモバイルアプリケーションからの着信アラート
- 充電のために接続されています
- 充電が切れています
- デバイスの電源がオフになりました
- アプリケーション更新のリマインダー
- 警報
- ネットワーク接続の切断
- ネットワーク接続の回復
このリストは網羅的なものではありませんが、最も一般的なシナリオを網羅しています。実用的な分類方法としては、発生源別に整理するのが良いでしょう。例えば、バッテリー残量や充電といったデバイス固有のイベント、通話への応答やアプリの切り替えといったユーザー操作によるイベント、エレベーターやトンネル内での信号途絶といった外部イベントなどです。
割り込み発生時の解決方法
これらの中断が発生した場合の想定される動作は、以下の4つのいずれかです。
- バックグラウンドで実行： 割り込みが発生すると、アプリケーションは一時的に処理を中断します。割り込みが終了すると、アプリケーションは再び処理を再開します。例えば、iBooks（または同様のアプリケーション）で電子書籍を読んでいる最中に、電話やFaceTime通話に応答した場合などがこれに該当します。ユーザーが電話に出ると、iBooksは通話が終了するまで待機し、通話終了後に処理を再開します。
- アラートを表示: アラートは消え、通常どおり作業を続けることができます。「SMS受信」というメッセージがヘッダーに表示されますが、ユーザーはそれを気にせず、アプリケーションを通常どおり使用し続けます。Facebookの新しい友達リクエストやWhatsAppメッセージなど、他のモバイルアプリのアラートもこのカテゴリに分類されます。ただし、ユーザーがメッセージを読むことを選択した場合は、1で説明した動作が適用されます。アラートを無視した場合、アプリケーションの状態は変わりません。
- アクションの呼び出し： 作業を再開する前に、アラームをオフにするか、スヌーズする必要があります。アプリの更新メッセージについても同様です。続行する前に、変更をキャンセルするか、承認する必要があります。バッテリー残量低下アラートもその一例です。デバイスが対応していれば、通常どおり作業を続けるか、低電力モードに移行するかを選択できます。
- 影響なし: 例えば、ネットワーク接続が利用可能になり、お使いのデバイスがそれに接続する場合などが挙げられます。また、デバイスを充電のために接続する場合も、アラートや操作を促す必要はありません。おそらく、アプリケーションを使い続けている間に自動的に処理が行われます。
したがって、テスト対象の割り込みの種類に応じて、その動作を理解し、アプリケーションがそれを満たすかどうかを確認してください。また、上記の動作はすべてのアプリケーションやデバイスで同じである必要はありません。モバイルアプリの具体的な詳細を必ず確認してください。
割り込みテストのテストケースと期待される結果
想定される解決策が合意されると、それぞれの障害は、トリガー、アクション、検証可能な結果を備えた通常のテストケースとなります。以下の表は、上記の4つの解決策が具体的なシナリオにどのように反映されるかを示しています。
| 中断 | テストシナリオ | 期待される結果 |
| 電話の着信 | フォームが半分入力された時点で通話を開始し、応答してから通話を終了する。 | アプリケーションはバックグラウンドに移行し、入力されたデータがそのまま保持された状態で同じ画面で再開します。 |
| 受信SMSまたはプッシュ通知 | 動画のアップロード中にメッセージを送信し、バナーを無視してください | バナーが表示されたり消えたりするが、アプリケーションの状態は変化しない。 |
| 警報 | アクティブなセッション中にスケジュールされたアラームが鳴り、それを解除する | アラームはまず行動を促すものであり、その後アプリケーションは停止したところから再開する。 |
| ローバッテリ警告 | 取引中にデバイスのバッテリー残量が警告しきい値まで低下する | 警告が表示され、取引はキャンセルされず、低電力モードでも画面は破損しません。 |
| ネットワーク接続の切断 | リクエストの途中で接続を無効にし、その後復元する | 明確なメッセージが表示され、クラッシュは発生せず、復元時にリクエストは安全に完了または失敗します。 |
| 充電中または充電解除中 | アクティブなセッション中に充電器を接続および切断する | 影響なし ― アプリケーションは目に見える変化なく継続されます |
| アプリケーション更新のお知らせ | アプリケーションの使用中にアップデートのプロンプトを表示する | ユーザーはキャンセルまたは承認を選択でき、どちらの選択をしても画面はそのまま表示されます。 |
アプリケーション全体で中断ごとに1行ずつ記述するのではなく、重要な画面ごとに中断ごとに1行ずつ記述するようにしてください。支払い画面、ログイン画面、長いフォームはそれぞれ異なるエラーが発生するため、単一の汎用的なケースではその違いが隠蔽されてしまいます。
割り込みテストとは何か、そして割り込みテストを実施する際に何を検証するのかを理解したところで、次はその方法について説明します。
割り込みテストの実行方法
次のステートメントを見てください。ユーザーが電話の着信を受けると、iBooks はバックグラウンドで実行される必要があります。
これはiBooksアプリの機能要件の一つではないでしょうか？私ならそう思います。
したがって、割り込みテストは次のサブセットです。 機能テスト モバイルアプリケーションの場合、割り込みテストを実施するには、モバイルアプリケーションのテストフレームワークとツールをそのまま使用します。これらのシナリオを考案するのはテスターのスキルです。シナリオが考案されたら、テストケースを設計し、他のテストとまったく同じ方法で実行します。
実際には、その手順は短く、繰り返し可能である。
- 重要なユーザー体験（ログイン、支払い、アップロード、長文フォームの入力、メディア再生など）をリストアップしてください。
- 上記のリストから考えられるすべての妨害要因を、それぞれの旅程にマッピングしてください。
- 各ペアリングにおける想定される解決策については、製品オーナーと合意してください。普遍的なデフォルト設定は存在しないためです。
- 最もリスクの高い瞬間に割り込みを実行し、何もしていない瞬間には実行せず、その後処理を再開する。
- アプリケーションがまだ開いているかどうかだけでなく、再開後の状態、データ、セッション、メモリを検証する。
より広範な学問分野に関する詳細については、以下を参照してください。 モバイルテスト チュートリアルとサンプルケース モバイルアプリのテスト.
中断をシミュレートするためのツールとテクニック
上記のシナリオは、待つのではなく、必要に応じて生成される必要があり、各プラットフォームはそれを実現する方法を提供している。
- Android エミュレーター拡張コントロール: エミュレーターのサイドパネルは、着信、SMS、バッテリー残量と充電状態、携帯電話の信号強度をシミュレートするため、2台目の端末がなくても、ほとんどの割り込みリストを表示できます。
- iOSシミュレーターと Xcode: 接続状態やハードウェアの状態はシミュレーターとデバイス設定の両方から変更可能であり、シミュレーターでは再現できない通話シナリオは、ペアリングされた実機デバイスでカバーできる。
- 2つ目の物理デバイス： テスト対象のデバイスに別の端末から電話をかけたりメッセージを送信したりすることは、特にタイミングが重要な場合において、実際の障害を再現する最も忠実な方法である。
- デバイスの設定： 機内モード、Wi-Fiのオン/オフ切り替え、おやすみモード、バッテリーセーバー、スケジュールアラームは、実際のハードウェアにおける接続性や電源の中断に対応する機能です。
- 自動化フレームワーク： 機能スイートの残りの部分で使用されているのと同じ自動化スタックを使用して、中断の前後にアプリケーションを制御できるため、再開チェックは目視ではなく、アサートによって行われます。
- 実機クラウド： ホスト型デバイスファームは、メーカーやOSバージョンを問わず対応範囲を拡大します。これは、割り込み処理がベンダーごとのカスタマイズの差異が最も大きい分野の一つであるため、重要な点です。
どのようなメカニズムであれ、テストケース内で中断が発生した正確な瞬間を記録してください。「アップロード中の中断」と「アップロード後の中断」は、それぞれ異なる障害モードを持つ別のテストです。
割り込みテストのベストプラクティス
実用的な割り込み処理スイートと、単なる形式的な作業とを分けるのは、いくつかの習慣の違いである。
- 最悪のタイミングで邪魔をする： Target トランザクションがコミットされた瞬間、またはファイルが書き込まれている瞬間。なぜなら、その瞬間こそが状態が最も脆弱な状態だからだ。
- 中断ではなく、再開をテストしてください。 この不具合はほぼ必ず制御が戻った後に発生するため、アサーションは復元された画面で行うべきである。
- ネットワーク変更の双方向をカバーする： 接続が切断されることと、接続が回復されることは別々のケースであり、後者の方が頻繁にスキップされる。
- 期間を変更する： 2秒間のアラートと10分間の通話では、アプリケーションはメモリからの削除を含む、異なるライフサイクル経路をたどることになる。
- OSのバージョンや低スペックのハードウェアにも広く分布している。 バックグラウンドアプリの削除は、性能が制限されたデバイスでははるかに積極的に行われ、フラッグシップ端末では隠されている欠陥を露呈させる。
- 繰り返し発生する作業を自動化する： 接続障害やバッテリー切れへの対応は自動的に行われるため、通話やアラーム発生時の手動作業は不要になります。
- リソースの使用状況と状態を監視します。 メモリリークや復帰時のバッテリー消耗を引き起こす中断は、画面が正しく見えても欠陥であり、この作業は モバイルアプリのパフォーマンステスト.
中断テストは回復テストと同じではないですか?
いいえそうではありません。 回復テスト 障害からの復旧を検証します。中断は必ずしも障害ではなく、単なる障害です。tracる。
それは英語のコンマとピリオドの違いのようなものです。違いは技術的なものに過ぎませんが、その意味は明確です。リカバリテストは、何らかの不具合が発生した後にアプリケーションが復旧できるかどうかを検証するものであり、割り込みテストは、他の処理が前面に出た際にアプリケーションが何らかの不具合を起こすかどうかを検証するものです。
以上が、モバイルアプリケーションテストの重要かつ直感的な分野である割り込みテストを始めるために知っておくべきことです。
