スクリプトによるテストプロセスの自動化

th_define ユーティリティでアクセスログタイプを指定して、障害投入テストスクリプトが作成できます。

# th_define -n name -i instance -a log [-e fixup_script]

th_define はインスタンスをオフラインにし、またオンラインに戻します。次に、修正スクリプト (fixup_script) が記述している作業負荷を実行し、ドライバインスタンスが行う I/O アクセスをログに記録します。

修正スクリプトは省略可能ないくつかの引数を指定されて 2 度呼び出されます (インスタンスがオフラインにされる直前と、オンラインに戻された後の 2 回です)。次の変数が、呼び出された実行可能ファイルの環境に渡されます。

DRIVER_PATH

インスタンスのデバイスパス

DRIVER_INSTANCE

ドライバのインスタンス番号

DRIVER_UNCONFIGURE

インスタンスがこれからオフラインになるときは、1 に設定

DRIVER_CONFIGURE

インスタンスがオンラインに戻されたときは、1 に設定

通常、修正スクリプトはテスト中のデバイスがオフラインとなってよい状態 (未構成)にあるか、あるいはエラー投入が適切な状態 (構成済み、エラーなし、および作業負荷を処理中) であることを確認します。次に、ネットワークドライバ用の最小限のスクリプトの例を示します。

#!/bin/ksh
driver=xyznetdrv
ifnum=$driver$DRIVER_INSTANCE

if [[ $DRIVER_CONFIGURE = 1 ]]; then
   ifconfig $ifnum plumb	
   ifconfig $ifnum ...	
   ifworkload start $ifnum
elif [[ $DRIVER_UNCONFIGURE = 1 ]]; then	
   ifworkload stop $ifnum	
   ifconfig $ifnum down	
   ifconfig $ifnum unplumb
fi
exit $?

ifworkload は作業負荷をバックグラウンドタスクとして開始する必要があります。障害の投入は、修正スクリプトがテスト中のドライバを構成してオンラインに戻した後で行われます (DRIVER_CONFIGURE は 1 に設定されます)。

-e fixup_script オプションを指定する場合は、コマンド行の最後に指定しなければなりません。指定しないと、デフォルトのスクリプトが使用されます。デフォルトのスクリプトは、テスト中のデバイスのオフラインとオンラインを繰り返し試行します。従って、作業負荷は、ドライバのアタッチとデタッチの処理となります。

出来上がったログは、自動障害投入テストに適した、いくつかの実行可能なスクリプトに変換されます。これらのスクリプトは、driver.test.id という名前で、現在のディレクトリの下のサブディレクトリに作成されます。スクリプトはドライバに障害を 1 度に 1 つずつ投入します。同時に、修正スクリプトが記述している作業負荷を実行します。

ドライバのテスト担当者は、テスト自動化プロセスで生成された errdef を大部分制御できます。詳細は、th_define(1M) のマニュアルページを参照してください。

テスト担当者がテストスクリプトに適した作業負荷の範囲を選択すれば、ハーネスはドライバの強化の多くの局面をテストできます。しかし、すべての局面を網羅するためには、テスト担当者は別のテストケースを手作業で作成しなければならなくなる場合があります。これらのケースは、テストスクリプトに追加します。テストを適切な時間内に完了させるには、テスト担当者は重複しているテストケースを手作業で削除する必要がある場合があります。

自動テストプロセス

自動テストのプロセスは、次のようになります。

1. ドライバの何をテストするかを確認します。

   次のようにドライバがハードウェアに作用する部分は、すべてテストします。

   • アタッチとデタッチ

   • スタック下の接続と切り離し

   • 通常のデータ転送

   • 文書化されたデバッグモード

   使用モードごとに、作業負荷スクリプト (fixup_script) を生成する必要があります。

2. 使用モードごとに、デバイスの構成と構成の解除を行い、作業負荷を作成し終了する、実行可能なプログラム (fixup_script) を作成します。

3. errdef によってアクセスの種類を -a log と指定し、th_define を実行します。

4. ログがいっぱいになるまで待ちます。

   ログには、bofi ドライバの内部バッファのダンプが入っています。このデータはスクリプトの最初に記載されます。

   ログの作成には数秒から数分かかるので、th_manage broadcast コマンドを使用して進行状況を検査します。

5. 作成されたテストディレクトリに移動し、マスターテストスクリプトを実行します。

   マスタースクリプトは、生成されたテストスクリプトを順次実行します。レジスタセットごとに、テストスクリプトが生成されます。

6. 分析結果を保存します。

   success (corruption reported) や success (corruption undetected) などの正常に終了したテスト結果は、テスト中のドライバが正常に動作していることを示しています。

   出力に test not triggered という失敗が 2、3 含まれても問題ではありませんが、そうした失敗がそれ以上になった場合には、テストがうまくいっていないことを示します。テストスクリプトが生成されたときと同じレジスタにドライバがアクセスしていないときは、こうした失敗が発生することがあります。

7. ドライバの複数のインスタンスに対して同時にテストを実行し、エラーパスのマルチスレッド化をテストします。

   たとえば、th_define コマンドごとに、テストスクリプトとマスタースクリプトが入ったディレクトリを作成します。

   # th_define -n xyznetdrv -i 0 -a log -e script # th_define -n xyznetdrv -i 1 -a log -e script

   マスタースクリプトを作成したら、それらを同時に実行します。

   ---

   注 –

   生成されたスクリプトでは、ログ対象の errdef がアクティブであった間に記録されたログ内容に基づいた障害投入のシミュレーションだけが生成されます。作業負荷を定義するときは、必要な結果がログに記録されることを確認し、出来上がったログや障害投入の仕様も分析します。出来上がったテストスクリプトが行ったハードウェアのアクセスの範囲が、要望どおりであることを確認する必要があります。

   ---