テストのためのアーキテクチャ戦略

この Azure Well-Architected Framework のオペレーショナル エクセレンスチェックリストの推奨事項に適用されます。

ワークロードに変更を導入する場合は、意図したとおりに動作し、新しい問題が発生しないことを確認する必要があります。 テストは、これらの変更を評価する方法です。 これは、品質を維持し、ワークロードに対する信頼を築く上で不可欠なプラクティスです。

効果的なテストは、信頼性の高い高品質のワークロードを提供します。 これにより、欠陥が運用環境に到達するのを防ぎ、コストのかかるやり直しと遅延を削減し、開発ライフサイクル全体を通じてビジネス目標に合わせて作業を維持します。

この記事では、効果的なテストプラクティスを通じて高品質のワークロードを提供するのに役立つ戦略について説明します。 これは、パフォーマンス、信頼性、セキュリティなどの他の柱の特殊なテスト ガイダンスの基礎となるガイダンスとして機能します。

テストプラクティスに関する実装ガイダンスについては、コンパニオン記事「効果的なテストプラクティスを使用してAzureワークロードの信頼性を高める」を参照してください。

テスト戦略と計画を正式化する

テスト戦略とテスト計画は重要な成果物です。 テスト作業の明確なロードマップを提供し、全員が同じ品質目標に向けて取り組んでいることを確認します。

テスト戦略を定義する

テスト戦略は、全体的なテスト アプローチをガイドする概要のブループリントです。 テストの目的、範囲、方法論、ツール、役割、責任が定義されます。 これは、テストの優先順位、リソースの割り当て、およびリスク管理に関する情報に基づいた意思決定を行うのに役立ちます。 また、利害関係者とどのようにコミュニケーションを取り、結果を報告するかをキャプチャします。

明確に定義されたテスト戦略は、利害関係者からの合意を得て、すべてのチームメンバーが一貫した品質基準に従うようにします。 方向と構造を提供し、テストをビジネス目標に合わせ、長期的な品質を保護します。

テスト戦略は、通常、特定のワークロードのリリース間で一貫性を保っています。 ただし、そのワークロードの特定のニーズとビジネス目標を反映するように常にカスタマイズします。

プランを作成する

チームとテスト戦略に同意したら、ビジネス目標に合わせてユース ケースを使用してテスト計画で正式化します。

テスト計画は、特定のリリースのテスト実行をガイドする詳細なドキュメントです。 テストの範囲、特定のテスト ケース、欠陥レポート、タイムライン、リソースの割り当て、テスト アクティビティの入退出基準について概説します。

適切に構造化されたテスト計画により、テストが効率的になり、リリースの目標とタイムラインに合わせて調整されます。 これは、進行状況を追跡し、テスト全体で情報に基づいた意思決定を行う際の参照ポイントです。

例: eコマース チェックアウト システムの場合、テスト戦略では、支払いフローが常に優先されることを定義し、ロード テスト用の JMeter などのシステムのテスト ツールを指定します。 さまざまなテストの種類に対するチームの責任を明確にしています。

リリースのテスト計画では、Apple Pay サポートの追加に重点を置いています。 このリリースでは、Apple Pay のテスト対象を正確に定義し、リソース (2 人のエンジニアと 3 台の iOS デバイス) を割り当て、4 週間のスケジュールを設定し、明確なエントリ条件 (コードの完了と環境の構成) と終了条件 (すべてのテストが成功し、重大なバグがゼロ) を確立します。

早い段階でテストし、頻繁にテストし、何が重要かをテストする

ソフトウェア開発ライフサイクルの最も早い段階でテストを開始します。 重大な問題が遅れて見つかると、リワークが増え、リリースが遅くなります。 多くの場合、アーキテクトは設計段階でテスト要件を見落とし、全体的な品質に悪影響を及ぼします。

