一、概述
WindowsCE是Mirosoft公司推出的一款嵌入式系统，同时还推出了Platform Builder开发工具和CETK测试工具，再加上MS其他的开发和管理工具，使得技术开发和项目管理WindowsCE项目变得非常简便。目前WindowsCE以其良好的人机界面、丰富可靠的应用程序逐渐为厂家所接受，在无线通信、工业控制、电子消费类产品中，占有越来越多的市场份额。对于开发者来讲，MS为了开发方便，对于不同的CPU平台，提供了不同的参考模型，并在一定程度上开放了源代码，使开发者能够更多地控制操作系统，并能迅速地做出个性化的产品。特别是MS的开发工具和测试工具，大大降低了门槛，提高了工作效率，缩短了产品开发周期，减少了产品售后服务所带来的支出。考虑到WindowsCE的授权费用，在小批量生产的产品中，综合以上因素，使用WindowsCE的成本，并不得比使用其他操作系统高。
开发WindowsCE产品的最佳教材，就是MSDN。本文只是简单的描述了WindowsCE的一个基本开发和测试的过程，让大家对 WindowsCE的开发和测试，有一个大概的了解。
二、使用Platform Builder开发BSP
Platform Builder是Microsoft公司出品的，专门为开发WindowsCE嵌入式操作系统的集成开发环境。在该环境中，开发者可以使用丰富的工具，创建、裁减、调试目标操作系统。WindowsCE的开发过程大概可以分为：OAL、驱动、应用程序开发三个步骤。本文只是对OAL和驱动的开发过程做一个大概的介绍，对应用程序的开发不与讨论。
A、 WindowsCE结构介绍
在开发一个操作系统前，必须要对操作系统的层次结构有所了解。下图是WindowsCE的体系结构图。
在硬件之上，就是操作系统了。其中的kernel是MS提供的库，用于内存管理、进程、线程的调度等，是没有源代码的。而OEM Layer则是有参考模型和源代码的，Platform Builder也主要是用来开发OEM层。其中：
Bootloader：主要负责将编译好的映像文件放入内存中；
OEM Adaptation Layer（OAL）：负责对硬件进行初始化和连接Kernel部分；
Driver：负责对外围设备的驱动。
Platform Builder对一些标准硬件开发板提供了BSP（board support package），而这些标准板使用的是业界常用的CPU和外围设备。换句话说就是：对常用类型的CPU和外围设备，Platform Builder都提供了Bootloader、OAL、Driver的源代码，只要使用Platform Builder对已有的BSP进行剪裁和稍做修改，再加上MS提供的内核，就能驱动大多数的硬件设备。而且Platform Builder还提供了丰富的标准应用程序和服务程序，在开发好OEM层之后，再加上这些应用和服务，就能让用户的硬件平台工作起来。
当然，如果用户使用了自己设计的CPU或者外围硬件设备，开发过程要复杂的多。但是MS对OAL、驱动、Bootloader的开发步骤和接口，都有严格的定义。因此在MSDN的帮助下，再对照参考模型，这个过程往往比想象的简单多。
B、BSP的开发
在这里，假设有一块开发板，使用MIPSII的CPU，那么就可以利用Platform Builder提供的MIPSII开发板的BSP原型，迅速的生成自己的BSP。
在Platform Builder中，在菜单Platform中选BSP Wizard，弹出下图对话框。
选中“Clone an existing BSP”，因为AMD DBAu1500的体系结构是MIPSII的，因此在下拉列表中选取AMD DBAu1500，然后点“Next”。出现下图所示对话框。
每一个BSP都对应了一个cec文件。在该文件中记录了有关该开发扳的信息。比如CPU类型，开发板上有哪些外围设备，它们在系统使用的名称、GUID、全局变量等。因此也必须给新的BSP生成的cec文件起个名字。这里命名为NewBSP。单击“Next”。
这时出现Catalog Information对话框。在这个对话框中填入该BSP的显示名称，发行商名，和BSP描述即可。单击“Next”。
在Directory and CPU对话框中，为新生成的BSP选择路径和指定CPU类型。单击“Next”。此时弹出Customization对话框，如下图所示。
在这里，可以根据自己开发板上的外围设备进行，对BSP中的驱动进行调整，比如是否需要Bootloader等。该驱动列表是对应于某块DBAu1500开发板的外围设备的。如果自己的开发板上没有这些设备，则可以删除掉。如果自己的开发板上的设备型号和类型与列表中的不相符，可以选择添加（如果有第三方提供的驱动程序），也可以选择编辑已有驱动的方法。由于现在同一类型的设备大同小异，因此驱动结构也基本一样，那么为什么不利用已经有的驱动，发扬拿来主义的精神呢？单击“Next”，初步完成了一个新BSP。
下面的任务就是要对已经生成的BSP进行修改，以让其更加符合实际开发板的需求。办法很简单，在Platform Builder的File菜单中选取“New Platform”，创建一个新的工程。注意在创建的第三步，选择BSP的时候，要选择刚刚生成的NewBSP。其他步骤根据提示进行就可以了。
在Platform Builder内，根据开发板的实际情况，参考硬件说明书，对相应的设备驱动和OAL层进行修改。修改完毕后，编译并生成映像文件，就可以下载到硬件平台上进行调试和修改bug的工作了。
三、使用CETK进行测试
在提供了开发工具的同时，MS还提供了一整套测试工具，对用户创建的WindowsCE操作系统进行测试，这套工具就是Microsoft® Windows® CE Test Kit (CETK)。该工具将一系列基于命令行测试工具图形化，用来检验各个驱动程序是否正确。
CETK工具包括两部分，一部分是在开发平台（PC）上的服务器应用，一部分是在目标平台上的客户端应用。因此在使用CETK时，必须首先把客户端应用程序下载到目标机上。如何下载的办法很多，比如使用PB中的Remote File Viewer，或者使用FTP服务从客户端下载，或者使用CETK自带的Connection工具等。本文描述的场景是脱离BSP开发过程，直接面对一个已经开发完毕的目标平台，如何使用CETK进行测试。
A、 测试过程
对于一个已经开发好的目标平台进行CETK测试，首先要了解几点：
该目标平台上运行的Windows CE版本号是多少；
该目标平台的CPU结构是什么；
该目标平台中是否安装了CETK客户端；
该目标平台上都有哪些硬件设备，它们分别支持哪些特性；
因为不同的的Windows CE版本使用不同的CETK版本；另外不同的CPU类型使用不同的客户端。特别是CETK是一个硬件特性的全集，其中的一些硬件特性也许现有的硬件平台并不具备，因此必须了解清楚现有目标平台的特性再进行测试，以免引起不必要的麻烦。在了解清楚以上几点后，就可以进行CETK的测试了。
1、 准备测试环境：
既然CETK有服务器端和客户端，那么它们之间至少应该通过某一种技术手段，使之连接起来。目前对于绝大多数嵌入式设备来说，都具有至少一个网络设备。因此这里假设服务器端和客户端是通过局域网进行连接的。在测试开始前，需要通过服务器端和客户端的网络设置程序，将它们设置在同一个网段之内，可以互相访问。
2、 从开始菜单的Microsoft Windows CE组中启动Windows CE .NET Test Kit。
3、 下载并运行客户端软件：
如果现有的硬件平台中，并没有包含CETK客户端软件clientside.exe，那么必须通过某种方式下载到硬件平台上。该客户端软件在Windows CE 安装目录中。在了解目标机的CPU类型后，下载/WINCEROOT/OTHERS/WCETK/CPU type/clientside.exe到目标平台上。由于假设服务器和目标平台都在同一个局域网内，因此可以通过文件共享或者FTP等方式将其拷贝到目标机上。
下载完毕后，打开目标机的一个控制台（SHELL），进入clientside.exe所在目录，用命令行上输入：clientside.exe /n=服务器IP地址 /p=5555。
4、 设置测试项目：
在客户端运行了clientside后，过几秒钟后，在服务器的Windows CE .NET Test Kit中将显示出目标设备的名字及可检测单元。如下图所示。
CETK通过连接到客户端程序，自动获取目标设备上的设备信息，并自动确定可以测试的项目。从上图可以知道，该硬件设备不包含声卡、红外、鼠标设备等。可以测试的项目包括显卡、调制解调器等。因为硬件设备种类繁多，因此该硬件扫描在具体细节上不见得准确。比如显示卡如果不支持Direct3D功能，就不能进行该功能的测试。这也就是为什么用户必须事先知道目标设备的具体硬件信息的原因。
每个单独的设备都有一些可选的测试项，测试人员可以通过项目前的方框，选中或者取消一些项目的测试。
5、 设置测试命令行
如果要测试一个项目，先用鼠标选取该项目，然后点右键，将弹出一个菜单。在该项测试完毕前，菜单中的“View Results”选项是灰色的。选中“Edit Command Line”，将出现下图所示对话框。
CETK从本质上讲，其实就是一套完整的测试用例的集合，而每个测试用例都是一个应用程序。在测试过程中，所要测试的硬件特性，其实是对应于驱动程序中的某些函数调用。因此测试用例就是调用相关的驱动程序中的函数，并通过检测函数运行结果来判断驱动程序是否正确的。MS提供了CETK工具的同时，也提供了这样一套完备的测试用例。如果开发者使用了自己设计、或者是已有BSP中没有的设备，在测试该设备的时候，就需要测试人员根据设备的特性及驱动程序，自行编写测试用例。
下图显示的对话框是对网卡进行测试的命令行。
其中tux是一个32位的客户/服务器程序，负责测试动态链接库中的功能模块。对于不同的动态链接库及其中的模块，当然要使用不同的命令行。因此测试者在进行工作前，必须要Windows CE .NET Test Kit的帮助文档，了解不同模块和不同功能所对应的命令行。
6、 开始测试：
如果仅仅对选中的一个项目进行测试，则选中菜单中的“Quick Start”即可。如果要对所有选定的项目进行测试，则要在Windows CE .NET Test Kit的菜单中选Tests->Start/Stop tests。
有些测试不需要人工干预，程序会自动完成。但是有些测试（比如鼠标、键盘等），在测试过程中包含人机交互的部分。因此测试人员在测试过程中，需要根据目标设备屏幕上的提示，进行相应的动作。
7、 查看测试报告：
在测试完毕后，菜单中的View Results将自动处于允许状态，选中得以查看该模块的测试结果。
在CETKParser的显示区域被分成三个窗口，最上面的窗口显示了此模块检测的综合参数，中间窗口显示的是用于此模块测试的所有用例和最终结果。当选中其中一个用例时，在最下面的窗口中就会显示此用例的测试详细信息。上面论述过，测试用例其实就是调用驱动程序中的某些函数，因此通过分析失败的测试用例的代码，就可以初步确定失败在驱动的哪个函数中。将信息提供给开发者后，开发者再使用PB提供的调试工具，就能迅速定位和解决程序中的问题。
B、压力测试
使用CETK还可以进行压力测试。所谓的压力测试就是让目标平台工作在极限状态中的一种测试方法。通过压力测试，能发现目标平台一些单一测试不能发现的、隐藏很深的问题。在Windows CE .NET Test Kit的菜单中选other Test->Modular Stress Test，就可以进行压力测试。
压力测试的项目也是可选的。所进行压力测试的项目定义在 /Program Files/Windows CE Platform Builder/VERSION/cepb/wcetk/ddtk/armv4/oemstress.ini文件中。该文件的格式和内容一目了然，通过修改该文件，就能够确定进行压力测试的模块和项目。
进行完压力测试后，View Results显示界面与其他结果不同，是一个表格，由于版面和篇幅的关系，这里不把该图完全显示出来，只显示其中的一部分。在表格中，对开发者意义比较大的是“System Health”、“Modules Status”两表，如下图所示。从“System Health”中可以看到，在压力测试前内存使用了20%，在测试后，内存使用情况为33%，这说明在压力测试前后有内存的泄露。因此可以进一步判断，内存的泄露在压力测试中所使用的函数中。
而“Modules Status”中，是对各个模块进行压力测试的用例统计。