パフォーマンステスト Digital.ai Continuous Testing

経歴

ソフトウェアテストの世界では、パフォーマンステストは、テスト対象によってチームや個人によって意味が異なります。例えば、JMeterやSoapUIなどのツールを用いた負荷テストやストレステストは、複数のユーザーが同時にアプリケーションを操作する際にアプリケーションのバックエンドサーバーを検証するパフォーマンステストと関連付けられることが多いです。

ただし、iOS または Android のモバイル Web およびネイティブ アプリケーションのパフォーマンス テストは、モバイル デバイス向けの適切なパフォーマンス テスト ソリューションを提供する市場ツールがほとんどないこともあって、多くの組織が検討していない分野です。

顧客向けアプリケーションを提供する組織は、ここ数年、モバイル向けの自動テストを優先してきました。しかし、アプリケーションの規模が拡大するにつれて、中断なく最適に動作するアプリケーションに対する顧客からの需要も高まっています。例えば、ユーザーがAppStoreからアプリケーションをダウンロードし、読み込み速度が遅い、クラッシュするなどの問題に遭遇したとします。その場合、ユーザーはニーズを満たす別のアプリケーションに切り替える可能性が高いでしょう。

従来の自動化スクリプトはアプリケーションの機能面に重点を置いているため、アプリケーションのパフォーマンスにおける他の重要な要素の検証が不十分です。例えば、ページ間の移動や新しいページへの遷移にかかる時間、CPU、メモリ、バッテリー使用量の急上昇、ユーザーフロー中に発生する不要なネットワーク呼び出しなどは検証されません。これらはユーザーが日々直面する課題であるにもかかわらず、組織はモバイルアプリケーションのこれらの領域のテストを重視していません。

どのように Digital.ai アプローチチャレンジ？

モバイルでのパフォーマンス テストの真の価値は、さまざまなデバイス モデルと OS バージョンにわたって多数のパフォーマンス テストを実行できるときに測定できます。

単一デバイスのパフォーマンステストは、ユーザーが実際に直面している状況を正確に反映しない可能性がありますが、傾向を使用し、さまざまなデバイスモデルと OS バージョンにわたって単一のトランザクションがどのように動作したかを理解することで、より正確な状況把握が可能になります。

しかし、そのようなデータを測定するためにモバイルでのパフォーマンス テストをどのように拡張すればよいのでしょうか?

Digital.ai 機能 Appium スクリプト内で実装できるコマンドを導入します。つまり、機能自動化スクリプトとパフォーマンス テストを組み合わせることができます。

アプリケーションのログイン機能をテストするシナリオを簡略化したFunctional Appiumスクリプトを見ると、テストが簡単であることがわかります。まず、ユーザー名とパスワードのフィールドに入力し、「ログイン」ボタンをクリックして次のページに進みます。

この機能 Appium スクリプトにパフォーマンス テストを実装すると、次のようになります。

スクリプトがログイン ボタンをクリックする前にパフォーマンス トランザクションを開始し、次のページに移動するとすぐにパフォーマンス トランザクションを終了します。

自動化スクリプトからテキストを入力すると、ユーザーが資格情報を入力するのに実際にかかる時間が正確に反映されない可能性があるため、ユーザー名とパスワード フィールドに入力するためのパフォーマンス トランザクションをキャプチャすることはそれほど重要ではありません。

ログイン ページから次のページに移動するのにかかる時間や、ログイン ボタンをクリックしたときに CPU、メモリ、バッテリーの消費に急上昇があったかどうかを測定できます。

また、異なるネットワーク条件をシミュレートして、異なるネットワーク条件でエンドユーザーがアプリケーションをどのように体験するかを確認することもできます。その場合、ネットワーク プロファイルが最初のパラメーターとして渡されます。

driver.executeScript(“seetest:client.startPerformanceTransaction(\”4G-average\”)”);

