小弟这两天学习和分析了CETK，并总结了一份文档，粘贴出来，希望对各位有用。

      因为文章有26页，没有办法在一篇帖子中罗列出来，我分好几个帖子进行罗列。

一．CETK概述

1．CETK是什么

       CETK全称是Microsoft® Windows® CE 5.0 Test Kit，用来对OEM厂商为Windows CE开发的设备驱动进行测试，同时也可以测试OAL等。其支持所有Windows CE所支持的CPU，对于那些Windows CE默认不支持的外设，用户可以自己去开发测试DLL并导入到CETK中进行测试。

2．工作原理简述

       在Work Station-Target Device模式下，PC端的cetest.exe（即Windows CE Test Kit）和Device端进行连接后，会将ClientSide.exe拷贝到Device的对象存储根目录下并将其运行起来，后续的测试过程中，PC和Device通过用户设定的通信方式进行交互。

交互的内容包括一些Log信息和命令等，Log信息的来自于模块Kato来，而命令来自于CETEST.exe。

       而具体负责测试的DLL就是下图中的Tux Test DLLs。

3．默认的测试模块

       默认的测试模块包括：Audio、BT、CD/DVD ROM、Direct3D、DirectDraw、FSD、GDI、IR(1.1/2.0)、Keyboard、Mouse、NDIS、OAL、PD、RDP、Storage Device、Telephony、Touch、Winsock、Serial和Parallel等。

二．使用方法[IMPORTANT]

1．在PB中添加对CETK的支持

1> 添加CETK Feature

       依次选择View | Catalog，打开Feature添加窗口，添加下图中的Windows CE Test Kit到当前的工程中。

       添加Windows CE Test Kit完成的功能是将Client Side 文件添加到 Build Release 文件夹中。Client Side应用程序完成的在Work Station和Target Device连接的时候被Platform Builder下载到Target Device上，并用来和Work Station的CETest.exe进行通信。

2> 配置Work Station和Target Device的连接方式

       打开StartàAll programsàMicrosoft Windows CE 5.0àWindows CE 5.0 Test Kit，其实也就是运行cetest.exe工具，选择ConnectionàStart Client，看到如下的窗口：

       选择Settings，看到如下的窗口：

       选择Properties，并在如下的弹出出窗口中去配置通信方式，典型的配置是使用ActiveSync进行连接。

2．Windows CE Test Kit的使用方法

1> 运行Windows CE Test Kit

       默认情况下，Windows CE Test Kit的可执行程序cetest.exe位于目录C:/Program Files/Windows CE Platform Builder/5.00/CEPB/wcetk下。

       通过下列的方式可以启动Windows CE Test Kit：

l         直接运行目录C:/Program Files/Windows CE Platform Builder/5.00/CEPB/wcetk下的cetest.exe；

l         从开始菜单启动，依次选择StartàAll ProgramsàMicrosoft Windows CE5.0àMicrosoft Windows CE Test Kit

l         从Platform Builder启动，依次选择Toolsà Windows CE Test Kit

对于后两个方式如果不能够启动，并提示找不到可执行程序的话，可以将cetest.exe从C:/Program Files/Windows CE Platform Builder/5.00/CEPB/wcetk下拷贝到[安装Platform Builder的逻辑磁盘盘符]:/Program Files/Windows CE Platform Builder/5.00/CEPB/wcetk下再次运行即可。

运行起来之后，其主界面如下图所示：

2> 连接Target Device

在WorkStation测试模式下，需要和Target Device进行连接以进行通信。

选择主菜单中的ConnectionàStart Client，打开如下窗口：

       点击选择Settings，打开如下的配置窗口：

       点击Properties按钮，在如下的打开窗口中去配置连接方式，典型的配置是采用ActiveSync方式。

       配置完连接方式后，点击OK退回到Device Connection窗口，点击Connect按钮，则Windows CE Test Kit开始和Target Device进行连接，并拷贝PC机Release目录下的ClientSide.exe到Target Device的Object Store的根目录下，然后开始对Target Device的模块进行检测。