開発者は、品質保証の考え方を採用する必要があります。 設計時でもテストを検討してください。 これを使用して、要件を明確にし、潜在的な制限を特定します。 テストを開発プロセスの不可欠な部分にします。 コードと共にテストの記述と保守を行う所有権を取得します。

問題を早期に検出すると、迅速に対応できます。 たとえば、日常的なバグ修正よりも、ユーザー エクスペリエンスに影響を与える重要な設計変更に優先順位を付ける場合があります。 早期に行動することで、直前の驚きと遅延を減らすことができます。

テストは 1 回限りのイベントではありません。 継続的なテストの考え方の一環として、起動後もテストを続けます。 テスト スイートを定期的に確認、更新、拡張して新機能をカバーし、運用環境で検出されたバグに対処して長期的な品質を維持します。

トレードオフ。 早期および継続的なテストでは、運用コストが増加し、最初は開発が遅くなったり、チームの摩擦が発生したりする可能性があります。 バランスを取り、どのテストと変更が早い段階で不可欠で、どのテストや変更を後のフェーズに延期できるかを特定します。 これにより、品質を損なうことなく効率が確保されます。

セーフガードを使用して運用環境でテストする

強力なテストと検証のプラクティスでも、一部の問題は実際の運用トラフィックでのみ発生します。 シミュレートできない問題を見つけるには、ユーザーの露出を制限し、リスクを軽減するセーフガードを使用して、運用環境で制御されたテストを実行します。

すべての運用テストを計画、分離、監視します。 そうすると、他のすべてのユーザーを混乱させることなく、実際のユーザー フィードバックとパフォーマンス データが得られます。

ワークロードが終了条件を満たし、強力な品質を示した後にのみ、カナリア リリースなどの段階的な露出戦略を検討してください。 この方法では、少数の対象ユーザー グループに対する更新プログラムが最初にリリースされるため、プレリリース環境に表示されない可能性のある問題をすばやく明らかにするのに役立ちます。 このアプローチでは、テスト プロセスを高速化し、関連するコストを削減できる可能性があります。

運用環境のテストを継続的に監視 して、早期に問題を見つけます。 自動ロールバック メカニズムやリアルタイムアラートなど、ユーザーに悪影響を与えた場合にテストを停止する自動セーフガードを実装します。 これらの手法により、迅速な対応が保証され、中断が最小限に抑えられます。

リスク： 運用環境でテストする場合は、実際の顧客に直接影響するため、注意が必要です。 ビジネスへの潜在的な悪影響を最小限に抑えるために、常にセーフガードを実装し、露出を制限します。

テストカバレッジにレイヤードアプローチを適用する

多層テスト カバレッジ戦略を使用すると、迅速なフィードバック、以前の欠陥検出、迅速なリリースが提供されます。 テストをレイヤーで構造化すると、欠陥をすばやく分離してデバッグできるため、問題の特定と対処が容易になります。

テスト ピラミッドをガイドとして使用する

テスト ピラミッド モデルは、テスト自動化のためのこの階層化アプローチを示しています。 テストはさまざまなレイヤーに分散され、実行時間とメンテナンス コストを最小限に抑えながらカバレッジを最大化します。

• 基本レイヤー: 単体テストでは、個々のコンポーネントが分離されていることを確認します。 迅速に実行し、すぐにフィードバックを提供します。
• 中間層: 統合テストでは、コンポーネントとサービス間の相互作用が検証されます。 単体テストよりも実行速度が遅くなりますが、システム動作の範囲が広くなります。
• 最上位レイヤー: エンド ツー エンドのテストでは、システム全体のユーザー体験を検証し、実際のシナリオをシミュレートします。 これらのテストは最も遅く実行されますが、全体的な品質に対する信頼度は最も高くなります。

基本テストと中間層テストは、依存関係が最小限であるため、パイプラインに簡単に統合できます。 この統合により、テストが失敗したときに迅速なフィードバックが可能になり、ビルド プロセスがすぐに停止し、障害のあるコードがさらに進行するのを防ぐことができます。

