次の方法で共有


Test Studio

Test Studio を使用して、キャンバス アプリのエンド ツー エンドの UI テストを構築します。 新しい変更や更新プログラムがデプロイされたときにアプリが期待どおりに動作することを継続的に検証することで、アプリの品質を維持します。

概要

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

アプリの変更が増加すると、テスト サイクルが長くなる可能性があります。 最終的に、アプリの回帰テストは、新機能の開発に費やされた時間よりも長くなる可能性があります。 ペースの速い開発では、アプリ内のすべての機能を徹底的にテストすることが、ソフトウェア更新プログラムのリリースのボトルネックになります。 テスト サイクルと回帰テストの間にかかる時間を短縮する 1 つのオプションは、テストの自動化です。 テスト自動化は、最小限の労力でアプリをテストし、テスト時間を短縮し、リリース前に重要な問題を特定するのに役立ちます。

Power Apps Test Studio は、キャンバス アプリのテストを記述、整理、自動化するためのローコード ソリューションです。 Test Studio では、Power Apps 式を使用してテストを記述したり、レコーダーを使用してアプリの対話を保存して式を自動的に生成したりできます。 Test Studio 内で書かれたテストを再生してアプリの機能を検証したり、Web ブラウザーでテストを実行したり、自動テストをアプリのデプロイ プロセスに組み込んだりすることもできます。

Test Studio。

[前提条件]

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

Test Studio の用語

次のセクションでは、Test Studio の主要な用語について説明します。

テスト事例

テスト ケースは、テスト ステップと呼ばれる一連の命令またはアクションで構成されます。 テスト ケースは、アプリまたはアプリ内の特定の機能が期待どおりに動作していることを検証するために実行されます。 たとえば、Expense アプリでは、関連する実際のコストを含む経費のみを送信できるようにする必要があります。 テスト ケースは、この条件または要件が常に満たされていることを確認するのに役立ちます。

Test Studio では、テスト手順は Power Apps 式言語を使用して記述されます。 テスト式は、アプリのビルド時に使用できる関数と、自動テストをサポートする追加の式の両方で構成できます。

テスト スイート

テスト スイートは、テスト ケースをまとめて整理またはグループ化するために使用されます。 アプリのテスト ケースの数が増えるにつれて、特定の機能でテスト ケースを整理することを検討できます。 たとえば、経費報告書の提出を検証するテスト ケースを含む 1 つのテスト スイートと、経費の承認のみに焦点を当てた別のテスト スイートがあるとします。

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

アサーションをテストする

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

上記の経費アプリの例では、経費明細項目にコストが関連付けられていない経費レポートが作成されているかどうかを検証するアサーションを記述できます。

ベスト プラクティス

Test Studio を使用してキャンバス アプリをテストする場合は、アプリの品質を向上させるための最大の利点を得るために、次のベスト プラクティスを検討してください。

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

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

    • 反復的なテスト。
    • ビジネスへの影響が大きい機能テスト。
    • 安定していて、大きな変更を受けなかった機能。
    • 複数のデータ セットを必要とする機能。
    • かなりの時間と労力を要する手動テスト。
  2. テスト ケースを小さくします。

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

  3. 式は 1 つのテスト アクションに保持します。

    テスト アクションには、複数の式を含めることができます。 1 つのステップに対する大規模なマルチアクション テスト式は、テストエラーをデバッグおよび分離する機能に影響を与える可能性があります。 複数のアクションを含むテスト ステップを 1 つのアクションのより多くのテスト ステップに分割して、問題をより迅速に特定することを検討してください。

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

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

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

    メンテナンスの場合は、同様のテスト ケースをまとめてグループ化または分類し、テストの目的と予想される結果を記述します。

既知の制限事項

Power Apps Test Studio で完全な制御範囲を提供するように取り組んでいますが、現在、次の機能は使用できません。

  • コンポーネント。
  • Power Apps コンポーネント フレームワークで記述されたコード コンポーネント。
  • 入れ子式のギャラリー。
  • メディア コントロール。
  • 数式レベルのエラー管理の試験的機能は、アプリで有効にする必要があります。
  • Select および SetProperty 関数にリストされていないコントロールのサポート。
  • 人物型の列。
  • Test Studio は試験的な Git バージョン管理機能と互換性がありません。この機能が有効になっている場合、正しく動作しません。

次のステップ

こちらも参照ください