他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

32.1. テストの実行

リグレッションテストは既にインストールされ稼働中のサーバや、ビルドツリー内の一時的なインストレーションに対して実行することができます。 さらに、テストの実行には並行連続モードがあります。 連続モードでは個々のテストスクリプトを単独で実行し、並行モードでは複数のサーバプロセスを実行し、テストをグループ化して並行的に実行します。 並行テストではプロセス間通信とロック機能が正常に作動しているかをテストします。

32.1.1. 一時的なインストレーションに対するテストの実行

構築後、インストール前に並行リグレッションテストを行う場合には、最上位のディレクトリで以下のように入力してください。

make check

(または、src/test/regressディレクトリに移動して、そこで実行してください。) 終了したら以下のような表示がされるはずです。


=======================
 All 193 tests passed.
=======================

これが表示されなければ、テストは失敗したことになります。 失敗を深刻な問題であると推測する前に、以下の 32.2 を参照してください。

この試験方法では、一時的にサーバを起動するので、rootユーザとして構築を行なった場合には動作しません。 サーバがrootでは起動しないからです。 rootで構築をしないこと、もしくはインストール完了後に試験を実施することをお薦めします。

古いPostgreSQLのインストレーションが既に存在している場所にPostgreSQLをインストールするように構築した場合、新しいバージョンをインストールする前にmake checkを行うと、新しいプログラムがインストール済みの共有ライブラリを使用しようとするために試験が失敗することになります。 (典型的な症状は、未定義シンボルに関するエラーメッセージです。) 古いインストレーションを上書きする前に試験を行いたいのであれば、configure --disable-rpathで構築する必要があります。 しかし、このオプションを最終的なインストレーションで使用することは推奨しません。

並行リグレッションテストは、実行したユーザのユーザIDを使用して相当数のプロセスを起動します。 現在、最大で20個の並行テストスクリプトが同時に実行されますが、これは合計40個のプロセスが実行されることを意味します。 各テストスクリプトに対して、1つのサーバプロセスと1つのpsqlプロセスが存在するためです。 ですので、使用するシステムでユーザ当たりのプロセス数に制限を加えている場合は、その上限が少なくとも50程度であることを確認してください。 さもないと、並行テストにおいて、ランダムに発生しているように見える失敗が発生するかもしれません。 この上限を変更できない場合は、MAX_CONNECTIONSパラメータを編集して、並行度を減らすことができます。 例えば、以下は同時実行数を10以下で実行します。

make MAX_CONNECTIONS=10 check

32.1.2. 既存のインストレーションに対するテストの実行

インストール(第16章を参照)後にテストを実行するには、第18章で説明したようにデータディレクトリを初期化し、サーバを起動し、そして以下を入力してください。

make installcheck

もしくは、並行テストの場合は以下を入力してください。

make installcheck-parallel

テストでは、PGHOST環境変数とPGPORT環境変数で指定がない限り、ローカルホストのサーバに接続し、デフォルトのポート番号を使用します。 テストはregressionという名前のデータベースで行なわれます。 この名前の既存のデータベースはすべて削除されます。

テストは、ロールやテーブル空間、サブスクリプションのようなクラスタ全体にわたるオブジェクトも一時的に作成します。 このオブジェクトの名前はregress_で始まります。 実際のグローバルオブジェクトがそのように名付けられたインストレーションでinstallcheckモードを使う場合には注意してください。

32.1.3. 追加のテストスイート

make checkmake installcheckコマンドはコアリグレッションテストだけを実行します。 そのテストはPostgreSQLサーバに組み込まれている機能のみをテストします。 ソース配布には、オプションとなっている手続き言語のような追加機能とその多くが関係のある追加のテストスイートが多く含まれています。

コアテストを含む、構築するよう選択されたモジュールに適用できるテストスイートをすべて実行するにはビルドツリーの最上位で以下のコマンドの一つを入力して下さい。