テスト カバレッジが拡大すると、パイプラインの実行時間が大幅に増加する可能性があります。 並列および分散テスト実行戦略を使用して高速なフィードバック ループを維持し、カバレッジが増加してもパイプラインの効率を維持します。

トレードオフ。 テスト カバレッジとパイプラインの効率にはトレードオフがあります。 テスト スイートを大きくするとカバレッジが向上しますが、実行時間とコストも増加します。 投資に対して意味のある収益率が提供されるとは限りません。

個別のアプリケーションとインフラストラクチャのテスト

アプリケーション コードのテストとインフラストラクチャ コードの間に明確なセグメント化を作成します。

検証内容と所有者によってテストを分離し、両方のレイヤーが連携していることを確認する統合テストを追加します。 アプリケーション コード テストでは、ワークロードの動作の検証に重点を置く必要があります。 インフラストラクチャ コード テストでは、インフラストラクチャのプロビジョニングと構成の検証に重点を置く必要があります。

アプリケーションとインフラストラクチャを一緒に実行するクロスレイヤー テストを追加します。 インフラストラクチャ テストを単独で実行すると、誤った信頼度が得られます。 IaC モジュールでは、すべてのリソースが正しくプロビジョニングされる可能性がありますが、アプリケーションが実際にそれらのリソースを使用できない場合でも、ワークロードは失敗します。 ソフトウェアを展開し、それに対してテストを実行することで、アプリケーションの動作を観察して、インフラストラクチャを検証します。 正常性エンドポイントに対する単純なスモーク テストでは、そのギャップが速くキャッチされます。

さまざまな種類のテストを組み込む

ワークロード全体でさまざまなテスト方法を使用します。 単体テストを完了しても、テストが完了したというわけではありません。 ワークロードのすべての側面には、個別のアプローチが必要です。 複数のテストの種類により、全体的な品質が向上し、システムが意図したとおりに機能する信頼性が高まります。

ジョブに適したツールを使用します。 さまざまな種類のテストを実施するために必要なツールを特定します。 ツールがない場合は、ツールを購入します。 リスクが発生する可能性があるため、ビルドしないでください。 ライセンス コストや、ツールがワークロード要件と直接統合されるかどうかなど、ツールとその機能を調査します。 各ツールでチームの専門知識を評価し、概念実証を行って互換性と統合を検討します。 ワークロード チームがその専門知識を持っていない場合は、ツールで利用できるサポートとトレーニングを利用します。

ワークロードの成熟度とリスク プロファイルに基づいて、適切なテストの種類を選択します。 テスト ピラミッド レイヤーを使用した機能検証から始めて、パフォーマンス、セキュリティ、回復性などの非機能テストを追加します。 テストの種類の選択を、ワークロードの重要なシナリオとリスクに合わせます。

次の表は、テスト サイクル全体で異なるテストの種類を適用するタイミングを示しています。 それぞれが特定のリスクに対処します。 この表は、使用可能なすべてのテストの種類の完全な一覧ではありませんが、例示の例として機能します。

• さまざまなテストの種類を組み合わせて、複数の角度からワークロードを評価します。 ミックスを実行して、1 つのテストで見逃される問題をキャッチします。

• ビジネスへの影響とリスクに基づいてテストの種類に優先順位を付けます。 潜在的な影響と関連するリスクに基づいて、各機能または変更を評価します。 顧客向けのワークロードの場合は、エンド ツー エンドおよび UI テストを重視します。 API 主導のワークロードの場合は、統合とコントラクトのテストに重点を置く必要があります。 高可用性システムの場合は、回復性と混乱のテストに投資します。

トレードオフ。 リリース プロセスの開始時にセキュリティ テストに優先順位を付けます。 このアプローチは、脆弱性を防ぎ、デプロイの安全性を確保するのに役立ちます。 ただし、この優先順位により、運用環境に新機能を提供するペースが遅くなる可能性があります。

テスト資産をコード資産と同じくらい重要に扱う

