第3章 OpenStack Integration Test Suite のテスト


OpenStack Integration Test Suite は、多数の異なる環境に役立つように設計されています。たとえば、OpenStack のコアプロジェクトへのコミットをフィルタリングして、OpenStack クラウドの実装が正確であるか、また OpenStack クラウドのツールに問題がないかどうかを検証します。そのため、OpenStack Integration Test Suite テストは多数のフレーバーがあり、それぞれ独自のルールやガイドラインが存在します。テストの種類は以下のとおりです。

  • シナリオテスト
  • API テスト
  • ストレステスト

これらのテストは、OpenStack クラウドデプロイメントに対して実行されますが、OpenStack Integration Test Suite では tempest の実装の検証のために実行可能な 単体テスト も提供しています。以下のセクションでは、各テストおよびテストの実装方法を簡単に説明しています。

3.1. シナリオテスト

シナリオテストとは、OpenStack 機能の スルーパス テストです。この種類のテストは通常、複数のサービスを必要とする複雑な状態を設定、実行、終了する一連のステップで構成されます。複数の OpenStack サービスがどのように関わりあうかを確認するため、複数の OpenStack サービス間の統合を伴うテストが理想的です。

注記

シナリオテストには、OpenStack の既存の Python クライアントを使用せずに、クライアントの tempest 実装を使用するようにしてください。

シナリオテストには、実際のユースケースが含まれているべきです。たとえば、オペレーターが空の環境から開始して、以下の機能を実行するユースケースがあります。

  • Image サービスのイメージのアップロード
  • そのイメージからのインスタンスのデプロイ
  • ssh を使用したゲストでのログイン
  • インスタンスのスナップショット作成

スコープ: OpenStack プロジェクトの統合テストに使用するシナリオテストは、OpenStack Integration Test Suite の中核的な目的となっています。シナリオテストは常に、OpenStack API の OpenStack Integration Test Suite 実装を使用して、公式なクライアントにバグが潜んでいないことを確認します。テストは、検証するサービスでタグ付けされます。これは、どのクライアントのライブラリーがテストで直接使用されるかにより決定されます。

適切なシナリオテストの例: 複数のサービスの対話をテストする際には、各対話を具体的に表します。「this is my data center」とうい大規模なスモークテストでは、問題が発生した場合にデバッグが困難です。特に、リソースの設定、変更、デタッチの後に、後ほどそのリソースを再利用する際に対話が繰り返し行われる場合など、冒頭で紹介した Image サービスとコンピュート間の対話のフローが例として適しています。

3.2. API テスト

API テストは、OpenStack API の検証テストです。

注記

API テストは、OpenStack の既存の Python クライアントを使用せずに、クライアントの tempest 実装を使用するようにしてください。

これにより、JSON をテストできるようになります。ロークライアントがあるので、無効な JSON を API に渡して結果を確認することができます。これは、ネイティブクライアントではできません。

スコープ: API テストは、OpenStack API の OpenStack Integration Test Suite 実装を常に使用して、公式のクライアントにバグが潜んでいないことを確認する必要があります。これらのテストでは、固有の API 呼び出しをテストし、API 呼び出しに意義を持たせるのに必要な場合には複雑な状況を構築することもできます。良好なデータだけでなく、不正なデータも API に送信して、エラーコードを検索する必要があります。以前のテストで作成された状態だけに依存せず、すべて独立して API テストを実行できる必要があります。

3.3. ストレステスト

ストレステストは、OpenStack 環境にストレスをかけるために設計されており、OpenStack 環境に負荷の高いワークロードを実行してどの部分が壊れてしまうかを確認します。ストレステストのフレームワークは、複数のテストジョブを並列して実行して、OpenStack Integration Test Suite で既存のテストをストレスジョブとして実行できます。

環境: この特定のフレームワークは、稼働中のコンピュートクラスターが nova API 2.0 に対応していることを前提としています。ストレスジョブは、クラスターからのログを読み込むことができます。これを有効化するには、nova-manage を呼び出すためのホスト名、クラスターに ssh 接続するための秘密鍵、ユーザー名を tempest.conf[stress] セクションに指定する必要があります。また、ログファイルの場所も指定する必要があります。

target_logfiles = “regexp to all log files to be checked for errors” target_private_key_path
= “private ssh key for controller and log file nodes” target_ssh_user = “username for
controller and log file nodes” target_controller = “hostname or ip of controller node (for
nova-manage) log_check_interval = “time between checking logs for errors (default 60s)”

コンソールへのログインを有効にするには、tempest.confuse_stderr を有効にするか、デフォルトの logging.conf.sample ファイルを使用するようにしてください。

デフォルトのストレステストセットの実行: ストレステストのフレームワークでは、OpenStack Integration Test Suite 内のテストを自動的に検出することができます。@stresstest のデコレーターが付いたテストフラグはすべて実行されます。この検出機能を使用するには、OpenStack Integration Test Suite CLI をインストールして、tempest root ディレクトリーに移動し、以下を実行してください。

# tempest run-stress -a -d 30

サンプルテストを実行してインストールをテストします。

# tempest run-stress -t tempest/stress/etc/server-create-destroy-test.json -d 30

このサンプルテストは、複数の仮想マシンを作成して、複数の仮想マシンを中断するように試みます。

テストが終了しない場合や、問題が発生することがあります。そのような場合には、nova クラスターを消去してください。tools のサブディレクトリーにスクリプトが提供されています。以下のスクリプトを使用して、キーペア、Floating IP アドレス、サーバーを破棄してください。

# tempest/stress/tools/cleanup.py

3.4. 単体テスト

単体テストは、OpenStack Integration Test Suite の自己テストで、tempest の内部コンポーネントの機能を検証したり、再発したバグがないかを確認したりします。このテストは、OpenStack Integration Test Suite の個別のコンポーネントが想定通りに機能していることを検証する目的のみで使用すべきでは、以下のようにテスト検出パスを指定して実行することができます。

# OS_TEST_PATH=./tempest/tests testr run --parallel

OS_TEST_PATH./tempest/tests に設定することで、テスト検出が単体テストのディレクトリーでしか実行できないと指定します。OS_TEST_PATH のデフォルト値は OS_TEST_PATH=./tempest/test_discover で、OpenStack Integration Test Suite でのみテスト検出が実行されるようになっています。

または、venv を作成して、単体テストを実行する run_tests.sh スクリプトを使用します。適切なバージョンの Python で単体テストを実行する py27 および py34 の tox ジョブもあります。

スコープ: 単体テストは、OpenStack Integration Test Suite で使用されるメカニズムが有効で機能していることを確認するためのものです。単体テストは、実行に外部サービスや追加の設定は必要ありません。テストに必要な状態がテスト用に作りだされるか、一時的なテストディレクトリーに作成されます (一時テストディレクトリーの使用例は、test_wrappers.py を参照してください)。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る