make check-world
make installcheck-world

make checkmake installcheckで以前述べたように、このコマンドは、それぞれ、一時的なサーバもしくは既にインストールされているサーバを使ってテストを行ないます。 それ以外に考慮すべきことはそれぞれのところで以前述べたことと同じです。 make check-worldはテストするモジュール毎に別のインスタンス(一時的なデータディレクトリ)を構築しますので、make installcheck-worldよりもずっとより多くの時間とディスク容量が必要です。

複数のCPUコアがあり、オペレーティングシステムの厳しい制限のない最近のマシンでは、並列処理でかなり速くできます。 ほとんどのPostgreSQL開発者がテストをすべて実行するのに実際に使っている方法は

make check-world -j8 >/dev/null

のようなものです。ここで-jの範囲は利用可能なコアの数に近い、もしくはそれより少し多い値です。 stdoutを捨てることで、成功を検証する時には興味のない出力を除きます。(失敗した場合、どこをより詳細に調べるべきか決めるにはstderrメッセージでたいてい十分です。)

代わりに、構築ツリーの適切なサブディレクトリでmake checkまたはmake installcheckと入力することで個々のテストスイートを実行することもできます。 make installcheckはコアサーバだけでなく、関係のあるモジュールもインストール済みであると仮定することを覚えておいて下さい。

このように実行できる追加のテストには以下のものが含まれます。

  • オプションとなっている手続き言語のリグレッションテスト。 これはsrc/plにあります。

  • contribの下にあるcontribモジュールのリグレッションテスト。 すべてのcontribモジュールにテストがあるわけではありません。

  • ECPGインタフェースライブラリのリグレッションテスト。 src/interfaces/ecpg/testにあります。

  • コアがサポートする認証方式のテスト。 src/test/authenticationにあります。 (認証に関連する追加のテストについては下記を参照してください。)

  • 同時実行中のセッションの振舞いの負荷テスト。 src/test/isolationにあります。

  • クラッシュリカバリと物理レプリケーションのテスト。 src/test/recoveryにあります。

  • 論理レプリケーションのテスト。 src/test/subscriptionにあります。

  • src/bin以下のクライアントプログラムのテスト。 32.4も参照してください。

installcheckモードを使う場合には、上記のテストは名前regressionを含むテストデータベースを破壊します。例えば、pl_regressioncontrib_regressionです。 非テストデータベースがそのように名付けられたインストレーションでinstallcheckモードを使う場合には注意してください。

この補助的なテストスイートの中には32.4で説明するTAP基盤を使うものがあります。 オプション--enable-tap-testsを指定してPostgreSQLを構築した場合にのみ、TAPベースのテストが行なわれます。 これは開発にはお薦めですが、適切なPerlのインストレーションがない場合には省略できます。

マルチユーザシステムにおいて安全に実行できない、あるいは、特別なソフトウェアを必要とする、といういずれかの理由により、一部のテストスイートはデフォルトでは実行されません。 どのテストスイートを追加で実行するかをmakeや環境変数PG_TEST_EXTRAに空白区切りのリストを設定することで決定できます。 以下に例を示します。

make check-world PG_TEST_EXTRA='kerberos ldap ssl'

現在、以下の値がサポートされます。

kerberos

src/test/kerberos以下のテストスイートを実行します。 これはMIT Kerberosのインストールを必要とし、TCP/IPリッスンソケットを開きます。

ldap

src/test/ldap以下のテストスイートを実行します。 これはOpenLDAPのインストールを必要としTCP/IPリッスンソケットを開きます。

ssl

src/test/ssl以下のテストスイートを実行します。 これはTCP/IPリッスンソケットを開きます。

現在のビルド設定ではサポートされない機能のテストは、PG_TEST_EXTRAに記述されていても、実行されません。

