WinCE6.0 CETKの実施 - その4
これでCETKのシリーズはいったん終了となります。
CETKの特徴としてKatoエンジンによるログの出力があります。このログではテストの合否はもちろんわかりますが、適切なログ出力を実装することで、不合格時の原因を追究することができます。またこのログを保存することでテスト結果の記録として残すことができます。なおログの保存先は以下になりますが、最初はちょっとわかりにくいです。
C:\Program Files\Microsoft Platform Builder\6.00\cepb\wcetk\results
この位置はログを保存するときにダイアログで表示されますので確認をしておいてください（下図ではDドライブになっています）。
今回のテストを実行するとこのファイルのような結果が得られます。このファイルを見るとテストの条件や結果を簡単に確認することができます。まず先頭ですがテストの基本条件が記録されています。パッと見るだけでもテストを2件実施したこと、ARM＋WinCE6.0であること、メモリの状態などを読み取ることができます。今回のテストでは「Suite Name」、「Suite Description」を記述していなかったのでN/Aになっていますが、ここに適切な記述を設定をするとより分かりやすくなります。
*** ==================================================================
*** SUITE INFORMATION
***
*** Suite Name: N/A (built on the fly)
*** Suite Description: N/A
*** Number of Tests: 2
*** ==================================================================
*** ==================================================================
*** SYSTEM INFORMATION
***
*** Date and Time: 05/07/2008 11:09 AM (Wednesday)
***
*** Device Name:
***
*** OS Version: 6.00
*** Build Number: 2217
*** Platform ID: 3 "Windows CE"
*** Version String: ""
***
*** Processor Type: 0x00000A11 (2,577) "StrongARM"
*** Processor Architecture: 0x0005 (5) "ARM"
*** Page Size: 0x00001000 (4,096)
*** Minimum App Address: 0x00010000 (65,536)
*** Maximum App Address: 0x7FFFFFFF (2,147,483,647)
*** Active Processor Mask: 0x00000001
*** Number Of Processors: 1
*** Allocation Granularity: 0x00010000 (65,536)
*** Processor Level: 0x0004 (4)
*** Processor Revision: 0x0001 (1)
*** ==================================================================
*** ==================================================================
*** MEMORY INFO
***
*** Memory Total: 59,691,008 bytes
*** Memory Used: 8,445,952 bytes
*** Memory Free: 51,245,056 bytes
***
*** Kernel Used: 278,528 bytes
*** Water Mark: 12,511 pages
***
*** Store Total: 59,584,512 bytes
*** Store Used: 303,104 bytes
*** Store Free: 59,281,408 bytes
*** ==================================================================
そしてこのテストのサマリーがファイルの最後に記録されます。
*** ==================================================================
*** SUITE SUMMARY
***
*** Passed: 1
*** Failed: 1
*** Skipped: 0
*** Aborted: 0
*** -------- ---------
*** Total: 2
***
*** Cumulative Test Execution Time: 0:00:00.026
*** Total Tux Suite Execution Time: 0:00:00.243
*** CPU Idle Time: 0:00:00.000
*** ==================================================================
ここではテストを2件実施して、1件は成功、1件でエラーが発生したことがわかります。そしてスキップしたり途中で終了したテストはありません。もちろん“Failed”ということでエラーが発生した場合は、その原因追求と対策が必要です。それに対して“Skipped”や“Aboarted”はその理由を明確にすることで、テストの結果として表れても問題が無い場合があります。これらの発生原因についてはソースを確認するなりして判断をしてください。
それでは今回のテストのエラー原因を確認してみます。テスト結果のログにはこのエラーに関する情報が含まれています。
BEGIN GROUP: TuxDriver01.DLL
<TESTCASE ID=1>
*** vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
*** TEST STARTING
***
*** Test Name: Sample test 1
*** Test ID: 1
*** Library Path: \tuxdriver01.dll
*** Command Line:
*** Kernel Mode: No
*** Random Seed: 18353
*** Thread Count: 0
*** vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
BEGIN TEST: "Sample test 1", Threads=0, Seed=18353
Driver01.dll IoControl test Starting
Driver01.dll Test - Open Driver01.dll
Driver01.dll Test - Open Driver01.dll OK
Driver01.dll Test - CMD_IOCTL_NO1 OK
Driver01.dll Test - CMD_IOCTL_NO2 OK
Driver01.dll Test - CMD_IOCTL_NO3 OK
Driver01.dll Test - CMD_IOCTL_NO4 is FAILED
END TEST: "Sample test 1", FAILED, Time=0.018
*** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*** TEST COMPLETED
***
*** Test Name: Sample test 1
*** Test ID: 1
*** Library Path: \tuxdriver01.dll
*** Command Line:
*** Kernel Mode: No
*** Result: Failed
*** Random Seed: 18353
*** Thread Count: 1
*** Execution Time: 0:00:00.018
*** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
このログを見るとわかるのですが、Driver01.dllのテストでDeviceIoControl関数を呼び出しています。そしてCMD_IOCTL_NO4の呼び出しでエラーが発生しています。ここでこのエラーがなぜ発生したのかを探ることにします。
CETKのソースコードtest.cppを見ると以下のようになっています。TestProc1関数ではDeviceIoControl関数を呼び出して、引数にCMD_IOCTL_NO4を渡しています。そして関数の戻りがエラーとなっているため、エラーログを出力していることがわかります。
// CMD_IOCTL_NO4
if ( DeviceIoControl( hDrv01, CMD_IOCTL_NO4, NULL, 0,
&dwValue, sizeof(DWORD), &dwReturnValue, NULL ) ){
if ( dwValue == 4){
g_pKato->Log(LOG_COMMENT,
TEXT("Driver01.dll Test - CMD_IOCTL_NO4 OK"));
}
else{
g_pKato->Log(LOG_COMMENT,
TEXT("Driver01.dll Test - CMD_IOCTL_NO4 is invalid return value"));
tRet = TPR_FAIL;
}
}
else{
g_pKato->Log(LOG_COMMENT,
TEXT("Driver01.dll Test - CMD_IOCTL_NO4 is FAILED"));
tRet = TPR_FAIL;
}
このテストによって呼び出されているのはDriver01.cのDRV_IOControl関数です。この関数で引数によって渡されるコマンドの制御を確認してみます。
switch ( dwIoControlCode ){
case CMD_IOCTL_NO1:
*(DWORD *)pOutBuf = 1;
*pBytesReturned = sizeof(DWORD);
break;
case CMD_IOCTL_NO2:
*(DWORD *)pOutBuf = 2;
*pBytesReturned = sizeof(DWORD);
break;
case CMD_IOCTL_NO3:
*(DWORD *)pOutBuf = 3;
*pBytesReturned = sizeof(DWORD);
break;
default:
RetVal = FALSE;
break;
}
ソースを確認するとわかるのですが、このDRV_IOControl関数ではCMD_IOCTL_NO4の処理が実装されていません。このようにCETKを通すことで、実装すべき処理の抜けを発見することができたわけです。このドライバの不具合は発見できましたので、その対策は容易です。
以上のように、CETKを通すことでデバイスドライバの不具合を発見することが可能です。最後になりますが、CETKを通すメリットをまとめます。
- WinCEのテスト用フレームワークに準拠しているため、テストの実行が容易。
- サーバークライアント型のテストとなっていて、テストの制御や結果の取得が簡単にできる。
- ユーザー作成のテストを追加できることから、テストプログラムが開発資産となる。
- CETKのフレームワークに合わせてユーザーテストを作成することができるため、テストの開発が比較的容易。
- Katoエンジンによるロギングができることから、その結果をきちんとした形で残すことができる。
- 常に同一のテストを行うことで、変更・修正後のデグレのチェックが可能。
プラットフォームのテストではCETKを必ず使わなくてはならないというものではありません。しかしCETKはフレームワークとして見るとよくできたシステムです。ぜひユーザーテストを追加して、テスト資産を増やしてみてください。
Recent Comments