収集したメトリックの種類と、パフォーマンス トランザクションがどのように行われたかを理解するためにそれらがどのように役立つかを見てみましょう。

パフォーマンス トランザクションの一部としてどのような種類のメトリックがキャプチャされますか?

パフォーマンス トランザクションごとに、次のメトリックを取得します。

• 期間： 取引全体の開始から終了までの期間
• スピードインデックス： 最終的なコンテンツがどれだけ早くペイントされたかの総合スコアを計算しました
• CPU： トランザクションで消費されたCPU、平均値、最大値を示すグラフ
• メモリ： トランザクションの消費メモリ、平均値、最大値を示すグラフ
• 電池： 消費されたバッテリー、トランザクションの平均値と最大値を示すグラフ
• ネットワーク： 適用されたネットワーク プロファイルに基づく、トランザクション中にアップロード/ダウンロードされた KB の合計
• ネットワーク呼び出し: トランザクション中に行われたすべてのネットワーク呼び出し

ここで確認しているのは、iPhone 13 Proで実行された単一のパフォーマンストランザクションです。パフォーマンストランザクションの一部としてキャプチャされたビデオを再生すると、ビデオに関連してCPU、メモリ、バッテリーの消費量を追跡できます。

このレポートは、傾向や潜在的なボトルネックを理解するのにどのように役立ちますか?

先ほどご覧いただいたレポートは、個々のパフォーマンストランザクションに焦点を当てています。しかし、同じパフォーマンストランザクションを複数のデバイスモデルとOSバージョンにわたって大規模に実行した場合、組み込みのレポート機能を活用して傾向を分析できるようになります。

以下は、特定のビルドと特定のトランザクションで実行したすべてのトランザクションを表示するようにフィルター処理されたレポートの例です (例: ネイティブ アプリケーションの検索フィールドからアイテムを検索し、小売アプリケーションのコンテキストで次のページを読み込むのにかかった時間を把握する)。

このレポートによると、iOS バージョン 13.2 の Speed Index は他の iOS バージョンと比べて大幅に高かったようです。

同様に、CPU、メモリ、バッテリーなどの他のメトリックの傾向も確認できます。

このレベルの情報により、QA テスターと開発者は、特定のデバイス モデルと OS バージョンを調査して潜在的なボトルネックを見つけ、テスト対象のモバイル アプリケーションの改善領域を特定できます。

デバイスやネットワークによってパフォーマンスに差が生じる可能性があることにご注意ください。デバイス間で最大30%の差が見られることはよくありますが、これは必ずしも深刻なパフォーマンスの問題を示すものではありません。しかし、パフォーマンスの問題によって、ベースライン測定値の10～100倍の差が生じることもあります。

既存の機能自動化スクリプトにパフォーマンス テストを実装する必要がありますか?

既存の機能スクリプトにパフォーマンス テストを実装するか、パフォーマンス テスト用の新しいスタンドアロン スクリプトを作成するかは、現在の自動化フレームワークの柔軟性と複雑さによって決まります。

先ほど示した例では、コードが過度に単純化されています。しかし、既存の自動化フレームワークのコンテキストで同じアプローチを考えてみましょう。クリックやキーの送信といった操作を実行するメソッドを呼び出す場合、より多くの依存関係やレイヤーが関係する可能性があります。

例を見てみましょう：

既存の自動化フレームワークにロジックを追加すると、自動化スクリプトの実行に必要な全体的な時間が長くなり、パフォーマンス テストに悪影響を与え、貴重なメトリックが提供されなくなる可能性があります。

既存の自動化フレームワークの複雑さによりパフォーマンス テストが妨げられる場合は、パフォーマンス メトリックをキャプチャするための専用の自動化スクリプトを別途作成することをお勧めします。

これにより、コード ロジックをある程度簡素化でき、パフォーマンス テストの適切なメトリックを正確に取得できるようになります。

取得したデータが測定可能であることを確認するには、どのような種類のベンチマーク数値を設定すればよいですか?