さらに、make check-worldでは実行されますが、make installcheck-worldでは実行されないテストがsrc/test/modulesにあります。 これは、実運用向けではない拡張をインストールしたり、実運用のインストレーションには望ましくない副作用があったりするためです。 お望みとあらば、そのサブディレクトリの1つでmake installmake installcheckを使うことはできますが、テスト用でないサーバでそうすることはお勧めしません。

32.1.4. ロケールと符号化方式

デフォルトでは、一時的なインストレーションを使うテストは、現在の環境で定義されたロケールとinitdbで決定される対応するデータベース符号化方式を使用します。 異なるロケールを試験する際は、以下の例のように適切な環境変数を設定することが有用です。

make check LANG=C
make check LC_COLLATE=en_US.utf8 LC_CTYPE=fr_CA.utf8

実装上の理由のため、LC_ALLはこの目的には動作しません。 この他のロケール関連の環境変数は動作します。

既存のインストレーションに対するテストでは、ロケールは既存のデータベースクラスタによって決まり、テスト実行時に別の値に設定することができません。

また、以下の例のようにENCODING変数を設定することで明示的にデータベース符号化方式を選択することができます。

make check LANG=C ENCODING=EUC_JP

この方法でデータベース符号化方式を設定することは、通常ロケールがCだった場合にのみ意味があります。 この他の場合、ロケールから自動的に符号化方式が選択されます。 ロケールと一致しない符号化方式を指定してもエラーになるだけです。

データベース符号化方式は一時的なインストレーションに対するテストでも既存のインストレーションに対するテストでも設定することができます。 ただし、後者の場合にはインストレーションのロケールと互換性がなければなりません。

32.1.5. 追加のテスト

プラットフォームに依存する、または非常に時間がかかる可能性があるという理由で、コアリグレッションテスト一式にはデフォルトでは動作しないテストがいくつか含まれています。 EXTRA_TESTS変数を設定することでこれらの追加テストやその他のテストを実行することができます。 例えば、numeric_bigテストを以下のように実行します。

make check EXTRA_TESTS=numeric_big

以下のように照合順序テストを実行します。

make check EXTRA_TESTS='collate.linux.utf8 collate.icu.utf8' LANG=en_US.utf8

collate.linux.utf8テストは、Linux/glibcプラットフォームにおいてのみ動作します。 collate.icu.utf8テストは、ICUをサポートするよう構築した場合にのみ動作します。 どちらのテストも、UTF-8符号化方式を使用するデータベースで実行した場合にのみ成功するでしょう。

32.1.6. ホットスタンバイのテスト

ソース配布は、ホットスタンバイの静的な挙動に対するリグレッションテストも含んでいます。 これらのテストは、稼働しているプライマリサーバと、(ファイルベースのログ転送、またはストリーミングレプリケーションによって)プライマリからの新規のWALの変更を受け付けられる稼働中のスタンバイサーバを必要とします。 これらのサーバは、自動的に作成されませんし、ここにはレプリケーション設定ドキュメントもありません。 必要なコマンドや関連する問題について記述されている、ドキュメントのさまざまなセクションを参照してください。

ホットスタンバイテストを実行するには、最初に"regression"という名前のデータベースをプライマリに作成します。

psql -h primary -c "CREATE DATABASE regression"

次に、準備のためのスクリプトsrc/test/regress/sql/hs_primary_setup.sqlをプライマリのregressionデータベース上で以下のように実行します。

psql -h primary -f src/test/regress/sql/hs_primary_setup.sql regression

この変更がスタンバイに伝搬するようにします。

ここで、デフォルトデータベース接続がスタンバイサーバの試験環境になるように(例えば、PGHOSTPGPORT環境変数を設定することで)手配してください。 最後に、リグレッションテスト用のディレクトリからmake standbycheckを実行してください。

cd src/test/regress
make standbycheck

いくつかの極端な挙動を、スタンバイのテストのための挙動を実現するスクリプトsrc/test/regress/sql/hs_primary_extremes.sqlを用いることでプライマリサーバ上で生成することができます。