テスト資産は、重要なビジネス ルール、エッジ ケース、過去の欠陥パターン、および貴重な組織の知識をキャプチャします。 テストの品質が低下すると、チームは実際の欠陥を見つけるのではなく、信頼性の低いテストのデバッグに時間を無駄にします。 この状況により、フラストレーションが生じ、開発者はテスト フレームワークに対する信頼を失います。

コード資産と同じ厳格なテスト資産を扱います。 テスト資産を完全に担当することで、テスト フレームワークの信頼性と全体的な品質の両方が向上します。

テストの構造とセキュリティ保護

アプリケーション コードと同じアーキテクチャ原則を使用してテスト コードを構成します。

• テストをコードと共に同じリポジトリに保持して、メンテナンスを効率化し、一貫性を高めます。

• 必須のコード レビュー、プル要求ポリシー、品質基準を維持するための検証パイプラインの構築など、同等のガバナンス制御を実装します。

• コードと共にテスト データのバージョンを設定します。 データ スキーマまたはビジネス ルールを変更する場合は、現在のワークロードの状態に合わせてテスト データを更新します。

• 独自のテストのベースライン検証を行 って、それらが期待どおりに動作することを確認します。 障害が発生した場合は、テストの欠陥ではなく、実際のアプリケーションの問題を示す必要があります。 テストが適切に失敗すること、およびワークロードが正常な場合にテストが常に合格することを確認してください。 信頼性の低いテストに迅速に対処し、テスト アサーションによって各テストの意図が強化されていることを確認します。

• テスト データの分離、共有状態の回避、自動セットアップと破棄プロセスの実装など、テストの独立性と信頼性を確保するプラクティスを設定します。

• 並列実行のテストを設計します。 並列テスト実行のメリットを得るには、結果に影響を与えずに任意の順序で実行できるように、テストを独立するように設計します。 独立したテストでは、状態が次のテスト実行に引き継がれないように、常に独自のデータと依存関係を設定して破棄する必要があります。

アプリケーションでテストのシーケンス処理が必要な場合は、順序付けされたテスト実行をサポートするテスト フレームワークを使用します。

• テスト コードにセキュリティで保護されたコーディングプラクティスを実装して、脆弱性を防ぎます。 テストは、多くの場合、運用データやシステムとやり取りするため、インポートされたライブラリや脆弱なテスト コードからリスクが発生する可能性があります。 運用コードと同じセキュリティ標準を使用してテストを処理します。

テスト資産を現在の使用パターンに合わせて維持する

パフォーマンス テスト資産には、ワークロードの予想される動作、許容できるパフォーマンスしきい値、現実的なトラフィック パターンに関する重要な知識が含まれています。

• テスト スイートを種類別に整理します。 ロード テスト、ストレス テスト、耐久テストは別々のスイートに保持します。 それらを混在させないでください。 種類ごとに、セットアップ要件、実行期間、成功条件が異なります。 編成されたスイートを使用すると、対象となるテストの実行、実行間での結果の比較、各スイートの個別の管理が容易になります。

• テスト データを定期的に更新します。 古いテスト データは、非現実的な結果につながります。 データ モデルが変化したり、データ量が増加したり、ユーザーの人口統計が変化したりするたびに、現在の運用データの特性を反映するようにテスト データを再生成します。

• ワークロードの進化に合わせてテスト シナリオを確認します。 シナリオに実際の使用状況が反映されるように定期的なレビューをスケジュールします。

• テスト データは実際の実稼働データのようになります。 運用データの特性を持つ合成データを使用します。 トランザクションの整合性、待機時間、ボリューム処理などのデータ管理の動作を強調するなど、特定のシナリオに対して運用データセットを予約 (適切に匿名化) します。

テストの保守と進化

テスト資産を維持することは、ワークロードの品質を維持するために不可欠です。 これらの資産には、多くの場合、組織の貴重な知識が含まれています。 定期的にメンテナンスしないと、すぐに古くなり、その有効性と高品質のリリースを提供する能力が損なわれます。

