mobile app testing tutorials
詳細なチュートリアルを使用してモバイルアプリケーションをテストするための完全なガイド：
モバイルテクノロジーとスマートデバイスは現在のトレンドであり、私たちが知っているように世界の未来を変えるでしょう。私たちは皆、保証することができます それ、できませんか？さて、これらのモバイルデバイスを何に使用するかをリストアップすると、素人っぽくなります。あなたは皆それを知っています–多分私たちよりも良いでしょう。
このチュートリアルの内容に直接取り掛かりましょう。
30以上のモバイルテストチュートリアルの完全なリスト：
モバイルテストの概要：
チュートリアル＃1： モバイルテストの概要
チュートリアル＃2： iOSアプリのテスト
チュートリアル＃3： Androidアプリのテスト
チュートリアル＃4 ： モバイルテストの課題とソリューション
チュートリアル＃5： なぜモバイルテストは難しいのですか？
モバイルデバイスのテスト：
チュートリアル＃6： 市場から出されたときにAndroidバージョンをテストする
チュートリアル＃7 ： ローエンドデバイスでモバイルアプリをテストする方法
チュートリアル＃8 ： モバイルアプリケーションのフィールドテスト
チュートリアル＃9： 電話モデルとOSバージョン：どちらを最初にテストする必要がありますか？
モバイルUIテスト：
チュートリアル＃10： モバイルアプリのUIテスト
チュートリアル＃11： モバイルレスポンシブテスト
モバイルテストサービス：
チュートリアル＃12： クラウドベースのモバイルアプリケーションテスト
チュートリアル＃13： モバイルテストサービス
チュートリアル＃14 ： モバイルアプリベータテストサービス
チュートリアル＃15： モバイルアプリ開発会社
チュートリアル＃16： クラウドベースのモバイルアプリテストサービスプロバイダー
モバイルアプリのパフォーマンスとセキュリティのテスト：
チュートリアル＃17： BlazeMeterを使用したモバイルアプリケーションのパフォーマンステスト
チュートリアル＃18 ： モバイルアプリのセキュリティテストガイドライン
モバイルテストツール：
チュートリアル＃19： Androidアプリテストツール
チュートリアル＃20： 最高のモバイルアプリセキュリティテストツール
チュートリアル＃21： 58最高のモバイルテストツール
モバイル自動化テスト：
チュートリアル＃22： Appiumモバイルオートメーションツールのチュートリアル
チュートリアル＃23： AppiumStudioチュートリアル
チュートリアル＃24： TestCompleteツールを使用してAndroidアプリケーションを自動化する
チュートリアル＃25 ： Robotiumチュートリアル–AndroidアプリUIテストツール
チュートリアル＃26： Selendroidチュートリアル：モバイルオートメーションフレームワーク
チュートリアル＃27： pCloudyチュートリアル：実際のデバイスでのモバイルアプリのテスト
チュートリアル＃28： Katalon StudioとKobitonのクラウドベースのデバイスファームチュートリアル
モバイルテストのキャリア：
チュートリアル＃29： モバイルテストの仕事を早く得る方法
チュートリアル＃30： モバイルテストの面接の質問と履歴書
チュートリアル＃31： モバイルテストの面接の質問パート2
************************************************* * **********
シリーズの最初のチュートリアルから始めましょう。
学習内容：
- チュートリアル＃1：モバイルアプリケーションテストの概要
チュートリアル＃1：モバイルアプリケーションテストの概要
電話が隅に座って私たちの注意を引くために鳴らさなければならなかった器具であったか、コンピュータがほんの数人しか使用しなかった機械であった時代は終わりました-彼らは今私たちの存在の延長です-彼らが言われているように行う世界と仮想の使用人。
コンピューターは大流行し、私たち人間の考え方、行動、学習、存在の仕方を変えました。
今日、モビリティソリューションが市場を引き継いでいます。人々は、すべてのラップトップ/ PCの電源を入れたくはありません。むしろ、ハンドヘルドデバイスですべてをすばやく実行することを望んでいます。
したがって、私たちがクライアントに提供するモバイルソリューションは非常によくテストする必要があります。このチュートリアルは、すでにモバイルテストを行っている人、または最近モバイルテストに切り替えた人を対象としています。モバイルテスト関連の用語の定義に関するチュートリアルはすでにたくさんあるので、このチュートリアルの範囲を直接扱います。
このチュートリアルは、モバイルテストの概要とガイドの両方になります。だから、読んでください！
モバイルテストの種類
モバイルデバイスで行われるテストには、大きく分けて2種類あります。
＃1。ハードウェアテスト：
内部プロセッサ、内部ハードウェア、画面サイズ、解像度、スペースまたはメモリ、カメラ、ラジオ、Bluetooth、WIFIなどを含むデバイス。これは、単純な「モバイルテスト」。
＃2。ソフトウェアまたはアプリケーションのテスト：
モバイルデバイスで動作するアプリケーションとその機能がテストされます。それは「モバイルアプリケーションのテスト以前の方法と区別するために」。モバイルアプリケーションでも、理解するのに重要な基本的な違いはほとんどありません。
a）ネイティブアプリ： ネイティブアプリケーションは、モバイルやタブレットなどのプラットフォームで使用するために作成されています。
b）モバイルウェブアプリ は、モバイルネットワークまたはWIFIなどのワイヤレスネットワークに接続することで、Chrome、Firefoxなどのさまざまなブラウザを使用してモバイル上のウェブサイトにアクセスするサーバーサイドアプリです。
c）ハイブリッドアプリ ネイティブアプリとウェブアプリの組み合わせです。これらはデバイス上またはオフラインで実行され、HTML5やCSSなどのWebテクノロジーを使用して記述されています。
これらを際立たせる基本的な違いはいくつかあります。
- ネイティブアプリには単一プラットフォームの親和性があり、モバイルWebアプリにはクロスプラットフォームの親和性があります。
- ネイティブアプリはSDKなどのプラットフォームで記述されていますが、モバイルWebアプリはHTML、CSS、asp.net、Java、PHPなどのWebテクノロジで記述されています。
- ネイティブアプリの場合はインストールが必要ですが、モバイルWebアプリの場合はインストールは必要ありません。
- ネイティブアプリはPlayストアまたはアプリストアから更新できますが、モバイルWebアプリは一元化された更新です。
- 多くのネイティブアプリはインターネット接続を必要としませんが、モバイルウェブアプリの場合は必須です。
- ネイティブアプリは、モバイルWebアプリと比較して高速に動作します。
- ネイティブアプリは、次のようなアプリストアからインストールされます Google Playストア または アプリストア モバイルウェブはウェブサイトであり、インターネット経由でのみアクセスできます。
記事の残りの部分では、モバイルアプリケーションのテストについて説明します。
モバイルアプリケーションテストの重要性
モバイルデバイスでのアプリケーションのテストは、デスクトップでのWebアプリのテストよりも困難です。
- さまざまな範囲のモバイルデバイス ハードキーパッド、仮想キーパッド（タッチスクリーン）、トラックボールなど、さまざまな画面サイズとハードウェア構成を備えています。
- 多種多様なモバイルデバイス HTC、Samsung、Apple、Nokiaなど。
- さまざまなモバイルオペレーティングシステム Android、Symbian、Windows、Blackberry、IOSなど。
- 異なるバージョンのオペレーティングシステム iOS 5.x、iOS 6.x、BB5.x、BB6.xなどのように。
- さまざまなモバイルネットワーク事業者 GSMやCDMAのように。
- 頻繁な更新–（Android- 4.2、4.3、4.4、iOS-5.x、6.xなど）–更新のたびに、アプリケーションの機能に影響がないことを確認するために、新しいテストサイクルをお勧めします。
他のアプリケーションと同様に、モバイルアプリケーションのテストも非常に重要です。これは、特定の製品の顧客は通常数百万人にのぼり、バグのある製品は評価されないためです。それはしばしば金銭的損失、法的問題、そして取り返しのつかないブランドイメージの損傷をもたらします。
モバイルアプリケーションテストとデスクトップアプリケーションテストの基本的な違い：
デスクトップテストとは別にモバイルアプリのテストを設定するいくつかの明らかな側面
- デスクトップでは、アプリケーションは中央処理装置でテストされます。モバイルデバイスでは、アプリケーションはSamsung、Nokia、Apple、HTCなどの携帯電話でテストされます。
- モバイルデバイスの画面サイズはデスクトップよりも小さいです。
- モバイルデバイスのメモリはデスクトップよりも少なくなります。
- モバイルは2G、3G、4G、WIFIなどのネットワーク接続を使用し、デスクトップはブロードバンドまたはダイヤルアップ接続を使用します。
- デスクトップアプリケーションのテストに使用される自動化ツールは、モバイルアプリケーションでは機能しない場合があります。
モバイルアプリテストの種類：
上記のすべての技術的側面に対処するために、次のタイプのテストがモバイルアプリケーションで実行されます。
- ユーザビリティテスト –モバイルアプリが使いやすく、顧客に満足のいくユーザーエクスペリエンスを提供することを確認するため
- 互換性テスト –要件に応じて、さまざまなモバイルデバイス、ブラウザー、画面サイズ、およびOSバージョンでのアプリケーションのテスト。
- インターフェイステスト –アプリケーションのメニューオプション、ボタン、ブックマーク、履歴、設定、およびナビゲーションフローのテスト。
- サービステスト –アプリケーションのサービスをオンラインおよびオフラインでテストします。
- 低レベルのリソーステスト ：メモリ使用量のテスト、一時ファイルの自動削除、低レベルのリソーステストとして知られるローカルデータベースの増大する問題。
- 性能試験 –接続を2G、3GからWIFIに変更し、ドキュメントを共有し、バッテリー消費量などを使用して、アプリケーションのパフォーマンスをテストします。
- 運用テスト –バッテリーがダウンした場合のバックアップとリカバリ計画のテスト、またはストアからのアプリケーションのアップグレード中のデータ損失。
- インストールテスト - デバイスにアプリケーションをインストール/アンインストールすることによるアプリケーションの検証。
- セキュリティテスト –アプリケーションをテストして、情報システムがデータを保護しているかどうかを検証します。
モバイルアプリケーションのテスト戦略
テスト戦略では、すべての品質とパフォーマンスのガイドラインが満たされていることを確認する必要があります。この領域のいくつかのポインタ：
1）デバイスの選択 - 市場を分析し、広く使用されているデバイスを選択します。 （この決定は主にクライアントに依存します。クライアントまたはアプリビルダーは、特定のデバイスの人気要因と、テストに使用する携帯電話を決定するためのアプリケーションのマーケティングニーズを考慮します。）
2）エミュレーター– これらの使用は、 アプリの迅速かつ効率的なチェックを可能にするため、開発の初期段階。エミュレータは、ソフトウェア自体を変更することなく、ある環境から別の環境にソフトウェアを実行するシステムです。機能を複製し、実際のシステムで動作します。
モバイルエミュレータの種類
- デバイスエミュレータ-デバイスメーカーが提供
- BrowserEmulator-モバイルブラウザ環境をシミュレートします。
- オペレーティングシステムエミュレーター-AppleはiPhone用のエミュレーター、MicrosoftはWindows電話用、GoogleAndroid電話用のエミュレーターを提供しています
推奨ツール
#1) Kobiton
Kobitonは、手頃な価格で柔軟性の高いクラウドベースのモバイルエクスペリエンスプラットフォームであり、実際のデバイスを使用して、AndroidとiOSの両方でネイティブアプリ、ウェブアプリ、ハイブリッドアプリのテストと配信を高速化します。彼らの新しいスクリプトレステスト自動化は、コーディングの専門知識がないチームがオープンスタンダードのAppiumスクリプトを簡単に生成するのに役立ちます。
Windows用の無料のシェルスクリプトエディタ
いくつかの無料で使いやすいモバイルデバイスエミュレータのリスト
私。 携帯電話エミュレータ – iPhone、Blackberry、HTC、Samsungなどの携帯電話のテストに使用されます。
ii。 MobiReady –これにより、Webアプリをテストできるだけでなく、コードを確認することもできます。
iii。 Responsivepx – Webページの応答、外観、およびWebサイトの機能をチェックします。
iv。 Screenfly –これはカスタマイズ可能なツールであり、さまざまなカテゴリでWebサイトをテストするために使用されます。
3） モバイルアプリの十分なレベルの開発が完了したら、次のテストに進むことができます。 物理デバイス より現実的なシナリオベースのテスト用。
4）クラウドコンピューティングベースのテストを検討します。 クラウドコンピューティング は基本的に、アプリケーションをテスト、更新、および管理できるインターネット経由で複数のシステムまたはネットワーク上でデバイスを実行しています。テストの目的で、シミュレーター上にWebベースのモバイル環境を作成してモバイルアプリにアクセスします。
長所：
- バックアップとリカバリ-クラウドコンピューティングは、リモートロケーションからデータを自動的にバックアップし、データのリカバリと復元を簡単にします。また、ストレージ容量は無制限です。
- クラウドには、さまざまなデバイスからどこからでもアクセスできます。
- クラウドコンピューティングは、費用対効果が高く、使いやすく、保守と更新が簡単です。
- 迅速かつ迅速な展開。
- Webベースのインターフェイス。
- 複数のデバイスで同じスクリプトを並行して実行できます。
短所
- 制御が少ない –アプリケーションはリモート環境またはサードパーティ環境で実行されるため、ユーザーは機能への制御とアクセスが制限されます。
- インターネット接続の問題 –セットアップはインターネット上にあります。ネットワークの問題は可用性と機能に影響します
- セキュリティとプライバシーの問題 –クラウドコンピューティングはインターネットコンピューティングであり、インターネット上で安全に完了しているものはないため、データハッキングの可能性は高くなります。
5） 自動化と手動テスト
- アプリケーションに新しい機能が含まれている場合は、手動でテストしてください。
- アプリケーションで1回または2回のテストが必要な場合は、手動でテストしてください。
- 回帰テストケースのスクリプトを自動化します。回帰テストを繰り返す場合は、自動テストが最適です。
- 手動で実行すると時間がかかる複雑なシナリオのスクリプトを自動化します。
モバイルアプリのテストには、次の2種類の自動化ツールを使用できます。
オブジェクトベースのモバイルテストツール –デバイス画面上の要素をオブジェクトにマッピングすることによる自動化。このアプローチは画面サイズに依存せず、主にAndroidデバイスで使用されます。
- 例：-Ranorex、jamoソリューション
画像ベースのモバイルテストツール –要素の画面座標に基づいて自動化スクリプトを作成します。
- 例：-Sikuli、Egg Plant、RoutineBot
6）ネットワーク 構成 モバイルテストの必要な部分でもあります。 2G、3G、4G、WIFIなどのさまざまなネットワークでアプリケーションを検証することが重要です。
モバイルアプリをテストするためのテストケース
機能ベースのテストケースに加えて、モバイルアプリケーションのテストには、次のシナリオをカバーする特別なテストケースが必要です。
- バッテリー使用量 –モバイルデバイスでアプリケーションを実行している間、バッテリー消費量を追跡することが重要です。
- アプリケーションの速度- さまざまなデバイス、さまざまなメモリパラメータ、さまざまなネットワークタイプなどでの応答時間。
- データ要件 –インストール用、およびデータプランが制限されているユーザーがダウンロードできるかどうかの確認用。
- メモリ要件 –繰り返しますが、ダウンロード、インストール、実行するには
- アプリケーションの機能 –ネットワーク障害などが原因でアプリケーションがクラッシュしていないことを確認します。
ダウンロードモバイルアプリケーションをテストするためのいくつかのサンプルテストケース：
=> モバイルアプリのサンプルテストケースをダウンロードする
モバイルアプリケーションのテストにおける典型的な活動と手続き
テストの範囲は、チェックする必要のある要件の数や、アプリに加えられた変更の範囲によって異なります。変更が少ない場合は、 正気 テストで十分です。大規模および/または複雑な変更の場合、 完全回帰 がおすすめ。
アプリケーションテストプロジェクトの例 ：ILL（International Learn Lab）は、管理者、発行者が共同でWebサイトを作成するのに役立つように設計されたアプリケーションです。インストラクターは、Webブラウザーを使用して、一連の機能から選択し、要件を満たすクラスを作成します。
モバイルテストプロセス：
ステップ1。を特定します テストの種類 ：ILLアプリケーションはブラウザに適用できるため、さまざまなモバイルデバイスを使用して、サポートされているすべてのブラウザでこのアプリケーションをテストする必要があります。私たちはする必要があります 使いやすさ、機能性 そして 互換性 さまざまなブラウザでのテスト 組み合わせ の ハンドブック そして オートメーション テストケース。
ステップ2。 手動および自動テスト： このプロジェクトで採用されている方法論は、2週間の反復でアジャイルです。 2週間ごとの開発チームはテストチーム用の新しいビルドをリリースし、テストチームはQA環境でテストケースを実行します。自動化チームは、一連の基本機能のスクリプトを作成し、新しいビルドがテストに十分安定しているかどうかを判断するのに役立つスクリプトを実行します。手動テストチームは、新しい機能をテストします。
JIRA 合格基準の作成に使用されます。テストケースの維持と欠陥のログ記録/再検証。反復が終わると、 反復 計画 どこで開発者会議が開催されました。チーム、製品所有者、ビジネスアナリスト、およびQAチームが話し合います 何がうまくいったか そして 何を改善する必要があるか 。
ステップ3。ベータテスト： QAチームによる回帰テストが完了すると、ビルドはUATに移行します。ユーザー受け入れテストはクライアントによって行われます。すべてのバグを再検証して、すべてのバグが修正され、承認されたすべてのブラウザーでアプリケーションが期待どおりに機能していることを確認します。
ステップ4。性能試験： パフォーマンステストチームは、JMeterスクリプトを使用し、アプリケーションの負荷を変えて、Webアプリのパフォーマンスをテストします。
java8インタビューの質問と回答
ステップ5。 ブラウザのテスト ： Webアプリは、さまざまなシミュレーションツールを使用するだけでなく、実際のモバイルデバイスを物理的に使用して、複数のブラウザーでテストされます。
ステップ＃6。打ち上げ計画： 4週間ごとに、テストはステージングに移行します。ステージングでは、これらのデバイスでエンドツーエンドのテストの最終ラウンドが実行され、製品の生産準備が整っていることを確認します。そして、それはライブになります！
******************************************
AndroidとiOSの両方のプラットフォームでモバイルアプリケーションをテストする方法
iOSとAndroidプラットフォームの両方でアプリをテストするテスターにとって、両方の違いを知ることは非常に重要です。 iOSとAndroidには、ルックアンドフィール、アプリビュー、エンコード標準、パフォーマンスなどに多くの違いがあります。
AndroidとiOSのテストの基本的な違い
あなたはすべてのチュートリアルを終えたかもしれません、私はここにいくつかの大きな違いを入れました、そしてそれはあなたのテストの一部としてあなたを助けるでしょう：
＃1） 市場には多くのAndroidデバイスがあり、それらはすべて異なる画面解像度とサイズで提供されているため、これは大きな違いの1つです。
例えば 、 Nexus 6と比較すると、SamsungS2のサイズが小さすぎます。いずれかのデバイスでアプリのレイアウトとデザインが歪む可能性が高くなります。 iOSでは、市場で入手可能なデバイスは数えられるだけであり、それらの多くの電話のうち、解像度が類似しているため、確率は低くなります。
例えば、 iPhone 6以降が登場する前は、すべての古いバージョンは同じサイズしかありませんでした。
＃二） 上記の点を主張する例は、Androidでは開発者が1x、2x、3x、4x、5xの画像を使用してすべてのデバイスの画像解像度をサポートする必要があるのに対し、iOSは1x、2x、3xのみを使用することです。ただし、画像やその他のUI要素がすべてのデバイスで正しく表示されることを確認するのはテスターの責任になります。
下の図を参照して、画像の解像度の概念を理解できます。
＃3） 市場にはAndroidデバイスが殺到しているため、パフォーマンスが安定した状態を維持するようにコードを記述する必要があります。そのため、ローエンドデバイスではアプリの動作が遅くなる可能性があります。
＃4） Androidのもう1つの問題は、ソフトウェアのアップグレードがすべてのデバイスで一度に利用できるわけではないことです。デバイスメーカーは、デバイスをいつアップグレードするかを決定します。新しいOSと古いOSの両方ですべてをテストすることは非常に困難な作業になります。
また、開発者が両方のバージョンをサポートするようにコードを変更するのは面倒な作業になります。
例えば 、 Android 6.0が登場したとき、このOSがアプリレベルの権限のサポートを開始したため、大きな変更がありました。さらに明確にするために、ユーザーは アプリレベルでも権限（場所、連絡先）を変更します。
現在、テストチームは、Android 6.0以降ではアプリの起動時に権限画面を表示し、それ以前のバージョンでは権限画面を表示しないようにする責任があります。
＃5） テストの観点から、実稼働前のビルド（つまり、ベータ版）のテストは両方のプラットフォームで異なります。 Androidでは、ユーザーがベータユーザーリストに追加された場合、ベータユーザーとして追加されたのと同じメールIDでPlayストアにログインしている場合にのみ、Playストアで更新されたベータビルドを確認できます。
モバイルテストの主な要因
私は過去2年間、iOSとAndroidプラットフォームの両方でモバイルテストに取り組んできました。このチュートリアルで後述するすべての重要なポイントは、私の個人的な経験からのものであり、プロジェクトで発生した問題から派生したものもあります。
独自のテスト範囲を定義する
誰もが独自のテストスタイルを持っています。一部のテスターは自分の目から見たものに集中し、残りのテスターはモバイルアプリケーションの舞台裏で機能するすべてのものに情熱を注いでいます。
iOS / Androidテスターの場合は、少なくともAndroidまたはiOSのいくつかの一般的な制限/基本機能に精通することをお勧めします。これは、テストのスタイルに常に価値を付加するためです。例を挙げないと理解しにくいことはわかっています。
以下にいくつかの例を示します。
- 6.0.1バージョン未満のAndroidデバイスでは、アプリレベルでカメラやストレージなどの権限を変更することはできません。
- 10.0バージョン未満のiOSの場合、コールキットはありませんでした。簡単に言うと、通話キットは通話アプリによって使用され、ユーザーがWhatsApp、Skypeなどの通話アプリから電話を受けたときに全画面表示を表示します。一方、10.0未満のiOSバージョンでは、これらの通話が表示されます。通知バナーとして。
- あなたの多くは、あなたがあなたの財布にお金を追加したい場合にあなたのアプリがあなたを銀行の支払いページにリダイレクトしないというPaytmの問題に遭遇したかもしれません。上記は銀行またはPaytmサーバーの問題であると考えていますが、AndroidSystemWebViewが更新されていないだけです。プログラミングについての知識がほとんどないことは、常にあなたにとって、そしてあなたのチームと共有するのに役立ちます。
- 簡単に言うと、アプリがその中のWebページを開いているときはいつでも、AndroidSystemWebViewを更新する必要があります。
テストを制限しないでください
テストは、モバイルアプリの探索とバグのログ記録だけに限定されるべきではありません。 QAとして、サーバーにヒットしたすべての要求と、サーバーから取得した応答を認識している必要があります。
プロジェクトで使用されているものに応じて、ログを表示したり、ログのsumoロジックを検証したりするようにPuttyを構成します。これは、アプリケーションのエンドツーエンドのフローを知るのに役立つだけでなく、より多くのアイデアやシナリオを今すぐ入手できるため、より優れたテスターになります。
理由： 理由もなくこの世界には何も入ってこない。すべてのステートメントには、その背後に正当な理由があるはずです。ログの分析の背後にある理由は、ログに多くの例外が観察されますが、それらはUIに影響を与えないため、気付かないためです。
それで、私たちはそれを無視すべきですか？
いいえ、すべきではありません。 UIには影響しませんが、将来的な懸念事項になる可能性があります。この種の例外が忍び寄り続けると、アプリがクラッシュする可能性があります。最後の文でAppCrashについて述べたように、これによりQAはプロジェクトのcrashlyticsにアクセスできるようになります。
Crashlyticsは、クラッシュが時間とデバイスモデルとともにログに記録されるツールです。
ここでの質問は、テスターがアプリのクラッシュを確認した場合、なぜクラッシュリティックについて悩む必要があるのかということです。
これに対する答えは非常に興味深いものです。 UIに表示されない可能性があるクラッシュがいくつかありますが、それらはcrashlyticsにログオンしています。メモリ不足のクラッシュまたは致命的な例外が発生し、後でパフォーマンスに影響を与える可能性があります。
クロスプラットフォームテスト
クロスプラットフォームの相互作用テストは非常に重要です。
簡単な引用 例 、画像やビデオの送信をサポートするWhatsAppのようなチャットアプリケーションで作業していて、アプリケーションがiOSプラットフォームとAndroidプラットフォームの両方で構築されているとします（開発が同期している場合と同期していない場合があります）
AndroidとiOSの通信を必ずテストしてください。これは、iOSが「ObjectiveC」を使用しているのに対し、AndroidプログラミングはJavaベースであり、両方が異なるプラットフォームで構築されているため、アプリで追加の修正が必要になる場合があるためです。異なる言語プラットフォームからの文字列を認識する側。
モバイルアプリのサイズに注意してください
モバイルテスターのためのもう1つの重要なアドバイス–チェックを続けてください アプリのサイズ 各リリース後。
アプリのサイズが、エンドユーザーでさえサイズが大きいためにこのアプリをダウンロードしたくないレベルに達しないようにする必要があります。
アプリのアップグレードシナリオのテスト
モバイルテスターの場合、 アプリのアップグレードテスト はとても重要です。開発チームがバージョン番号の不一致を行った可能性があるため、アップグレード時にアプリがクラッシュしないようにしてください。
ユーザーが以前のバージョンで保存した設定をアプリをアップグレードするときに保持する必要があるため、データの保持も同様に重要です。
例えば 、 ユーザーが自分の銀行カードの詳細をPayTmなどのアプリに保存した可能性があります。
デバイスOSはアプリをサポートしていない可能性があります
興味深いですね？
ええ、多くのデバイスはあなたのアプリをサポートしていないかもしれません。多くの人は、ベンダーが米国の上に独自のラッパーを作成していることを知っている必要があります。アプリのSQLクエリがデバイスと互換性がない可能性があるため、例外がスローされ、起動すらできない可能性があります。その電話のアプリ。
ここでのポイントは–オフィスで使用するデバイスを除いて、自分のデバイスでアプリを使用するようにしてください。アプリに問題が発生する可能性は十分にあります。
アプリの権限テスト
リストの次は モバイルアプリの権限テスト 。ほぼ毎秒アプリがユーザーに電話の連絡先、カメラ、ギャラリー、場所などへのアクセスを要求します。これらの権限の適切な組み合わせをテストしないことで間違いを犯すテスターはほとんどいません。
リアルタイムで思い出せます 例 画像と音声ファイルを共有するすべての機能を備えたチャットアプリをテストしていたとき。ストレージのアクセス許可がNOに設定されました。
これで、ユーザーが(カメラ)オプションをクリックすると、ストレージのアクセス許可が(はい)に設定されるまで開かれませんでした。 Android Marshmallowには、ストレージ権限がNOに設定されている場合、そのアプリでカメラを使用できないという機能があったため、シナリオは無視されました。
範囲は、上記の段落で説明したものよりもさらに拡張されます。アプリが使用されていない権限を要求していないことを確認する必要があります。
ソフトウェア業界に精通しているエンドユーザーは、あまりにも多くの権限が要求されているアプリをダウンロードできない可能性があります。アプリから機能を削除した場合は、その機能の許可画面を必ず削除してください。
ソフトウェアテストにおける欠陥のライフサイクル
市場で同様の人気のあるアプリと比較する
この話の教訓 –疑問がある場合は、自分で結論を出さないでください。同じプラットフォーム上の他の同様のアプリと比較すると、テスト対象の機能が機能するかどうかという議論を強化できます。
Appleのビルド拒否基準の概要を入手する
最後に、あなたの大多数はあなたのビルドがAppleによって拒否された状況に出くわしたかもしれません。このトピックが読者の大部分に関心を持たないことは知っていますが、Appleの拒否ポリシーを知っておくのは常に良いことです。
テスターとして、技術的な側面に対応することは困難になりますが、それでも、テスターが対処できるいくつかの拒否基準があります。
詳細については、をクリックしてください ここに。
常に前足で
テスターであるため、開発チーム/マネージャーから法廷に物事を渡さないでください。テストに情熱を注いでいるなら 「常に前足で」 。コードがテストのためにバケットに届くかなり前に行われるアクティビティに参加するようにしてください。
最も重要なことは、クライアントとビジネスアナリストからのチケットに関するすべての最新の更新について、JIRA、QC、MTM、またはプロジェクトで使用されている方を引き続き確認することです。また、変更が必要な場合は、意見を共有する準備をしてください。これは、さまざまなドメインやプラットフォームで作業しているすべてのテスターに適用されます。
製品が自社のものであると感じない限り、既存の機能に対する新しい改善や変更について提案するべきではありません。
アプリを長時間（12〜24時間）バックグラウンドで保持する
奇妙に聞こえるかもしれませんが、舞台裏には私たち全員が理解できない多くの論理があります。
アプリを起動した後、たとえばバックグラウンド状態から約14時間後にクラッシュするのを見たので、これを共有しています。理由は、開発者がどのようにコーディングしたかによって異なります。
リアルタイムの例を共有しましょう：
私の場合、トークンの有効期限がその背後にある原因でした。チャットアプリの1つでは、12〜14時間後に起動すると、接続バナーに表示されなくなり、強制終了して再起動するまで接続されません。これらの種類のものを見つけるのは非常に難しく、ある意味で、モバイルテストをより困難で創造的にします。
アプリのパフォーマンステスト
モバイルの世界では、アプリのパフォーマンスは、アプリケーションが世界中で認識される程度に影響を与えます。テストチームとして、アプリの応答を確認すること、さらに重要なことに、多数のユーザーがアプリをすべて一緒に使用している場合にアプリがどのように機能するかを確認することが重要になります。
例：
PayTmについて話しましょう。
PayTmアプリの(お金を追加)オプションをクリックすると、ウォレットの残高が表示されます。舞台裏で何が起こっているかを考えると、それはPayTm UserIDを使用してサーバーに送信される要求であり、サーバーはアカウントの残高とともに応答を送り返します。
上記のケースは、1人のユーザーがサーバーにアクセスした場合のみです。 1000人のユーザーがサーバーにアクセスした場合でも、エンドユーザーの使いやすさが私たちの主な目標であるため、ユーザーが時間どおりに応答を返すようにする必要があります。
結論
このチュートリアルは、最初はモバイルテストが非常に簡単に思えることを繰り返して締めくくりますが、掘り下げていくと、開発したものが世界中の何千ものデバイスでスムーズに実行されることを保証するのは簡単ではないことがわかります。 。
ほとんどの場合、OSの最新バージョンと最新バージョンでのみサポートされているアプリが表示されます。ただし、シナリオを見逃さないようにすることはテスターの義務になります。これらは考慮に入れる必要のある他の多くのポイントですが、他のチュートリアルですでに繰り返されているポイントについては触れていません。
モバイルテストに関しては、バッテリー消費、割り込みテスト、さまざまなネットワーク（3G、Wi-Fi）でのテスト、ネットワークの切り替え中のテスト、モバイルアプリのモンキーテストなどのシナリオがすべて役立ちます。
実際のテスト環境に関しては、テスターの態度が非常に重要です。あなたが自分の仕事を愛するまで、そしてあなたがあなたの仕事を愛さない限り、あなたはチュートリアルで言及されていることをわざわざすることはありません。
私はこの分野に約6年間携わっており、タスクが単調になることがあることをよく知っていますが、それらの単調なタスクをいくらか面白くするために、他にも多くのことができます。
適切なテスト戦略を設計し、適切なモバイルシミュレーター、デバイス、およびモバイルテストツールを選択することで、100％のテストカバレッジを確保し、セキュリティ、使いやすさ、パフォーマンス、機能、および互換性ベースのテストをテストスイートに含めることができます。
これは、モバイルアプリケーションのテストガイドに関する読者からの複数の要求を満たすための取り組みです。
著者 ：このシリーズのコンパイルを手伝ってくれたSwapna、Hasnet、および他の多くのモバイルテストの専門家に感謝します！
次の記事では、 iOSアプリのテスト 。