如果一切连接正常，最终会看到如下的窗口：

       Target Device上不支持的模块， 表示支持的模块，而 表示当前的Test Kit， 表示未选中的Test Kit。

3> 启动测试

>> 一次性测试所有模块

Win CE Test Kit中共包括3项Test Kit，在具体的某一Test Kit中右键并选择Select All，则当前处于选择状态的Test Kit的所有测试模块的测试项都被选中，如下图所示：

       在Windows CE Test Kit连接到Target Device并检测到所有的模块后，就可以对当前检测到的所有模块开始测试。

       对所有模块进行测试的方法如下：

l         在选中的Test Kit上右键并选择Select All Test，则当前Test Kit下所有模块的测试项都被选中；

l         然后选择主菜单中的TestsàStart/Stop TestsàWindows CE（ARMV4I），启动当前选中的所有模块的测试。

如果想停止当前测试，依然是选择TestsàStart/Stop TestsàWindows CE（ARMV4I），如下图所示：

>> 测试单个模块

如果要启动默认模块测试的方法如下图所示：

>>   指定测试模块的具体测试项

如果觉得模块测试的时间太长，或者仅仅是想针对模块的特定测试Item进行测试的话，可以编辑测试Command，选择上图中的Edit Command Line，在如下弹出的窗口中编辑传递给Tux的测试命令。

       Serial Prot包括1001~1009共9项测试，如果要指定测试1007，可以在Command Line中输入tux -0 –d serdrvbvt –x 1007，其中-x是tux语法的关键词，用来指定测试项的编号，如果要指定测试1007和1008可以输入tux -0 –d serdrvbvt –x 1007,1008，如果要测试1007&1008&1009可以输入tux -0 –d serdrvbvt –x 1007-1009。注意编辑命令的时候不同的测试项之间最好不要加入空格，否则会报错。

       另外，为了不影响后续对该模块的测试，在测试完之后应该将Command Line Restore（选择上面窗口中的Restore按钮）或者关闭WinCE Test Kit，这样就可以将刚才编辑的命令还原为默认值。

4> 查看测试结果

>> 查看当前测试结果

以查看Serial Port的测试结果为例，依次在Tests菜单项下做如下的选择：

       将看到如下的测试结果：

>> 查看以前测试结果

       所有的测试结果都会被保存到[安装PB的逻辑磁盘盘符]:/Program Files/Windows CE Platform Builder/5.00/CEPB/WCETK/results/WindowsCE_(ARMV4I)目录下。该目录下会包含很多以测试日期命名的文件夹，对于某一天的很多次测试结果，又以启动测试的具体HH-MM-SS进行命令。

       目录结构如下：

       可以直接打开这些Log文件进行查看。

 

      

>> 如何打开CETK工具

StartàAll programsàMicrosoft Windows CE 5.0àWindows CE 5.0 Test Kit

如果提示找不到CETK的工具，则重新指定到安装路径/Windows CE Platform  Builder/5.00/CEPB/WCETK下的cetest.exe。

>> 配置CETK通信分类

有两种方式，Platform Manager和WinSock

>> 配置CETK测试中WorkStation和Target Device的连接方式

       用来选择通信方式。

5> 分析测试结果

应该分析测试结果中Skip和Failed的测试Item。

弄清楚测试Item主要测试哪些内容有如下三种途径：

l         对于简单的测试Item，通过测试结果的Log信息就可以知道其在测试那些内容；

l         对于稍微复杂一点的Item，可以通过在测试项上右键选择Test Information，直接跳转到Platform Builder的help文档中进行查询，如下；

l         对于特别复杂的测试项，可以到Platform Builder安装目录下/PRIVATE/TEST搜索查询其测试源文件。

需要指出的是，并不是所有的Skipped和Failed测试Item都是由OEM厂商的Driver和OAL造成的，部分情况下是由Microsoft的测试代码本身的Bug引起，这个时候就需要根据测试源码来进行判断。

