テスト スタジオ

  • [アーティクル]

テスト スタジオを使用して、キャンバス アプリのエンド ツー エンドの UI テストを作成します。 新しい変更および更新が展開されるときに、アプリが期待どおりに動作することを継続的に検証することによって、アプリの品質を維持します。

概要

テストは、ソフトウェア開発ライフ サイクル (SDLC) の重要な部分です。 テストは、顧客に提供されるアプリの品質を確認するのに役立ちます。 リリース プロセスの問題または欠陥を早期に特定し、変更をリリースする前にアプリの信頼性を高めるために、これらの問題を修正する機会が提供されます。 アプリのサイズおよび使用によっては、新しい変更を手動でテストするだけで十分な場合もあります。 ただし、アプリの複雑さおよび使用量が増えると、手動テストに代わる、テスト戦略を考慮することが必要になる場合があります。 アプリがミッション クリティカルである場合は、小さな間違いでも大きな影響を与える可能性があります。

アプリの変更が増えると、テスト サイクルが長くなる場合があります。 最終的に、アプリの回帰テストが、新機能の開発にかかった時間より長くなる可能性があります。 急速な開発では、アプリのすべての機能を徹底的にテストすることは、ソフトウェア更新プログラムのリリースのボトルネックになります。 テスト サイクルおよび回帰テストにかかる時間を減らすための 1 つのオプションは、テストの自動化です。 テストを自動化すると、最小限の労力でアプリをテストし、テスト時間を減らし、およびリリース前にクリティカルな問題を特定するのに役立ちます。

Power Apps のテスト スタジオは、キャンバス アプリのテストを書き込み、整理、および自動化するための、わずかなコードを使用するソリューションです。 テスト スタジオでは、Power Apps の式を使用してテストを書き込んだり、またはレコーダーを使用してアプリの対話を保存し、式を自動的に生成したりすることができます。 書き込まれたテストをテスト スタジオで再生してアプリの機能を検証することができ、および Web ブラウザーでテストを実行して、アプリの展開プロセスに自動化されたテストを作成することもできます。

テスト スタジオ。

前提条件

Test Studio でアプリをテストするには、アプリの作成者または共同所有者である必要があります。

テスト スタジオの用語

次のセクションでは、テスト スタジオの重要な用語について説明します。

テスト ケース

テスト ケースは、テスト ステップと呼ばれる一連の指示またはアクションで構成されます。 テスト ケースを実行して、アプリまたはアプリ内の特定の機能が期待通りに動作することを検証します。 たとえば、経費アプリで、実際のコストが関連付けられている経費だけを送信できることを確認するとします。 テスト ケースは、この条件または要件が常に満たされていることを確認するのに役立ちます。

テスト スタジオで、テスト ステップは Power Apps の式言語を使用して書き込まれます。 テストの式は、アプリを作成するときに使用できる関数および自動化されたテストをサポートするための追加の式の両方で構成されます。

テスト スイート

テスト スイートは、テスト ケースを整理またはグループ化するために使用されます。 アプリのテスト ケースの数が増えるにつれて、特定の特色または機能でテスト ケースを整理することを考えるようになる場合があります。 たとえば、経費レポートの送信を検証するためのテスト ケースが含まれる 1 つのテスト スイートと、経費の承認のみに重点を置いた別のテスト スイートがあるとします。

テスト スイートに含まれるテスト ケースは、順番に実行されます。 アプリの状態は、スイート内のすべてのテスト ケースにわたって保持されます。 たとえば、アプリのスクリーン 5 で完了するテスト ケースがある場合、テスト スイート内の次のテスト ケースは、スクリーン 5 から実行を開始します。 これにより、複雑なテスト シナリオを 1 つのスイート内の複数のテスト ケースに分割でき、状態はすべてのテスト ケースにわたって共有されます。 2 番目のテスト ケースをアプリのスタート スクリーンで開始したい場合は、テスト ケースの最初の手順としてスタート スクリーンに移動できます。 テストの実行を計画する場合、テスト スイートのすべてのテスト ケースの開始時でアプリが再度読み込まれることはないということを覚えておくことは重要です。

テスト アサーション

すべてのテスト ケースには、予想される結果が必要です。 テストの実際の結果に対してテストの予想される結果を検証するには、テスト アサーションを書き込むことができます。 アサーションは、テストで true または false に評価される式です。 式が false を返す場合、テスト ケースは失敗します。

上記の経費アプリの例では、アサーションを書き込んで、経費レポートがゼロのコストと関連付けられた経費明細行品目で作成されているかどうかを検証することができます。

ベスト プラクティス

テスト スタジオを使用してキャンバス アプリをテストするときは、次のベスト プラクティスを考慮して、アプリの品質を向上するために最大限のメリットが取得できるようにします。

  1. 自動化する必要があるテスト ケースを決定します。

    すべてのテストを自動化することは困難であり、テストの自動化に完全に依存することはお勧めしません。 テストの自動化に加えて、手動テストを実行する必要があります。 自動化に最適なテストは次のとおりです。

    • 反復テスト。
    • ビジネスに大きな影響を与える機能のテスト。
    • 安定しており、大きな変更が行われていない機能。
    • 複数のデータ セットを必要とする機能。
    • かなりの時間と労力を要する手動テスト。

  2. テスト ケースを小さいままにします。

    1 つのテスト ケースでアプリ内のすべての機能のテストをサポートすることができるとしても、モノリシックなテスト ケースを作成することは避け、複数のテスト ケースに分割することをお勧めします。 各テスト ケースでは、アプリ内の特定の特色または機能をテストすることができます。 大規模なテスト ケースでアサーションが失敗すると、他の機能がテストされないままになる可能性があります。 テスト スイートに含まれる複数のテスト ケースを使用すると、前のテスト ケースが失敗したかどうかに関係なく、他の機能をテストできます。 この戦略では、テストの失敗を簡単に分離することもできます。

  3. 式を 1 つのテスト アクションに保ちます。

    テスト アクションには、複数の式を含めることができます。 1 つの手順の大規模な複数のアクション テストの式では、テストの失敗をデバッグおよび分離する機能に影響を与える可能性があります。 問題をより迅速に特定するために、複数のアクションのテストの手順を 1 つのアクションのより詳細なテストの手順に分割することを検討します。

  4. すべてのテスト ケースには、予想される結果が必要です。

    各テスト ケースには、1 つ以上の予想される結果が必要です。 テスト アサーションを使用して、実際の結果に対して、テストの予想される結果を検証する必要があります。 1 つのテスト ケースに対して、複数のアサーションを作成できます。

  5. テスト スイートを使用します。

    メンテナンスのため、類似するテスト ケースを一緒にグループ化または分類し、テストの目的および予想される結果を説明します。

既知の制限

Power Apps テスト スタジオでの完全な制御範囲を提供する作業が行われているとはいえ、現在、次の機能は使用できません。

  • コンポーネント。
  • Power Apps Component Framework で作成されたコード コンポーネント。
  • 入れ子になったギャラリー。
  • メディア コントロール。
  • アプリに対して、数式レベルのエラー管理の実験的な機能をオンにする必要があります。
  • Select および SetProperty 関数で一覧にないコントロールのサポート。
  • 個人タイプの列。
  • Test Studio は実験的な Git バージョン管理機能 と互換性がなく、この機能が有効になっている場合は正しく動作しません。

次の手順

参照

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。