この記事では、Microsoft Dynamics 365 Commerce 実装プロジェクトの機能テスト、パフォーマンス テスト、パフォーマンスのトラブルシューティングに関連するプラクティスとツールの概要について説明します。
ユーザー受け入れテスト
ユーザー受け入れテスト (UAT) の主な目的は、特定のビジネス シナリオが期待どおりに動作するかを確認することです。 テストには、カスタマイズだけでなく、すぐに使用できる Microsoft の機能と非満足パス テストも含める必要があります。 運用環境に移動する前に正しく動作しないものは、すべてキャッチすることが目標です。
最良の結果を得るには、開発環境 (階層 1) ではなく、UAT 用の階層 2 から階層 5 の環境を使用します。
開発環境を使用すると、開発者が同じ環境を使用するときにエラーが発生する可能性があります。 たとえば、コミットされていないソースの変更やデバッガーのアタッチされたエラーが原因でエラーが発生する可能性があります。 Microsoft インターネット インフォメーション サービス (IIS) Express と IIS を切り替えると、エラーが発生する可能性もあります。 さらに、開発マシンで何が起こったかを正確に知る方法がないため、レベル 1 環境での Microsoft のサポートは限られたものとなります。
UAT の運用環境を使用できます (たとえば、稼働後の "ドライ ラン" として)。 ただし、何らかの理由でデータベースへのアクセスを必要とする場合は、配置サポート エンジニア (DSE) サービスの要求を通す必要があります。 したがって、この方法は効率的ではない場合があります。 さらに、運用環境は、計画された稼動日以前には、長期間使用することはできません。
正式にビルドされたデプロイ可能なパッケージをデプロイした後、UAT を実行します。 Microsoft Visual Studio で手動でビルドされたパッケージに対して UAT を実行しないでください。 その理由は、どのコード変更が手動でビルドされたパッケージに含まれているかを証明する手段が無いからです。 公式のビルド システムだけが、特定のビルド内にある正確な変更の保証と監査証跡を提供します。
Store Commerce アプリまたは Web 用 Store Commerce を使用する場合は、正しいユーザー ロールを使用していることを確認してください。 より低い特権を持つマネージャーとレジ担当者の両方としてサインインしてテストします。
パフォーマンス
チャネルの実績
場合によっては、チャネルのパフォーマンスが期待したほど良くない場合があります。 パフォーマンスの低下は、多くの場合、次の要因によって生じます。 このリストは、影響の高い順に並べられています。
- Commerce Scale Unit への追加のカスタム コール。 追加の呼び出しで製品を拡張すると、パフォーマンスが大幅に低下することがよくあります。 余分な処理が発生する可能性があるだけでなく、ネットワーク待機時間も考慮する必要があります。 コマース スケール ユニットの追加の呼び出しは避けてください。 多くの場合、拡張機能のプロパティを使用して、既存の Commerce Runtime (CRT) のハンドラーやトリガーの拡張によって、同じタスクを実行できます。
- 追加のチャネル データベース拡張機能。 カスタム SQL が効率的で、正しいインデックスを使用していることを確認してください。
- 同じカスタムまたは組み込みの CRT SQL クエリを複数回実行します。 この方法が高すぎる場合は、必要に応じて CRT 要求ハンドラーにキャッシュを適用できます。
詳細については、IT プロおよび開発者向け Commerce を参照してください。
テレメトリ データを使用してパフォーマンスの問題を見つける
パフォーマンスの問題 (特に低速な SQL クエリまたは SQL デッドロック) をトラブルシューティングする必要がある場合は、Microsoft Dynamics Lifecycle Services (LCS) の環境診断ページに貴重なテレメトリ データが表示されます。 このデータを使用して、コード、構成、または設計で潜在的なパフォーマンスの問題を見つけることができます。 詳細については、Lifecycle Services の監視および診断ツール を参照してください。 その情報により、いくつかのバッチ処理またはフォームの読み込みが遅い理由が明らかになります。
パフォーマンス テスト
通常、システムのパフォーマンスをテストするときは、多くの共有リソースが競合を作成するコンポーネントに焦点を当てます。 これらのリソースは、さまざまなプロジェクト、顧客、または要件ごとに異なる場合があります。
ボトルネックが発生する理由を次に示します。
- 明細書の転記、チャネル データ同期の計算変更、大規模な製品品揃えを含む倉庫管理の操作、および MRP (Material Requirements Planning) の実行などのリソース集中型の計算
- いくつかの Commerce Scale Unit で実行する、複数のターミナルまたは店舗に対する複雑なビジネス ロジック
- 統合パートナー システム (コマースまたはコマース スケール ユニットから統合)
- コマース スケール ユニットが頻繁に呼び出すリアルタイム トランザクション サービス
- 非標準または拡張された標準機能 (たとえば、カスタム WHS コードを使用する拡張明細書転記)
一般に、既定の POS 操作とリアルタイム以外の POS 操作は、独自の専用リソース (POS がインストールされているか実行されているコンピューター) があるため、ボトルネックになりません。 パフォーマンスの問題は、通常、コマース スケール ユニットに対するビジネス ロジックまたは "おしゃべり" 呼び出しに起因します。
この記事の前半の情報を使用して、いくつかの初期最適化に対処した後でパフォーマンス テストを完了するのが理想的です。 システムが 1 人のユーザーまたはプロセスに対して適切にパフォーマンスを発揮しない場合、同時実行ユーザーまたはプロセスに対して適切に動作しません。 詳細については、Finance ドキュメントで "PerfSdk" または "Trace parser" を検索します。
すべてのプロジェクトが異なるため、実行する必要がある正確なパフォーマンス テストに関する一般的な回答を提供することは困難です。 たとえば、トランザクションの販売ラインの数が少ない場合 (すべての店舗で 1 日あたり 100,000 未満)、明細書の転記用のカスタム拡張コードを追加しない場合、転記にパフォーマンス テストは必要ありません。 ただし、販売ラインの数が大幅に多い場合や、大規模なカスタム変更を追加する場合は、転記のパフォーマンス テストをお勧めします。
通常、すべての環境でハードウェア機能は異なります。 ただし、コードとデータが似ている場合は、通常、他の環境でパフォーマンスの問題を再現できます。 パフォーマンス テストには運用環境を使用しないでください。 開発環境、テスト環境、運用環境でも同じデータを使用します。 開発環境を使用して、修正プログラムの作業と検証を行うことができます。 パフォーマンスクリティカルなコード パスの多くはデータに依存するため、Contoso サンプル データベースで同じ問題が発生しない可能性があります。
パフォーマンスの修正が完了したら、テスト環境で修正プログラムを確認します。 公式に構築されたパッケージをテスト環境に展開し、問題が解決した場合は、パッケージをリリース パッケージとしてマークします。
パフォーマンスの問題が大きい場合は、その後に新しいパフォーマンス テストを行う必要があります。 多くの場合、大きな問題は、他のより小さな問題をマスクします。 最上位の問題を解決したら、パフォーマンスが顧客の期待を満たすまで、次の問題を見つけて対処できます。