パフォーマンスを測定する際に適用できる普遍的または標準化された指標は存在しません。各組織とそのチームが独自のアプリケーションのユーザーエクスペリエンスを定義するためです。さらに、アプリケーションの複雑さに応じて、ベンチマークの数値はページごと、またはアプリケーションごとに異なる場合があります。

使用できるメトリックの例としては、TTI (time-to-interactivity) があります。これは、ユーザーがアプリケーションを起動してから使用可能になるまでにかかる時間を測定します。

これについては研究が行われており、HCI (ヒューマン コンピュータ インタラクション) 研究に基づくいくつかの役立つ経験則が示されています。

• 500 ミリ秒を超える遅延は「認知」イベントとなり、ユーザーは時間が経過したことを認識します。
• 3秒を超える遅延は「反映」イベントとなり、ユーザーは時間が経過したという事実を振り返る時間を持つことになります。ユーザーは気を散らされたり、他のことに取り組んだりする可能性があります。

ただし、主要パフォーマンス指標と見なされる他の指標も存在します。たとえば、次のようなものがあります。

• 最速応答時間
• 平均応答時間
• リクエストの最大数

サーバーの応答時間が遅いと、ユーザーエクスペリエンスに悪影響を与える可能性があります。Google PageSpeed Insightsでは、サーバーの応答時間を200ミリ秒未満にすることを推奨しています。300～500ミリ秒の範囲が標準とされ、500ミリ秒を超えると許容範囲を下回ります。

これらの指標には万能の答えはなく、ベースラインの決定はケースごとに異なる可能性があることに留意してください。したがって、テスト対象のアプリケーションのコンテキストにおいて何が許容範囲であるかを理解することが重要です。これには、アプリケーション開発者と協力し、特定のユーザーフロー中に行われるネットワーク呼び出しの数、特定のアプリケーションコンポーネントとのやり取り時にバックエンドで発生する負荷の高い操作、その他の関連要因など、アプリケーションのバックエンドに関する洞察を得ることが含まれる場合があります。

いくつかのパフォーマンス テストを実行して、それをベースラインとして使用すると便利です。

利用可能なすべてのデバイスの組み合わせでパフォーマンス テストを実行する必要がありますか?

パフォーマンステストの対象となるデバイスを決定する際には、最も収益性の高いデバイスを検討することが重要です。そのためには、テスト対象のアプリケーションで最も頻繁に使用されるユーザーベースとデバイスの種類を明確に理解する必要があります。

そこから、一貫してテストを行う上位5～10台のデバイスを選択することをお勧めします（正確な数はプロジェクトの規模やユーザーベースによって異なります）。このアプローチにより、テスト対象デバイスのベースラインを確立し、より正確なパフォーマンス測定が可能になります。

製品概要

パフォーマンステストは、ソフトウェア、アプリケーション、システムが想定される負荷とトラフィックを処理できることを確認するために不可欠です。パフォーマンステストは、導入前にパフォーマンスのボトルネックや潜在的な障害を特定し、対処することで、エンドユーザーにシームレスなエクスペリエンスを提供することを可能にします。

従来の自動化スクリプトとは対照的に、パフォーマンス テストは、ユーザーがページ間を移動するのにかかる時間を測定し、CPU、メモリ、およびバッテリー消費の急増を特定し、不要なネットワーク呼び出しを正確に特定することを目的としています。

パフォーマンステストの価値は、開発プロセスの早い段階で問題を特定し、後々の修正にかかるコストを削減できることにあります。さらに、パフォーマンス指標のベースラインを確立し、それを監視・比較することで、システムの変更がパフォーマンスにどのような影響を与えるかについての洞察を得ることができます。パフォーマンステストは、開発から導入、そしてそれ以降のあらゆるソフトウェア開発サイクルに不可欠です。

 

モバイル向けパフォーマンステストを始める準備はできましたか？今すぐお問い合わせください。 https://digital.ai/why-digital-ai/contact/