ワークロードが進化するにつれて、テスト資産はビジネス目標に合わせて並行して進化する必要があります。

• 小規模から始めて、回帰スイートを意図的に拡張します。 回帰テスト スイートには、最も価値のある安定したテストが含まれている必要があります。 運用インシデントが発生したとき、重大なバグを修正するとき、およびリスクの高い変更を導入するときにテストを追加します。

• 回帰スイートを自動化して 、人間の介入なしに一貫して実行されるようにします。 すべてのコミットで実行される高速スモーク テストと、夜間またはリリース前に実行されるより広範な回帰テストを作成します。

• テスト自動化スクリプトとテスト ケースの両方を同期します。 テスト ケースでは、意図、スコープ、予想される結果がキャプチャされます。 自動化スクリプトが対応するテスト ケースと異なる場合、検証対象を追跡するのは難しく、カバレッジとアカウンタビリティのギャップにつながります。

• ワークロードに新機能と拡張機能を導入するときに、テスト ケースの定期的な更新を事前に計画します。 テスト ケースを自動化する場合は、自動化を元のテスト ケースにリンクして、カバレッジをトレースできるようにします。

テストの技術的負債を管理する

過負荷になる前に、累積債務に対処するために定期的なテストメンテナンススプリントをスケジュールします。 不安定なテスト、重複カバレッジ、古いテスト、不適切なテスト設計はすべて、テスト負債に寄与します。

• 信頼性の低いテストの修正または削除に優先順位 を付けて、テスト スイートの整合性を維持します。 信頼性の高いテストの小さなセットは、不安定なテストの大規模なセットよりも価値があります。

• テストのスキップまたは遅延に関する戦略的な決定を行います。 ビジネス ロジックのない単純なゲッターやセッター、非常にまれなエッジ ケース、サードパーティ製ライブラリ、削除がスケジュールされたレガシ コードなど、単純なコードやリスクの低いコードのテストをスキップすることを検討してください。 これらの決定を文書化して、チームがコンテキストの変化に合わせて再検討できるようにします。

• テスト スイートを評価し、信頼性の高い一貫性のあるテストと外部の変更が発生しやすいテストを分離します。 頻繁な UI 更新の影響を受ける UI テストなど、コントロールの外部の要因によって頻繁に中断されるテストは、自動化の適した候補ではない可能性があります。 この分離は、自動化するテストと手動で保持するテストを決定するのに役立ちます。

トレードオフ。 脆弱なテストを削除すると、自動化の対象範囲が減ります。 頻繁に変化する UI 要素の手動テストを受け入れながら、安定したインターフェイスと重要なワークフローに自動化を集中することで、この削減のバランスを取ります。

すべてのテストが継続的なメンテナンスに値するわけではありません。 削除した機能のテスト、カバレッジが重複するテスト、値が提供されなくなったテストを廃止します。 チームが決定を明確にするために、テストを削除する理由を文書化します。

監視機能をテスト フレームワークに拡張する

テストでの可観測性には、2 つの重要な利点があります。 まず、テスト フレームワークが動作していることを確認します。 次に、ワークロードの品質と正常性を継続的に可視化します。

この可視性がないと、問題の診断にかなりの困難が生じ、システムをリアルタイムで監視する能力が制限され、自動化カバレッジの有効性に関する明確で実用的な分析情報が得られません。

テスト スイートは時間の経過と同時に悪化します。 テストは信頼性が低くなり、関連性が失われるか、ワークロードの変更に対応できなくなります。 可観測性を組み込むことで、テスト スイートの正常性を効果的に監視し、障害を迅速に特定して対処し、メンテナンスの優先順位と改善に関する情報に基づいた意思決定を行うことができます。

カバレッジ レポートを生成して、自動化のギャップを特定します。 テスト カバレッジが運用インシデントの可観測データと一致すると、チームは適切な検証が不足しているシナリオに関する分析情報を得ることができます。