可以在修改完Microsoft的测试源码中的Bug后，重新编译并进行测试。编译的时候注意修改sources和头文件，因为Microsoft的很多CETK测试源码中的存在很多头文件没有加全的情况，而sources文件的错误更多，如果修改源码并进行编译，主要的工作就是在修改sources文件上。

从以往的测试经验和网上的评论来看，绝大部分的Failed Item是由OEM厂商添加的代码的Bug造成，而Skipped Item由Microsoft测试代码的Bug引起的情况相对多一点。我们可以只分析Failed Item，而对Skipped Item不用理会，除非出现大量的Skipped Item。

再者，通过CETK测试并不能说明OEM的代码由多么的正确，只能够说明其在基本功能没有问题，与系统的兼容性和及其可靠性方面基本符合要求。但是CETK测试并不能够模仿所有的用户行为，也不能模仿测试系统上PNP设备的兼容性，在性能测试方便CETK也比较少。

 

 

三．定制自己的CETK DLL（ADV）

1．编写自己的CETK DLL

1>  CETK DLL的结构

安装Platform Builder的时候，除了安装了测试用的DLL到路径<Platform Builder installation path>/Cepb/Wcetk/DDTK/<CPU>下，同时也将其源码安装到目录<Platform Builder安装目录>/WINCE500/PRIVATE/TEST下。

>> ShellProc接口的功能

       测试DLL可以有多个导出接口，但只有一个导出接口是必须的，即ShellProc函数。该函数包括很多分支，如下：

