アプリのテストおよびトラブルシューティング

  • 8 分

これで、パフォーマンスのボトルネックと、その軽減方法のいくつかを学習しました。このユニットでは、テスト手法について説明します。 これらの手法は、パフォーマンスのテストと一般的なデバッグの両方に適用される、ガイダンス、手法、および検出の組み合わせです。

タイマー コントロールを使用するメトリックの取得

データの取得またはアップロードのためのデータ接続の使用に関しては、具体的な数字が役立ちます。 Power Apps では、変数とタイマー コントロールを使用して、数式の実行にかかる時間をキャプチャできます。 次のコントロールを使用してこの操作を行う方法を、次のシナリオで示します。

  • ボタン

  • タイマー

  • テキスト ラベル

'Workout tracker' というデータ ソースがあり、タイマー コントロールは Timer1 と名付けられ、ボタン コントロールの OnSelect プロパティは次のとおりに設定されているとします。

Collect(colWorkoutTracker, Filter('Workout tracker', Status = "Active"))

  1. この設定を行う場合、まずボタン コントロールの OnSelect 式を次のとおりに変更します。

    Reset(Timer1);
UpdateContext({StartTimer: true});
Refresh('Workout tracker');
ClearCollect(colWorkoutTracker, Filter('Workout tracker', Status = "Active"));
UpdateContext({StartTimer: false})

    この式は、タイマーのリセットで開始されます。 次に、タイマーを開始/停止するために使用するコンテキスト変数を "true" に更新します。その後、コレクションを構築してからコンテキスト変数を "false" に設定します。

  2. 次に、タイマー コントロールのプロパティを更新する必要があります。開始 プロパティを StartTimer に設定します。

  3. ここで、テキスト ラベル コントロールを挿入し、時刻を表示します。

  4. ラベル コントロールの Text プロパティについては、式を Timer1.Value に設定します。

  5. ここで、アプリをプレビューし、ボタンを選択します。

アプリをプレビュー モードにして、ボタンを選択すると、コレクションの作成にかかった時間がミリ秒単位で表示されます。

注意

アプリがプレビュー モードでない場合、タイマー コントロールはカウントを開始しません。

この手法は、特定のクエリにかかる時間を正確に把握するのに適しています。 このデータを別のコレクションに記録してから、数値を平均して所要時間を判別できます。 データの送信時にもこの概念を適用できます。 ローカル コンピューターからだけでなく、ユーザーの環境のすべてのシナリオからも必ずテストするようにしてください。

ユーザーがアプリを使用する場所をテストする

これは手法というよりむしろアドバイスです。 ほとんどのアプリ ビルダーにとって、アプリを実行する最適な場所は、アプリを構築するために使用するローカル PC です。 そのコンピューターからのテストでは、通常、最良の結果が得られますが、ユーザーのエクスペリエンスと一致しない場合があります。 ユーザーがアプリを実行する方法をテストするのを忘れる場合が多くあります。 たとえば、携帯ネットワーク経由で実行するモバイル アプリを構築する場合、テストに同じものが含まれていることを確認します。 モバイル デバイスのより小さいフォーム ファクターと、さまざまなインターネット接続の待機時間の把握は、アプリの設計で考慮する必要があります。 ここでは、前のタイマー テストの方法が適しています。 PC、Wi-Fi 上の携帯電話、および携帯データ ネットワーク上の携帯電話で、アプリのクエリまたはアップロードのパフォーマンスを比較します。 3 つすべてのシナリオに問題がないか、あるいはより低速ネットワーク用にアプリを最適化する必要があるかを判断します。

テストに役立つラベルを使用する

アプリでより複雑なロジックとより多くのバックグラウンド変数を組み込んで、そのロジックを容易にする場合は、テスト ツールキットの一部として、ラベル コントロールを使用することを検討してください。 変数の値を表示する画面にラベルを追加するだけで、アプリで何かを行う、あるいは行わない理由を理解するのに大いに役立つ場合があります。 構築およびテスト フェーズでこれを使用できます。 アプリが有効な場合、これらのトラブルシューティング ツールを非表示および表示する他の機能を追加できます。

Power Apps Studio で作業を行っている場合は、ファイルと変数を選択し、すべての変数、その値、作成場所、アプリでの使用場所を確認することもできます。

構築プロセス時にラベルを使用する別の方法は、バージョン番号を手動で表示するようこそ画面にラベルを追加することです。 Power Apps では、エクスペリエンスを最適化するためにアプリをキャッシュします。 SharePoint フォームをカスタマイズする場合と同じように、繰り返し発行すると、キャッシュされたバージョンが表示される場合があるため、表示されているフォームのバージョンを把握しにくくなる可能性があります。 隅に v1 または v2 というラベルを追加すると、常にバージョンを確認できます。

プレビュー アプリと発行されたアプリ

Power Apps Studio のプレビュー機能を使用すれば、アプリを公開した時にどのように実行されるについて分析情報が得られます。 しかし、発行されたアプリによってプレイヤーで行われる内容と比較した場合、キャッシュやその他のローカル PC によって行われる内容により、何らかの不整合が生じていることに気付く場合があります。 ユーザーがアプリを使用する方法と一貫性のある方法で、必ず発行後のアプリをテストしてください。

アプリのネットワーク アクティビティの確認

これでアプリ内からのテストについて学習したので、実際のネットワーク呼び出しとパフォーマンスを確認する必要があります。 これを行うには、組み込みの Monitor 関数を使用します。 これにより、アプリで行われる個々のネットワーク呼び出しを表示し、各呼び出しに要した時間などの詳細を確認することができます。 パフォーマンスの観点から、これが重要になる場合があります。

Monitor にアクセスする場合、左側のツールバーの高度なツール アイコンか、またはコマンド バーのアプリ チェッカー アイコンを選択します どちらを選択する場合も、Monitor を開くというリンクが表示されます。

Monitor を開くを選択すると、別のブラウザー タブで Monitor セッションが開かれ、空白のイベント リストと「新しい監視セッションを開始しました。」というメッセージが表示されます。

Monitor が、ネットワーク パフォーマンスを含むすべてのアプリのアクションを追跡し、ログに記録するようになりました。 これを使用して、データ ソースに対して行われた呼び出し、所要時間、受信/送信情報を確認できます。

この機能の用途の一例としては、前の例で示したタイマー コントロールによって測定されたパフォーマンスの遅延が、アプリ、ネットワーク、あるいはデータ ソース内のものであるかどうかの判定があります。 アプリをプレビュー モードで実行し、ユーザーが行うであろう方法で開始します。 次の例では、ボタンとタイマー コントロールを用いる例を使用して、ソースからデータを取得し、コレクションの作成に必要な時間を確認しました。 戻される情報により、タイム スタンプ、カテゴリ、操作、結果、結果情報、ステータス、期間 (ミリ秒)、データ ソース、(アプリから) 選択したコントロールが提供される点に注意してください。

アプリのボタンを選択したことにより表示された Monitor のスクリーンショット。

このインスタンスでは、ほとんどの時間が、データ ソースでのデータのフィルター処理と応答の待機に費やされました。 これは、アプリを変更することで、呼び出しを高速化できないことを示しています。 代わりに、クエリの調整またはデータ ソースの高速化に重点を置く必要があります。

このモジュールでは完全にはカバーできませんが、Monitor によって、いくつかの優れた機能が実現されます。 詳細を確認するには、サマリー ユニット内のリンクを参照してください。 カバーされているすべての技術は、アプリのテストおよびトラブルシューティングに役立ちます。