フレームワーク内で業界標準のテスト カバレッジとレポート ツールを使用して、次の処理を行います。

• テストされたコード パスを明確に可視化する
• 一貫して失敗するテストを特定する
• テスト信頼性の長期的な傾向を分析する
• 障害の発生元を追跡して、対象を絞った改善を行う

リスク： ログに一貫性がなく、過度に詳細な場合は、値よりもノイズが多くなり、デバッグが困難になる可能性があります。 明確で実用的なメッセージとさまざまな詳細レベルで構造化されたログを実装して、チームを圧倒することなく、ログに意味のある洞察を提供できるようにします。

現実的な条件をシミュレートする

エンドユーザーの観点からワークフローを評価し、顧客のニーズと期待に真に対応していることを確認します。 ワークロードの明確な受け入れ基準を定義し、分離されたシステム動作だけでなく、実際のユーザー フローとエクスペリエンスを正確に反映するテストを設計します。

戦略的にカバレッジをスケーリングする

リスクと価値に基づいてテスト カバレッジをスケーリングします。 カスタマー エクスペリエンスに直接影響を与える価値の高いユーザー体験と重要なパスの対象範囲に優先順位を付けます。 ワークロードの複雑さが増すにつれて、ワークロードの品質と信頼性に最も高い信頼性を提供するシナリオを評価することで、テストの対象範囲を拡大します。

リスク： 1 人のユーザーフローにおいて、収益が減少し始めるポイントを超えて過剰に投資しないこと。 クリティカルパスに対して十分なカバレッジを実現したら、焦点を他の重要な領域に移します。 完璧を目指すのではなく、バランスの取れた範囲を目指します。

ビジネスの目標およびサービスレベル目標（SLO）と整合させる

テストをビジネス目標とサービス レベル目標 (SLO) の両方に合わせます。

ビジネス コミットメントとユーザーの期待を反映する測定可能な品質しきい値を設定します。 これらのしきい値に同意してください。それらは偏差を検出し、エラーをトラブルシューティングするための参照ポイントを提供します。 この方法では、主要なサービス品質しきい値が侵害されないようにすることで、ユーザー エクスペリエンスを保護します。

ベースライン メトリックを定期的に確認して更新し、現在の顧客のニーズと期待を引き続き満たしていることを確認します。

代表的なテスト データを使用する

テスト データは、実際のシナリオを可能な限り密接に表す必要があります。

合成データは、実稼働データ処理の複雑さを回避しながら、本物のユーザー シナリオをシミュレートできます。 たとえば、合成テストでは、代表的なデータ セットを生成して、計画されたスケーリング条件下でのワークロードのパフォーマンスを評価することで、実際のシナリオをレプリケートできます。

既定の選択肢として合成データを使用します。 データ移行スクリプトのテストなど、合成データが必要な複雑さをレプリケートできない特定のシナリオに合わせて運用データを予約します。

テストに運用データを使用する必要がある場合は、機密情報を保護するためにすべての情報を適切に匿名化してください。

運用環境をシミュレートする

運用環境は、実際の状況でのワークロードの動作を理解するための信頼のソースです。 運用環境でシステムが期待どおりに動作することを信頼できるように、実際の状態を厳密に反映する環境を作成します。

• ワークロード固有のニーズに合わせて、運用環境をミラーリングするためのアプローチを調整します。

高可用性を必要とするミッション クリティカルなワークロードの場合は、運用環境によく似た専用環境でテストします。 これらのワークロードでは、コストの最適化と堅牢な検証の必要性を慎重にバランスを取ります。

パフォーマンスとロード テストには、運用環境に似た専用の環境を使用して、現実的な条件下でサービスの動作が正確に評価されるようにします。

他のワークロードの場合は、テストが下位環境で成功しても運用環境で失敗する場合など、誤検知を減らすために、運用環境のインフラストラクチャを厳密にミラー化します。

