検証フェーズの推奨事項

システムのコードが完了すると、システムは完全に安定化するための準備が整い、リリース条件を検証できるようになります。 通常、この段階を安定化フェーズといいます。 このフェーズの最終的な目標は、バグを特定して修正し、システムの稼動準備が整っていることを証明することです。 したがって、ここでは、システムのリリース候補バージョンの最終テストを行います。

リリース候補は、既に開発が完了しており、十分に安定していると見なされたシステム バージョンです (通常は最新バージョン)。検証テストに合格すれば、このリリース候補が製品バージョンとなります。 そのためには、さまざまな機能テスト、パフォーマンス テスト、およびストレス テストを実施し、本当に問題なく動作することを実証する必要があります。

スループットの安定性と遅延を検証するテスト

パフォーマンス検証テストは実装フェーズと並行して既に開始されていますが、リリース条件テストをすべてクリアしているリリース候補バージョンに対して、最終的なパフォーマンス テストを行う必要があります。 できれば、変更を加えたことによる影響を心配しなくて済むよう、最終テスト段階ではリリース候補バージョンを修正しないのが望ましいのですが、 実際には、そうしたケースはほとんどありません。そして、変更をビルドにチェックインしたときは、それらの変更が他の部分に影響していないかどうかを確認する必要があります。

たとえば、パイプラインやオーケストレーションなどのシステム要素に重要な変更を加えた場合は、パフォーマンス テストを再実行して、この新しいリリース候補バージョンを検証します。

システムを確実に稼動できるようにするため、システム全体が持続可能な方法でテストされていることを確認してください。 つまり、トピック「 持続可能なパフォーマンス とは」で定義されているように、データベースのメンテナンス、操作クエリ、計画および計画外の停止などのすべての操作アクティビティをテストする必要があります。これは、システムの準備を認定する最後の機会であるため、最終的なテスト パスで持続可能なパフォーマンス テストの完全なスイートを組み合わせることが重要です。

ボトルネックの特定とハードウェアの調整、または目標へのマイナス影響を除去するための解決方法

実際には、最終的なテスト パスのテスト ベッドは、テスト ベッドの開発よりもハードウェアに関して運用環境に近い一般的です。 したがって、最終的なテスト パス中に機会を使用して、システム内の新規または既存のボトルネックを特定し、ハードウェアの調整を必要とするのに十分な大きさであるかどうかを判断することが重要です。 ハードウェアをすぐに調整する必要がない場合でも、頻繁に発生するシステムのボトルネックを特定することにより、計画および操作に関する有用な情報が得られます。

たとえば、システムは実稼動のロード プロファイルを維持できるが、メッセージ ボックス サーバーの物理的なディスク アイドル時間の低下 (20% を下回るなど) が観察された場合は、稼動状況の主要な指標として実稼動中にこのディスクを監視することを指定できます。 また、現時点でシステムの読み込み機能の改善を計画する場合は、ディスク サブシステムを向上させる必要があるという情報が得られます。

参照

フェーズごとのプロジェクト計画の推奨事項
要件フェーズの推奨事項
設計フェーズの推奨事項
実装フェーズの推奨事項
リリース フェーズの推奨事項