SHELLPROCAPI ShellProc(UINT uMsg, SPPARAM spParam) {     LPSPS_BEGIN_TEST    pBT;     LPSPS_END_TEST      pET;       switch (uMsg)     {     case SPM_LOAD_DLL:         Debug(TEXT("ShellProc(SPM_LOAD_DLL, ...) called"));           // If we are UNICODE, then tell Tux this by setting the following flag. #ifdef UNICODE         ((LPSPS_LOAD_DLL)spParam)->fUnicode = TRUE; #endif // UNICODE         g_pKato = (CKato*)KatoGetDefaultObject();         break;       case SPM_UNLOAD_DLL:         Debug(TEXT("ShellProc(SPM_UNLOAD_DLL, ...) called"));         break;       case SPM_SHELL_INFO:         Debug(TEXT("ShellProc(SPM_SHELL_INFO, ...) called"));           // Store a pointer to our shell info for later use.         g_pShellInfo = (LPSPS_SHELL_INFO)spParam;         break;       case SPM_REGISTER:         Debug(TEXT("ShellProc(SPM_REGISTER, ...) called"));         ((LPSPS_REGISTER)spParam)->lpFunctionTable = g_lpFTE; #ifdef UNICODE         return SPR_HANDLED | SPF_UNICODE; #else // UNICODE         return SPR_HANDLED; #endif // UNICODE       case SPM_START_SCRIPT:         Debug(TEXT("ShellProc(SPM_START_SCRIPT, ...) called"));         break;       case SPM_STOP_SCRIPT:         Debug(TEXT("ShellProc(SPM_STOP_SCRIPT, ...) called"));         break;       case SPM_BEGIN_GROUP:         Debug(TEXT("ShellProc(SPM_BEGIN_GROUP, ...) called"));         g_pKato->BeginLevel(0, TEXT("BEGIN GROUP: Passion_Memory_Test.DLL"));         break;       case SPM_END_GROUP:         Debug(TEXT("ShellProc(SPM_END_GROUP, ...) called"));         g_pKato->EndLevel(TEXT("END GROUP: Passion_Memory_Test.DLL"));         break;       case SPM_BEGIN_TEST:         Debug(TEXT("ShellProc(SPM_BEGIN_TEST, ...) called"));         // Start our logging level.         pBT = (LPSPS_BEGIN_TEST)spParam;         g_pKato->BeginLevel(             pBT->lpFTE->dwUniqueID,             TEXT("BEGIN TEST: /"%s/", Threads=%u, Seed=%u"),             pBT->lpFTE->lpDescription,             pBT->dwThreadCount,             pBT->dwRandomSeed);         break;       case SPM_END_TEST:         Debug(TEXT("ShellProc(SPM_END_TEST, ...) called"));         // End our logging level.         pET = (LPSPS_END_TEST)spParam;         g_pKato->EndLevel(             TEXT("END TEST: /"%s/", %s, Time=%u.%03u"),             pET->lpFTE->lpDescription,             pET->dwResult == TPR_SKIP ? TEXT("SKIPPED") :             pET->dwResult == TPR_PASS ? TEXT("PASSED") :             pET->dwResult == TPR_FAIL ? TEXT("FAILED") : TEXT("ABORTED"),             pET->dwExecutionTime / 1000, pET->dwExecutionTime % 1000);         break;       case SPM_EXCEPTION:         Debug(TEXT("ShellProc(SPM_EXCEPTION, ...) called"));         g_pKato->Log(LOG_EXCEPTION, TEXT("Exception occurred!"));         break;       default:         return SPR_NOT_HANDLED;     }       return SPR_HANDLED; }

       该函数并不需要去修改，但是也可以在这个函数中完成一些附加的功能，例如打印一些Log等等。对于理解整个测试DLL有用的分支解释如下：

l         SPM_REGISTER：TUX通过调用该接口获取测试DLL所支持的测试项，这个是最需要关注的一个分支；

l         SPM_BEGIN_GROUP：整个测试过程开始调用到；

l         SPM_BEGIN_TEST：在开始测试Item时调用到，具体的测试项编号由TUX指定，包含哪些测试项后续会进行说明。

l         SPM_END_TEST：在结束具体测试Item时调用到；

l         SPM_END_GROUP：整个测试过程结束调用到；

>> 具体的测试项

       前面已经提到，TUX通过调用ShellProc的SPM_REGISTER 分支来获取测试DLL所支的具体测试项，每个测试项都有一个编号。对于测试DLL来说，所有的测试Item及其编号记录在一个名称为g_lpFTE的数组中。

       该数组的内容如下：

#define BASE 1000[Passion1]    BEGIN_FTE[Passion2]      FTH("Read/Write All Sectors"   , 0 )     FTE(   "1 Sector at a time"    , 1,   1[Passion3] ,       BASE+  1[Passion4] , WriteAllSectors [Passion5] )     FTE(   "4 Sectors at a time"   , 1,   4,       BASE+  2, WriteAllSectors )     FTE(   "16 Sectors at a time"  , 1,  16,       BASE+  3, WriteAllSectors )     FTE(   "32 Sectors at a time"  , 1,  32,       BASE+  4, WriteAllSectors )     FTE(   "64 Sectors at a time"  , 1,  64,       BASE+  5, WriteAllSectors )     FTE(   "128 Sectors at a time" , 1, 128,       BASE+  6, WriteAllSectors )     FTE(   "5 Sectors at a time"   , 1,   5,       BASE+  7, WriteAllSectors )     FTE(   "13 Sectors at a time"  , 1,  13,       BASE+  8, WriteAllSectors )     FTE(   "129 Sectors at a time" , 1, 129,       BASE+  9, WriteAllSectors ) END_FTE

>> 编写自己测试DLL中需要修改的内容

       从上面有关测试DLL结构的描述中可以看到，用户只需要在g_lpFTE数组中添加自己的测试函数和测试编号以及测试参数，然后去实现自己的测试函数就可以了。

       如果对这些不是很熟悉的话，可以借助Platform Builder的向导来创建测试DLL，熟悉到一定程度后在已有的测试DLL基础上进行修改效率更高。

2> 编写自己的测试DLL

       Platform Builder提供了创建测试DLL的向导，可以根据该向导来创建测试DLL。

步骤如下：

l         选择FileàNew Project or File，打开创建向导窗口如下

       在窗口中选择WCE TUX DLL，并输入工程名称，注意工程名称不能包含空格。点击OK进入下一步。

l         在下面的弹出向导窗口中输入一些相关测试DLL的信息，并选择Next进入下一步。

l         在下面的弹出窗口中选择Next，进入下一步。

l         在接下来的弹出窗口中选择Release Type为CETK，然后选择Finish完成创建。

 

       如前边所说，接下来去修改FT.h中的g_lpFTE数组并实现具体的测试函数即可。

2．添加自己定制的测试DLL到CETK

       按照TUX接口的要求，编写好自己的测试DLL后，可以通过下面的步骤将其导入到CETK测试中。

l         选择Windows CE Test Kit主菜单中的TestsàUser Defined，打开下面的用户向导窗口：

l         点击选择下一步，将看到下面的窗口，选择Add a New Test

l         接下来将看到下面的弹出窗口，详细说明如下：

n         在Test Kit下拉框中可以选择将你要添加的测试放在哪个Test Kit下，系统中共有3个Test Kit

n         在Name of Test编辑框中，为自己的测试Item起一个名字，格式上没有任何要求，只要好记就行

n         在Tux Module中，选择供TUX调用的测试DLL，就是自己编写的DLL

n         在Command Line中，可以直接对向TUX传送的命令进行编辑，如下图中就对DLL中的101和102测试项进行测试。也可以采用默认的命令，默认的命令将根据测试DLL中提供的测试函数表格进行测试

n         Processor一栏中，用来对Target Device的CPU内核的类型进行选择，对于当前我们的项目，就选择ARMV4I

输入和选择完毕后，点击下一步

l         接下来将看到下面的窗口，可以在这里选择将测试DLL存放在哪里，选项解释如下：

n         Copy the files to the directory for user-defined tests：将测试DLL拷贝到系统预定义的用户测试DLL的路径下，即<Platform Builder installation path>/Cepb/Wcetk/User/<CPU>下。另外，Microsoft默认PB自带的测试DLL的路径是<Platform Builder installation path>/Cepb/Wcetk /DDTK/ /<CPU>，在这里你可以找到所有的自带的测试DLL；

n         Leave the file at current location：不改变存放DLL的路径，下次启动Windows CE Test Kit的时候，将不会再到这里去找User Defined的测试DLL；

所以，如果想将自己定制的测试永久添加到CETK中的话，应该选择第一个选项。

l         点击下一步，将看到如下窗口

l         选择下一步，看到如下窗口

l         选择完成，完成定制

 

3．运行自己定制的CETK测试项

       Windows CE Test Kit不会自动的将用户自定义的测试项更新Test Kit中，需要重新连接Target Device才可以在Test Kit中看到用户自定义的测试项。

       重新连接后，将在<用户选择的Test Kit>/User Tests下看到自定义的测试项，如下图：

       运行的方法和默认的测试项相同。

四．常见错误

1．连接Target Device错误

描述：

Tools下面的所有工具都不可用，并在启动连接的过程中出现下面的窗口：

原因：

       Platform Manager的连接方式配置不正确。

解决方法：

       选择Connection菜单下的Configure Windows CE Platform Manager选项，如下：      

       将看到如下窗口：

       选择Properties按钮，将看到如下的窗口：

       在这里选择你所使用的连接方式就可以了。

2．测试Item启动不成功

描述：

可以正确连接Target Device，但不能执行任何测试用例，会看到如下的弹出窗口：

原因：

Windows操作系统安装在C盘，而WinCE安装在其它逻辑盘下，导致测试的时候所需要的一些文件夹缺失。这应该是Microsoft的Bug造成的，可以通过拷贝特定文件夹的方式来进行Fix。

同时某些杀毒软件和防火墙也会造成这种问题。

解决方法：

将C:/Program Files/Windows CE Platform Builder/5.00/CEPB/wcetk目录下results和users目录拷贝到[安装WinCE500的逻辑盘符]:/Program Files/Windows CE Platform Builder/5.00/CEPB/WCETK目录下。

       同时建议将防火墙和杀毒软件关闭。

       有时候会碰到Windows CE Test Kit运行得时候提示找不到路径的情况，也是这种原因引起的，解决方法是将cetest.exe从System盘下拷贝到Platform Builder安装盘下。