作成したアプリケーションのテスト方法を、以下の内容で説明します。
サーバアプリケーションのテスト方法（Solarisの場合）
クライアントアプリケーションのテスト方法
スナップショットによるテスト支援
運用環境への移行
運用環境におけるテスト
■サーバアプリケーションのテスト方法 
サーバアプリケーションのテストは、実際にクライアントアプリケーションと結合して行います。このとき、サーバアプリケーションをデバッガ配下で動作させると、サーバアプリケーションが正しく作成されているかを確認できます。
注意
サーバアプリケーションは、Solarisの場合にだけテストすることができます。
デバッガと連携するには、アプリケーションをdbx配下などで動かす必要があります。
デバッガとの連携時の動作概要、およびサーバアプリケーションをデバッガ配下でテストする場合の手順を以下に示します。
(1) テスト用モジュールの作成
テストするサーバアプリケーションを、-gオプション・-xsオプションを指定してコンパイルします。コンパイル方法の詳細については、関連するマニュアルを参照してください。
テスト用モジュールのコンパイル例を以下に示します。
%CC -c -g -xs -D_REENTRANT -I/opt/FSUNod/include -I/opt/FSUNtd/include tdsample1_s.C
(2) ワークユニットの起動
テストするサーバアプリケーションのワークユニット定義を作成し、isstartwuコマンドでデバッグオプション（-dオプション）を指定してワークユニットを起動します。-dオプションを指定してワークユニットを起動すると、ワークユニットの動作環境まで作成し、APMプロセスを起動せずに復帰します。isstartwuコマンドの詳細については、“リファレンスマニュアル（コマンド編）”を参照してください。
デバッグ用のワークユニットの起動例を以下に示します。
%isstartwu -d TDSAMPLE1
(3) サーバアプリケーションプロセスの起動
dbxコマンドなどでサーバアプリケーションを指定して起動することにより、サーバアプリケーションをそのデバッガ配下で起動します。
サーバアプリケーションプロセス起動時のdbxコマンドの指定方法を以下に示します。
dbx サーバアプリケーション
(4) テスト開始
デバッガ配下でサーバアプリケーションを起動後、デバッガ画面でサーバアプリケーションを実行します。
サーバアプリケーションの実行方法を以下に示します。
(dbx)run 業務システム名 ワークユニット名 オブジェクト名 T
“td001”を指定します。
本サーバアプリケーションが動作するワークユニット名を指定します。
ワークユニット定義で設定した本サーバアプリケーションのオブジェクト名を指定します。
“T”を指定します。
サーバアプリケーションの実行後、クライアントアプリケーションからサーバアプリケーションを呼び出し、処理を実行することで、サーバアプリケーションの動作状態をデバッガから確認できます。これにより、アプリケーションを実行でき、ステップ単位でデバッグすることができます。なお、C++プログラムのデバッグ方法の詳細については、関連するマニュアルを参照してください。
なお、アプリケーションのテストは、以下の手順で終了します。
サーバアプリケーションのデバッグを終了し、クライアントアプリケーションから要求待ちの状態にします。
ワークユニットを停止します。
注意
デバッガでサーバアプリケーションをデバッグする場合の注意事項
デバッガ配下でサーバアプリケーションを起動してデバッグしている場合は、再デバッグ（rerun）を行わないでください。再デバッグを行う場合は、いったんデバッガを停止してから、再起動してください。
サーバアプリケーションのデバッグ中は、ワークユニットを停止しないでください。サーバアプリケーションが復帰して要求待ち状態になってから、ワークユニットを停止してください。
ワークユニット定義のプロセス多重度には、“1”を指定してください。
デバッガは、1つのワークユニットに対して1つだけ起動してください。
デバッガは、デバッガによる実行が完了した状態で終了してください。
前出口プログラム・後出口プログラムのデバッグ中は、他のワークユニットの起動処理／停止処理を保留します。
時間監視は、デバッガによるステップ実行中にも行われます。ワークユニット定義において時間監視を行わないように設定するか、またはデバッグに十分な時間を設定してください。
デバッガ使用時は、isstopwuコマンド実行時に-cオプション、およびisstopコマンド実行時に-c／-f／-s（Windows(R)版）オプションを指定できません。
デバッガは、環境変数LD_LIBRARY_PATHにワークユニット定義のアプリケーション使用ライブラリパス・アプリケーションライブラリパスに指定されているパスを設定してから、起動してください。
■クライアントアプリケーションのテスト方法
クライアントアプリケーションのテスト方法は、クライアントアプリケーションを動作させるオペレーティングシステム／ミドルウェアによって異なります。使用しているオペレーティングシステム／ミドルウェアにおいて推奨されている方法でテストを行ってください。
■スナップショットによるテスト支援
スナップショットを使用して、クライアントからの要求に対する入出力情報をワークユニット単位に取得することにより、アプリケーションをデバッグすることができます。
ログファイルの出力形式を以下に示します。
SNAP START: TIME: 10:51:02.159574 (1)
MODULE NAME : SNAP10_OBJ1 (2)
OPERATION NAME : OPE1 (3)
INPUT INFORMATION (4)
PARAMETER NUMBER:10 (5)
VARIABLES
PARAM0001: ATTRIBUTE :long (6)
DATA LENGTH :4 (7)
DATA :1 (8)
:
:
SNAP START: TIME: 13:08:03.317794 (9)
MODULE NAME : SNAP10_OBJ1 (2)
OPERATION NAME : OPE1 (3)
RETURN INFORMATION (10)
RETURN VALUES : 0 (11)
OUTPUT INFORMATION (12)
PARAMETER NUMBER:10 (5)
VARIABLES
PARAM0001: ATTRIBUTE :short (6)
DATA LENGTH :2 (7)
DATA :100 (8)
:
:アプリケーションの実行開始時間
オブジェクト名
オペレーション名
アプリケーション呼出し時のパラメタ
注）タイプがin／inoutのパラメタ情報を表示します。
パラメタ数
PARAMxxxx：xxxx番目のパラメタ
ATTRIBUTE：データ属性
データ長（バイト数）
データの値
注）整数以外は、16進数で表示します。
アプリケーションからの復帰時間
アプリケーションからの復帰時の情報
復帰値
アプリケーションの復帰時のパラメタ
注）タイプがout／inoutのパラメタ情報を表示します。
属性別のパラメタ情報の出力例については、“B.1 パラメタ情報の出力例”を参照してください。
採取できるログファイルは、以下の2種類です。
ファイル出力
メモリ出力
それぞれについて以下に示します。
ワークユニット単位のロギング情報をファイルに取得します。ワークユニットの起動から停止までの範囲で取得し、開発初期時のアプリケーションのデバッグを目的とします。ワークユニット定義では、スナップショットの取得指定を定義することにより取得されます。
ロギング情報は、以下に出力されます。
ワークユニット定義のスナップショット出力パスで指定されたディレクトリ
注）スナップショット出力パスを指定していない場合は、カレントディレクトリ配下に出力されます。ワークユニット定義の定義方法については、“OLTPサーバ運用ガイド”を参照してください。
取得するワークユニット名．アプリケーションの実行プロセスID
ワークユニット単位のロギング情報をメモリに取得します。
以下の5つのコマンドを使用してロギング情報を取得します。各コマンドの詳細については、“リファレンスマニュアル（コマンド編）”を参照してください。
ロギング情報の取得を開始します。
本コマンド実行時は、ロギング情報を取得するワークユニットが起動されている必要があります。
ロギング情報の取得を終了します。
本コマンドは、ロギング情報を取得するワークユニットを停止する前に実行してください。本コマンドを実行する前に取得対象のワークユニットを停止した場合、ワークユニットの停止と同時にスナップショットの取得も終了されます。
メモリに蓄積されたロギング情報をファイルに出力します。本コマンドは、ロギング情報の取得を終了させてから投入してください。
ロギング情報は、以下に出力されます。
格納パス
本コマンド実行時のカレントディレクトリ
ファイル名
取得するワークユニット名.コマンドの実行プロセスID
メモリに取得されたロギング情報のワークユニット一覧を表示します。
メモリからロギング情報を削除します。
メモリには、ワークユニット単位固定で取得情報が格納されます。このため、メモリ不足が発生した場合、同一ワークユニット内の古い情報に上書きされます。
ロギング情報が取得可能なワークユニット数を以下に示します。
システム規模 | ロギングできるワークユニット数 |
|---|---|
SMALL | 8 |
MODERATE | 16 |
LARGE | 24 |
SUPER | 32 |
実際のロギング情報の取得手順を以下に示します。
サーバアプリケーションが動作中であることを確認し、tdstartsnapコマンドを使用してロギング情報の取得を開始します。
目的のロギング情報の取得完了後、tdstopsnapコマンドを使用してロギング情報の取得を終了します。
tdformsnapコマンドを使用して取得したロギング情報を表示します。本ロギング情報により、サーバアプリケーションのインタフェースを確認します。
tdfreesnapコマンドを使用して、ロギング情報の取得のために獲得した領域（共有メモリ）を解放します。
■運用環境への移行
開発環境でテストした資源を運用環境へ移行するための作業手順、および運用環境でのテスト方法について説明します。
クライアント資源は、サーバ資材を移行してサーバアプリケーションがコンパイルされるまでに移行します。
サーバ資源を運用環境に移行する手順について、以下に示します。
■運用環境におけるテスト
開発環境では、各モジュールの単体テストを行いますが、運用環境では、システム全体として以下のテストを行う必要があります。
システム負荷テスト
業務に沿った運用テスト
業務に則した性能テスト
それぞれのテスト方法について、以下に示します。
システム負荷テストでは、業務を遂行するため、システム上のすべてのコンポーネントを含めたテストを行います。システム負荷は、システムへのデータ入力の頻度（呼量と呼びます）をあげて、高くします。たとえば、多数のCORBAクライアントから入力する場合、CORBAクライアントを高速なマシン上で動作させると、呼量が増加して負荷を高くできます。また、Web連携の負荷は、WebStoneなどをSolaris/Linuxサーバに設定し、同様に呼量を増加させて、高くします。
業務に沿った運用テストでは、実際の業務を想定したテストを行い、システムとして運用に問題がないかを確認します。したがって、システムで利用する製品・業務アプリケーションのすべてを動作させます。たとえば、受注業務の運用テストを行う場合、受注業務で利用する全製品・アプリケーションを動作させて、受注業務の開始／終了、データ入力とその処理などを行います。
性能テストでは、業務運用中の性能について測定し、問題がないかを確認します。