• コードがパイプラインを介して進むにつれて、すべての環境で一貫性を目指します。 インフラストラクチャ、データ、セキュリティなど、ワークロードのさまざまな側面を通じて運用環境の状態をシミュレートし、信頼性の高いテスト結果を確保します。

• 構成の誤差を防ぎます。 環境を運用環境にミラーリングすると、構成の誤差によって品質に誤った信頼が生まれる可能性があります。 構成ドリフトの自動検証チェックを実装して、環境が運用環境と整合していることを確認します。 必要に応じて、テストを開始する前に、正しいバージョンがデプロイされていることを確認するようにデプロイ ゲートを設定します。

リスク： 運用環境をミラーリングすると、運用コストが大幅に増加する可能性があります。 エフェメラル環境と永続的なテスト環境のどちらが、ワークロードのコスト効率と品質の最適なバランスを提供するかを評価します。

目的に基づくテスト環境を構築する

意図した目的に明確に焦点を当てた環境を設計します。 テスト ライフサイクルの各フェーズの個別の要件を評価し、環境がそのフェーズの目標と密接に一致していることを確認します。

機能検証、統合テスト、またはその他の目的に関係なく、テストの特定のステージと目標に合わせて、すべてのテスト環境を意図的に設計します。 合理化された環境がテストニーズに効果的に対応する場合は、効率を最大化するためにそのアプローチに優先順位を付けます。

モック サービスを使用する

多くの場合、すべてのテスト シナリオに対する実稼働システムの完全なレプリケーションは実用的ではありません。 重要なビジネス ワークフローを損なうことなく、テストのために安全にレプリケートできるワークロードのコンポーネントを評価します。 完全なレプリケーションが実現できない場合は、運用サービスの動作を正確にシミュレートするモック サービスを使用して、ライブ操作を危険にさらすことなくシナリオを効果的に検証します。

目的に基づくテスト環境は、一時的な環境にモック サービスをデプロイするための理想的な基盤を提供します。 エフェメラル環境は、テスト用の運用環境をシミュレートするコスト効率の高い方法を提供します。 すべてのテスト シナリオで完全な運用環境に似た環境を維持するオーバーヘッドなしで、対話と動作を検証できます。 これらのオンデマンド環境は、特定のテスト目的で作成され、使用後に破棄され、テスト品質を維持しながらインフラストラクチャ コストを削減します。

エフェメラル環境を構築するには、ワークロードが成熟度レベルに達する必要があります。このレベルでは、Infrastructure as Code (IaC) とデプロイ パイプラインを使用した自動化が適切に確立されます。

Azureファシリテーション

Azure Test Plans は、計画的な手動テスト、ユーザー受け入れテスト、探索的テスト、利害関係者からのフィードバックの収集に必要なすべての機能を提供する、ブラウザーベースのテスト管理ソリューションです。 これには、テストの品質を経時的に追跡し、改善のための領域を特定するための Test Analytics が含まれています。

Azure Pipelines を使用すると、テストを CI/CD パイプラインに統合できます。 Azure と統合された GitHub Actions を 使用することもできます。

Azure App Testing は、機能テストとパフォーマンス テストをサポートするサービスです。 これにより、Playwright ワークスペースを使用した機能テストと、Azure Load Testingを使用したパフォーマンス テストを実行できます。

Azure Deployment Environment は、セキュリティを最大化しながら一貫性とベスト プラクティスを確立するプロジェクト ベースのテンプレートを使用してアプリ インフラストラクチャを起動するのに役立ちます。

Azure には、信頼性、パフォーマンス、およびセキュリティ テストをサポートするプラットフォームネイティブ ツールも用意されています。

関連リンク

• パフォーマンス テストに関する推奨事項
• 信頼性テストに関する推奨事項
• セキュリティ テストに関する推奨事項

オペレーショナル エクセレンス チェックリスト

推奨事項の完全なセットを参照してください。