アプリ開発の調査にかかる
時間を削減したい
内製化支援サービス
アプリを自分たちで
作成できるようになりたい
DX人材育成プログラム
プロに開発を依頼したい
アプリ開発導入支援サービス
SharePoint デザイン拡張サービス
X-SP Design
モダン化から運用管理までサポート
SharePoint 構築支援サービス
Power Appsでキャンバスアプリを作成した際、そのアプリが想定通り動作するかを確認するため、必ずテストを行うかと思います。
Power Apps キャンバスアプリにもテストを自動化するテストスタジオという機能がありますので、今回はその機能を紹介します。
テストスタジオを用いると、一連の処理の流れを保存しておくことができますので、 例えば機能やUIが追加された際に、今までの処理にエラーが発生していないか継続的に確認することが可能となります。
Power Appsのキャンバスアプリを構築している方に向けた内容となっています。
弊社はPower Platform（Power Apps・Power Automate）に関するアプリ開発や、 皆様が内製化を行う際の支援サービスを提供しておりますので、Power Platformに関する内容でお悩みがある場合は、 以下URLからぜひお問い合わせください。
前回はテストスタジオの基本知識について紹介しました。
今回は実際にテストスタジオを用いてテストを行いたいと思います。
前回のブログは、以下よりご確認ください。
目次
前提：アプリとテスト内容
まず初めに、今回作成したアプリとそのテスト内容について紹介します。
作成したアプリ
作成したアプリとしては、一覧画面とフォーム画面の2つです。
新規作成ボタンをクリックすると、FormMode.Newでフォーム画面が開きます。 またギャラリー内のレコードをクリックすると、FormMode.Viewでフォーム画面が開きます。
フォーム画面では、えんぴつアイコンをクリックすると、FormMode.Editのフォームになります。
テスト内容
フォームの機能として以下3パターンの機能を実装しています。
- 初期値の設定
- 表示モードの設定
- 表示の設定
フォームモードに応じてステータス列や申請者列を設定しています。
フォームモードに応じてえんぴつアイコンや登録ボタンの表示モードを設定しています。
「詳細があるか」という列（データ型：はい・いいえ）の値に応じて、「詳細」列の表示・非表示を設定しています。
全体概要については、以下を御覧ください。
テストの設計
続いて、テストの設計を行いました。
今回は以下のようにテストスイート・テストケースを構成しました。
各テストケースの確認観点は以下のとおりです。
- テストスイート1 初期値の確認
- テストケース1＿1 Newモード
- テストケース1＿2 Viewモード
- テストスイート2 表示モードの確認
- テストケース2＿1 Newモード
- テストケース2＿2 Viewモード
- テストケース2＿3 Editモード
- テストスイート3 表示・非表示の確認
- テストケース3＿1 新規作成の初期表示と切り替え
- テストケース3＿2 初期表示時：オンの場合
- テストケース3＿3 初期表示時：オフの場合
フォームモードがNewの場合の初期値を確認
フォームモードがViewの場合の初期値を確認
フォームモードがNewの場合の表示モードを確認
フォームモードがViewの場合の表示モードを確認
フォームモードがEditの場合の表示モードを確認
新規作成時の表示状態を確認 トグルを切り替えた時の表示状態を確認
選択したレコードのトグルに応じた表示状態となっているか確認
選択したレコードのトグルに応じた表示状態となっているか確認
テストを設計するにあたり、Docsにベストプラクティスが掲載されております。 以下URLからご確認ください。
ベストプラクティスまた、テストスタジオのみで用いることができるプロパティは、以下のように設計しました。
- OnTestCaseStart
- OnTestCaseComplete
- OnTestSuiteComplete
初期画面（ギャラリー画面）へ遷移する
テスト結果をバナーで表示
テストが失敗した場合は、エラーメッセージをコレクションに格納
テスト結果とエラーメッセージ一覧をメールにて通知
テストの実装
それでは、実際にテストを実装していきます！
テストスイート1 初期値の確認
各テストケースでの確認項目は以下です。
- テストスイート1 初期値の確認
- テストケース1_1 Newモード
- テストケース1_2 Viewモード
【確認項目】 ・ステータス列が下書きとなっているか？ ・申請者列がログインユーザーとなっているか？
【確認項目】 ・選択したレコードのステータスとなっているか？ ・選択したレコードの申請者となっているか？
作成したテストは以下です。
全体の流れについては、画像を見ていただければ理解いただけると思います。
ポイントとしては「Viewモード」ケースの順序1・2です。
順序1： Select(Gallery, 1)
順序2： Set(selectedRecord, Gal_申請レコード.Selected)
順序1にてギャラリーの1行目を選択しています。
また、順序2にて選択した値を変数に設定することで、フォーム画面にギャラリーの1行目を表示するように制御しています。
テストスイート2 表示モードの確認
各テストケースでの確認項目は以下です。
- テストスイート2 表示モードの確認
- テストケース2_1 Newモード
- テストケース2_2 Viewモード
- テストケース2_3 Editモード
【確認項目】 ・えんぴつアイコンはDisabledとなっているか？ ・登録ボタンはEditとなっているか？
【確認項目】 ・えんぴつアイコンはEditとなっているか？ ・登録ボタンはDisabledとなっているか？
【確認項目】 ・えんぴつアイコンはDisabledとなっているか？ ・登録ボタンはEditとなっているか？
作成したテストは以下です。
こちらは特に特筆すべき点はありません。
テストスイート3 表示・非表示の確認
各テストケースでの確認項目は以下です。
- テストスイート3 表示・非表示の確認
- テストケース3_1 新規作成の初期表示と切り替え
- テストケース3_2 初期表示時：オンの場合
- テストケース3_3 初期表示時：オフの場合
【確認項目】 ・新規作成ボタンクリック時は、非表示となっているか？ ・詳細があるかトグルをオンにすると、表示となるか？ ・詳細があるかトグルをオフにすると、非表示となるか？
【確認項目】 ・選択したレコードの詳細があるかトグルがオンの場合、表示となっているか？
【確認項目】 ・選択したレコードの詳細があるかトグルがオフの場合、非表示となっているか？
作成したテストは以下です。
ポイントとしては「初期表示時：オンの場合」ケースの順序1・2です。
順序1： Set(selectedRecordForTest, LookUp(テスト機能確認用リスト, 詳細があるか = true));
順序2： Set(selectedRecord, selectedRecordForTest);
順序1にてLookUp関数を用いて詳細があるか列がオン（=true）となっているレコードを取得しています。
順序2にて取得した値を変数に設定することで、フォーム画面に取得した値を表示するように制御しています。
※Select(Gallery, 1)とすると、選択したレコードの詳細があるか列がオンになっているかどうかわかりません。よって、LookUp関数で値を取得しています。
テストスタジオのみで用いることができるプロパティの設定
テストスタジオのみで用いることができるプロパティについては、以下のように実装しました。
各プロパティの詳細を以下に記載します。
OnTestCaseStart
初期画面（ギャラリー画面）へ遷移する
本プロパティでは、常に初期画面から各テストケースが開始されるように、Navigate関数でトップ画面（一覧画面）に遷移するよう処理を記載しています。
Navigate('Gallery Screen');OnTestCaseComplete
テスト結果をバナーで表示
テストが失敗した場合は、エラーメッセージをコレクションに格納
本プロパティでは、大きく2つの処理を実装しています。
1つ目は、各テストケースが終了した際にテスト結果をバナーに表示する処理です。
Notify(
// 通知メッセージ
//// テストケースの名称
TestCaseResult.TestCaseName & " : "
//// テストケースの結果（エラーの場合はメッセージを表示）
& If(TestCaseResult.Success,
"Passed", TestCaseResult.TestFailureMessage)
,
// 通知レベルの設定
If(TestCaseResult.Success
, NotificationType.Success
, NotificationType.Error)
);2つ目は、テストが失敗した際にはエラーメッセージをコレクションに格納する処理です。
※本コレクションは、テストスイートが完了した時に管理者へ送信するために使用します。
If(TestCaseResult.Success = false,
Collect(colErrorMessage,
{
TestCaseName: TestCaseResult.TestCaseName,
TestFailureMessage: TestCaseResult.TestFailureMessage
}
)
);OnTestSuiteComplete
テスト結果とエラーメッセージ一覧をメールにて通知
本プロパティでは、テスト結果をメールにて通知しています。
OnTestCaseCompleteプロパティにて取得したエラーメッセージと、TestSuiteResultから取得できる各種情報を通知しています。
Office365Outlook.SendEmailV2(
// 宛先
"your_mail_address@...",
// 件名
$"テストが完了しました：{TestSuiteResult.TestSuiteName}",
// 送信内容
"<html><body>" &
Substitute(
$"テストスイート名：{TestSuiteResult.TestSuiteName}
開始時刻：{TestSuiteResult.StartTime}
終了時刻：{TestSuiteResult.EndTime}
成功したテストケース：{TestSuiteResult.TestsPassed}
失敗したテストケース：{TestSuiteResult.TestsFailed}
エラーメッセージ：
{JSON(colErrorMessage, JSONFormat.IndentFour)}",
Char(10),
"<br>"
) &
"</body></html>"
)失敗したテストケースと、通知される内容は以下です。
上記でテストの実装は完了です。
実際にテストを実行してみてください！
テストスタジオでテストを行う際のポイント
私が実際にテストスタジオを使って感じたポイントを以下にまとめています。
- ポイント1：まずは記録機能を使う
- ポイント2：テストスイートは分割しすぎない
- ポイント3：テストケースは同じ観点でまとめる
- ポイント4：Galley.Selectedは使わない
- Gallery.OnSelect
- 新規作成ボタン.OnSelect
- Form.Item
- ポイント5：テスト実行時には、アプリが公開される
- ポイント6：手動テスト vs 自動テスト
- テスト実行時、アプリが公開されてしまう
- テストスタジオは初期コストが大きい
- テストスタジオですべてのケースをテストできるわけではない
- 変数管理
- フォーム設定
テストスタジオには、「記録」という機能があります。 本機能を用いた状態でアプリを操作すると、操作履歴をステップとして記録することが可能です。
各ステップをすべて自分で記載するのは時間もかかりますので、テストケースを作成する場合は、まず記録機能を使って大枠を作成すると良いと思います。
今回はブログ用にあえてテストスイートを3つに分割していますが、複数のテストスイートを一括で実行することはできません。
あまり細かくテストスイートを分割すると、テストの実行回数が多くなりますので、テストスイートはある程度大きなまとまりで管理すると良いと思います。
1つのテストケースが途中で失敗した場合は、失敗したステップ以降のステップは省略され、次のテストケースから再開されます。 よって、基本的にはつのテストケース内でのチェック（Assert関数）は、同じ観点でまとめると良いと思います。
テストを行う際には、特定条件のレコードを選択し、フォームに表示したい場合があるかと思います。
（今回のブログでは、テストスイート3が該当します。）
しかし、SetProperty関数では、Galley.Selectedに特定の値を追加することができません。
よって、アプリの作り自体を少し工夫する必要があります。 具体的には、以下にてアプリを実装するイメージです。
Set(selectedRecord, ThisItem);
Set(selectedRecord, Blank());
selectedRecord
そしてテストを行う際には、selectedRecordにLookUp関数で取得した特定条件のレコードを設定します。
※テストスイート3のポイントで記載した内容です。
テストのために、アプリを改変するのか？と思うかもしれませんが、私はそもそもアプリ内でGallery.Selectedをあまり使わないことをおすすめしています。
※本題から外れるため詳細は省きますが、Gallery.Selectedはアプリ作成者が値の中身を制御できないため、予想していないレコードが選択されていることがあるためです。
こちらは結構重要だと思いますが、テストを実行する際には、アプリを公開する必要があります。
環境を複数作成し、アプリを本番用とテスト用などでそれぞれ管理している場合であれば問題ありませんが、 普段本番で利用しているアプリをテストスタジオを用いてテストする場合、 自動的にアプリが公開されてしまいますので、テスト中のアプリがユーザーに使用されることになります。
（「Test Studio によって保存されました」というメッセージと共に、アプリが自動公開されます。）
ご注意ください。
テストスタジオを用いると自動的にテストができるようになるため、「今後は手動テストが不要になるのでは？」と思った方もいらっしゃるかと思います。
ただ私としては、今後も手動テストはなくならないと思っています。
理由は以下のとおりです。
前述しましたが、テスト実行時にはアプリは自動公開されてしまいます。 アプリをテスト用と本番用で別々に管理していない場合は、そもそもテストスタジオは使うことは難しいです。
テストスタジオを使ってテストを行う際、はじめにテストスイートやテストケースの作成が必要となり、手動テストに比べて初期コストが大きくなります。
UIやセキュリティに関するテストはテストスタジオではテストすることは難しいです。
また、テストスタジオにも既知の制限があります。 既知の制限に該当する場合は、手動テストが必要となります。
既知の制限
上記の問題がありますので、自動＆手動を併用して今後もテストを行っていく形になるかと思います。
また両者の使い分けに関して、Docsに考え方が掲載されています。
自動化する必要があるテストケースを決定します
テストスタジオのメリットとしては、一度テストケースを作成すれば、継続的にテストを実行できる部分かと思いますので、 以下のような場合にご利用されると良いのではないでしょうか。
各種ボタンで変数の値を設定しているアプリを作成された際、 最初は正常に動作していたけど、機能追加したことが原因で従来とは異なる値になっていたことはありませんか？
テストスタジオを用いて変数の設定値を管理しておくと、機能追加時に変更箇所以外は従来と同じ挙動となっているか確認することが可能です。
フォームの各項目について、初期値や表示・非表示などの条件付けをしているケースもあるかと思います。 こちらも最初は正常に動作していたけど、機能追加したことが原因で従来とは異なる挙動になることがあります。
テストスタジオを用いてフォームの項目についてテストケースを作成しておくと、機能追加時に変更箇所以外は従来と同じ挙動になっているか確認することが可能です。
おわりに
本ブログでは、テストスタジオを用いたテストの実装方法について紹介しました。
アプリを作成した際には、そのアプリが正常に動作しているかテストすることはとても重要です。
テストスタジオを用いた自動テストと手動テストの両方を活用し、品質の高いテストを行っていただければと思います。
最後までお読みいただきまして、ありがとうございました！
弊社ではお客様の業務を効率化するご支援を数多く承っております。
普段の業務の中で、「〇〇をもっと効率化できないか」というような疑問がある場合には、お気軽にアーティサン株式会社までお問い合わせください。
【こちらも合わせて読みたい】
小刀稱知哉
小刀稱知哉さんのブログ一覧はこちら大分県出身（温泉大好き）、現在は東京都在住
1990年生まれ
30才でメーカーの技術営業からIT業界にジョブチェンジ!!!
趣味は読書
主にMicrosoftのローコード（SharePoint・Power Platform）に関するに関する営業活動や設計、開発などを担当しております！
（最近はCopilot Studioについても勉強中）
持ってる資格はPL-200/PL-300/PL-400/PL-600/MS-700/AZ-104/AZ-305/SC-200/SC-100
こんにちは。アーティサン株式会社の小刀稱（ことね）です。