詳細なチュートリアルによるモバイルアプリケーションのテストへの完全ガイド：
モバイルテクノロジーとスマートデバイスは現在のトレンドで、私たちが知る世界の未来を変えるものです。 私たちは皆、それを保証できますよね？ さて、私たちがこれらのモバイル機器を何に使っているかを列挙すると、素人丸出しになります。 このチュートリアルが何をしようとしているのか、率直にお話ししましょう。
The Complete List of 30+ Mobile Testing Tutorials:
Mobile Testing Introduction:
Tutorial #1: Introduction to Mobile Testing
Tutorial #2: iOS App Testing
Tutorial #3: Android App Testing
Tutorial #4: Mobile Testing Challenges and Solutions
Tutorial #5: Why Mobile Testing is Tough?
モバイルデバイスのテスト:
Tutorial #6: 市場から撤去されたAndroidバージョンをテストする
Tutorial #7: ローエンドデバイスでモバイルアプリをテストするには
Tutorial #8: モバイルアプリケーションのフィールドテスト
Tutorial #9: 電話機モデルとOSバージョン。
モバイルUIテスト:
Tutorial #10: モバイルアプリのUIテスト
Tutorial #11: モバイル・レスポンシブ・テスト
Mobile Testing Services:
Tutorial #12: Cloud-Based Mobile Application Testing
Tutorial #13: モバイルテストサービス
チュートリアル#14：モバイルアプリのベータテストサービス
チュートリアル#15：モバイルアプリ開発会社
チュートリアル#16：クラウドベースのモバイルアプリテストサービスプロバイダー
Mobile App Performance and Security Testing:
Tutorial #17.モバイルアプリのパフォーマンスとセキュリティテスト
Mobile App Testing:
Tutorial #14: モバイルアプリベータテスト
Tutorial #14: モバイルテストサービスチュートリアル#18: モバイルアプリのセキュリティテストのガイドライン
Mobile Testing Tools:
Tutorial #19: Android App Testing Tools
Tutorial #20: Best Mobile App Security Testing Tools
Tutorial #21: 58 Best Mobile Testing Tools
Mobile Automation Testing:
Tutorial #22: Appium Mobile Automation Tool tutorial
Tutorial #23: Android App Testing Tools
Tutorial #20: Android App Security Testing Tools
Tutorial #22: Mobile App Testing Tools
Mobile Automation ToolsMobile Automation ToolTutorial #22: Android App Testing Tools Appium Studio tutorial
Tutorial #24: TestComplete Toolを使ったAndroidアプリケーションの自動化
Tutorial #25: Appium Studio tutorial
Tutorial #24: TestComplete Toolを使ったAndroidアプリケーションの自動化
Tutorial #25: Robotiumチュートリアル – AndroidアプリのUIテストツール
Tutorial #26: Selendroidチュートリアル。 モバイル自動化フレームワーク
チュートリアル#27: pCloudy チュートリアル:
Tutorial #28: Katalon Studio & Kobiton’s Cloud-Based Device Farm Tutorial
Mobile Testing Career:
Tutorial #29: How to Get a Mobile Testing Job Fast
Tutorial #30: Katalon Studioのチュートリアル。 モバイルテストの面接の質問と履歴書
Tutorial #31: モバイルテストの面接の質問 Part 2
***************************
まず、シリーズの最初のチュートリアルを始めましょう。
- Tutorial #1: Introduction to Mobile Application Testing
- モバイルテストの種類
- The significance of Mobile Application Testing
- Basic Difference Between Mobile and Desktop Application Testing:
- モバイル アプリケーション テストの種類：
- Mobile Application Testing Strategy
- おすすめツール
- Test Cases for Testing a Mobile App
- Typical activities and proceedings in Testing Mobile Application
- How to Test Mobile Applications on Both Android and iOS Platforms
- Basic Difference between Android and iOS Testing
- Key Factors in Mobile Testing
- テストを制限しない
- Cross-Platform Testing
- Keep an eye on your Mobile App
- アプリのアクセス許可テスト
- 常に前面に立つ
- Keep your app in background for a long time (12-24 hours)
- アプリのパフォーマンス テスト
- 結論
Tutorial #1: Introduction to Mobile Application Testing
電話が隅に置かれ、注意を引くために鳴らなければならない家電であったり、コンピューターが一部の人だけが使う機械だった時代はもう過去のものです。
コンピュータは大流行し、私たち人間の思考、行動、学習、存在の仕方を変えました。 人々は、すべてのことにラップトップ/PC をオンにすることを望まず、むしろ、携帯デバイスがすべてをすばやく実行することを望んでいます。 このチュートリアルは、すでにモバイルテストを行っている人、または最近モバイルテストに切り替えた人を対象としています。 モバイルテスト関連の用語の定義については、すでに多くのチュートリアルがあるので、このチュートリアルの範囲を直接扱います。
このチュートリアルは、モバイルテストへの導入とあなたのガイドの両方になります。
モバイルテストの種類
モバイルデバイスで行われるテストには、大きく分けて2つの種類があります：
#1. ハードウェアのテスト。
デバイスは、内部プロセッサ、内部ハードウェア、画面サイズ、解像度、スペースまたはメモリ、カメラ、ラジオ、Bluetooth、WIFI などを含みます。 これは、単純に「モバイルテスト」と呼ばれることもあります。
#2. ソフトウェアまたはアプリケーションのテスト：
モバイルデバイス上で動作するアプリケーションとその機能がテストされます。 先の方法と区別するために「モバイルアプリケーションテスト」と呼ばれています。 モバイルアプリケーションでも、理解する上で重要な基本的な違いがいくつかあります：
a) ネイティブアプリ。
b) モバイルWebアプリケーションは、モバイルネットワークまたはWIFIなどのワイヤレスネットワークに接続し、Chrome、Firefoxなどの異なるブラウザを使用してモバイルでWebサイトにアクセスするためのサーバーサイドアプリケーションです。
c) ハイブリッド アプリは、ネイティブ アプリと Web アプリの組み合わせで、デバイスまたはオフラインで実行され、HTML5 や CSS などの Web 技術を使って記述されています。
記事の残りの部分は、モバイル アプリケーション テストについてです。
The significance of Mobile Application Testing
Testing applications on mobile devices is more challenging than web apps on the desktop because
- Different range of mobile devices with different screen sizes and hardware configurations like a hard keypad, virtual keypad (touch screen) and trackball etc…そのため、モバイル デバイスのアプリケーションをテストするのは、デスクトップのウェブ アプリケーションをテストするよりも困難です。
- HTC、Samsung、Apple、Nokia などの多種多様なモバイル デバイス。
- Android、Symbian、Windows、Blackberry、IOS などさまざまなモバイル オペレーティング システム。
- iOS 5.x, iOS 6.x, BB5.x, BB6.x などの異なるバージョンのオペレーションシステム。
- GSM や CDMA など異なるモバイル ネットワーク オペレーター。このような状況下で、私たちは、「私たちは、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような状況下で、このような私たちを助けてくれるのは、私たちである。 その結果、金銭的な損失や法的な問題、取り返しのつかないブランドイメージの低下を招くことがよくあります。
Basic Difference Between Mobile and Desktop Application Testing:
モバイル アプリケーション テストをデスクトップ テストと区別するいくつかの明白な側面
- デスクトップの場合、アプリケーションは中央処理装置でテストされます。 モバイル デバイスでは、アプリケーションは Samsung、Nokia、Apple、HTC などの携帯電話でテストされます。
- モバイル デバイスの画面サイズはデスクトップよりも小さい。
- デスクトップ アプリケーションのテストに使用される自動化ツールは、モバイル アプリケーションでは動作しないかもしれません。
モバイル アプリケーション テストの種類：
上記のすべての技術面に対処するために、以下の種類のテストがモバイル アプリケーションで実行されます。
- ユーザビリティ・テスト-モバイルアプリが使いやすく、顧客に満足のいくユーザー体験を提供できることを確認する。
- 互換性テスト-要件に従って、異なるモバイルデバイス、ブラウザ、画面サイズ、OSバージョンでアプリケーションをテストする。
- インターフェーステスト-メニューオプション、ボタン、ブックマーク、履歴、設定、アプリケーションのナビゲーションフローのテスト。
- サービステスト-アプリケーションのサービスをオンラインとオフラインでテスト。
- 低レベルのリソーステスト：メモリ使用量のテスト、一時ファイルの自動削除、ローカルデータベースの成長の問題は、低レベルのリソーステストとして知られています。
- パフォーマンステスト：2G、3GからWIFIへの接続変更、文書の共有、バッテリー消費などによるアプリケーションのパフォーマンスのテスト。
- インストールテスト – デバイスへのインストール/アンインストールによるアプリケーションの検証。
- セキュリティテスト – 情報システムがデータを保護するかどうかを検証するためのアプリケーションのテスト。
Mobile Application Testing Strategy
テスト戦略は、すべての品質とパフォーマンスのガイドラインが満たされるようにしなければならない。 この分野でのいくつかのポイント:
1) デバイスの選択 – 市場を分析し、広く使用されているデバイスを選択します。 (この決定は、ほとんどクライアントに依存しています。 クライアントまたはアプリ開発者は、特定のデバイスの人気度やアプリケーションのマーケティング ニーズを考慮して、テストに使用する端末を決定します)
2) エミュレーター – これらの使用は、アプリを迅速かつ効率的にチェックできるため、開発の初期段階で非常に有用です。 エミュレータは、ソフトウェアそのものを変更することなく、ある環境から別の環境へソフトウェアを走らせるシステムです。 実際のシステム上の機能や動作を複製します。
モバイル エミュレータの種類
- Device Emulator- デバイス メーカーが提供
- Browser Emulator- モバイル ブラウザ環境をシミュレートします。
- Operating systems Emulator- AppleはiPhone、MicrosoftはWindows Phone、GoogleはAndroid Phoneのエミュレータを提供
おすすめツール
#1) Kobiton
Kobitonは、手頃で非常に柔軟な、クラウド型のモバイル体験プラットフォームで、実際のデバイスを使ってAndroidとiOS両方でネイティブ、Web、ハイブリッドアプリのテストと提供を加速させることが可能です。 同社の新しいスクリプトレス テスト自動化により、コーディングの専門知識がないチームでも、オープン スタンダードの Appium スクリプトを簡単に生成できます。
=> Kobiton ウェブサイトへ
List of some free and easy to use mobile device emulator
i. 携帯電話エミュレータ – iPhone、Blackberry、HTC、Samsung などの携帯電話のテストに使用します。
ii. MobiReady – これを使用すると、Web アプリをテストできるだけでなく、コードも確認できます。
iii. Responsivepx – Web ページのレスポンス、外観、Web サイトの機能性をチェックします。
iv. Screenfly – カスタマイズ可能なツールで、さまざまなカテゴリのWebサイトをテストするために使用されます。
3) モバイル アプリの開発が満足できるレベルで完了したら、よりリアルなシナリオに基づいたテストのために物理デバイスでのテストに移行することができます。 クラウドコンピューティングは、基本的にインターネットを介して複数のシステムまたはネットワーク上でデバイスを実行し、アプリケーションをテスト、更新、管理することができます。 テスト目的で、シミュレーター上に Web ベースのモバイル環境を作成し、モバイル アプリにアクセスします。
Pros:
- Backup and recovery- クラウドコンピューティングは、リモートロケーションからデータのバックアップを自動的に作成し、データを簡単に回復および復元します。 また、ストレージ容量は無制限です。
- クラウドコンピューティングはコスト効率が良く、使用、保守、更新が簡単です。
- 複数のデバイスで同じスクリプトを並行して実行できる。
Cons
- コントロールが少ない- アプリケーションはリモートまたはサードパーティ環境で実行されるので、ユーザーは機能に対するコントロールやアクセスが制限されます。
- ネットワークの問題は、可用性と機能に影響します。
- セキュリティとプライバシーの問題 – クラウドコンピューティングはインターネットコンピューティングであり、インターネット上のものは安全ではないので、データハッキングの可能性はより高くなります。
- アプリケーションが一度か二度のテストを必要とする場合、それを手動で行います。
- 回帰テストケース用のスクリプトを自動化します。 回帰テストが繰り返される場合、自動テストはそれに最適です。
- 手動で実行すると時間がかかる複雑なシナリオのスクリプトを自動化します。
モバイル アプリケーションのテストには、2 種類の自動ツールがあります：
オブジェクト ベースのモバイル テスト ツール- デバイス画面上の要素をオブジェクトにマッピングすることによって自動化します。
- Eg:- Ranorex, jamo solution
画像ベースのモバイル テスト ツール-要素の画面座標に基づいて自動化スクリプトを作成します。
- Eg:- Sikuli, Egg Plant, RoutineBot
6) ネットワーク設定もモバイル テストでは必要な部分です。 2350>
Test Cases for Testing a Mobile App
機能ベースのテストケースに加え、モバイル アプリケーション テストでは、以下のシナリオをカバーする特別なテストケースが必要です。
- バッテリーの使用状況 – モバイル機器でアプリケーションを実行している間、バッテリー消費を追跡することが重要です。
- アプリケーションの速度 – 異なる機器、異なるメモリ パラメータ、異なるネットワーク タイプなどでの応答時間。
- データ要件 – インストールのため、また限られたデータプランのユーザーがダウンロードできるかどうかを確認するため。
- メモリ要件-再び、ダウンロード、インストール、実行するため
- アプリケーションの機能性-ネットワーク障害やその他の原因でアプリケーションがクラッシュしないことを確認します。
モバイル アプリケーションのテスト用のいくつかのサンプル テストケースをダウンロードすることができます。
=> モバイル アプリケーションのサンプル テストケースをダウンロードする
Typical activities and proceedings in Testing Mobile Application
テストの範囲は、チェックすべき要件の数またはアプリケーションに加えられた変更の程度に依存します。 変更が少ない場合は、サニティ テストのラウンドで十分です。 大きな、あるいは複雑な変更の場合は、完全なリグレッションを推奨します。 ILL (International Learn Lab) は、管理者と出版社が共同で Web サイトを作成するのに役立つように設計されたアプリケーションです。 Web ブラウザーを使用して、講師は一連の機能から選択して、要件を満たすクラスを作成します。
Mobile Testing process:
Step #1. テストの種類を特定する。 ILLアプリケーションはブラウザに適用されるため、さまざまなモバイル デバイスを使用して、サポートされているすべてのブラウザでこのアプリケーションをテストすることが必須となります。 手動および自動テストケースを組み合わせて、さまざまなブラウザーでユーザビリティ、機能、および互換性テストを行う必要があります。 手動および自動化テスト。 このプロジェクトに従った方法論は、2週間の反復を伴うアジャイルです。 2週間ごとに開発チームはテストチーム用に新しいビルドをリリースし、テストチームはQA環境でテストケースを実行します。 自動化チームは、基本的な機能のセットに対してスクリプトを作成し、新しいビルドがテストするのに十分安定しているかどうかを判断するのに役立つスクリプトを実行します。 手動テストチームは、新しい機能をテストします。
JIRA は、受け入れ基準の作成、テストケースの維持、および不具合の記録/再確認に使用されます。 イテレーションが終了すると、イテレーション計画会議が開催され、開発者が参加します。 チーム、製品オーナー、ビジネスアナリスト、および QA チームは、何がうまくいき、何を改善する必要があるかについて議論します。 ベータテスト。 QAチームによる回帰テストが完了すると、ビルドはUATに移行する。 ユーザー受入テストは、クライアントによって行われます。 彼らは、すべてのバグが修正され、アプリケーションが承認されたすべてのブラウザー上で期待どおりに動作していることを確認するために、すべてのバグを再確認します。 パフォーマンス テスト。 パフォーマンス テスト チームは、JMeter スクリプトを使用して、アプリケーションにさまざまな負荷をかけ、Web アプリケーションのパフォーマンスをテストします。 ブラウザー テスト。 さまざまなシミュレーション ツールや実際のモバイル デバイスを使用して、複数のブラウザーで Web アプリケーションをテストします。 起動計画。 4週間ごとに、テストはステージングに移行し、これらのデバイスでエンドツーエンドテストの最終ラウンドが実行され、製品が本番に対応できることを確認します。 そして、ライブになります！
*****************
How to Test Mobile Applications on Both Android and iOS Platforms
iOS と Android プラットフォームでアプリをテストするテスターにとって、両者の違いを知ることは非常に重要です。 iOS と Android には外観、アプリ ビュー、エンコード標準、パフォーマンスなどにおいて多くの相違点があります。
Basic Difference between Android and iOS Testing
すべてのチュートリアルに目を通したかもしれませんが、ここにいくつかの大きな違いを挙げておきました。
たとえば、Samsung S2 のサイズは、Nexus 6 と比較すると小さすぎます。 アプリのレイアウトやデザインが、どちらかのデバイスで歪んでしまう可能性が高くなります。 iOSの場合、市場に出回っている端末は数えるほどしかなく、そのうち多くの端末が同じような解像度を持っているため、その可能性は低くなります。
例えば、iPhone 6以上が登場する前は、すべての旧バージョンが同じようなサイズしかありませんでした。 しかし、画像やその他のUI要素がすべてのデバイスで正しく表示されることを確認するのはテスターの責任となります。
画像解像度の概念を理解するために、以下の図を参照することができます。 そのため、下位のデバイスでは、アプリの動作が遅くなる可能性があります。
#4) Android のもうひとつの問題は、ソフトウェアのアップグレードがすべてのデバイスで一度に利用できるわけではないことです。 デバイスメーカーがデバイスのアップグレードのタイミングを決定します。 また、開発者にとっても、両方のバージョンをサポートするためにコードを修正するのは面倒な作業です。
たとえば、Android 6.0の登場時、このOSはアプリレベルのパーミッションをサポートし始めたので、大きな変化がありました。 さらに明確にすると、ユーザーはアプリ レベルでも権限（場所、連絡先）を変更できました。
今、テスト チームには、Android 6.0 以上でアプリ起動時に権限画面を表示し、それ以下のバージョンでは権限画面を表示しないことを確認する責任があります。 Androidでは、ユーザーがベータユーザー一覧に追加された場合、ベータユーザーとして追加されたのと同じ電子メールIDでPlayストアにサインインしている場合のみ、Playストア上で更新されたベータ版ビルドを見ることができます。
Key Factors in Mobile Testing
私は過去 2 年間、iOS と Android プラットフォームの両方でモバイル テスティングに携わってきました。このチュートリアルで以下に述べるすべてのキーポイントは、私の個人的経験から得たもので、一部はプロジェクトで遭遇した問題から派生したものです。 iOS/Android テスターである場合、少なくとも Android または iOS の一般的な制限事項や基本的な機能に精通しておくことをお勧めします。
以下にいくつかの例を挙げます。
- 6.0.1 バージョン未満の Android デバイスでは、アプリ レベルでカメラやストレージなどの権限を変更できません。 簡単に説明すると、コールキットは通話アプリで使用され、ユーザーが WhatsApp や Skype などの通話アプリから電話を受けたときに全画面表示されます。 一方、iOS バージョン 10.0 未満では、これらの通話は通知バナーとして表示されます。
- Paytm で、財布にお金を追加する場合に、アプリが銀行の支払いページにリダイレクトしない問題に遭遇した人は多いかもしれません。 上記の問題は、銀行または Paytm サーバーの問題だと思いますが、AndroidSystemWebView が更新されていないだけです。
- 簡単に言うと、アプリで Web ページを開くときはいつでも、AndroidSystemWebView を更新する必要があります。
テストを制限しない
テストは単にモバイル アプリを調査してバグを記録することに限定すべきではありません。 QA として、サーバーにヒットしたすべてのリクエストと、そこから得られたレスポンスを認識する必要があります。
プロジェクトで使用されているものに応じて、ログを表示するように Putty を構成するか、ログ用の sumo ロジックを検証します。 これは、アプリケーションのエンドツーエンドのフローを知るのに役立つだけでなく、より多くのアイデアやシナリオを今得られるので、より良いテスターになります。
理由。 この世界には、理由なくして生まれてくるものはありません。 どのような発言にも、その背後にある正当な理由があるはずです。 ログを分析する背後にある理由は、多くの例外がログで観察されますが、それらは UI に影響を示さないため、それに気づかないということです。 UI には何の影響もありませんが、将来的な懸念事項であるかもしれません。 この種の例外が増え続けると、アプリがクラッシュする可能性があります。
最後の文章でアプリのクラッシュについて触れましたが、これは QA がプロジェクトの crashlytics にアクセスすることにつながります。
Crashlyticsは、クラッシュが時間やデバイス モデルとともに記録されるツールです。 UI では見えないかもしれませんが、crashlytics に記録されるクラッシュがあります。 メモリ不足によるクラッシュや、後にパフォーマンスに影響を与える致命的な例外が発生する可能性があります。
Cross-Platform Testing
Cross-Platform Interaction Testing は、非常に重要です。
簡単な例を挙げると、画像や動画の送信をサポートする WhatsApp のようなチャット アプリケーションに取り組んでいて、アプリケーションが iOS と Android の両方のプラットフォームで構築されているとします（開発が同期しているかどうかは別として）
Android と iOS のコミュニケーションを確実にテストすることです。
Keep an eye on your Mobile App
Another important advice for mobile testers – Please keep checking the size of your app after each release.
アプリのサイズが、エンド ユーザーである私たちでさえ、その大きなサイズのためにこのアプリをダウンロードしたくないと思うようなポイントに到達しないようにする必要があります。 開発チームがバージョン番号の不一致を行った可能性があるため、アップグレード時にアプリがクラッシュしないことを確認します。
データの保持も同様に重要で、ユーザーが以前のバージョンで保存した設定はすべて、アプリをアップグレードしても保持されるべきです。
そうです、多くのデバイスがアプリをサポートしない可能性があります。 ベンダーが US の上に独自のラッパーを記述していることをご存知の方も多いと思いますが、アプリの SQL クエリがデバイスと互換性がないために例外が発生し、その電話機ではアプリが起動しないこともあり得ます。
アプリのアクセス許可テスト
次に、モバイル アプリのアクセス許可テストがあります。 ほぼすべての 2 番目のアプリは、ユーザーに携帯電話の連絡先、カメラ、ギャラリー、位置情報などへのアクセスを要求します。 これらのアクセス許可の適切な組み合わせをテストしないことで、間違いを犯すテスターを何人か見てきました。
画像や音声ファイルを共有するすべての機能を持つチャット アプリをテストしていたときのリアルタイムな例を思い出すことができます。 ストレージの許可が NO に設定されていました。
ここで、ユーザーがカメラ オプションをクリックすると、ストレージの許可が YES に設定されるまで、決して開きませんでした。 Android Marshmallow には、ストレージの許可が NO に設定されている場合、そのアプリでカメラを使用できない、という機能があるため、このシナリオは無視されました。 ソフトウェア業界に精通したエンド ユーザーは、あまりにも多くの権限を要求されるアプリをダウンロードしないかもしれません。 あなたのアプリから任意の機能を削除した場合は、同じの許可画面を削除することを確認してください。
Moral of the story – もしあなたが疑わしい場合は、ちょうどそれを自分で結論づけることはありません。 同じプラットフォーム上の他の類似アプリと比較することで、テスト中の機能が動作するかどうかの論拠を強めることができます。 このトピックが読者の大半の興味を引かないことは承知していますが、Apple の拒否ポリシーを知っておくことは常に良いことです。
テスターとして、技術的な側面を満たすことは難しくなりますが、テスターが対処できるいくつかの拒否基準があります。
これについては、こちらをご覧ください。
常に前面に立つ
テスターである以上、開発チームや管理者から物事を譲り渡さないようにすることです。 もし、あなたがテストに情熱を持っているならば、「常にフロント・フットであれ」。
最も重要なことは、JIRA、QC、MTM、またはプロジェクトで使用されているどれでもいいので、顧客やビジネスアナリストからのチケットに関するすべての最新情報を常に見ておくことです。 また、修正が必要な場合は、自分の意見を共有できるようにしておくことです。 これは、さまざまなドメインやプラットフォームで作業しているすべてのテスターに当てはまります。
製品を自分のものとして感じない限り、新しい改善や既存の機能への変更について提案するべきでは決してありません。
Keep your app in background for a long time (12-24 hours)
I know it sounds weird but there is much logic behind the scenes which all of us don’t understand.
I have seen the app crashing after launching it, say after around 14 hours from background state.This is sharing because I have been seen the app crashing after launching it, so after 14 hours from background state. 開発者がどのようにコーディングしたかによって、原因はさまざまです。
リアルタイムの例を共有しましょう。 あるチャットアプリでは、12～14時間後に起動すると、接続中のバナーから抜け出せなくなり、終了して再起動するまで接続されないことがありました。 これらの種類のものをキャッチするのは非常に難しく、ある意味、モバイル テストをより挑戦的で創造的にします。
アプリのパフォーマンス テスト
モバイル世界では、アプリのパフォーマンスは、アプリケーションが世界中で認識される程度に影響を及ぼします。 テスト チームとして、アプリのレスポンスを確認し、さらに重要なことに、多数のユーザーが一斉に使用するときにどのように動作するかを確認することは、あまりにも重要になります。
例を挙げます。
PayTm について説明します。
皆さんは PayTm アプリの [お金を追加] オプションをクリックし、財布にある残高を表示したことがあるはずです。 舞台裏で何が起こっているかを考えてみると、PayTm UserID でサーバーにリクエストを送信し、サーバーはあなたのアカウントの残高を示す応答を返します。 エンドユーザーのユーザビリティが私たちの最大の目標であるため、1000 人のユーザーがサーバーにアクセスした場合でも、時間通りに応答が返されるようにする必要があります。
結論
このチュートリアルの最後に、モバイル テストは最初は非常に簡単そうに見えますが、掘り下げていくと、開発したものが世界中の何千ものデバイスでスムーズに動作することを確認するのは簡単ではないことがわかります。 しかし、どんなシナリオも見逃さないようにすることがテスターの義務になります。 バッテリーの消費、中断テスト、異なるネットワーク (3G、Wi-Fi) でのテスト、ネットワークを切り替えながらのテスト、モバイル アプリのモンキー テストなどのシナリオは、モバイル テストに来るとき、すべて役に立ちます。
私はこの分野で6年ほど働いていますが、仕事が単調になることがあるのは重々承知しています。
正しいテスト戦略を設計し、正しいモバイル シミュレーター、デバイス、およびモバイル テスト ツールを選択することにより、100%のテスト カバレッジを確保し、セキュリティ、ユーザビリティ、パフォーマンス、機能性、および互換性に基づくテストをテスト スイートに含めることが可能になります。 Swapna、Hasnet、および他の多くのモバイルテストの専門家に感謝します！
次の記事では、iOSアプリのテストについてもっと議論する予定です
最終更新日: 2012年11月28日 2021年2月18日