モバイル アプリのテスト: サンプル テスト ケースとテスト シナリオ
トーマス・ハミルトン
学習者からのよくある質問は、「モバイル アプリをテストするにはどうすればよいですか?」です。 このチュートリアルでは、モバイル アプリケーションをテストするためのサンプル テスト シナリオ/テスト ケースを提供します。
モバイル テストの要件に基づいて、一部またはすべてのテスト ケースを実行できます。 テスト ケースは、モバイル テスト タイプに基づいて編成されています。
モバイルアプリケーションの機能テスト
この モバイルアプリケーションの機能テスト ユーザー操作などのモバイル アプリケーションの機能をテストするプロセスや、ユーザーが実行する可能性のあるトランザクションをテストするプロセスです。 モバイル アプリケーションの機能テストの主な目的は、品質を確保し、指定された期待を満たし、リスクやエラーを軽減し、顧客満足度を高めることです。
機能テストに関連するさまざまな要素は次のとおりです。
- ビジネス機能の使用法 (銀行、ゲーム、ソーシャル、またはビジネス) に基づくアプリケーションのタイプ
- Target 対象者タイプ（消費者、企業、教育）
- アプリケーションを広めるために使用される配布チャネル (例: Apple App Store、Google play、直接配布)
機能テストにおける最も基本的なテスト シナリオは次のように考えることができます。
- すべての必須必須フィールドが要求どおりに機能しているかどうかを検証します。
- 必須フィールドが、必須でないフィールドとは異なる方法で画面に表示されることを検証します。
- アプリケーションが起動/停止するたびに、アプリケーションが要件どおりに動作するかどうかを検証します。
- 電話の着信があるたびにアプリケーションが最小化モードになるかどうかを検証します。 同じことを検証するには、XNUMX 番目の電話を使用してデバイスを呼び出す必要があります。
- アプリが実行されているときはいつでも、電話機が SMS を保存、処理、受信できるかどうかを検証します。 同じことを検証するには、XNUMX 番目の電話を使用して、テスト対象のデバイスとテスト対象のアプリケーションが現在実行されているデバイスに SMS を送信する必要があります。
- 必要なときにいつでも、デバイスが必要なマルチタスク要件を実行できることを検証します。
- アプリケーションが共有、投稿、ナビゲーションなどの必要なソーシャル ネットワーク オプションを許可していることを検証します。
- アプリケーションが必要とする Visa、Mastercard、Paypal などの支払いゲートウェイ トランザクションをアプリケーションがサポートしていることを検証します。
- 必要に応じて、ページスクロールシナリオがアプリケーションで有効になっていることを検証します。
- アプリケーション内の関連モジュール間のナビゲーションが要件に従っていることを検証します。
- 切り捨てエラーが絶対に許容可能な限度内であることを検証するため。
- 「ネットワーク エラー。」などの適切なエラー メッセージがユーザーに表示されることを検証します。 ネットワークエラーが発生するたびに、しばらくしてからお試しください。
- インストールされたアプリケーションが他のアプリケーションを十分に実行できること、および他のアプリケーションのメモリを消費しないことを検証します。
- ハードリブートまたはシステムクラッシュが発生した場合に、アプリケーションが最後の操作から再開されることを検証します。
- ユーザーに必要なリソースがあり、重大なエラーが発生しない限り、アプリケーションのインストールがスムーズに実行できるかどうかを検証します。
- アプリケーションが要件に従って自動起動機能を実行することを検証します。
- モバイルのすべてのバージョン (2g、3g、4g) でアプリケーションが要件に従って動作するかどうかを検証します。
- 実行する 回帰テスト システムの既存の領域に変更が加えられた後に、その領域で新しいソフトウェアのバグを発見します。 また、以前に実行したテストを再実行して、変更によってプログラムの動作が変わっていないことを確認します。
- アプリケーションが、アプリケーションに詳しくないユーザー向けに利用可能なユーザー ガイドを提供しているかどうかを検証するため
パフォーマンステストのテストケース
このタイプのテストの基本的な目的は、多数のユーザーによるアクセスやデータベース サーバーなどの主要なインフラストラクチャ部分の削除など、特定のパフォーマンス要件の下でアプリケーションが適切に動作することを確認することです。
モバイル アプリケーションのパフォーマンス テストの一般的なテスト シナリオは次のとおりです。
- アプリケーションがさまざまな負荷条件下で要件どおりに動作するかどうかを判断します。
- 現在のネットワーク カバレッジがピーク、平均、最小のユーザー レベルでアプリケーションをサポートできるかどうかを判断します。
- 既存のクライアント/サーバー構成セットアップが必要な最適なパフォーマンス レベルを提供しているかどうかを判断します。
- アプリケーションが必要な許容レベルで実行するのを妨げているさまざまなアプリケーションおよびインフラストラクチャのボトルネックを特定します。
- アプリケーションの応答時間が要件どおりであるかどうかを検証します。
- 製品やハードウェアを評価して、予測される負荷量を処理できるかどうかを判断します。
- バッテリー寿命が、予測される負荷量の下でアプリケーションの実行をサポートできるかどうかを評価します。
- ネットワークが 2G/3G から WIFI に、またはその逆に変更された場合のアプリケーションのパフォーマンスを検証します。
- 必要な各CPUサイクルを検証するには最適化が必要です
- バッテリー消費、メモリ リーク、GPS などのリソース、カメラのパフォーマンスが必要なガイドラインの範囲内であることを検証します。
- ユーザーの負荷が厳しい場合にアプリケーションの寿命を検証するため。
- デバイスを持ち歩きながらネットワークのパフォーマンスを検証します。
- 断続的な接続フェーズのみが必要な場合にアプリケーションのパフォーマンスを検証するため。
セキュリティテストのテストケース
セキュリティ テストの基本的な目的は、アプリケーションのデータとネットワークのセキュリティ要件がガイドラインに従って満たされていることを確認することです。
以下は、モバイル アプリケーションのセキュリティをチェックする上で最も重要な領域です。
- アプリケーションがブルート フォース攻撃に耐えられることを検証するため。ブルート フォース攻撃は、ユーザーのユーザー名、パスワード、またはクレジット カード番号を推測するために使用される試行錯誤の自動化されたプロセスです。
- 適切な認証なしで攻撃者が機密コンテンツや機能にアクセスすることをアプリケーションが許可していないかどうかを検証します。
- アプリケーションに強力なパスワード保護システムがあり、攻撃者が他のユーザーのパスワードを取得、変更、または回復できないことを検証します。
- アプリケーションにセッションの有効期限が不十分になっていないことを検証するため。
- 動的な依存関係を特定し、攻撃者によるこれらの脆弱性へのアクセスを防ぐための措置を講じます。
- を防ぐために SQL インジェクション関連の攻撃。
- アンマネージ コード シナリオを特定して回復するため。
- 証明書が検証されたかどうかを確認するには、アプリケーションが証明書のピン留めを実装しているかどうかを調べます。
- アプリケーションとネットワークをサービス妨害攻撃から保護するため。
- データ ストレージとデータ検証の要件を分析するため。
- セッション管理を有効にして、権限のないユーザーによる一方的な情報へのアクセスを防止します。
- 暗号化コードが壊れているかどうかを確認し、修復されていることを確認します。
- ビジネス ロジックの実装が安全であり、外部からの攻撃に対して脆弱ではないかどうかを検証します。
- ファイル システムの相互作用を分析するには、脆弱性を特定し、問題を修正します。
- プロトコル ハンドラーを検証するため。たとえば、悪意のある iframe を使用してアプリケーションのデフォルトのランディング ページを再構成しようとします。
- 悪意のあるクライアント側のインジェクションから保護するため。
- 悪意のあるランタイム インジェクションから保護するため。
- ファイルのキャッシュを調査し、それによる悪意のある可能性を防ぐため。
- アプリケーションのキーボード キャッシュに安全でないデータが保存されるのを防ぐため。
- Cookie を調査し、Cookie による悪意のある行為を防止するため。
- データ保護分析のための定期的な監査を提供するため。
- カスタム作成されたファイルを調査し、カスタム作成されたファイルによる悪意のある行為を防止します。
- バッファオーバーフローやメモリ破損の発生を防ぐため。
- さまざまなデータ ストリームを分析し、それらからの脆弱性を防止します。
ユーザビリティテストのテストケース
モバイル アプリケーションのユーザビリティ テスト プロセスは、多くの機能を備えた遅くて難しいアプリケーションよりも、機能が少ない迅速で簡単なステップ アプリケーションを作成するために実行されます。 主な目的は、使いやすく直感的で、広く使用されている業界で認められたインターフェイスと同様のインターフェイスを最終的に実現することです。
- ボタンが必要なサイズであり、大きな指に適していることを確認するため。
- エンド ユーザーの混乱を避けるために、ボタンが画面の同じセクションに配置されるようにします。
- アイコンが自然でアプリケーションと一貫していることを確認するため。
- 同じ機能を持つボタンも同じ色にする必要があります。
- タップによるズームインおよびズームアウト機能の検証が有効になっていることを確認します。
- キーボード入力を適切な方法で最小化できるようにするため。
- アプリケーションが、間違った項目に触れたときに、許容可能な期間内にアクションを元に戻すか元に戻す方法を提供することを保証するため。
- コンテキスト メニューはすぐに使用する必要があるため、過負荷にならないようにするため。
- テキストがユーザーに見えるようにシンプルかつ明確に保たれるようにするため。
- 短い文章や段落がエンドユーザーにとって読みやすいものであることを確認します。
- フォント サイズが読みやすい大きさであり、大きすぎたり小さすぎたりしないことを確認します。
- ユーザーがアプリケーションのパフォーマンスに役立たない可能性のある大量のデータのダウンロードを開始するたびに、アプリケーションを検証するためのプロンプトがユーザーに表示されます。
- アプリケーションの終了が異なる状態から実行されたことを検証し、同じ状態で再度開くかどうかを確認します。
- 言語翻訳機能が利用可能な場合は常に、すべての文字列が適切な言語に変換されるようにするため。
- アプリケーション項目がユーザーのアクションに応じて常に同期されるようにします。
- アプリケーションの手順に詳しくないエンドユーザーがアプリケーションを理解して操作するのに役立つユーザーマニュアルをエンドユーザーに提供することを保証する。
他のユーザーの感性や快適性を理解できるのは人間だけであるため、ユーザビリティテストは通常手動ユーザーによって行われます。
互換性テストのテストケース
モバイル デバイスでの互換性テストは、モバイル デバイスのサイズ、解像度、画面、バージョン、ハードウェアが異なるため、すべてのデバイスでアプリケーションをテストして、アプリケーションが期待どおりに動作することを確認するために実行されます。
互換性テストの最も重要な領域は次のとおりです。
- アプリケーションのユーザー インターフェイスがデバイスの画面サイズに従っていることを検証するために、テキスト/コントロールが部分的に表示されない、またはアクセスできないことはありません。
- アプリケーションのすべてのユーザーがテキストを読めるようにします。
- アプリケーションの実行中は常に通話/アラーム機能が有効になるようにするため。 アプリケーションは通話が発生すると最小化または一時停止され、通話が停止すると必ずアプリケーションが再開されます。
回復可能性テストのテストケース
- クラッシュリカバリとトランザクション中断
- 予期せぬ中断/クラッシュシナリオ後の効果的なアプリケーション回復状況の検証。
- 停電時（バッテリー切れやデバイスの突然の手動シャットダウンなど）、アプリケーションがトランザクションをどのように処理するかを検証します。
- 接続が中断されたプロセスの検証では、中断された接続によって直接影響を受けたデータを回復するためにシステムを再確立する必要があります。 権利の活用 モバイルテストツール シームレスな回復プロセスを確保するのに役立ちます。
重要なチェックリスト
- インストールテスト (アプリケーションが適切な時間内に、必要な基準に従ってインストールできるかどうか)
- アンインストールテスト (アプリケーションが適切な時間内に、必要な基準に従ってアンインストールできるかどうか)
- ネットワーク テスト ケース (ネットワークが必要な負荷の下で動作しているかどうか、テスト手順中にネットワークが必要なすべてのアプリケーションをサポートできるかどうかの検証)
- マップされていないキーをチェックする
- アプリケーションのスプラッシュ画面を確認する
- 割り込み中やネットワークの問題などの場合にキーパッド入力が継続される
- アプリケーションの終了を処理するメソッド
- アプリケーションがバックグラウンドで実行されている間の充電器効果
- バッテリーの低下と高いパフォーマンスの要求
- アプリケーション実行中のバッテリーの取り外し
- アプリケーション別のバッテリー消費量
- アプリケーションの副作用を確認する
