モバイルパフォーマンステストとは？詳しく解説させていただきます
概要
ここでは、モバイルパフォーマンステストについて説明させていただきます。
モバイルパフォーマンステストは、モバイルアプリ開発の最終段階の重要な部分として機能します。
これは、アプリがさまざまなデバイスやさまざまなネットワークでスムーズに機能することを保証するため大きな責任を伴います。
モバイルパフォーマンステストの主な目的は、アプリがさまざまなデバイスやネットワークで適切に動作することを確認することです。
また、開発者が開発段階でアプリのバグや問題を特定するのにも役立ちます。
AndroidまたはiOSのネイティブアプリのパフォーマンスをテストする場合、適切なデバイスセットを選択することが成功の可能性を最大限に高めるために重要です。
OS、画面サイズ、画面密度、ハードウェアの違いはすべて、アプリの動作やユーザーエクスペリエンスに影響を与える可能性があります。
アプリの新しいアップデートに対応し出荷するには、開発中にアプリのパフォーマンスを効率的に分析して、問題がエンドユーザーに届く前に問題を特定する必要があります。
以上が簡単ではありますがモバイルパフォーマンステストに関する概要とさせていただきます。
さらに詳しくいくつかのポイントについて説明させていただきます。
パフォーマンステスト
モバイルパフォーマンステストを理解するためには、そもそもパフォーマンステストの重要性について理解しておく必要があります。
テクノロジーの進歩により、ユーザーは必要な情報に対してすぐにアクセスすることに慣れております。
情報を受け取るのが遅れると、フラストレーションが生じ様々なリスクを負うことになります。
これはWebにせよモバイルにせよ同様ですが、特にモバイルの場合にこの傾向が顕著です。
また、時間の経過とともに注意力が低下することや、サービスへの関心が低下することも明らかになっております。
これは多くのユーザーが経験があることですが、ページの速度が遅いことがわかった場合、速度の遅いWebサイトの読み込みが完了するのを待つのではなく、競合他社のWebサイトに移動という行動をとります。
詳細
サービスを提供する企業としては、このような事態を回避するために様々な点についてテストを実行する必要があります。一般的なパフォーマンステストにおいては、通常クライアント側とサーバー側の2つの領域に分けて検証が実施されます。
サーバー側のパフォーマンステストで最も一般的なアプローチの1つは、負荷テストです。
負荷テストでは、異なるユーザーから複数のリクエストが同時に送信された場合に、サーバーがそれに応じて負荷を処理できることを確認しています。
JMeter、K6、Gatlingなどのツールを使用して同時実行ユーザーの数をシミュレートすることで、サーバーがどのように応答するかを予測できます。
中でもJMeterは、最も有名なサービスの一つです。
JMeterはWebサイトのパフォーマンスをテストするために使用されるオープンソースソフトウェアです。
高負荷下でのシステムの負荷テスト、ベンチマーク、および一般的なパフォーマンステストに使用できます。
JMeterはJavaで記述されており、Windows、Mac OS、Linux、Solaris、および HP-UXで実行できます。
JMeterを使用して、Webアプリケーションの機能動作をテストすることやさまざまな負荷の下でサーバーの応答時間を測定することが可能です。
次に、クライアント側のパフォーマンステストについて説明させていただきます。
これらは1人のユーザーがWeb応答を即座に確認できる速度をテストすることです。
サーバーは同時負荷を処理できるかもしれませんが、さまざまなブラウザーがサーバーからのデータを処理する方法もパフォーマンスに影響を与えます。
たとえば、JavaScriptはWebサイトをインタラクティブにしますが、特に最適化されていない場合にWebサイトが遅くなる原因にもなります。
1人のユーザーのパフォーマンスエクスペリエンスは、複数のユーザーと同じくらい重要となるためあらゆるデバイスにおけるパフォーマンスをしっかりと検証する必要があります。
パフォーマンスメトリック
モバイルテストにとって重要な点の一つがパフォーマンスメトリックです。
今日のユーザーは、アプリのバッテリーの消耗率や、アプリの実行中にデバイスがどれだけ熱くなるかなどについて、より懸念しています。
限られたリソースと多くのモバイルアプリケーションでは、ユーザーはアプリケーションのアンインストールを躊躇せずに実行し、自身のモバイルを最適化しようとします。
これにより、パフォーマンス関連のシナリオテストが重要な仕事になり、深刻なケースではサービスの品質に関係なく、アプリケーションがアンインストールされたり利用されなくなるなどのリスクを負います。
パフォーマンスメトリックには様々な観点が存在しますが、いくつか紹介させていただきます。
一点目がアプリケーションが使用しているCPUエネルギーの量と、グラフに異常なスパイクがあるかどうかの確認です。これは、デバイスがフリーズするのを防ぐために行われます。
二点目がアプリケーションが消費するGPUエネルギーです。
GPUは、データとグラフィックスの処理に使用されます。それらは、携帯電話、ゲーム機、デスクトップ、ラップトップ、サーバーなどのさまざまなデバイスで見つけることができます.
GPUの主な機能は、画像とビデオ フレームのレンダリングを高速化することです。 GPUは、ニューラルネットワークのトレーニングなどのタスクのための機械学習アプリケーションでも使用されます。
アプリケーションがCPUとGPUの両方を高速で使用している場合、モバイルデバイスは実行中に過熱することになります。
三点目がアプリケーションの使用中にバッテリーが消耗する速度です。
バッテリーの消耗とCPUとGPUの使用率は相互に関連しています。CPUサイクルの消費量が多いほど、バッテリーの消耗が多くなります。
検証内容
次にモバイルパフォーマンスの検証について説明させていただきます。
モバイルパフォーマンスの検証とは、クライアント側でのアプリのパフォーマンスの測定と分析を指します。Androidでの CPU、メモリ、バッテリー、ストレージ I/Oのほか、FPS、スレッド、エンドユーザー応答時間、アプリの起動時間、クラッシュまたはANRなどをアプリがどのように使用するかを理解する必要があります。
開発者とテスターは通常、Android ProfilerやInstruments (Xcode) などのツールを使用してアプリをローカルでプロファイリングすることにより、このデータの一部にアクセスします。
これらのモバイルパフォーマンスKPIは、デバイス/OSまたはネットワーク接続を変更することにより (帯域幅と待機時間をシミュレートすることにより)、さまざまな環境で分析できます。
目標は、ユーザーが実際の状況でアプリを使用するときに直面する可能性のある潜在的な問題を早い段階で検出し、新しいバージョンがリリースされる前に修正するために行動することです。
自動化
これらの検証を実行するための最も有効な方法の一つが自動化です。
アプリの自動プロファイリングを実行することで、手動でプロファイリングを開始したり、アプリでテストを実行したり、プロファイリングを停止したりする必要がなくなります。
最も簡単な方法は、機能検証のために作成された自動機能テストを再利用することです。
これらのテストは、実際のデバイスまたはエミュレーターにインストールできるアプリのパッケージバージョンでUIレベルで実行され、実際のユーザージャーニーをシミュレートします。このテストの実行中にパフォーマンス データを取得できます。
ほとんどのモバイルチームはCIパイプラインで実行されている、ある種の自動化されたUIテストを既に持っています。
アプリがベータ版または市場に出たばかりの場合は、近い将来にそれらを追加することを検討している可能性があります。これは、アプリのリリースプロセスにモバイルパフォーマンスの検証を含める方法を検討するのに最適な時期です。
たとえば、eコマースアプリで典型的なユーザージャーニーを実行するテストで何が起こるかを示します。
ユーザーが製品を検索し、リストから製品を選択し、カートに追加し、カートに移動して完了するというフローがあります。この機能テストは、正しい製品がカートに追加されたこと、製品の数量が正しいこと、またはチェックアウトが適切に機能しているかどうかを確認するためにチェックする必要があります。
また、カートに追加ボタンをクリックするなどの単純なアクションの応答時間と、アクションが複数回実行された場合のメモリ使用量を検証します。
チームに自動化された機能テストがない場合は、小規模で価値のあるユースケースを自動化して、時間の経過に伴うパフォーマンスの測定を開始することが推奨されます。たとえば、アプリの起動時間を測定したり、ログインユーザーエクスペリエンスをテストしたりします。
Appium
これらの自動化の代表的なサービスの一つがAppiumです。
Appiumは、iOS モバイル、Android モバイル、およびWindowsデスクトッププラットフォーム上のネイティブ、
モバイルWeb、およびハイブリッドアプリケーションを自動化するためのオープンソースツールです。
ネイティブアプリは、iOS、Android、または Windows SDKを使用して作成されたアプリです。
モバイルWebアプリは、モバイルブラウザーを使用してアクセスするWebアプリです 。
これらにいずれにも対応し、Appium は、iOS およびChromeのSafari、またはAndroidの組み込みのブラウザーアプリもサポートします。
Apache Cordovaのようなプロジェクトでは、Webテクノロジーを使用してアプリを簡単に構築できます。
これらのアプリはネイティブラッパーにバンドルされ、ハイブリッドアプリを作成します。
Appiumはもちろんハイブリッドアプリもサポートしております。
原則
Appiumは、4つの原則によって概説されている哲学に従って、モバイル オートメーションのニーズを満たすように設計されています。
一点目がアプリを自動化するために、アプリを再コンパイルしたり変更したりする必要がないことです。
二点目がテストを作成して実行するために、特定の言語やフレームワークに縛られるべきではないということです。
三点目が自動化APIに関しては、モバイル自動化フレームワークで一からやり直すべきでないということです。
四点目がモバイルオートメーションフレームワークは、名前だけでなく、精神と実践においてもオープンソースであるべきということです。
コーポネント
Appiumのコーポネントや機能についても説明させていただきます。
一点目がクライアントサーバーアーキテクチャーです。
Appiumの最も重要なコーポネントの一つがREST APIを公開するWebサーバーです。
クライアントから接続を受信し、コマンドをリッスンし、それらのコマンドをモバイルデバイスで実行し、コマンドの実行結果を表すHTTP応答で応答します。
HTTPクライアントAPIを持つ任意の言語でテストコードを記述できますが、Appiumクライアントライブラリの1つを使用する方が簡単です。
テストを実行しているマシンとは別のマシンにサーバーを配置できます。テストコードを記述し、コマンドの受信と解釈をクラウドサービスに任せることができます。
セッション
クライアントは、各ライブラリに固有の方法でサーバーとのセッションを開始しますが、最終的にPOST /sessionは必要な機能オブジェクトであるJSONオブジェクトを使用してサーバーに要求を送信します。
この時点で、サーバーは自動化セッションを開始し、さらにコマンドを送信するために使用されるセッションIDで応答します。
機能
Appiumサーバーに送信されるキーと値のセットはサーバーにどのような種類の自動化セッションを開始したいかを伝えます。
自動化中にサーバーの動作を変更できるさまざまな機能もあります。
たとえば、AndroidやWindowsのセッションではなく、iOSのセッションが必要であることをAppiumに伝えるplatform Name機能を設定する場合があります。
iOSまたは、Safari自動化セッション中にJavaScriptを使用して新しいウィンドウを開くことができるようにするために、Safari Allow Popups機能を設定することもできます。
テスト環境
モバイルパフォーマンステストを実行するためにどういった環境を準備するかについても検討する必要があります。
エミュレータまたは実際のデバイスを使用してこれらの検証を実行する必要があるかという点については
ケースバイケースです。
パフォーマンス指標を比較またはベンチマークする重要性が高い場合は、できるだけ類似したテスト環境を用意する必要があります。特に、テストに使用するデバイスは同じである必要があります。
さまざまな環境の使用に伴うデータのノイズを最小限に抑え、各バージョンで測定されたパフォーマンスの違いを確認する必要があります。エミュレートされたデバイスのハードウェアとOSのバージョンを指定し、同じエミュレータをベンチマークに使用できるため、エミュレータが非常に役立ちます。
頻繁にベンチマークを実行する場合は、実際のデバイスを使用する代わりに費用対効果が高くなります。 一方、実際のユーザーエクスペリエンスを評価する場合は、現実世界の条件にできるだけ近づける必要があります。 これは、実際のハードウェアでテストすることを意味します。アプリのバージョン間での顕著なパフォーマンスの違いを探すだけでなく、アプリのパフォーマンスが特定のデバイスで許容できるものであることを確認する必要があります。これを行うには、デバイスごとにしきい値を定義します。
エミュレーターでのテスト
エミュレータ―でのテストについて説明させていただきます。
いくつか注意点がありますので、簡単に紹介させていただきます。
一点目がエミュレーターまたはシミュレーターは、携帯電話などのデバイスをまったく異なるハードウェア上のソフトウェアとしてエミュレートするコンピューター上で実行される点に注意する必要があります。
つまりコンピューターで実行されるエミュレーターでのユーザーエクスペリエンスと実際のパフォーマンス評価の測定は、乖離が発生するという点に気をつける必要があります。
二点目が動作です。
公式のAndroidエミュレーターは、特定のオペレーティングシステムで一連のデバイスをエミュレートしますが、実際のブランドには独自のAndroid実装があり、動作が異なる点に注意が必要です。
また、一部のアプリは、セキュリティ上の制限、デバッグ モード、アーキテクチャの非互換性など、さまざまな理由により、エミュレーターで動作しません。
三点目がサポートです。
ほとんどのエミュレーターは、一般的なソフトウェア スタックのみをサポートしています。多くのアプリで必要とされる Googleなどの一般的なサービスはサポートされていません。
アプリユーザーは、エミュレーターでアプリを実行するのではなく、実際のデバイスで実行します。正確な測定を行うために、ユーザーが操作するのと同じデバイスでアプリをテストする必要があります。
実際のデバイスでのテスト
実際のデバイスでテストを行った場合について説明させていただきます。
実際のデバイスでテストを行うと、アプリを成功させ、自信を持って新しいアップデートをリリースするために必要な結果が得られる可能性が高くなります。ただし、注意点もありますので説明させていただきます。
一点目が、市場によっては完全に最新の状態に保つために、多数の実際のデバイスでテストし、定期的に新しいデバイスを購入する必要がある場合がある点です。
リリースされた最新のデバイスを含め、多くのデバイスを購入すると、費用がかかる可能性があります。
二点目が、多くの異なるデバイスを使用するには時間がかかる点です。
それらを起動し、アプリを開き、実行し、デバイスを充電して充電し、電源コードを近くに置いて適切に保管し、アクセスできるようにすることはすべて、簡単ではなく、時間を浪費する可能性がある点に注意が必要です。
三点目が環境コストです。
テスト用にデバイスを借りることもできますが、それにはある程度の調整と時間が必要です。さらに、貸出中のデバイスを壊した場合、修理または交換の費用を支払わなければならない可能性が高くなります。
これらの問題の解決策は、クラウドデバイスラボを使用することです。現在、市場には多くのデバイスラボがあります。
ネットワーク関連のテスト
モバイルテストにおいて関連性の高いネットワーク関連のテストについても説明させていただきます。
テストエンジニアは、モバイルデバイスがデスクトップのように1つの場所に留まらず、高速ブロードバンドネットワークにも接続されていない環境で操作されるという点を念頭に置く必要があります。モバイルデバイスは多くの場合ネットワークで動作し、これらを通信するネットワークの強度は地理的なエリアと移動速度など様々な条件によって異なるため、テストを実施する際に注意が必要となります。
そのため、開発者やテストエンジニアが堅牢で信頼性の高いモバイルアプリケーションを実現するには、ネットワークに合わせて環境を調整することが非常に重要です。
このようなシナリオは、テストしているモバイルアプリケーションの種類に応じて優先順位が高くなります。
ゲーム、ソーシャルメディア、eコマースなどの重いアプリケーションの場合、移動中のユーザーの期待はすでに低くなりますが、サービスを提供する側としては期待を裏切ることにならないようにする必要があります。
コンテンツストリーミング、書き込みコンテンツ、またはGoogleドライブやOnedriveなどのクラウドベースのサービスを提供するアプリケーションでは、ユーザーは少なくとも部分的なコンテンツがデバイスに読み込まれ、高速で実務ができることを前提として利用します。
また、ストリーミングの場合、上記よりも品質が低くなることが一般的ではありますが、ネットワーク環境やそれらの調査の重要性がさらに高まるため、注意が必要となります。
位置情報
モバイルテストのジオロケーションおよびローカリゼーション関連のシナリオも重要です。
ジオロケーションは、携帯電話やコンピューターなどのオブジェクトの地理的な位置の識別です。
ジオロケーションは、マッピングとナビゲーション、時間ベースのメディア、広告とマーケティング、天気予報と疫学など、さまざまな分野で使用されています。
これらの地理位置情報サービスは、リアルタイムの地理情報を、それを受け入れることができるデバイスに提供できます。
この情報には、現在の位置 (たとえば、GPS 座標)、高度、移動速度および移動方向 (移動している場合)、向き (静止している場合) が含まれます。取得された位置情報データには、近くのワイヤレスアクセスポイントや携帯電話基地局に関する情報も含まれる場合があります。ジオロケーションとローカリゼーションにより、地理的な位置に基づいてユーザーにパーソナライズされたエクスペリエンスが提供されます。 これらには、近くのレストランの提案や、マップ内の距離メトリック、または距離を介した接続を作成するアプリの簡単なテキストなど、ユーザーが一般的に利用する情報が含まれるため、これらはモバイルアプリケーションもしくはモバイルテストと重要な関連性があります。
このように、地理位置情報機能を使用すると、ローカリゼーションも実装できます。
ローカリゼーションは、製品を特定の国または地域に適合させるプロセスです。
企業がより多くのオーディエンスにリーチし、顧客ベースを増やすことができるため、これはビジネスの重要な部分です。
海外市場で製品を販売したい企業にとってローカリゼーションは必要ですが、企業と参入しようとしている市場との間に文化的な違いがある場合、それは困難な場合があります。
主なローカリゼーション手法には、言語適応、技術適応、文化適応、デザイン適応の4つがあります。
アプリケーションが地域に応じてローカル言語で読み込まれるようにして、スムーズなユーザーエクスペリエンスを実現します。
しかし、ジオロケーションのシナリオとテストは、セキュリティと法的な問題の点で重要な役割を果たします。
現地の法律が破られていないことを確認し、その国でのみ許可されていることを示します。
位置情報テストの欠落は、法的にも財政的にも、そしてもちろん個人的にも、ユーザーやビジネスにとって危険な場合があります。
重要性
位置情報テストの重要性や必要な機能、あるいは具体例などについて少し掘り下げて説明させていただきます。
世界地図上の線は単なる境界線ではなく、多くの慎重になるべきルールが地域ごとに設定されている点についての理解がまず最も重要です。ルールは世界中で一貫していないため、Web開発者として、ルールを遵守し、クライアントが法的な問題に巻き込まれないようにする必要があります。
具体的には、ルールを遵守している間、アプリケーションが地理位置情報に完全に依存するシナリオが存在する可能性があります。したがって、ジオロケーションのテストが重要になり、それによってすべてのシナリオが適切に実行されることを確認する必要があります。
では、具体例を出しながら説明させていただきます。
たとえば、食品配達アプリケーションで数百マイルなど遠方の離れたレストランが表示されることはユーザーにとって煩わしい情報と言えるでしょう。
このような不便な情報を排除し、ユーザーが本当に必要な情報を適切に表示することで、企業価値を上げることが可能となります。
これらが位置情報テストの根幹をなす重要な役割の一つです。
そのために抑えておくべき機能についても紹介させていただきます。
一点目が位置データの正確な取得です。
ユーザーのデバイスの地理位置情報を取得して、Googleマップなどのアプリケーションで直接使用したり、Uberや食品配達アプリケーションなどの位置に応じて結果を取得したりできます。
二点目がコンテンツ配信法に基づく結果の表示です。いくつかの国では、特定のコンテンツを自国で表示することを制限しています。
それは日本では考えることができないような制約があります。
全てのルールを正確に判断することは難しいですが表示するコンテンツ、ビデオ、画像、または電子商取引上のアイテムなど、あらゆるデータの取り扱いについて該当国の国内法を遵守する必要がある点についての理解が必要です。
これらの位置情報テストは、これらの法律を遵守しているかどうかを確認しリスク排除に役立ちます。
三点目が広告のカスタマイズです。地理位置情報のテストは、地域に応じて広告を配信しているかどうかを判断するのにも役立ちます。
位置情報テストを実行する方法
地理位置情報のテストの重要性については説明させていただきましたが、それらを実行するための方法についても簡単に紹介させていただきます。
位置情報テストを実行する最も面倒で複雑な方法は、実際に複数の場所からアプリケーションを使用することです。
これは決して簡単な方法ではありませんが、様々なツールなどを利用し、協力を仰ぎ実行することが可能です。
例えば、GitHubを通じて世界中のさまざまな場所からアプリケーションをダウンロードし、テストできるテスターに連絡が可能ですが、この実行方法は時間もかかります。
utestやtestlioなどのクラウドテストプラットフォームを利用することも効率を高める手段の一つですが、これらの方法は機密情報や必要な情報などのリスクを負う必要があります。
また、VPNを使用して場所を変更するという方法も一つの手段です。これは比較的簡単であり
VPNをインストールして使用し、現在の場所を変更することで実施することができます。
VPNは「仮想プライベート ネットワーク」の頭字語です。 VPNを使用すると、インターネット経由で同じローカルエリアネットワーク上の別のコンピューターに安全に接続できます。VPNは、次のようなさまざまな理由で使用できます。
例えば、IPアドレスと場所を変更してオンラインで身元を隠すことや、他の国を介して接続して地域限定コンテンツにアクセスすることや、データを暗号化して傍受から保護することです。組織で安全なネットワークを作成したり、サーバーの場所を変更して現在の地域で禁止されているゲームをプレイしたりするなど、さまざまなドメインで徹底的に使用されています。
ただし、VPNはあらゆる環境で万能ではなくサードパーティアプリケーションがVPNの使用を認識してブロックすることがあります。
これによりテストに多少の支障をきたす可能性がある点については注意が必要となります。
上記以外でも位置情報テストを実行するためのツールがありますので、そちらを利用することも手段の一つです。
例えば、Browserstackは代表的なツールと言えます。
これは、あたかも世界中のさまざまな場所から操作しているかのように、アプリケーションやWebサイトをテストするジオロケーションテスト機能を提供するツールです。Browserstackには、ジオタグ付け(メディアが正しい場所にタグ付けされているかどうかのテスト)、ローカリゼーション テスト、ジオターゲティング、ジオフェンシングなどがあります。これらをジオロケーションテストと組み合わせて、アプリケーションを徹底的にテストできます。
また、Browserstackはシームレスな統合が可能でありユーザーが使用するツールとフレームワークを使用することができるため非常に便利です。
Visual Studioから開発コードをテストし、App Centerからベータアプリをテストします。
CI/CD パイプラインからのコミットごとに自動テストを実行し、JenkinsとSlackで直接テスト結果を取得します。バグを直接Jiraに報告し、クリック1つで再現することが
できます。
ポップアップ表示
関連するのがポップアップ表示です。
モバイルテストで関連するシナリオをポップアップ表示することは多くのシーンで利用されるサービスであり、
ポップアップはアプリケーションの魅力的な要素であることは間違いありません。
これらはアプリケーションの新機能や現在用意されているオファーをユーザーが確認するのに役立ちます。
その一方でユーザーにとってポップアップは非常に役立つだけでなく、非常に煩わしいこともあります。
ポップアップがさまざまなデバイスやさまざまな画面で完全にテストされていない場合、デバイスで異常な動作が示されます。
たとえば、Webサイトにアクセスしているときに、ポップアップのアイコンがビューポートから消えるなどの
ケースです。開発者は、ユーザーが領域外をクリックするとポップアップが消えるように設計していないなど
多くの例外が存在します。
テスト担当者として、関連するテストシナリオを常に優先する必要があります。ユーザーがそのような経験をして戻ってくることはなく、アプリケーションと対話することさえせずにアンインストールすることさえあります. これは悪いフィードバックにつながり、すべての開発時間を無駄にする可能性があります。
まとめ
いかがでしたでしょうか？
モバイルパフォーマンステストについて詳しく解説させていただきましたので、参考にしていただけましたら幸いです。