| PostgreSQL 9.4.5文書 | |||
|---|---|---|---|
| 前のページ | 上に戻る | 第 30章リグレッションテスト | 次のページ |
リグレッションテストは既にインストールされ稼働中のサーバや、ビルドツリー内の一時的なインストレーションに対して実行することができます。 さらに、テストの実行には"並行"と"連続"モードがあります。 連続モードでは個々のテストスクリプトを単独で実行し、並行モードでは複数のサーバプロセスを実行し、テストをグループ化して並行的に実行します。 並行テストではプロセス間通信とロック機能が正常に作動しているかをテストします。
構築後、インストール前に並行リグレッションテストを行う場合には、最上位のディレクトリで以下のように入力してください。
make check
（または、src/test/regressディレクトリに移動して、そこで実行してください。） 終了したら以下のような表示がされるはずです。
======================= All 115 tests passed. =======================
これが表示されなければ、テストは失敗したことになります。 "失敗"を深刻な問題であると推測する前に、以下の 項30.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
インストール（第15章を参照）後にテストを実行するには、第17章で説明したようにデータ領域を初期化し、サーバを起動し、そして以下を入力してください。
make installcheck
もしくは、並行テストの場合は以下を入力してください。
make installcheck-parallel
テストでは、PGHOST環境変数とPGPORT環境変数で指定がない限り、ローカルホストのサーバに接続し、デフォルトのポート番号を使用します。 テストはregressionという名前のデータベースで行なわれます。 この名前の既存のデータベースはすべて削除されます。 テストは、regressuserNという名前のユーザIDのような、クラスタ全体にわたるオブジェクトも一時的に作成します。
make checkとmake installcheckコマンドは"コア"リグレッションテストだけを実行します。 そのテストはPostgreSQLサーバに組み込まれている機能のみをテストします。 ソース配布には、オプションとなっている手続き言語のような追加機能とその多くが関係のある追加のテストスイートも含まれています。
コアテストを含む、構築するよう選択されたモジュールに適用できるテストスイートをすべて実行するにはビルドツリーの最上位で以下のコマンドの一つを入力して下さい。
make check-world make installcheck-world
make checkとmake installcheckで以前述べたように、このコマンドは、それぞれ、一時的なサーバもしくは既にインストールされているサーバを使ってテストを行ないます。 それ以外に考慮すべきことはそれぞれのところで以前述べたことと同じです。 make check-worldはテストするモジュール毎に別の一時的なインストールツリーを構築しますので、make installcheck-worldよりもずっとより多くの時間とディスク容量が必要です。
代わりに、構築ツリーの適切なサブディレクトリでmake checkまたはmake installcheckと入力することで個々のテストスイートを実行することもできます。 make installcheckはコアサーバだけでなく、関係のあるモジュールもインストール済みであると仮定することを覚えておいて下さい。
このように実行できる追加のテストには以下のものが含まれます。
オプションとなっている手続き言語のリグレッションテスト（PL/pgSQLを除きます。そちらはコアテストでテストされます）。 これはsrc/plにあります。
contribの下にあるcontribモジュールのリグレッションテスト。 すべてのcontribモジュールにテストがあるわけではありません。
ECPGインタフェースライブラリのリグレッションテスト。 src/interfaces/ecpg/testにあります。
同時実行中のセッションの振舞いの負荷テスト。 src/test/isolationにあります。
src/bin以下のクライアントプログラムのテスト。 項30.4も参照してください。
installcheckモードを使う場合には、上記のテストはregressionだけでなくpl_regression、contrib_regression、isolationtest、regress1、connectdbという名前の既存のデータベースも破壊します。
デフォルトでは、一時的なインストレーションを使うテストは、現在の環境で定義されたロケールと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だった場合にのみ意味があります。 この他の場合、ロケールから自動的に符号化方式が選択されます。 ロケールと一致しない符号化方式を指定してもエラーになるだけです。
データベース符号化方式は一時的なインストレーションに対するテストでも既存のインストレーションに対するテストでも設定することができます。 ただし、後者の場合にはインストレーションのロケールと互換性がなければなりません。
プラットフォームに依存する、または非常に時間がかかる可能性があるという理由で、コアリグレッションテスト一式にはデフォルトでは動作しないテストがいくつか含まれています。 EXTRA_TESTS変数を設定することでこれらの追加テストやその他のテストを実行することができます。 例えば、numeric_bigテストを以下のように実行します。
make check EXTRA_TESTS=numeric_big
以下のように照合順序テストを実行します。
make check EXTRA_TESTS=collate.linux.utf8 LANG=en_US.utf8
collate.linux.utf8テストは、Linux/glibcプラットフォームにおいてUTF-8符号化方式を使用するデータベースで実行した場合のみ動作します。
ソース配布は、ホットスタンバイの静的な挙動に対するリグレッションテストも含んでいます。 これらのテストは、稼働しているプライマリサーバと、（ファイルベースのログ転送、またはストリーミングレプリケーションによって）プライマリからの新規の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
この変更がスタンバイに伝搬するようにします。
ここで、デフォルトデータベース接続がスタンバイサーバの試験環境になるように（例えば、PGHOSTとPGPORT環境変数を設定することで）手配してください。 最後に、リグレッションテスト用のディレクトリからmake standbycheckを実行してください。
cd src/test/regress make standbycheck
いくつかの極端な挙動を、スタンバイのテストのための挙動を実現するスクリプトsrc/test/regress/sql/hs_primary_extremes.sqlを用いることでプライマリサーバ上で生成することができます。