作成したアプリケーションのテスト方法を、以下の内容で説明します。
サーバアプリケーションのテスト方法
クライアントアプリケーションのテスト方法
スナップショットによるテスト支援
運用環境への移行
運用環境におけるテスト
サーバアプリケーションのテスト方法
サーバアプリケーションのテストを行う場合、実際にクライアントアプリケーションと結合して行います。このとき、サーバアプリケーションをデバッガ配下で動作させることで、サーバアプリケーションが正しく作成されているか確認できます。
サーバアプリケーションのテストは、Solarisの場合だけが可能です。
デバッガと連携するには、アプリケーションをdbx配下などで動かせるようにする必要があります。デバッガと連携するときの動作の概要と、サーバアプリケーションをデバッガ配下でテストする場合の手順を、以下に示します。
テストを行うサーバアプリケーションを、-gオプションおよび-xsオプションを指定してコンパイルします。コンパイル方法の詳細については、関連するマニュアルを参照してください。
テスト用モジュールのコンパイル例を以下に示します。
%CC -c -g -xs -D_REENTRANT -I/opt/FSUNod/include -I/opt/FSUNtd/include tdsample1_s.C |
テストを行うサーバアプリケーションのワークユニット定義を作成し、isstartwuコマンドでデバッグオプション-dを指定してワークユニットを起動します。-dオプションを指定してワークユニットを起動した場合、ワークユニットの動作環境まで作成し、サーバアプリケーションプロセスを起動せずにコマンドは復帰します。isstartwuコマンドの詳細については“リファレンスマニュアル（コマンド編）”を参照してください。
デバッグ用のワークユニットの起動例を、以下に示します。
%isstartwu -d TDSAMPLE1 |
dbxコマンドなどをサーバアプリケーションを指定して起動することにより、サーバアプリケーションをそのデバッガ配下で起動します。サーバアプリケーションプロセスを起動する際のdbxコマンドの指定方法を以下に示します。
dbx サーバアプリケーション |
デバッガ配下でサーバアプリケーションを起動後、デバッガ画面でサーバアプリケーションの実行を行ってください。サーバアプリケーションの実行方法を以下に示します。
(dbx)run 業務システム名 ワークユニット名 オブジェクト名 T |
“td001”を指定します。
本サーバアプリケーションが動作するワークユニット名を指定します。
ワークユニット定義で指定した、本サーバアプリケーションのオブジェクト名を指定します。
“T”を指定します。
サーバアプリケーションの実行後、クライアントアプリケーションからサーバアプリケーションを呼び出し、処理を実行することで、サーバアプリケーションの動作状態をデバッガから確認することができます。これにより、アプリケーションを実行することができ、ステップ単位でデバッグすることができます。なお、C++プログラムのデバッグ方法の詳細については、関連するマニュアルを参照してください。
アプリケーションのテストを終了する場合は、以下の手順で行います。
サーバアプリケーションのデバッグを終了し、クライアントアプリケーションからの要求待ちの状態にします。
ワークユニットを停止します。
デバッガにより、サーバアプリケーションをデバッグする場合の注意事項について示します。
サーバアプリケーションをデバッガ配下で起動しデバッグを行っているときは、再デバッグ（rerun）を行わないでください。再デバッグを行う場合は一度デバッガを停止し、その後再起動してください。
サーバアプリケーションのデバッグ中にワークユニットを停止しないでください。必ずサーバアプリケーションが復帰し、要求待ちの状態になっている状態でワークユニットを停止してください。
ワークユニット定義におけるプロセス多重度には必ず１を指定してください。
１つのワークユニットに対しては、デバッガは１つだけ起動するようにしてください。
デバッガを終了する場合は、必ずデバッガによる実行状態が完了している状態で行ってください。
前出口プログラム、および後出口プログラムのデバッグ中は、他のワークユニットの起動処理または停止処理が保留されます。
デバッガによるステップ実行中でも時間監視は行われますので、ワークユニット定義で時間監視を行わないか、またはデバッグに十分な時間を指定してください。
デバッガを使用している場合は、isstopwu コマンドで-cオプション、およびisstopコマンドで-c、-fおよび-s（Windows版）オプションは投入できません。
ワークユニット定義のアプリケーション使用ライブラリパス、およびアプリケーションライブラリパスに指定されているパスを環境変数(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種類があります。
ファイル出力
メモリ出力
それぞれについて以下に示します。
ロギング情報をワークユニット単位にファイルに取得します。ワークユニットの起動から停止までの範囲で取得し、開発初期時のアプリケーションのデバッグを目的とします。ワークユニット定義では、スナップショット取得指定を定義することにより取得されます。ロギング情報の出力先は、ワークユニット定義のスナップショット出力パスで指定されたディレクトリに、以下に示すファイル名で作成されます。
取得するワークユニット名．アプリケーションの実行プロセスID
スナップショット出力パスを指定していない場合は、カレントディレクトリ配下に作成されます。ワークユニット定義の定義方法については、“OLTPサーバ運用ガイド”を参照してください。
ロギング情報をワークユニット単位にメモリに取得します。ロギング情報の取得に関しては、以下に示す５つのコマンドで操作を行います。なお、それぞれのコマンド文法の詳細については“リファレンスマニュアル（コマンド編）”を参照してください。
ロギング情報の取得を開始します。投入前に、ロギング情報を取得するワークユニットが起動されている必要があります。
ロギング情報の取得を終了します。ロギング情報を取得しているワークユニットを停止する前に投入してください。tdstopsnapコマンドを投入する前に取得対象のワークユニットを停止した場合、ワークユニットの停止と同時にスナップショットの取得を終了します。
メモリに蓄積されたロギング情報を、ファイルへ出力します。作成されるディレクトリは、コマンド投入時のカレントディレクトリです。以下に示すファイル名で作成されます。
取得するワークユニット名.コマンドの実行プロセスID
tdformsnapコマンドは、ロギング情報の取得を終了させてから投入してください。
ロギング情報をメモリに取得してあるワークユニットの一覧を表示します。
ロギング情報をメモリから削除します。
取得情報を格納するメモリは、ワークユニット単位で固定です。このため、メモリが満杯になった場合、同一ワークユニット内の古い情報から上書きされます。
ロギング情報を取得できるワークユニットの数を以下に示します。
システム規模 | ロギングできるワークユニット数 |
|---|---|
SMALL | 8 |
MODERATE | 16 |
LARGE | 24 |
SUPER | 32 |
実際のロギング情報の取得手順を、以下に示します。
サーバアプリケーションが動作しているのを確認後、tdstartsnapコマンドを投入してロギング情報の取得を開始します。
目的のロギング情報が取得できたところで、tdstopsnapコマンドを投入してロギング情報の取得を終了します。
tdformsnapコマンドを投入し、取得したロギング情報を表示します。このロギング情報により、サーバアプリケーションのインタフェースを確認します。
ロギング情報の取得のために獲得した領域（共有メモリ）を、tdfreesnapコマンドを投入して解放します。
運用環境への移行
開発環境でテストした資材を運用環境へ移行するための作業手順と、運用環境でのテスト方法について説明します。
クライアント資材は、サーバ資材を移行してサーバアプリケーションがコンパイルされるまでに移行してください。
サーバ資材を運用環境に移行する手順について、以下に示します。
運用環境におけるテスト
開発環境では各モジュールの単体テストを行いますが、運用環境ではシステム全体として以下に示すテストが必要です。
システム負荷テスト
業務に沿った運用テスト
業務に則した性能テスト
それぞれのテスト方法について、以下に示します。
システム負荷テストは業務を遂行するために、システム上のすべてのコンポーネントを含めたテストを実施します。システムの負荷をあげるためには、システムへのデータ入力の頻度（呼量と呼びます）をあげると、実施できます。たとえば、多数のCORBAクライアントからの入力の場合、CORBAクライアントを高速なマシン上で動作させると、呼量が増加し、負荷があげられます。また、Web連携の負荷をあげるときは、WebStoneなどをUNIXサーバに設定し、同様に呼量を増加させることができます。
業務に沿った運用テストは、実際の業務を想定したテストを実施し、システムとして運用に問題がないかを確認します。したがって、システムで利用する製品および業務アプリケーションすべてを動作させます。たとえば、受注業務の運用テストを実施する場合、受注業務で利用する全製品とアプリケーションを動作させて、受注業務の開始/終了、データ入力とその処理などを実施します。
性能テストは、業務運用中の性能について測定し、問題がないかを確認するテストです。
