1. 项目概述与核心价值在嵌入式开发这个行当里尤其是基于Windows CE这类实时嵌入式操作系统最让人头疼也最耗时的环节往往不是功能实现而是后期的稳定性验证。一个板级支持包BSP写出来驱动能跑起来这只是万里长征第一步。真正的考验在于它能否在7x24小时不间断运行、在各种边界条件和异常场景下保持稳定。早年做项目测试基本靠“人肉”——手动点点屏幕插拔外设记录日志效率低不说还容易遗漏。后来接触到微软的Windows Embedded CE Test KitCETK才算是找到了一个系统化、自动化的解决方案。这套工具集特别是其核心的Tux测试框架和Kato日志引擎为BSP的单元测试和集成测试提供了标准化的“流水线”。今天要聊的就是如何将CETK这套“标准装备”应用到具体的硬件平台上这里以飞思卡尔现恩智浦经典的i.MX31 PDK开发板为例。i.MX系列处理器在工业控制、车载信息娱乐等领域应用广泛其BSP的稳定性至关重要。通过CETK我们可以对BSP中的关键驱动比如电源管理集成电路PMIC、显示、存储等进行批量化、可重复的测试。这不仅仅是跑几个测试用例那么简单其背后的技术价值在于它将测试过程从依赖个人经验的“手艺活”转变为了可追溯、可复现、可自动化的工程实践。对于团队协作和产品迭代来说这意味着更快的验证周期和更高的质量基线。无论你是刚接触Windows CE BSP开发的新手还是正在为项目寻找可靠测试方法的老兵理解并掌握CETK在具体平台上的应用都是一项非常值得投入的技能。2. CETK工具链深度解析与i.MX平台适配2.1 CETK架构核心三驾马车CETK不是一个单一的工具而是一个由多个协同工作的组件构成的测试生态系统。理解它的架构是高效使用它的前提。其核心可以概括为“三驾马车”Tux测试框架、Kato日志引擎和DDLX设备驱动加载器。Tux测试框架是测试任务的“调度中心”和“执行引擎”。它采用客户端/服务器C/S架构服务器端运行在开发主机Host上客户端则运行在目标设备Target即我们的i.MX31开发板上。Tux负责加载、管理和执行具体的测试模块这些模块通常以动态链接库DLL的形式存在。CETK提供了两个版本的Tux经典的Tux Test Harness用于本地代码测试和Tux.Net Test Harness用于托管代码/C#测试。对于BSP驱动测试我们主要与前者打交道。Tux的强大之处在于它定义了一套标准的测试接口任何符合该接口的DLL都可以被它识别和调度这为集成自定义测试提供了可能。Kato日志引擎是测试过程的“黑匣子”和“广播站”。在嵌入式测试中日志输出是定位问题的生命线。Kato提供了一个统一的日志接口所有测试用例都通过它来输出信息。它的设计非常灵活可以将日志同时路由到多个输出设备比如控制台、文件、甚至是网络上的远程服务器。在CETK的工作流中运行在目标设备上的测试DLL通过Kato接口输出日志Kato客户端将这些日志信息打包通过通信层如KITL发送回主机。主机上的CETK GUI或日志解析器CETK Parser则接收并可视化这些信息。这种设计将测试逻辑和日志输出解耦使得测试代码更清晰也便于集中管理测试结果。DDLXDevice Driver Loader and Tux Extender是一个关键但常被忽略的组件。它的作用是解决测试DLL的加载地址空间问题。默认情况下测试DLL会被加载到Tux进程的地址空间中。但对于一些需要直接操作硬件的底层驱动测试比如我们要做的PMIC测试测试代码可能需要在内核模式Kernel Mode下运行或者需要被加载到设备驱动宿主进程device.exe的地址空间中以获得更高的硬件访问权限。DDLX就是负责完成这个“搬家”工作的。它会创建一个特殊的进程来承载测试DLL或者将其注入到目标地址空间。在运行内核模式测试时我们使用的ktux.dll就是Tux的内核模式版本它通常需要与DDLX机制配合工作。2.2 i.MX平台通信层选择KITL vs ActiveSync要让主机上的CETK控制台与目标板“对话”必须建立可靠的通信连接。对于Windows CE平台CETK主要支持两种方式KITL和ActiveSync。在i.MX31 PDK平台上这两种方式都可用但适用场景和配置复杂度不同。KITLKernel Independent Transport Layer是微软为Windows CE内核调试和测试专门设计的通信协议。它需要在目标系统的操作系统镜像中预先启用并编译进去。对于i.MX31 BSP你需要在Platform Builder的Catalog中找到你的BSP勾选“KITL”相关组件通常位于Core OS - CEBASE - Applications - End User - Core OS Services - KITL下。使用KITL的优势非常明显无需额外软件只要镜像支持通过以太网或USB线具体取决于BSP配置连接后即可使用。内核级访问提供更底层的通信能力非常适合驱动和内核模块的测试。稳定性高作为系统级组件通信通常比较稳定可靠。 因此在开发测试阶段尤其是进行BSP单元测试时KITL是首选连接方式。在CETK中配置设备连接时选择“KITL Transport for Windows CE”作为传输层Transport并选择“KITL Bootstrap Server”作为启动服务器Startup Server。Microsoft ActiveSync在后续Windows Mobile/CE版本中演变为Windows Mobile设备中心是更上层的连接方式它通过USB或串口与设备上的ActiveSync客户端通信。它的配置相对简单只要在PC和目标设备上安装好ActiveSync并成功建立合作关系即可。在CETK中你需要新建一个设备配置选择“Microsoft Active Sync”作为传输层和启动服务器。ActiveSync更适合在操作系统完全启动并进入桌面后的应用层功能测试或者在不支持KITL的零售版镜像上进行测试。但对于需要早启动、深层次访问硬件的BSP测试其能力有限。实操心得在i.MX31 PDK的实测中强烈建议在开发调试阶段始终使用KITL。它不仅连接稳定还能与Platform Builder的调试器无缝协作。当你通过PB下载镜像并启动调试时KITL连接会自动建立此时再打开CETK选择默认的KITL设备连接成功率几乎是100%。而ActiveSync有时会因为设备休眠、连接超时等问题中断测试给长时间的自动化测试带来不确定性。2.3 CETK环境配置实战理解了核心组件和连接方式我们来一步步配置CETK环境。假设你已经为i.MX31 PDK定制好了包含KITL和CETK客户端组件的操作系统镜像并已成功下载到开发板上运行。安装CETK工具CETK是Platform Builder 6.0的一部分安装PB时会默认安装。你可以在Windows开始菜单的“Windows Embedded CE 6.0”程序组中找到“Windows Embedded CE 6.0 Test Kit”并启动它。配置设备连接首次启动CETK进入主界面后点击菜单栏的Connection-Start Client。这会弹出“Device Connection”窗口。点击窗口中的Settings...按钮打开“Windows CE Platform Manager Configuration”配置窗口。这里管理着所有可连接的目标设备。默认会有一个“Default Device”其属性通常已预设为使用KITL传输。为了清晰我们可以为其重命名为“iMX31_KITL”。确认其属性中Transport为“KITL Transport for Windows CE”Startup为“KITL Bootstrap Server”。如果你想同时配置ActiveSync备用可以点击Add Device新建一个名为“iMX31_ActiveSync”的设备并将其Transport和Startup均设置为“Microsoft Active Sync”。配置完成后关闭所有属性窗口。回到Device Connection窗口在“Device”下拉列表中你就可以选择刚才配置好的“iMX31_KITL”进行连接了。建立连接选择正确的设备名称点击Connect...。如果开发板镜像运行正常且KITL已启动CETK会尝试建立连接。连接成功后左侧的“Windows CE Test”树形列表将从灰色变为可用状态里面列出了所有可用的测试套件如Display, Storage, Audio等这些都是微软提供的标准测试。3. 编译与集成自定义BSP测试模块微软提供的标准测试套件覆盖面广但对于特定的硬件平台尤其是芯片厂商提供的特色外设如i.MX系列的PMIC、GPU、VPU等必须依赖厂商或开发者自己编写的自定义测试。飞思卡尔为其i.MX31 PDK BSP提供了PMIC测试的示例这是一个绝佳的学习模板。3.1 获取与理解测试源码通常自定义测试的源代码会随BSP包或SDK一同提供。对于i.MX31 PDKPMIC测试的源码位于BSP目录下的\WINCE600\PLATFORM\BSP_NAME\SRC\TEST或类似路径中也可能在单独的测试支持包内。示例文档中提到的路径是\WINCE600\SUPPORT\MX31\TESTS\PMIC。这个目录下一般会包含sources文件CEBuild工具使用的编译描述文件定义了源文件、目标类型DLL、依赖库等。*.cpp和*.h文件测试用例的具体实现代码。makefile文件可能存在的传统编译文件。打开测试代码你会发现它遵循Tux测试框架的规范。核心是实现一个或多个测试函数并使用特定的宏如TESTPROCAPI来声明最后通过一个导出函数如ShellProc来向Tux框架注册这些测试用例。测试函数内部会调用PMIC驱动的接口执行诸如读写寄存器、配置电源域、检查电压输出等操作并使用Kato日志接口如LOG宏输出每一步的结果和状态。3.2 编译测试DLL编译CE下的驱动测试DLL需要在Platform Builder的环境中进行。因为编译过程需要CE的系统头文件和库文件。打开构建环境在Platform Builder中打开你的i.MX31 PDK工程。从菜单栏选择Build OS-Open Release Directory。这会打开一个命令行窗口其中环境变量如_WINCEROOT都已设置好指向你的CE系统根目录。定位并编译# 切换到PMIC测试源码目录 cd \WINCE600\SUPPORT\MX31\TESTS\PMIC # 设置环境变量使得编译输出直接到Flat Release目录即最终镜像所在的目录 set WINCEREL1 # 执行清理并构建 build -cbuild -c命令会先清理clean之前的编译中间文件然后重新构建。编译成功后你会在工程的Release目录例如\WINCE600\OSDesigns\YourOSDesign\YourOSDesignRel\) 下找到生成的pmictest.dll文件。注意事项编译时务必确保你为当前Active Platform选择的CPU类型如ARMV4I与测试代码和目标设备匹配。set WINCEREL1这个步骤很关键它保证了DLL被复制到扁平化的Release目录方便我们后续将其加入到镜像或手动复制到设备。3.3 准备内核模式测试环境许多硬件底层测试包括这个PMIC测试需要在内核模式下运行以获得对硬件寄存器的直接访问权限。这带来一个额外的步骤准备内核模式的Tux。定位ktux.dll标准的tux.exe和其依赖的DLL运行在用户模式。内核模式测试需要特殊的ktux.dll。这个文件通常不在默认的Release目录中。你需要在Platform Builder的安装目录下寻找它路径通常是\Program Files\Microsoft Platform Builder\6.00\cepb\wcetk\ddtk\CPU_TYPE\对于i.MX31ARM11CPU类型是armv4i。所以完整路径可能是\Program Files\Microsoft Platform Builder\6.00\cepb\wcetk\ddtk\armv4i\ktux.dll。复制必要文件为了运行测试你需要将以下文件从上述系统目录复制到你的工程Release目录即和pmictest.dll同一个目录ktux.dll内核模式Tuxkato.dllKato日志引擎可能需要的其他运行时库根据测试DLL的依赖但通常CE的Release目录已包含基本系统DLL。避坑技巧直接复制ktux.dll是最简单的方法。另一个更规范的做法是在Platform Builder的Catalog中找到“Windows Embedded CE Test Kit”组件查看其子项看是否有“Kernel Mode Tux”相关的可选组件并将其加入你的OS设计然后重新Sysgen。这样ktux.dll会被自动包含进镜像。但对于快速测试和验证手动复制更为灵活。4. 执行测试命令行与图形界面双路径一切准备就绪后就可以在目标设备上执行测试了。有两种主要方式通过Platform Builder的Target Control命令行或者通过CETK图形界面。两者各有优劣。4.1 使用Target Control命令行执行这种方式直接、快速适合开发者快速迭代和调试单个测试模块。建立连接确保你的i.MX31设备通过KITL与Platform Builder连接成功PB底部状态栏显示“Connected”。打开Target Control在Platform Builder中点击菜单Target-Target Control。这会打开一个CE命令提示符窗口你可以在这里向设备发送Shell命令。执行测试命令在命令窗口中输入以下命令s tux -o -n -d pmictest.dlls是Target Control的“shell”命令前缀表示在设备上执行后面的命令。tux这里实际调用的是我们复制到设备上的ktux.dll通过之前的设置系统会关联.dll到ktux来执行内核模式测试。如果调用的是用户模式的tux.exe则直接写tux。-o表示执行完测试后退出Tux。-n关键参数指定测试在内核模式下运行。-d pmictest.dll指定要加载和运行的测试DLL名称。查看结果命令执行后测试过程的所有Kato日志输出会实时显示在Platform Builder的“Output”窗口通常选择“Target”或“Debug”视图中。你可以看到每个测试用例的通过/失败状态、详细的调试信息和可能的错误信息。这种方式输出信息最原始也最全面便于深度调试。4.2 使用CETK图形界面执行这种方式更图形化、更结构化适合管理多个测试、生成标准化的测试报告以及非开发人员如测试工程师执行测试。添加自定义测试到CETK库打开CETK应用程序。点击菜单Tests-User defined...启动“User-defined test wizard”。选择“Add a New Test”点击下一步。在“Add”页面填写测试名称如“iMX31 PMIC Unit Test”点击“Browse”定位到你的pmictest.dll文件注意这里浏览的是开发主机上的路径CETK会在执行时自动将其传输到设备。处理器类型选择“ARM4I”。点击“Finish”。向导可能会问你是否将DLL复制到CETK目录选择“是”可以方便以后使用。配置测试命令添加的测试默认命令可能不包含内核模式参数。在CETK主界面左侧的“Windows CE Test”树中展开“User Test”文件夹找到你刚添加的“iMX31 PMIC Unit Test”。右键点击该测试选择“Edit Command Line”。将命令修改为tux -o -n -d pmictest.dll。确保勾选“Set this change permanently”以保存。这个步骤至关重要它告诉CETK使用正确的参数来调用测试。连接设备并运行按照之前所述通过Connection-Start Client并选择你的KITL设备建立CETK与目标板的连接。连接成功后在测试树上右键点击“iMX31 PMIC Unit Test”选择“Quick Start”。CETK会自动将测试DLL传输到设备启动Tux执行测试并开始接收Kato日志。查看与分析结果实时输出测试运行时日志会显示在CETK底部的输出窗口中。结果解析测试结束后点击菜单Tests-View Results...可以打开CETK Parser。这是一个更强大的日志分析工具它能以结构化的方式展示测试套件、测试用例的层次关系并用颜色绿色/红色清晰标记通过/失败的用例。你可以导出这些结果为文本或XML格式用于生成正式的测试报告。实操心得对比Target Control优势是极简、直接与PB调试环境集成度高输出信息实时且完整适合开发阶段“边改边测”。缺点是缺乏测试用例管理结果需要人工解析。CETK GUI优势是测试管理能力强可以方便地组织测试套件、重复执行、对比历史结果图形化结果更直观适合回归测试和版本发布前的系统化验证。缺点是配置稍复杂且对于深度的调试信息有时不如命令行窗口查看方便。 在实际项目中我通常两者结合使用开发调试阶段用Target Control快速验证功能稳定后将测试用例整合到CETK中作为每日构建Daily Build或版本发布自动化测试的一部分。5. 运行微软标准测试套件与测试策略除了自定义测试充分利用微软提供的庞大标准测试套件是验证BSP基础功能的捷径。这些测试涵盖了存储、显示、音频、网络、输入等核心领域。5.1 执行标准测试示例DirectDraw测试以“Display”目录下的“DirectDraw Test”为例这是一个测试显示驱动DirectDraw接口兼容性和性能的套件。前提确保你的OS镜像包含了“Windows Embedded CE Test Kit”组件并且目标设备已通过KITL与CETK连接成功。定位测试在CETK左侧的“Windows CE Test”树中展开“Display”文件夹。运行测试右键点击“DirectDraw Test”选择“Quick Start”。CETK会自动处理一切定位对应的测试DLL、传输到设备、执行并收集结果。结果分析同样可以通过CETK Parser查看详细的图形化结果。DirectDraw测试会包含多个子测试如表面创建、位块传输、颜色填充、翻转链测试等。任何失败项都会直接指向显示驱动可能存在的问题区域。5.2 构建系统化的BSP测试策略单纯地运行几个测试意义有限将CETK融入开发流程才能最大化其价值。一个有效的BSP测试策略可以这样规划冒烟测试Smoke Test在每次新的BSP代码提交或每日构建后自动执行一组最核心、最快的测试。例如基本的PMIC电源状态测试、时钟初始化测试、内存控制器自检等。这可以快速发现重大阻断性问题。可以利用CETK的命令行工具cetest编写脚本实现自动化。功能测试Functional Test对BSP的每个主要驱动模块进行深入测试。例如显示驱动运行全部的DirectDraw, GDI, OpenGL ES如果支持测试套件。存储驱动运行FAT/FAT32文件系统测试、SD/MMC卡读写测试、ATA/Flash驱动测试。音频驱动运行WaveAPI测试验证录音、播放、混音功能。网络驱动运行NDIS、TCP/IP协议栈一致性测试。输入驱动运行触摸屏校准、键盘、鼠标测试。 这部分测试可以按模块在CETK中创建不同的测试计划Test Plan定期手动或自动执行。压力与稳定性测试Stress Stability Test选择关键测试用例让其长时间循环运行CETK支持设置迭代次数。例如让PMIC测试连续运行24小时频繁切换电源模式让显示测试循环执行数千次位块传输。目的是发现内存泄漏、资源耗尽、偶发性死机等深层问题。自定义驱动验证对于芯片厂商提供的特色驱动如i.MX的VPU视频编解码驱动、GPU 3D加速驱动需要根据驱动API编写特定的验证测试并集成到CETK框架中。方法就和前面编译PMIC测试一样遵循Tux框架规范。常见问题与排查测试DLL无法加载检查DLL是否已正确复制到设备文件系统如\Windows目录。在Target Control中使用ls命令查看。确认DLL的CPU架构ARMV4I与设备匹配。检查依赖的系统DLL是否都存在。测试执行无响应或报错首先在Target Control中运行查看最原始的Kato错误输出。常见原因包括测试代码访问了未初始化的硬件、内存地址错误、测试需要的内核模式权限不足未使用-n参数或未用ktux.dll。CETK连接失败确认目标设备镜像已启用KITL并正常启动。在PB中确认调试连接正常。检查CETK设备配置中的传输层Transport设置是否正确。尝试重启CETK服务和目标设备。测试结果不明确善用CETK Parser的过滤和搜索功能。关注“FAIL”和“WARN”级别的日志。对比测试代码中的预期输出和实际输出定位第一个出现偏差的地方。将CETK与持续集成CI系统如Jenkins结合可以实现BSP测试的完全自动化。通过脚本控制CETK命令行工具执行测试计划解析输出的XML结果文件并生成测试报告邮件。这样任何代码回归都能被快速捕捉真正让测试成为保障嵌入式软件质量的坚实防线。从手动点灯到自动化测试这一步的跨越带来的不仅是效率的提升更是工程可靠性的质变。